diff --git a/.gitignore b/.gitignore index 9c788a9..94b3bb9 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,6 @@ .obsidian/ CLAUDE.md research/ +agents/ +scripts/ +templates/ diff --git a/README.md b/README.md index a82a03b..36dd807 100644 --- a/README.md +++ b/README.md @@ -58,10 +58,12 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | ID | Title | Tier | Funding | Status | Category | Submit Proposal | |---------|----------------------------------------------------------------------------|------|---------|--------|------------------------------------|-------------------------------------------------------------------------------------| -| RFP-001 | [Admin Authority](RFPs/RFP-001-admin-authority-poc.md) | XS | $XXXXX | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-002 | [Freeze Authority](RFPs/RFP-002-freeze-authority-poc.md) | XS | $XXXXX | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | $TBD | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-001 | [Admin Authority Library](RFPs/RFP-001-admin-authority-lib.md) | XS | $XXXXX | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | $XXXXX | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | $TBD | draft | Applications & Integrations | — | | RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-015 | [Token Launchpad: Bonding Curve](RFPs/RFP-015-bonding-curve-launchpad.md) | L | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-012 | [Advanced Lending Features](RFPs/RFP-012-advanced-lending-features.md) | L | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | diff --git a/RFPs/RFP-000-template.md b/RFPs/RFP-000-template.md index 0f7b6d4..06aec13 100644 --- a/RFPs/RFP-000-template.md +++ b/RFPs/RFP-000-template.md @@ -89,6 +89,13 @@ Standard requirements (adapt as needed): 5. A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and mini-app. +6. Provide a privacy and anonymisation properties document covering: + what on-chain state and transaction data is visible to observers; + what data is protected when the private account path is used; + trust assumptions, specifying which guarantees are enforced by + the on-chain program and which depend on correct client + behaviour; and what happens if a user bypasses the expected + interaction path. ### Soft Requirements diff --git a/RFPs/RFP-001-admin-authority-lib.md b/RFPs/RFP-001-admin-authority-lib.md new file mode 100644 index 0000000..4f4a712 --- /dev/null +++ b/RFPs/RFP-001-admin-authority-lib.md @@ -0,0 +1,113 @@ +--- +id: RFP-001 +title: Admin Authority Library +tier: XS +funding: $XXXXX +status: open +category: Developer Tooling & Infrastructure +--- + + +# RFP-001 — Admin Authority Library + +## 🧭 Overview + +Build a reusable library that provides standardised access control for LEE +programs, where privileged functions, including the ability to transfer or +renounce authority, can only be called by an admin authority. + +The library must be integrated into the SPEL framework and ship with +documentation and usage examples so teams can enable the pattern with +minimal boilerplate. + +## 🔥 Why This Matters + +As the Logos ecosystem grows, programs deployed on LEZ need foundational +security primitives from day one. Without standardised access control, +every team must design their own — leading to inconsistent implementations, +duplicated effort, and a higher risk of critical vulnerabilities. + +Delivering this as a shared library lowers the barrier for developers building +on LEE. Teams can focus on application logic rather than re-inventing admin +authority patterns, accelerating the pace at which new programs ship. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Admin authority is set at program initialisation. +2. Admin authority can transfer admin authority to a new signer. +3. Admin authority can revoke admin authority, effectively renouncing + admin control. +4. Admin authority is the only one that can call privileged instructions + exposed by the library (demonstrated via a gated `config` PDA update). + +#### Usability + +1. The library is integrated into the [SPEL framework](https://github.com/logos-co/spel) + so that programs using SPEL can enable admin authority with minimal + boilerplate — ideally a single annotation or configuration flag. +2. There can only be one admin authority (signer) at a time. +3. Documentation includes at least one end-to-end usage example showing + how a SPEL program gates its own instructions behind the admin authority. + +#### Performance + +No compute budget constraints are expected for this library. Document the +additional transaction size overhead introduced by the admin authority +check on any gated instruction. + +#### Supportability + +1. CI must be green on the default branch. +2. Every hard requirement in Functionality, Usability, and Reliability has + at least one corresponding test. +3. A README documents how to add the library as a dependency and integrate + it into a SPEL program, including a step-by-step example. +4. A sample program that imports the library is included to validate the + integration path and serve as a reference for consumers. + +### Soft Requirements + +If possible. + +#### Reliability + +1. Admin authority can only be set to a valid new signer (on-curve key + or deployed PDA), when set or initialised. + +## 👤 Recommended Team Profile + +Developer experienced with: + +- Solana or SVM program development (Anchor or native) +- Access control and authority patterns in on-chain programs +- PDA derivation and account validation +- Writing and running on-chain tests (e.g. Bankrun, Anchor tests) +- Library/crate packaging and documentation + +## ⏱ Timeline Expectations + +Estimated duration: **4 weeks** + + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 License**. + + +## Resources + +- [SPEL framework](https://github.com/logos-co/spel) +- TODO: LEE official doc + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, +please use **Discussions**. diff --git a/RFPs/RFP-001-admin-authority-poc.md b/RFPs/RFP-001-admin-authority-poc.md deleted file mode 100644 index 071d03e..0000000 --- a/RFPs/RFP-001-admin-authority-poc.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -id: RFP-001 -title: Admin Authority -tier: XS -funding: $XXXXX -status: open -category: Developer Tooling & Infrastructure ---- - - -# RFP-001 — Admin Authority - -## 🧭 Overview - -Build a proof-of-concept that demonstrates access control on an LEE program, -where privileged functions, including the ability to transfer or renounce -authority, can only be called by an admin authority. - -This is particularly useful during early-stage program development and testing, -where the ability to change specific parameters can help iterate on the program, -and potentially prevent exploits from causing lasting damage. - -This RFP targets a standalone PoC to validate the approach. A follow-up RFP -will be issued to package the pattern into a reusable developer library for -the Logos ecosystem. - -## 🔥 Why This Matters - -As the Logos ecosystem grows, programs deployed on LEZ need foundational -security primitives from day one. Without standardised access control, -every team must design their own — leading to inconsistent implementations, -duplicated effort, and a higher risk of critical vulnerabilities. - -Establishing these patterns early lowers the barrier for developers building -on LEE. Teams can focus on application logic rather than re-inventing admin -authority patterns, accelerating the pace at which new programs ship. A proven -PoC also gives the ecosystem a reference implementation that builds confidence -among developers and users alike — demonstrating that LEE programs can be -managed and secured with the same rigour expected in mature smart contract -environments. - -## ✅ Scope of Work - -### Hard Requirements -#### Functionality -1. Admin authority is set at program initialisation. -2. Admin authority can transfer admin authority to a new signer. -3. Admin authority can revoke admin authority, effectively renouncing - admin control. -4. Admin authority is the only one that can set a specific value on the - unique `config` PDA used by the program (sample value to demonstrate - gated access). -#### Usability -1. There can only be one admin authority (signer) at a time. -#### Supportability -1. Demonstrated as a sample app; the program's core functionality does - not matter — the focus is on the admin authority pattern. -### Soft Requirements -If possible. -#### Reliability -1. Admin authority can only be set to a valid new signer (on-curve key - or deployed PDA), when set or initialised. - -## 👤 Recommended Team Profile - -Developer experienced with: - -- Solana or SVM program development (Anchor or native) -- Access control and authority patterns in on-chain programs -- PDA derivation and account validation -- Writing and running on-chain tests (e.g. Bankrun, Anchor tests) - -## ⏱ Timeline Expectations - -Estimated duration: **2 weeks** - - -## 🌍 Open Source Requirement - -All code must be released under the **MIT+Apache2.0 dual License**. - - -## Resources - -TODO: LEE official doc - -## ✏️ How to Apply - -👉 Submit a proposal using the Issue form: - -**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** - -We typically respond within **14 days**. For clarification questions, -please use **Discussions**. diff --git a/RFPs/RFP-002-freeze-authority-lib.md b/RFPs/RFP-002-freeze-authority-lib.md new file mode 100644 index 0000000..f50cada --- /dev/null +++ b/RFPs/RFP-002-freeze-authority-lib.md @@ -0,0 +1,123 @@ +--- +id: RFP-002 +title: Freeze Authority Library +tier: XS +funding: $XXXXX +status: open +category: Developer Tooling & Infrastructure +--- + + +# RFP-002 — Freeze Authority Library + +## 🧭 Overview + +Build a reusable library that provides a standardised freeze mechanism for +LEE programs, allowing an authorised account to disable all (or selected) +interactions as a circuit breaker when an issue is discovered. + +The library must be integrated into the SPEL framework and ship with +documentation and usage examples so teams can enable the pattern with +minimal boilerplate. + +## 🔥 Why This Matters + +As the Logos ecosystem grows, programs deployed on LEZ need foundational +security primitives from day one. Without a standardised emergency stop +mechanism, every team must design their own — leading to inconsistent +implementations, duplicated effort, and a higher risk of critical +vulnerabilities. + +Delivering this as a shared library lowers the barrier for developers +building on LEE. Teams can focus on application logic rather than +re-inventing freeze patterns, accelerating the pace at which new programs +ship. As more programs begin handling real value, the ability to freeze a +compromised program is the difference between a contained incident and a +catastrophic loss. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Freeze authority can be set at program initialisation. +2. Freeze authority can be changed by admin authority. +3. Freeze authority can freeze the program, rejecting any attempt to interact + with it; apart from unfreezing or changing the freeze authority. +4. Freeze authority can un-freeze the program, re-enabling interactions. +5. Freeze authority can be revoked by admin authority. +6. Freeze authority can freeze a specific account by `AccountId`, preventing + it from interacting with the program while leaving the rest of the program + operational. +7. Freeze authority can un-freeze a specific account, re-enabling its + interactions with the program. + +#### Usability + +1. The library is integrated into the [SPEL framework](https://github.com/logos-co/spel) + so that programs using SPEL can enable freeze authority with minimal + boilerplate — ideally a single annotation or configuration flag. +2. There can only be one freeze authority (signer) at a time. +3. Documentation includes at least one end-to-end usage example showing + how a SPEL program integrates the freeze check. + +#### Performance + +No compute budget constraints are expected for this library. Document the +additional transaction size overhead introduced by the freeze check on any +gated instruction. + +#### Supportability + +1. CI must be green on the default branch. +2. Every hard requirement in Functionality, Usability, and Reliability has + at least one corresponding test. +3. A README documents how to add the library as a dependency and integrate + it into a SPEL program, including a step-by-step example. +4. A sample program that imports the library is included to validate the + integration path and serve as a reference for consumers. + +### Soft Requirements + +If possible. + +#### Reliability + +1. Freeze authority can only be set to a valid new signer (on-curve key + or deployed PDA), when set or initialised. + + +## 👤 Recommended Team Profile + +Developer experienced with: + +- Solana or SVM program development (Anchor or native) +- Access control and authority patterns in on-chain programs +- PDA derivation and account validation +- Writing and running on-chain tests (e.g. Bankrun, Anchor tests) +- Library/crate packaging and documentation + +## ⏱ Timeline Expectations + +Estimated duration: **4 weeks** + + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 License**. + + +## Resources + +- [SPEL framework](https://github.com/logos-co/spel) +- TODO: LEE official doc + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, +please use **Discussions**. diff --git a/RFPs/RFP-002-freeze-authority-poc.md b/RFPs/RFP-002-freeze-authority-poc.md deleted file mode 100644 index e1871fc..0000000 --- a/RFPs/RFP-002-freeze-authority-poc.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -id: RFP-002 -title: Freeze Authority -tier: XS -funding: $XXXXX -status: open -category: Developer Tooling & Infrastructure ---- - - -# RFP-002 — Freeze Authority - -## 🧭 Overview - -Build a proof-of-concept that demonstrates the ability to *freeze* an LEE -program, disabling all (or selected) interactions. This acts as a circuit -breaker; an emergency stop mechanism that an authorised account can trigger -when an issue is discovered. - -This is particularly useful during early-stage program development and testing, -where the ability to halt interactions quickly can prevent exploits from causing -lasting damage. - -This RFP targets a standalone PoC to validate the approach. A follow-up RFP -will be issued to package the pattern into a reusable developer library for -the Logos ecosystem. - -## 🔥 Why This Matters - -As the Logos ecosystem grows, programs deployed on LEZ need foundational -security primitives from day one. Without standardised emergency stop mechanism, -every team must design their own — leading to inconsistent implementations, -duplicated effort, and a higher risk of critical vulnerabilities. - -Establishing these patterns early lowers the barrier for developers building -on LEE. Teams can focus on application logic rather than re-inventing admin -and freeze authority patterns, accelerating the pace at which new programs -ship. A proven PoC also gives the ecosystem a reference implementation that -builds confidence among developers and users alike — demonstrating that LEE -programs can be managed and secured with the same rigour expected in mature -smart contract environments. - -This is a prerequisite for safe experimentation: as more programs are deployed -and begin handling real value, the ability for an authority to freeze a -compromised program is the difference between a contained incident and a -catastrophic loss. - -## ✅ Scope of Work - -### Hard Requirements -#### Functionality -1. Freeze authority can be set at program initialisation. -2. Freeze authority can be changed by admin authority. -3. Freeze authority can freeze the program, rejecting any attempt to interact - with it; apart from unfreezing or changing the freeze authority. -4. Freeze authority can un-freeze the program, re-enabling interactions. -5. Freeze authority can be revoked by admin authority. -#### Usability -1. There can only be one freeze authority (signer) at a time. -#### Supportability -1. Demonstrated as a sample app; the program's core functionality does - not matter — the focus is on the freeze pattern. - -### Soft Requirements -If possible. -#### Reliability -1. Freeze authority can only be set to a valid new signer (on-curve key - or deployed PDA), when set or initialised. - -### Out-of-scope - -Note that due to the privacy properties of LEE, it is not possible to freeze actions for a given signer/account. Hence, such a feature is not expected. Freezing is expected to be agnostic to the signers or initiators of a transaction. -## 👤 Recommended Team Profile - -Developer experienced with: - -- Solana or SVM program development (Anchor or native) -- Access control and authority patterns in on-chain programs -- PDA derivation and account validation -- Writing and running on-chain tests (e.g. Bankrun, Anchor tests) - -## ⏱ Timeline Expectations - -Estimated duration: **2 weeks** - - -## 🌍 Open Source Requirement - -All code must be released under the **MIT+Apache2.0 dual License**. - - -## Resources - -TODO: LEE official doc - -## ✏️ How to Apply - -👉 Submit a proposal using the Issue form: - -**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** - -We typically respond within **14 days**. For clarification questions, -please use **Discussions**. diff --git a/RFPs/RFP-008-lending-borrowing-protocol.md b/RFPs/RFP-008-lending-borrowing-protocol.md index 665c6e3..74276c4 100644 --- a/RFPs/RFP-008-lending-borrowing-protocol.md +++ b/RFPs/RFP-008-lending-borrowing-protocol.md @@ -376,7 +376,8 @@ All code must be released under the **MIT+Apache2.0 dual License**. ## Resources -- [RFP-001 — Admin Authority](/RFPs/RFP-001-admin-authority-poc.md) — reference pattern for admin-gated operations (F8, F11) +- [RFP-001 — Admin Authority Library](/RFPs/RFP-001-admin-authority-lib.md) +- [RFP-002 — Freeze Authority Library](/RFPs/RFP-002-freeze-authority-lib.md) - TODO: LEE official doc - TODO: Oracle integration guide for LEZ - TODO: SPEL framework documentation diff --git a/RFPs/RFP-012-advanced-lending-features.md b/RFPs/RFP-012-advanced-lending-features.md index 4872bd1..40e89c7 100644 --- a/RFPs/RFP-012-advanced-lending-features.md +++ b/RFPs/RFP-012-advanced-lending-features.md @@ -210,7 +210,8 @@ All code must be released under the **MIT+Apache2.0 dual License**. ## Resources - [RFP-008 — Lending & Borrowing Protocol](./RFP-008-lending-borrowing-protocol.md) -- [RFP-001 — Admin Authority](./RFP-001-admin-authority-poc.md) — reference pattern for admin-gated operations (F2, F3, F5) +- [RFP-001 — Admin Authority Library](./RFP-001-admin-authority-lib.md) +- [RFP-002 — Freeze Authority Library](./RFP-002-freeze-authority-lib.md) - TODO: Oracle integration guide for LEZ - TODO: SPEL framework documentation diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md new file mode 100644 index 0000000..8cca6cb --- /dev/null +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -0,0 +1,620 @@ +--- +id: RFP-015 +title: Privacy-Preserving Token Launchpad: Bonding Curve +tier: L +funding: $XXXXX +status: open +dependencies: See Platform Dependencies section +category: Applications & Integrations +--- + + +# RFP-015: Privacy-Preserving Token Launchpad: Bonding Curve + +## 🧭 Overview + +Build a bonding curve token launchpad on LEZ, using a supply-driven pricing +mechanism where token price increases deterministically as a function of +tokens remaining in the curve. Unlike the time-driven LBP mechanism in +[RFP-016](./RFP-016-lbp-launchpad.md), a bonding curve's price +progression is supply-driven: price advances with each purchase. Participants can buy tokens directly from a public account +or, for privacy, via a deshield→buy→re-shield pattern (see +[RFP-008](./RFP-008-lending-borrowing-protocol.md), which defines this +interaction model for LEZ applications): when a private account is +used, each purchase is routed through a fresh, single-use public +account, hiding the link between the buyer's private identity and their +participation in the sale. + +The bonding curve launchpad complements [RFP-016](./RFP-016-lbp-launchpad.md): where LBPs reward +patient buyers (price falls over time unless buying pressure +counteracts it), bonding curves reward early believers (price rises +with each purchase). The two mechanisms suit different project profiles, +and together they give the Logos ecosystem a complete token launch +toolkit. + +## 🔥 Why This Matters + +Bonding curves are one of the most proven token distribution mechanisms +in DeFi. pump.fun surpassed $1B in daily trading volume on Solana using a +constant-product bonding curve, demonstrating that the model scales and +attracts broad community participation. Meteora's Dynamic Bonding Curve +is a leading open-source SVM launchpad primitive, used in +production by multiple projects. Beyond Solana, the constant-product +model underpins Uniswap, Balancer, and virtually every major AMM; the +formula is the most audited and best-understood pricing primitive in +DeFi. + +## 🏗 Design Rationale + +### Constant product AMM with virtual reserves + +The recommended pricing mechanism is the **constant product AMM with +virtual reserves**, as used by pump.fun and Meteora's Dynamic Bonding +Curve. It is preferred over alternatives (polynomial integral curves, +Bancor power function) for three reasons: it is proven at scale on +Solana; the implementation requires only multiplication and division, +with no fixed-point exponentiation or approximation, making it +straightforward to audit; and correctness reduces to a single invariant +that any reviewer can check. The full formula specification is in the +Reference Implementation section. Teams may propose alternative +mechanisms under the deviation standard described there. + +### Supply-driven close over time-driven close + +The bonding curve's canonical close condition is a **supply target**: +the sale ends when all `D` sale tokens have been purchased. A supply +target defines the sale's complete economic trajectory at creation time: +the starting price, the price at any given supply point, and the +total collateral raised at graduation are all computable before the +sale opens. This gives buyers a calculable price ceiling and gives the +project a predictable raise range. + +A time-based close creates a weaker invariant: if buying stops early, +the sale ends with unsold supply and no clear clearing price. +Supply-based close avoids this. No bonding curve platform in the +ecosystem implements time-based close; all use supply or price +targets exclusively (see the +[Sale Lifecycle](../appendix/token-launchpad-ecosystem.md#sale-lifecycle-and-close-mechanics) +section of the appendix). An optional end timestamp is available as +a soft requirement for projects that need a hard deadline. + +### Two-way curve + +The bonding curve supports both buy and sell operations, matching +the ecosystem standard established by Pump.fun. Participants can +buy tokens from the curve and sell them back at the current AMM +price. The sell formula is the inverse of the buy formula (see +Reference Implementation). This provides continuous liquidity +during the sale window: participants who want to exit can do so +at market price without waiting for graduation and DEX listing. + +The two-way design introduces reflexive sell pressure during the +sale: if early buyers sell back into the curve, the price drops, +potentially discouraging new participants. Projects that want to +prevent this dynamic can use the optional one-directional mode +(see Soft Requirements), which disables selling during the sale +window. + +### Public pool state + +All bonding curve state is public on-chain: virtual reserve values, +invariant `k`, real reserve balances, current spot price, +open/closed status. As with [RFP-016](./RFP-016-lbp-launchpad.md), +this is a deliberate architectural choice. Public state enables +permissionless price verification (any participant can verify +`tokens_out` against the formula independently), composability with +other LEZ programs, and verifiable sale analytics without +cryptographic complexity in the curve program itself. Participant +privacy is enforced at the UX layer via the optional +deshield→buy→re-shield pattern, which does not require private pool +state. + +### Fee structure + +This RFP does not mandate a specific fee rate. Proposals must +specify: (1) who pays the fee (issuer, buyer, or both), (2) when +fees are collected (per-transaction, at sale close, or both), +(3) the fee rate or rate range, and (4) where fees are routed +(protocol treasury, sale creator, burn, or other destination). See +the [Fee Structures](../appendix/token-launchpad-ecosystem.md#fee-structures) +section of the token launchpad ecosystem appendix for a +cross-platform comparison of fee models across seven surveyed +protocols. + +### Bonding curves and LBPs as complementary mechanisms + +The Logos ecosystem provides both a bonding curve launchpad (this RFP) +and an LBP launchpad ([RFP-016](./RFP-016-lbp-launchpad.md)). The two +mechanisms are not redundant: they suit different project profiles and +together provide a complete token launch toolkit. + +A bonding curve rewards early participation with a lower entry price +and provides a fully deterministic, supply-driven price trajectory. The +complete economic outcome is computable before the sale opens: starting +price, price at any supply point, and total collateral at graduation +are all known in advance. Graduation to a DEX pool is natural, since +the virtual reserve model accumulates both token and collateral reserves +in the correct ratio throughout the sale. This suits projects that want +to reward early believers, need a transparent and auditable price +formula, and value a predictable raise range. + +An LBP opens above estimated fair value and lets the market discover +price over multiple days, without requiring the project to pre-set a +valuation. It is better suited to projects that want broad, patient +participation and market-driven price discovery. The two mechanisms +are genuinely different tools for genuinely different launch +strategies: teams should choose based on their community profile and +distribution goals. + +### Known limitations of bonding curves for token launches + +Bonding curves have weaker bot deterrence than LBPs. In an LBP, buying +early is unprofitable because price is highest at the start and falls +over time. In a bonding curve, buying early is cheapest: bots that +execute at the first block of an open sale acquire tokens at the +starting spot price `p₀ = Vc / Vt`, before the broader community can +participate. No bonding curve platform in the ecosystem implements +access restrictions or bot mitigation at the protocol level. +Projects seeking stronger bot-deterrence properties should use +RFP-016 instead. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Implement a bonding curve program on LEZ with a deterministic, + supply-driven pricing mechanism that maintains a well-defined + invariant across all buy and sell operations. The buy instruction + accepts a collateral input `C_in` and computes a deterministic + token output based on the current curve state. The SDK must also + expose the inverse: the exact collateral cost for a buyer who + requests a specific token quantity `Q`. The sell instruction + accepts a token input `tokens_in` and computes a deterministic + collateral output from the real collateral reserve. Sell + transactions must not withdraw more collateral than the real + reserve holds. After each buy, the real token reserve decreases + by `tokens_out` and the real collateral reserve increases by + `C_in`. After each sell, the real token reserve increases by + `tokens_in` and the real collateral reserve decreases by + `C_out`. If the computed `tokens_out` on a buy would exceed the + remaining sale reserve, the transaction must revert. All + arithmetic must use integer-only operations and round against + the trader: on buy, `tokens_out` rounds down and `C_in` rounds + up; on sell, `C_out` rounds down. This ensures the pool remains + solvent and the pricing invariant is never violated by rounding. + The pricing invariant must never change after creation. See the + Reference Implementation section for the recommended formulas + and the deviation standard for alternative mechanisms. +2. A sale creator can configure a sale with the following parameters: + 1. Token pair (project token + collateral token). + 2. Sale quantity `D`: the number of tokens available for + purchase. All `D` tokens must be transferred from the creator + at sale creation. + 3. Optional: DEX seed quantity `R`: tokens reserved for + post-graduation DEX seeding (may be zero). If set, `R` + tokens must also be transferred from the creator at sale + creation. Total real deposit is `D + R`. + 4. Virtual token reserve `Vt`: a synthetic pricing parameter + that determines the shape of the bonding curve (`Vt > D`). + This is not the deposit amount; it is typically larger than + `D + R` to position the starting price on the curve. + 5. Virtual collateral reserve `Vc`: a synthetic starting value; + no real collateral is deposited by the creator. Together + with `Vt`, determines `k = Vt × Vc` (computed and stored at + creation) and the starting spot price `p₀ = Vc / Vt`. + + The program must maintain two distinct accounting buckets: a + **sale reserve** (starts at `D`, decreases with each purchase) + and a **DEX seed reserve** (starts at `R`, untouched until + close). `D` is the supply target: the sale auto-closes when + the sale reserve is exhausted. +3. Participants buy and sell project tokens on the curve using + either a public account directly, or via the + deshield→trade→re-shield pattern for private account interaction + (see [RFP-008](./RFP-008-lending-borrowing-protocol.md), which + defines this interaction model for LEZ applications). Both paths + must be supported by the program and SDK. +4. The sale closes automatically when the sale reserve is exhausted + (all `D` tokens have been sold). +5. After the sale closes, the creator can withdraw: + - The real collateral raised, net of fees as defined by the + fee model specified in the proposal (see the Fee structure + subsection in Design Rationale). + - The DEX seed reserve `R` tokens (if not used for + auto-graduation). +6. Slippage protection: on buy, buyers specify the collateral + amount to spend and a minimum token quantity they are willing to + accept; the transaction reverts if the computed `tokens_out` is + below this minimum. On sell, sellers specify the token quantity + to sell and a minimum collateral amount they are willing to + accept; the transaction reverts if the computed `C_out` is below + this minimum. +7. Use Associated Token Accounts (ATAs) for all token interactions, + consistent with + [LP-0014](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0014.md) + and [RFP-008](./RFP-008-lending-borrowing-protocol.md). + +#### Usability + +1. Provide an SDK for building Logos modules that interact with the + bonding curve program. The SDK must expose the full lifecycle for + both participants (discover active sales, compute price and + impact, buy, query position) and creators (create sale, + close, withdraw). The SDK must support both direct + public account interaction and the deshield→buy→re-shield pattern + for private account interaction. When the private account path is + used, the SDK must handle the atomic deshield (both collateral + and gas) as a single indivisible user action. +2. Provide a Logos mini-app GUI with local build instructions, + downloadable assets, and loadable in Logos app (Basecamp) via + git repo. The mini-app must cover: + - **Participant view**: browse active sales with current spot + price, sale reserve as a percentage of the supply + target `D`, total collateral raised, and a price-vs-supply + chart; execute a buy; view purchase history. + - **Creator view**: create a new sale (all parameters including + `Vt`, `Vc`, sale quantity `D`), + monitor an active sale (live supply progress, collateral + raised), close sale, and withdraw proceeds. +3. Provide a CLI that covers core functionality of the program. + The CLI may have fewer features than the GUI mini-app but must + support all essential operations for both participants (buy, + query price, check sale status) and creators (create sale, + close, withdraw). +4. The mini-app must display a pre-buy confirmation summary before + each purchase: collateral to spend, exact tokens to be received + (computed using the pricing formula), current spot price + (`Vc / Vt`), price impact (percentage increase in spot price + after the buy), and fee. +5. When using the private account path, the mini-app must display a + privacy disclosure before each buy, identifying what will be + visible on-chain (buy transaction, collateral amount, tokens + received, curve address, ephemeral account) and what will not be + traceable (the buyer's private account and the subsequent + destination of purchased tokens). +6. When using the private account path, the mini-app must enforce + the atomic deshield, preventing a buyer from funding the + ephemeral account from any external source, which would create + an on-chain link to an existing identity. +7. When using the private account path, the mini-app must confirm + before each buy that the buyer's shielded balance covers both + the collateral cost and the gas fee within the single deshield + action. A clear, actionable error must be shown if the balance + is insufficient. +8. Provide a sale analytics view showing, for each active or + completed sale: total collateral raised, current spot price, + supply sold over time (progress chart), price-vs-supply curve + with current position marked, and number of buy transactions. + Analytics must not expose individual participant identities or + link buy transactions to specific accounts. +9. Provide an IDL for the bonding curve program using the + [SPEL framework](https://github.com/logos-co/spel). +10. Failed or rejected buys must return clear, actionable error + messages (e.g., insufficient balance, supply target already + reached, slippage + exceeded). +#### Reliability + +1. Curve state (`Vt`, `Vc`, `k`, real reserves) must remain + consistent under concurrent buy submissions. No double-spend, + incorrect accounting, or invariant violation. +2. A failed buy must revert atomically: the buyer's collateral is + not consumed and the curve state is unchanged. +3. Auto-close on supply target: when the final sale tokens are sold + and the sale reserve is exhausted, the sale must close + atomically in the same transaction. No additional close + instruction should be required; no further buys must be accepted + after close. + +#### Performance + +1. A single buy transaction completes within one LEZ transaction. +2. A close transaction (manual or auto-triggered by final buy) + completes within one LEZ transaction. +3. Document the compute unit (CU) cost of each operation: create + sale, buy, close sale, withdraw. + Note the LEZ testnet version against which measurements were + taken. + +#### Supportability + +Proposals must include separate milestones for testnet 0.2, testnet 0.3, +and mainnet deployment. + +1. The bonding curve program is deployed and tested on LEZ testnet 0.2. +2. End-to-end integration tests run against a LEZ sequencer + (standalone mode) and are included in CI. CI must be green on + the default branch. +3. Every hard requirement in Functionality, Usability, Reliability, + and Performance has at least one corresponding test. Test + coverage must include: invariant preservation across multiple + buys, happy-path buy, slippage revert (tokens_out below + minimum), auto-close on supply + target, manual close. +4. A README documents end-to-end usage: deployment steps, program + addresses, and step-by-step instructions for both creators and + participants via CLI and mini-app. +5. Provide a privacy and anonymisation properties document covering: + what on-chain state and transaction data is visible to observers; + what data is protected when the private account path is used; + trust assumptions, specifying which guarantees are enforced by + the on-chain program and which depend on correct client + behaviour; and what happens if a user bypasses the expected + interaction path. +6. The program is updated and verified on LEZ testnet 0.3. +7. The program is deployed to LEZ mainnet. + +#### + Privacy + +1. The mini-app and SDK must support both direct public account + interaction and the deshield→buy→re-shield pattern for private + account interaction. When a user chooses the private account + path, the SDK must enforce the complete pattern; the re-shield + step must not be skippable. +2. When using the private account path, the mini-app must display + the pre-confirmation privacy summary described in the Usability + section before each buy operation. +3. When using the private account path, the SDK must validate that + the re-shield target for purchased tokens is a private (shielded) + account before submitting the transaction, and reject with an + explicit error if it is not. +4. The ephemeral public account created during the deshield step + must never be reused across operations. Each buy from a private + account must use a freshly generated account with no prior + on-chain history. + +### Privacy Architecture + +All bonding curve state is public on-chain (virtual reserve values +`Vt` and `Vc`, invariant `k`, real reserve balances, current spot +price, open/closed status). This is a deliberate architectural +choice: public state enables permissionless price verification (any +participant can verify `tokens_out` against the pricing formula +independently), composability, and sale analytics without +cryptographic complexity in the curve program itself. + +User privacy is optionally enforced at the UX layer. The mini-app and +SDK support both direct public account interaction and private account +interaction via the deshield→buy→re-shield pattern. When users opt to +interact from a private account, the SDK must enforce the complete +pattern as described below. + +#### Interaction flow + +For every buy from a private account: + +1. The buyer initiates from their private account. The SDK deshields + to a **fresh, single-use** public account (account A) with no + prior on-chain history. The deshield atomically transfers both + the collateral token and enough native token for gas in a single + indivisible action. +2. Account A executes the buy against the bonding curve program. +3. Account A re-shields the purchased project tokens to the buyer's + private account. Account A is never reused. + +> **Gas:** Both collateral and gas must come exclusively from the +> deshield in step 1. Funding account A from any external source +> (such as a CEX withdrawal or a known wallet) creates an +> on-chain link to an existing identity and breaks the privacy +> guarantee. The SDK must make this impossible; the atomic deshield +> is a single, indivisible user action. + +#### What is public (observable on-chain) + +- All curve state: token pair, virtual reserves (`Vt`, `Vc`), + invariant `k`, sale reserve, DEX seed reserve, real collateral + reserve, sale quantity `D`, current spot price, open/closed + status. +- All buy transactions: collateral spent, tokens received, and + block height. When using the private account path, the buyer's + address is an ephemeral intermediary account with no prior + on-chain history. +- Sale close and creator withdrawal transactions. + +#### What is private (when using the private account path) + +- Which private account originated the collateral for a buy. +- Where purchased tokens go after re-shielding. +- Any link between multiple buys by the same buyer (no on-chain + linkability across ephemeral accounts). +- Whether a specific private account participated in the sale at all. + +#### Trust assumptions + +The privacy guarantees above depend on the buyer using an SDK or +client that correctly implements the full deshield→buy→re-shield +pattern. The bonding curve program itself cannot enforce the +re-shield step: a buyer who calls the program directly or uses a +non-conforming client could skip the re-shield, leaving purchased +tokens in the ephemeral public account and breaking their own +anonymity. The program enforces correctness of the buy (invariant +preservation, slippage checks); the privacy pattern is enforced +by the SDK, not by the on-chain program. Buyers who bypass the +SDK accept full responsibility for any resulting privacy loss. + +### Known Limitations + +**Front-running at sale open.** Unlike the LBP mechanism, which opens +at a price above estimated fair value and declines over time, a bonding +curve opens at its lowest price (`p₀ = Vc / Vt`). Bots that execute +at the first block of the sale acquire tokens at the cheapest possible +price, before the community can participate. No bonding curve platform +in the ecosystem implements access restrictions or bot mitigation at +the protocol level. Projects requiring stronger bot deterrence should +use [RFP-016](./RFP-016-lbp-launchpad.md) instead. + +### Reference Implementation + +The recommended pricing mechanism is the **constant product AMM with +virtual reserves**, as described in the Design Rationale. Proposals +that use this formula require no additional justification beyond the +hard requirements above. + +The constant product invariant is `Vt × Vc = k`, where `Vt` is the +virtual token reserve and `Vc` is the virtual collateral reserve. The +buy formula computes token output as: + +``` +tokens_out = Vt - k / (Vc + C_in) +``` + +The inverse (exact collateral cost for a requested token quantity `Q`): + +``` +C_in = k / (Vt - Q) - Vc +``` + +The sell formula computes collateral output as: + +``` +C_out = Vc - k / (Vt + tokens_in) +``` + +After each buy, `Vt` decreases by `tokens_out` and `Vc` increases +by `C_in`. After each sell, `Vt` increases by `tokens_in` and `Vc` +decreases by `C_out`. In both cases, `k = Vt × Vc` is preserved. +`k` is computed at creation and must never change. + +**Deviation standard.** Teams may propose an alternative pricing +mechanism (such as a polynomial integral, the Bancor power function, +a piecewise constant product as used in Meteora DBC, a batch auction, +or a commit-reveal scheme) provided the proposal includes: (1) a +formal specification equivalent in detail to the formulas above, +(2) a security argument that the mechanism's core invariant is +preserved under all operations, and (3) citations to existing +production deployments or audits. + +### Soft Requirements + +- **One-directional mode**: a creator-configurable option that + disables sell-back during the sale window. When enabled, buyers + can only purchase tokens from the curve; the accumulated + collateral reserve is locked until close. This prevents reflexive + sell pressure during the distribution window and simplifies pool + accounting, at the cost of removing exit liquidity for + participants before graduation. +- **Auto-graduation to DEX**: when the supply target is reached and + the sale auto-closes, the program can automatically deploy the + accumulated real collateral reserve and the DEX seed reserve `R` + tokens as liquidity into a LEZ DEX pool (requires + [RFP-004](./RFP-004-privacy-preserving-dex.md) and LP-0015 to + be available). This eliminates manual post-sale liquidity seeding + and provides immediate post-graduation tradability. +- **Optional end timestamp**: the sale creator can configure an end + timestamp at creation time. The sale closes when the supply target + is reached or the end timestamp passes, whichever comes first. + This prevents zombie sales (curves that sit open indefinitely if + demand is low). On Pump.fun, the graduation rate is approximately + 0.7% to 1.4%, meaning over 98% of bonding curves never reach + their supply target and remain as dormant on-chain state. When an + end timestamp is configured, the program must enforce a minimum + sale duration at creation time, long enough that latency in the + deshield→buy→re-shield privacy path does not systematically + disadvantage private-path buyers on price relative to public-path + buyers. No bonding curve platform currently implements this + feature. + + +## ⚠ Platform Dependencies + +This RFP is open for proposals. However, full implementation is +blocked until the hard dependency below is delivered. Proposers may +begin design and development work, but a working on-chain deployment +requires LP-0015 to be available. + +### Hard blockers + +#### General cross-program calls (LP-0015) + +A buy operation must: (1) call the token program to transfer +collateral from the buyer into the real collateral reserve, (2) +compute `tokens_out` using the constant product formula, (3) call +the token program again to transfer project tokens to the buyer, and +(4) update curve state (`Vt`, `Vc`, real reserves). Without general +cross-program calls, the execution cannot continue after the first +token program call, making it impossible to complete the full buy +atomically. + +[LP-0015](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0015.md) +(General cross-program calls via tail calls) solves this. This prize +is currently **open**. + +### Soft blockers + +#### Event emission (LP-0012) + +Analytics dashboards and monitoring services need to react to curve +events (buy executed, sale closed). Without structured +events, off-chain services must poll all accounts. + +[LP-0012](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md) +(Structured events for LEZ program execution) is currently **open**. + +## 👤 Recommended Team Profile + +Team experienced with: + +- AMM and constant product pool design +- Solana or SVM program development (Anchor or native) +- DeFi smart contract security and auditing practices +- Fixed-point arithmetic and precision-safe integer math for on-chain AMMs +- Front-end development for token sale and trading applications + + +## ⏱ Timeline Expectations + +Estimated duration: **10–12 weeks** + + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + + +## Evaluation Criteria + +Proposals that meet all hard requirements will be ranked on the +following criteria. + +| Criterion | Weight | What we look for | +|-----------|--------|-----------------| +| Technical design quality | 30% | Formal specification of pricing mechanism, invariant proofs or arguments, integer arithmetic strategy, audit plan | +| Privacy architecture | 25% | Strength of anonymity properties in the private account path, completeness of the deshield→buy→re-shield flow | +| Team experience | 20% | Prior AMM or DeFi protocol work, smart contract security track record, familiarity with SVM or similar execution environments | +| Timeline and milestones | 15% | Realistic schedule with concrete deliverables, risk identification, dependency management (especially LP-0015) | +| Ecosystem alignment | 10% | Open source commitment, composability with other LEZ programs (DEX), community engagement plan | + + +## Resources + +- [Logos Documentation](https://github.com/logos-co/logos-docs) +- [RFP-016: Privacy-Preserving Token Launchpad (LBP)](./RFP-016-lbp-launchpad.md) + (companion launchpad RFP using the LBP mechanism) +- [RFP-008: Lending & Borrowing Protocol](./RFP-008-lending-borrowing-protocol.md) + (reference for the public/private account interaction pattern used + across LEZ applications) +- [RFP-004: Privacy-Preserving DEX](./RFP-004-privacy-preserving-dex.md) + (soft requirement: auto-graduation target) +- [Appendix: Token Launchpad Ecosystem](../appendix/token-launchpad-ecosystem.md) + (survey of existing launchpad protocols, scale data, and refund mechanisms) + +- [LP-0013: Token program improvements: mint authorities](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0013.md) +- [LP-0014: Token program improvements: ATAs + wallet tooling](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0014.md) +- [Meteora Dynamic Bonding Curve (program and docs)](https://github.com/MeteoraAg/dynamic-bonding-curve) + (primary reference implementation for constant product bonding curve on Solana) +- [pump.fun bonding curve mechanism](https://deepwiki.com/pump-fun/pump-public-docs/3.1-pump-bonding-curve-mechanism) + (canonical production deployment of constant product with virtual reserves) +- [pumpdotfun-sdk: bondingCurveAccount.ts](https://github.com/rckprtr/pumpdotfun-sdk/blob/main/src/bondingCurveAccount.ts) + (TypeScript reference for buy/sell formula) +- [SPEL framework](https://github.com/logos-co/spel) + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, +please use **Discussions**. diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md new file mode 100644 index 0000000..e2ffbcb --- /dev/null +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -0,0 +1,613 @@ +--- +id: RFP-016 +title: "Privacy-Preserving Token Launchpad: LBP" +tier: XL +funding: $XXXXX +status: open +category: Applications & Integrations +--- + + +# RFP-016: Privacy-Preserving Token Launchpad: LBP + +Note that ecosystem research is available in the [appendix](appendix/token-launchpad-ecosystem). + +## 🧭 Overview + +Build a token launchpad on LEZ using a Liquidity Bootstrapping Pool +(LBP) mechanism, a time-limited, weight-shifting AMM that enables +fair, bot-resistant price discovery for new token launches. +Participants can buy tokens directly from a public account or, for +privacy, via a deshield→buy→re-shield pattern (see +[RFP-008](./RFP-008-lending-borrowing-protocol.md), which defines this +interaction model for LEZ applications): when a private account is +used, each purchase is routed through a fresh, single-use public +account, hiding the link between the buyer's private identity and their +participation in the sale. An optional private allowlist +gate enables projects to restrict participation without exposing the +eligibility set on-chain. + +The launchpad is the entry point for new projects into the Logos +ecosystem. It is where token price and initial distribution are +established. + +## 🔥 Why This Matters + +LBPs are an established mechanism for fair, bot-resistant token price +discovery, with over $1.5B in cumulative swap volume on Fjord Foundry +alone. Fjord Foundry's own FJO token LBP raised $15.35M in +April 2024 ([DL News](https://www.dlnews.com/articles/defi/fjord-foundry-raises-15-million-in-fjo-token-sale/)), +described at the time as the highest LBP raise of the year. Autonolas +raised $547k from $50k in initial USDC liquidity via an LBP on the +same platform +([olas.network](https://olas.network/blog/olas-public-launch), +[CryptoRank](https://cryptorank.io/ico/autonolas)). +The mechanism deters bots and removes the need for project teams to +pre-set a valuation for their token. + +On transparent chains, participation in a token sale is immediately +linkable to a wallet address and, by extension, to the buyer's full +transaction history. Early investors and community members can be +identified, targeted for social engineering, or front-run at the +unlock date. Platforms like Fjord Foundry, DAO Maker, and Polkastarter +all require participants to expose their wallet identities on-chain; +those using KYC leak that data to a centralised service. + +On LEZ, the optional deshield→buy→re-shield pattern means a buyer's +private account is never linked to their purchase on-chain. Observers +see a buy transaction from an ephemeral public account with no prior +history. The buyer's identity, their total position size, and the +destination of their purchased tokens are all private. This is a +structurally different, and stronger, privacy guarantee than +anything available on existing launchpad platforms. + +## 🏗 Design Rationale + +### LBP mechanism and its place in the ecosystem + +The LBP runs price discovery continuously over days: the token price +starts above estimated fair value and falls unless buying pressure +counteracts it. Bots are naturally deterred: early sniping is +unprofitable because price is highest at the start. The mechanism has a multi-year track record: Fjord Foundry (built on +Balancer's weighted pool primitive) has hosted 717 LBPs with over +$1.1B in cumulative funds raised and 106,762 participants since 2021. + +Among other token sale mechanisms, fixed-price forces a binary gamble: +underpricing benefits buyers and dilutes the project; overpricing leads +to an incomplete raise and reputation damage. Dutch auctions clear at a +single price moment, which creates a coordination game: buyers wait for +the price to fall and then rush simultaneously, producing congestion and +poor UX. [LP-0004 (sealed-bid)](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0004.md) hides individual bids and is well-suited +to single-item auctions, but clears at one moment rather than over days, +making it unsuitable for broad community distribution. + +The Logos ecosystem also provides a bonding curve launchpad +([RFP-015](./RFP-015-bonding-curve-launchpad.md)) for projects where +early-entry incentives are intentional: price rises deterministically +with each purchase, rewarding early believers with a lower entry price. +The two mechanisms suit different project profiles and together provide +a complete token launch toolkit. + +Fixed-price mode is retained as a soft requirement for projects that +have an existing community with a known clearing price and prefer +simplicity over discovery. + +### Public pool state + +A fully private AMM pool (where token reserves and price are +shielded) would provide stronger privacy guarantees, but it is an +open research problem with no practical implementation on any +network. It would also undermine the LBP mechanism itself: price +discovery requires all participants to observe the same current price +curve so they can make informed decisions about when to buy. + +Public pool state is the correct choice here. It enables +permissionless price transparency (every participant sees the same +price), composability with other LEZ programs (e.g., routing, +aggregators), permissionless weight poke transactions (anyone can +advance the schedule without depending on the creator), and +verifiable sale analytics. Participant privacy is instead enforced +at the UX layer via the optional deshield→buy→re-shield pattern, +which unlinks the buyer's private identity from their on-chain +purchase without requiring private pool state. + +### Optional allowlist + +The allowlist gate is opt-in: many projects want permissionless open +sales. When projects do need access control (e.g., geographic +restrictions, community-only sales, pre-selected investor lists), the +creator can commit an eligibility set at creation time and restrict +buys to participants who can prove inclusion. The implementation +approach is left to the proposing team. + +On LEZ, the relevant anonymity set for any private account action is +all private accounts in the zone, not the allowlist size. The +execution environment is shielded by construction: an observer cannot +determine which private account interacted with the sale, regardless +of whether an allowlist is active. This means an allowlist does not +degrade privacy in the way it would on a transparent chain, where +the anonymity set shrinks to the allowlist size (see the +[Allowlist Privacy in Shielded Execution Environments](../appendix/token-launchpad-ecosystem.md#allowlist-privacy-in-shielded-execution-environments) +section of the token launchpad ecosystem appendix). + +The recommended approach is ZK set membership proofs (a Merkle tree +commitment with a ZK inclusion proof) rather than a public address +list. This avoids publishing the allowlist on-chain and preserves the +zone-wide anonymity set regardless of allowlist size. When both the +allowlist gate and the private account path are enabled, the proposal +must document the resulting privacy properties and any reduction in +anonymity set relative to a non-gated sale. + +### Sale pause capability + +The pause function is an emergency stop for security incidents, +analogous to the freeze authority in +[RFP-002](./RFP-002-freeze-authority-poc.md). Crucially, pausing does +not halt weight progression: the weight schedule continues to advance +during a pause. This prevents a creator from gaming the mechanism by +pausing at a weight that is artificially favourable and resuming once +they detect large buy orders. + +### Fee structure + +This RFP does not mandate a specific fee rate. Proposals must +specify: (1) who pays the fee (issuer, buyer, or both), (2) when +fees are collected (per-transaction, at sale close, or both), +(3) the fee rate or rate range, and (4) where fees are routed +(protocol treasury, sale creator, burn, or other destination). See +the [Fee Structures](../appendix/token-launchpad-ecosystem.md#fee-structures) +section of the token launchpad ecosystem appendix for a +cross-platform comparison of fee models across seven surveyed +protocols. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Implement an LBP program on LEZ. An LBP is a two-asset pool + consisting of a project token and a collateral token (e.g., + stablecoin or native token), with start and end weights configured + by the sale creator. Pool weights shift linearly from the start + weight to the end weight over the sale duration, causing the token + price to decline over time unless buying pressure counteracts it. +2. A sale creator can configure a sale with the following parameters: + 1. Token pair (project token + collateral token). + 2. Start and end weights (e.g., 99/1 → 1/99 for the + token/collateral ratio). + 3. Sale start and end timestamps. + 4. Initial token deposit amount. + 5. Optional: per-block token allocation ceiling (maximum number + of tokens that can be sold across all buy transactions within + a single block). When set, any buy that would exceed the + block ceiling is rejected. This limits the rate at which any + participant (or set of participants) can accumulate supply, + regardless of how many accounts they use. + 6. Optional: private allowlist gate (see item 7 below). +3. Participants buy project tokens from the pool using either a + public account directly, or via the deshield→buy→re-shield + pattern for private account interaction (see + [RFP-008](./RFP-008-lending-borrowing-protocol.md)). Both paths + must be supported by the program and SDK. +4. Pool weights shift deterministically according to the configured + schedule. Any account can submit a weight-update ("poke") + transaction to advance the current weights to the value dictated + by the elapsed time. The LBP program must apply the correct weight + at transaction time regardless of how recently the last poke + occurred. +5. After the sale end timestamp passes, the creator can withdraw: + - The collateral raised, net of fees as defined by the fee + model specified in the proposal (see the Fee structure + subsection in Design Rationale). + - Any unsold project tokens remaining in the pool. +6. The sale creator can pause buying at any time during the sale + period (emergency stop). Pausing does not affect weight + progression; the weight schedule continues during a pause. +7. The sale creator can enable an optional allowlist gate for the + sale. When enabled, only participants who can prove inclusion in + the committed eligibility set may buy from the pool. The + proposing team must specify and justify their allowlist mechanism + in their application. When the allowlist gate is used in + conjunction with the private account path, the proposal must + document the resulting privacy properties, including any change + in the effective anonymity set relative to a non-gated sale. +8. Slippage protection: buyers can specify a minimum token output + amount. The transaction reverts if the execution price would + produce fewer tokens than the specified minimum. +9. Use Associated Token Accounts (ATAs) for all token interactions, + consistent with + [LP-0014](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0014.md) + and [RFP-008](./RFP-008-lending-borrowing-protocol.md). + +#### Usability + +1. Provide an SDK for building Logos modules that interact with the + launchpad program. The SDK must expose the full lifecycle for both + participants (discover active sales, buy, query position) and + creators (create sale, pause/resume, close, withdraw). The SDK + must support both direct public account interaction and the + deshield→buy→re-shield pattern for private account interaction. + When the private account path is used, the SDK must handle the + atomic deshield (both collateral and gas) as a single + indivisible user action. +2. Provide a Logos mini-app GUI with local build instructions, + downloadable assets, and loadable in Logos app (Basecamp) via + git repo. The mini-app must cover: + - **Participant view**: browse active sales with live price, + current token/collateral weight, time remaining, and total + raised; execute a buy; view purchase history. + - **Creator view**: create a new sale (all parameters including + allowlist configuration), monitor an active sale, + pause/resume, close sale, and withdraw proceeds. +3. Provide a CLI that covers core functionality of the program. + The CLI may have fewer features than the GUI mini-app but must + support all essential operations for both participants (buy, + query price, check sale status) and creators (create sale, + pause/resume, close, withdraw). +4. The mini-app must display a pre-buy confirmation summary before + each purchase: current token price, estimated tokens to be + received, price impact, collateral spent, and fee. +5. When using the private account path, the mini-app must display a + privacy disclosure before each buy, identifying what will be + visible on-chain (buy transaction, collateral amount, tokens + received, pool address, ephemeral account) and what will not be + traceable (the buyer's private account and the subsequent + destination of purchased tokens). +6. When using the private account path, the mini-app must enforce + the atomic deshield, preventing a buyer from funding the + ephemeral account from any external source, which would create + an on-chain link to an existing identity. +7. When using the private account path, the mini-app must confirm + before each buy that the buyer's shielded balance covers both + the collateral amount and the gas fee within the single deshield + action. A clear, actionable error must be shown if the balance + is insufficient, preventing a partial deshield that could leave + funds stranded. +8. Provide a sale analytics view showing, for each active or + completed sale: total collateral raised, token price over time + (price chart), number of buy transactions, and current pool + composition. Analytics must not expose individual participant + identities or link buy transactions to specific accounts. +9. Provide an IDL for the launchpad program using the + [SPEL framework](https://github.com/logos-co/spel). +10. Failed or rejected buys must return clear, actionable error + messages (e.g., insufficient balance, sale not yet started, sale + ended, allowlist gate rejected, slippage exceeded). + +#### Reliability + +1. Pool state (weights, token balances, collateral raised) must + remain consistent under concurrent buy submissions. No + double-spend or incorrect pool accounting. +2. A failed buy must revert atomically: the buyer's collateral is + not consumed and the pool state is unchanged. +3. Weight updates (pokes) must be idempotent: submitting multiple + pokes within the same block or timestamp window must not corrupt + pool state. + +#### Performance + +1. A single buy transaction completes within one LEZ transaction. +2. A weight poke completes within one LEZ transaction. +3. Document the compute unit (CU) cost of each operation: create + sale, buy, poke weights, pause/resume, close sale, withdraw. + Note the LEZ testnet version against which measurements were + taken. + +#### Supportability + +Proposals must include separate milestones for testnet 0.2, testnet 0.3, +and mainnet deployment. + +1. The launchpad program is deployed and tested on LEZ testnet 0.2. +2. End-to-end integration tests run against a LEZ sequencer + (standalone mode) and are included in CI. CI must be green on + the default branch. +3. Every hard requirement in Functionality, Usability, Reliability, + and Performance has at least one corresponding test. Test + coverage must include: happy-path buy, slippage revert, allowlist + gate accept and reject, sale close before end time, weight poke + at multiple points in the schedule. +4. A README documents end-to-end usage: deployment steps, program + addresses, and step-by-step instructions for both creators and + participants via CLI and mini-app. +5. Provide a privacy and anonymisation properties document covering: + what on-chain state and transaction data is visible to observers; + what data is protected when the private account path is used; + trust assumptions, specifying which guarantees are enforced by + the on-chain program and which depend on correct client + behaviour; and what happens if a user bypasses the expected + interaction path. +6. The program is updated and verified on LEZ testnet 0.3. +7. The program is deployed to LEZ mainnet. + +#### + Privacy + +1. The mini-app and SDK must support both direct public account + interaction and the deshield→buy→re-shield pattern for private + account interaction. When a user chooses the private account + path, the SDK must enforce the complete deshield→buy→re-shield + pattern; the re-shield step must not be skippable. +2. When using the private account path, the mini-app must display + the pre-confirmation privacy summary described in the Usability + section before each buy operation, identifying what is visible + on-chain (buy amount, pool address, ephemeral intermediary + account) and what remains private (the originating private + account, the destination of re-shielded tokens, and any link + between separate buys by the same user). +3. When using the private account path, the SDK must validate that + the re-shield target for purchased tokens is a private (shielded) + account before submitting the transaction, and reject with an + explicit error if it is not. +4. The ephemeral public account created during the deshield step + must never be reused across operations. Each buy from a private + account must use a freshly generated account with no prior + on-chain history. + +### Privacy Architecture + +All LBP pool state is public on-chain (token pair, weights, price, +cumulative volume, total collateral raised). This is a deliberate +architectural choice: public state enables permissionless price +discovery, composability, and sale analytics without cryptographic +complexity in the pool itself. + +User privacy is optionally enforced at the UX layer. The mini-app +and SDK support both direct public account interaction and private +account interaction via the deshield→buy→re-shield pattern. When +users opt to interact from a private account, the SDK must enforce +the complete pattern as described below. + +#### Interaction flow + +For every buy from a private account: + +1. The buyer initiates from their private account. The SDK + deshields to a **fresh, single-use** public account (account A) + with no prior on-chain history. The deshield atomically + transfers both the collateral token and enough native token for + gas in a single indivisible action. +2. Account A executes the buy against the LBP pool. +3. Account A re-shields the purchased project tokens to the buyer's + private account. Account A is never reused. + +> **Gas:** Both collateral and gas must come exclusively from the +> deshield in step 1. Funding account A from any external source +> (such as a CEX withdrawal or a known wallet) creates an +> on-chain link to an existing identity and breaks the privacy +> guarantee. The SDK must make this impossible; the atomic deshield +> is a single, indivisible user action. + +#### What is public (observable on-chain) + +- All pool state: token pair, current weights, price, total + collateral raised, total tokens sold, sale start/end timestamps. +- All buy transactions: collateral spent, tokens received, and + timestamp. When using the private account path, the buyer's + address is an ephemeral intermediary account with no prior + on-chain history. +- Allowlist gate configuration and whether the gate is enabled, + but not the list of eligible addresses. +- Sale close and creator withdrawal transactions. + +#### What is private (when using the private account path) + +- Which private account originated the collateral for a buy. +- Where purchased tokens go after re-shielding. +- Any link between multiple buys by the same buyer (no on-chain + linkability across ephemeral accounts). +- Whether a specific private account participated in the sale + at all. + +#### Trust assumptions + +The privacy guarantees above depend on the buyer using an SDK or +client that correctly implements the full deshield→buy→re-shield +pattern. The LBP program itself cannot enforce the re-shield step: +a buyer who calls the program directly or uses a non-conforming +client could skip the re-shield, leaving purchased tokens in the +ephemeral public account and breaking their own anonymity. The +program enforces correctness of the buy (weight computation, +slippage checks); the privacy pattern is enforced by the SDK, not +by the on-chain program. Buyers who bypass the SDK accept full +responsibility for any resulting privacy loss. + +### Known Limitations + +**Per-wallet buy limits are not supported.** Enforcing a cap on how +much collateral a single participant can contribute requires the +program to track cumulative spend per address. This is straightforward +for public account interactions, but is fundamentally incompatible +with the private account path: each buy from a private account uses +a fresh ephemeral public address with no prior history, so the program +cannot link multiple buys to the same underlying participant. Providing +this feature would either require breaking the privacy guarantee or +introducing off-chain coordination that reintroduces centralisation. +Projects that need whale concentration limits should use the allowlist +gate to restrict the eligible set instead. + +### Soft Requirements + +- Support for a fixed-price sale mode (no weight shift; constant + price over duration), as an alternative to the LBP mechanism, + for projects that prefer a known token price. + +### Reference Implementation + +The recommended pricing mechanism is the **weight-shifting AMM** +derived from the Balancer weighted pool formula. Proposals that use +this formula require no additional justification beyond the hard +requirements above. + +#### Weight interpolation + +At any point in time `t`, the token and collateral weights are +linearly interpolated between their start and end values: + +``` +w_token(t) = w_start + (w_end - w_start) × (t - t_start) / (t_end - t_start) +w_collateral(t) = 1 - w_token(t) +``` + +Where `w_start` is the initial token weight (e.g., 0.99), +`w_end` is the final token weight (e.g., 0.01), `t_start` and +`t_end` are the sale start and end timestamps, and `t` is the +current block timestamp. + +#### Spot price + +At any reserve state, the spot price of the project token in +terms of collateral is: + +``` +price = (reserve_collateral × w_token) / (reserve_token × w_collateral) +``` + +As weights shift (`w_token` decreases, `w_collateral` increases), +the price naturally falls even if reserves are unchanged. This is +the mechanism behind the LBP's declining price curve. + +#### Buy formula + +Given a collateral input `C_in`, the token output is computed +using the Balancer weighted pool swap formula: + +``` +tokens_out = reserve_token × (1 - (reserve_collateral / (reserve_collateral + C_in)) ^ (w_collateral / w_token)) +``` + +All arithmetic must use integer-only operations and round against +the trader: `tokens_out` rounds down. After each buy, +`reserve_token` decreases by `tokens_out` and +`reserve_collateral` increases by `C_in`. + +#### Lazy weight computation + +Weights are computed at each swap using the block timestamp and +the stored weight schedule (start weights, end weights, start +time, end time). No external poke transactions are required for +correct pricing: the program evaluates the weight interpolation +formula at transaction time, ensuring the on-chain price always +reflects the current weight without relying on external callers. +The poke function (Functionality requirement 4) is an optional +convenience that advances stored weights for off-chain consumers +(e.g., price feeds, analytics dashboards) but does not affect +pricing correctness. + +#### Weight continuity + +The weight function is linear and continuous over the sale +duration. Because weights are evaluated at each transaction using +the formula above, there is no discontinuity between poke +intervals. Stale-weight arbitrage (exploiting a gap between the +stored weight and the correct weight) is prevented by lazy +computation: the program always uses the current timestamp, not +a previously stored weight value. + +#### Timestamp dependency + +The program reads the block timestamp (or equivalent on-chain +time source) at each buy to compute current weights. This creates +a hard dependency on an on-chain clock primitive, noted in +Platform Dependencies. The weight function's correctness depends +on the timestamp advancing monotonically; if the on-chain clock +stalls or regresses, weight computation will produce incorrect +results. + +#### Deviation standard + +Teams may propose an alternative pricing mechanism (such as a +constant product AMM with time-varying parameters, a piecewise +weight function, or a batch auction overlay) provided the proposal +includes: (1) a formal specification equivalent in detail to the +formulas above, (2) a security argument that the mechanism's core +invariant is preserved under all operations, and (3) citations to +existing production deployments or audits. + +## ⚠ Platform Dependencies + + +These must be available on LEZ for development to start: +#### On-chain clock / timestamp + +LEZ does not yet have on-chain block time. The LBP mechanism is +fundamentally time-driven: pool weights shift linearly from the +start weight to the end weight over the sale duration, and the +current price at any moment is a function of elapsed time since +sale start. Without a reliable on-chain timestamp, weight +progression cannot be computed, and sale start and end timestamps +cannot be enforced. The launchpad cannot function without this +primitive. + +#### General cross-program calls (LP-0015) + +LEZ uses a tail-call execution model with no return. A buy +operation must: (1) call the token program to transfer collateral +from the buyer into the pool, (2) compute the token output based +on current weights, (3) call the token program again to transfer +project tokens to the buyer, and (4) update pool state (weights, +balances, cumulative volume). Without general cross-program calls, +the execution cannot continue after the first token program call, +making it impossible to complete the full buy atomically. + +[LP-0015](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0015.md) +(General cross-program calls via tail calls) solves this. This +prize is currently **open**. + +#### Event emission (LP-0012) + +Analytics dashboards and sale monitoring services need to react to +pool events (buy executed, weights updated, sale closed). Without +structured events, off-chain services must poll all accounts, which +is expensive and unreliable. + +[LP-0012](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md) +(Structured events for LEZ program execution) is currently +**open**. + +## 👤 Recommended Team Profile + +Team experienced with: + +- AMM and weighted pool design (Balancer-style or equivalent) +- Solana or SVM program development (Anchor or native) +- DeFi smart contract security and auditing practices +- Front-end development for token sale and trading applications + + +## ⏱ Timeline Expectations + +Estimated duration: **14–16 weeks** + + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. +## Resources + +- [Logos Documentation](https://github.com/logos-co/logos-docs) +- [RFP-008: Lending & Borrowing Protocol](./RFP-008-lending-borrowing-protocol.md) + (reference for the optional public/private account interaction + pattern) +- [RFP-017: Privacy-Preserving Token Vesting](./RFP-017-token-vesting.md) + (soft requirement: post-sale vesting integration) +- [Appendix: Token Launchpad Ecosystem](../appendix/token-launchpad-ecosystem.md) + (survey of existing launchpad protocols, scale data, and refund mechanisms) + +- [LP-0013: Token program improvements: mint authorities](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0013.md) +- [LP-0014: Token program improvements: ATAs + wallet tooling](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0014.md) +- [RFP-015: Token Launchpad: Bonding Curve](./RFP-015-bonding-curve-launchpad.md) + (companion launchpad RFP using the bonding curve mechanism) +- [Balancer LBP documentation](https://balancer.gitbook.io/balancer/smart-contracts/smart-pools/liquidity-bootstrapping-faq) +- [Fjord Foundry LBP reference](https://help.fjordfoundry.com/fjord-foundry-docs/for-sale-creators/faqs-creators/lbp-faq) +- [SPEL framework](https://github.com/logos-co/spel) + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, +please use **Discussions**. diff --git a/RFPs/RFP-018-tiered-sale-launchpad.md b/RFPs/RFP-018-tiered-sale-launchpad.md new file mode 100644 index 0000000..71313d6 --- /dev/null +++ b/RFPs/RFP-018-tiered-sale-launchpad.md @@ -0,0 +1,663 @@ +--- +id: RFP-018 +title: "Privacy-Preserving Token Launchpad: Tiered Sale" +tier: L +funding: $XXXXX +status: open +dependencies: See Platform Dependencies section +category: Applications & Integrations +--- + + +# RFP-018: Privacy-Preserving Token Launchpad: Tiered Sale + +Note that ecosystem research is available in the [appendix](appendix/token-launchpad-ecosystem). + +## 🧭 Overview + +Build a tiered sale token launchpad on LEZ, a fixed-price token +distribution mechanism with multiple sequential rounds (e.g., Seed, +Private, Public), each with independently configurable prices, +allocation sizes, and access restrictions. Participants can buy +tokens directly from a public account or, for privacy, via a +deshield→buy→re-shield pattern (see +[RFP-008](./RFP-008-lending-borrowing-protocol.md), which defines this +interaction model for LEZ applications): when a private account is +used, each purchase is routed through a fresh, single-use public +account, hiding the link between the buyer's private identity and their +participation in the sale. An optional private allowlist gate per tier +enables projects to restrict participation without exposing the +eligibility set on-chain. + +The tiered sale launchpad complements the Logos ecosystem's existing +token launch toolkit: where bonding curves +([RFP-015](./RFP-015-bonding-curve-launchpad.md)) reward early +believers with supply-driven pricing and LBPs +([RFP-016](./RFP-016-lbp-launchpad.md)) run time-driven price +discovery, tiered sales serve projects that already have a known +valuation and want controlled distribution across investor tiers at +predetermined prices. + +## 🔥 Why This Matters + +Tiered sales are an established distribution mechanism for projects +with an existing investor base and a known target valuation. Fjord +Foundry supports tiered sales (Seed, Private, and Public rounds) with +per-tier configuration of token amounts, prices, and allocation limits +[33]; across all sale types (primarily LBPs), the platform has hosted +717 sales with over $1.1B in cumulative funds raised and 106,762 +participants since 2021 [5][6]. DAO Maker's Strong Holder Offering +(SHO) model uses phased rounds (priority tranches for high-tier +holders, then public rounds) and has raised $90M+ [8][12]. Polkastarter runs +fixed-price IDOs with hard caps across 105+ projects and $46M+ in +cumulative funds raised [10]. Metaplex Genesis on Solana supports +multiple inflow buckets per launch, enabling private/seed rounds +(allowlisted wallets, fixed price) followed by public rounds (open, +fair launch pool), with an estimated $55-70M in total funds raised +during its alpha period [16]. + +On transparent chains, participation in a tiered sale is immediately +linkable to a wallet address and, by extension, to the buyer's full +transaction history. Early investors in seed and private rounds are +especially exposed: their wallet addresses, allocation sizes, and +vesting unlock dates are all public, making them targets for social +engineering and front-running. Platforms like Fjord Foundry, DAO Maker, +and Polkastarter all require participants to expose their wallet +identities on-chain; those using KYC leak that data to a centralised +service [11][12][10]. + +On LEZ, the optional deshield→buy→re-shield pattern means a buyer's +private account is never linked to their purchase on-chain. Observers +see a buy transaction from an ephemeral public account with no prior +history. The buyer's identity, their tier allocation, and the +destination of their purchased tokens are all private. This is a +structurally different, and stronger, privacy guarantee than anything +available on existing tiered sale platforms. + +## 🏗 Design Rationale + +### Tiered sales and their place in the ecosystem + +A tiered sale distributes tokens at predetermined fixed prices across +multiple sequential rounds, each with its own access rules, allocation +limits, and token quantity. The mechanism is well suited to projects +that have already established a valuation through prior fundraising, +community building, or market analysis and want to distribute tokens +in a controlled, phased manner to different investor classes. + +Tiered sales differ from the other two launchpad mechanisms in the +Logos ecosystem in a fundamental way: they do not perform price +discovery. A bonding curve +([RFP-015](./RFP-015-bonding-curve-launchpad.md)) discovers price +through supply progression, with each purchase moving the price higher. +An LBP ([RFP-016](./RFP-016-lbp-launchpad.md)) discovers price +through time-driven weight shifting, letting the market converge on +fair value over days. A tiered sale, by contrast, fixes the price per +tier before the sale opens. This makes tiered sales the right choice +when the project already knows its target price and wants deterministic +raise outcomes, and the wrong choice when price discovery is needed. + +The three mechanisms together give the Logos ecosystem a complete token +launch toolkit: bonding curves for early-stage projects that want to +reward early believers, LBPs for projects seeking broad community price +discovery, and tiered sales for projects with established valuations +distributing across investor tiers. + +### Fixed price per tier + +Each tier has a predetermined token price set by the sale creator at +creation time. The price does not change during a tier's active window. +This is the standard model across the ecosystem: Fjord Foundry's tiered +sales support per-tier price configuration [33], DAO Maker's SHO +allocates at a fixed price per round [12], and Polkastarter IDOs use +a single fixed price per sale [10]. + +Fixed pricing eliminates price uncertainty for both the project and +participants. Projects know exactly how much collateral they will raise +at each tier (assuming full subscription), and participants know their +exact entry price before committing. The tradeoff is that mispricing +is binary: if the price is set too high, the tier will not fill; if +set too low, the project leaves value on the table. Projects that want +the market to find the right price should use +[RFP-016](./RFP-016-lbp-launchpad.md) instead. + +### Minimum cap with auto-refund + +A minimum raise target can be configured for the entire sale. If the +total collateral raised across all tiers does not reach this minimum +by the time the final tier closes, all contributions are automatically +refunded to participants. Fjord Foundry's tiered sales support this +feature: if the minimum cap is not met, contributions are automatically +refunded [33]. Metaplex Genesis's Launch Pool also refunds depositors +if the funding goal is not met [16], and DAOs.fun provides full refunds +when the fundraise hard cap is not reached [21]. + +The auto-refund mechanism protects both participants and projects. It +prevents a project from launching with insufficient capital, and it +assures participants that their funds will be returned if the raise +fails to reach a viable threshold. + +### Per-wallet allocation limits + +Unlike the LBP and bonding curve launchpads (which cannot enforce +per-wallet limits for the private account path because each buy uses a +fresh ephemeral address), the tiered sale can enforce per-wallet +allocation limits for public account interactions. Each tier can +specify a minimum and maximum allocation per participant. + +For the private account path, per-wallet limits cannot be enforced +on-chain for the same reason as in RFP-015 and RFP-016: each buy from +a private account uses a fresh ephemeral public address, so the program +cannot link multiple buys to the same underlying participant. The +allowlist gate with limited entries per eligibility proof is the +recommended mitigation for the private account path: each allowlist +entry can be restricted to a single use via a nullifier, bounding total +allocation per eligible participant regardless of how many ephemeral +accounts they use. + +### Public sale state + +All tiered sale state is public on-chain (tier configuration, prices, +allocation limits, collateral raised per tier, open/closed status per +tier). As with [RFP-015](./RFP-015-bonding-curve-launchpad.md) and +[RFP-016](./RFP-016-lbp-launchpad.md), this is a deliberate +architectural choice. Public state enables permissionless price +verification, composability with other LEZ programs, and verifiable +sale analytics without cryptographic complexity in the sale program +itself. Participant privacy is enforced at the UX layer via the +optional deshield→buy→re-shield pattern, which does not require private +sale state. + +### Optional allowlist + +The allowlist gate is opt-in and configurable per tier: a seed tier +might require allowlist membership while the public tier is open to +all. When gating is needed (geographic restrictions, community-only +rounds, pre-selected investor lists), the creator can commit an +eligibility set at creation time and restrict buys to participants who +can prove inclusion. The implementation approach is left to the +proposing team. + +On LEZ, the relevant anonymity set for any private account action is +all private accounts in the zone, not the allowlist size. The +execution environment is shielded by construction: an observer cannot +determine which private account interacted with the sale, regardless +of whether an allowlist is active. This means an allowlist does not +degrade privacy in the way it would on a transparent chain, where +the anonymity set shrinks to the allowlist size (see the +[Allowlist Privacy in Shielded Execution Environments](../appendix/token-launchpad-ecosystem.md#allowlist-privacy-in-shielded-execution-environments) +section of the token launchpad ecosystem appendix). + +The recommended approach is ZK set membership proofs (a Merkle tree +commitment with a ZK inclusion proof) rather than a public address +list. This avoids publishing the allowlist on-chain and preserves the +zone-wide anonymity set regardless of allowlist size. When both the +allowlist gate and the private account path are enabled, the proposal +must document the resulting privacy properties and any reduction in +anonymity set relative to a non-gated sale. + +### Sale pause capability + +The pause function is an emergency stop for security incidents, +analogous to the freeze authority in +[RFP-002](./RFP-002-freeze-authority-poc.md). Pausing halts all +buy operations across all tiers. The pause does not affect tier +scheduling: if a tier's time window expires during a pause, it remains +closed when the sale resumes. This prevents a creator from gaming the +mechanism by pausing at a moment that is artificially favourable and +extending a tier's effective duration. + +### Fee structure + +This RFP does not mandate a specific fee rate. Proposals must +specify: (1) who pays the fee (issuer, buyer, or both), (2) when +fees are collected (per-transaction, at sale close, or both), +(3) the fee rate or rate range, and (4) where fees are routed +(protocol treasury, sale creator, burn, or other destination). See +the [Fee Structures](../appendix/token-launchpad-ecosystem.md#fee-structures) +section of the token launchpad ecosystem appendix for a +cross-platform comparison of fee models across seven surveyed +protocols. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Implement a tiered sale program on LEZ. A tiered sale consists of + one or more tiers (rounds), each with a fixed token price, a token + allocation, and an independent time window. Tiers execute + sequentially: a tier becomes active at its start timestamp and + closes at its end timestamp. No two tiers may have overlapping + active windows. +2. A sale creator can configure a sale with the following parameters: + 1. Collateral token (e.g., stablecoin or native token), shared + across all tiers. + 2. Project token, shared across all tiers. All project tokens for + all tiers must be deposited by the creator at sale creation. + 3. Per-tier configuration (one or more tiers), each with: + - Tier name or identifier (e.g., "Seed", "Private", "Public"). + - Token price (fixed, denominated in the collateral token). + - Token allocation (number of project tokens available in this + tier). + - Start and end timestamps. + - Optional: per-wallet minimum and maximum allocation limits + (enforced for public account interactions; see Design + Rationale for private account path limitations). + - Optional: private allowlist gate (see item 8 below), + configurable independently per tier. + 4. Optional: minimum raise target (minimum total collateral across + all tiers). If set, and the minimum is not met by the time the + final tier closes, all contributions are automatically refunded + (see item 6 below). +3. Participants buy project tokens from an active tier using either a + public account directly, or via the deshield→buy→re-shield + pattern for private account interaction (see + [RFP-008](./RFP-008-lending-borrowing-protocol.md)). Both paths + must be supported by the program and SDK. +4. A buy transaction specifies the collateral amount to spend. The + program computes the token output using the tier's fixed price. + If the requested amount would exceed the tier's remaining token + allocation, the transaction must revert (no partial fills). +5. After the final tier closes (and the minimum raise target is met, + if configured), the creator can withdraw: + - The collateral raised across all tiers, net of fees as defined + by the fee model specified in the proposal (see the Fee + structure subsection in Design Rationale). + - Any unsold project tokens remaining across all tiers. +6. Minimum raise with auto-refund: if a minimum raise target is + configured and the total collateral raised across all tiers does + not meet this target by the time the final tier closes, the sale + enters a refund state. In the refund state: (a) the creator + cannot withdraw collateral, (b) each participant can reclaim + their full collateral contribution, and (c) the creator can + reclaim all deposited project tokens once all participant refunds + have been processed or after a configurable claim window expires. +7. The sale creator can pause buying at any time during the sale + period (emergency stop). Pausing halts all buy operations across + all tiers. Tier time windows continue to advance during a pause; + if a tier's end timestamp passes while the sale is paused, that + tier is closed when the sale resumes. +8. The sale creator can enable an optional allowlist gate per tier. + When enabled for a tier, only participants who can prove inclusion + in the committed eligibility set may buy from that tier. Different + tiers can have different allowlists (e.g., a seed tier restricted + to investors, a public tier open to all). The proposing team must + specify and justify their allowlist mechanism in their application. + When the allowlist gate is used in conjunction with the private + account path, the proposal must document the resulting privacy + properties, including any change in the effective anonymity set + relative to a non-gated sale. +9. Allocation limit enforcement: for public account interactions, + the program must track cumulative spend per address per tier and + enforce the per-wallet minimum and maximum limits. A buy that + would cause the participant's cumulative allocation to exceed the + tier's maximum must revert. A buy below the tier's minimum must + also revert, unless the remaining tier allocation is less than + the minimum (in which case the minimum is waived to allow the + tier to fill completely). +10. Use Associated Token Accounts (ATAs) for all token interactions, + consistent with + [LP-0014](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0014.md) + and [RFP-008](./RFP-008-lending-borrowing-protocol.md). + +#### Usability + +1. Provide an SDK for building Logos modules that interact with the + tiered sale program. The SDK must expose the full lifecycle for + both participants (discover active sales, query tier status, buy, + query allocation, claim refund) and creators (create sale, + pause/resume, close, withdraw, configure tiers). The SDK must + support both direct public account interaction and the + deshield→buy→re-shield pattern for private account interaction. + When the private account path is used, the SDK must handle the + atomic deshield (both collateral and gas) as a single + indivisible user action. +2. Provide a Logos mini-app GUI with local build instructions, + downloadable assets, and loadable in Logos app (Basecamp) via + git repo. The mini-app must cover: + - **Participant view**: browse active sales with per-tier details + (price, allocation remaining, time window, allowlist status), + execute a buy, view purchase history, claim refund (if + applicable). + - **Creator view**: create a new sale (all parameters including + per-tier configuration and allowlist setup), monitor an active + sale (live tier progress, collateral raised per tier and total), + pause/resume, close sale, and withdraw proceeds. +3. Provide a CLI that covers core functionality of the program. + The CLI may have fewer features than the GUI mini-app but must + support all essential operations for both participants (buy, + query price, query tier status, check sale status, claim refund) + and creators (create sale, pause/resume, close, withdraw). +4. The mini-app must display a pre-buy confirmation summary before + each purchase: tier name, token price, exact tokens to be + received, collateral to spend, remaining tier allocation, and fee. +5. When using the private account path, the mini-app must display a + privacy disclosure before each buy, identifying what will be + visible on-chain (buy transaction, collateral amount, tokens + received, tier, sale address, ephemeral account) and what will + not be traceable (the buyer's private account and the subsequent + destination of purchased tokens). +6. When using the private account path, the mini-app must enforce + the atomic deshield, preventing a buyer from funding the + ephemeral account from any external source, which would create + an on-chain link to an existing identity. +7. When using the private account path, the mini-app must confirm + before each buy that the buyer's shielded balance covers both + the collateral amount and the gas fee within the single deshield + action. A clear, actionable error must be shown if the balance + is insufficient, preventing a partial deshield that could leave + funds stranded. +8. Provide a sale analytics view showing, for each active or + completed sale: total collateral raised (per tier and overall), + tier fill rates (percentage of allocation sold per tier), number + of buy transactions per tier, and time-to-fill for completed + tiers. Analytics must not expose individual participant identities + or link buy transactions to specific accounts. +9. Provide an IDL for the tiered sale program using the + [SPEL framework](https://github.com/logos-co/spel). +10. Failed or rejected buys must return clear, actionable error + messages (e.g., insufficient balance, tier not yet active, tier + ended, tier fully allocated, allowlist gate rejected, allocation + limit exceeded, sale paused, minimum not met for refund + eligibility). + +#### Reliability + +1. Sale state (collateral raised per tier, tokens remaining per tier, + cumulative allocations per participant) must remain consistent + under concurrent buy submissions. No double-spend or incorrect + sale accounting. +2. A failed buy must revert atomically: the buyer's collateral is + not consumed and the sale state is unchanged. +3. Refund state transition must be atomic: when the final tier closes + and the minimum raise target is not met, the sale must transition + to the refund state in the same transaction that processes the + final tier's close. No additional instruction should be required + to trigger the refund state. +4. Refund claims must be idempotent: a participant who has already + claimed a refund must not be able to claim again. The program must + track refund status per participant. + +#### Performance + +1. A single buy transaction completes within one LEZ transaction. +2. A refund claim completes within one LEZ transaction. +3. Document the compute unit (CU) cost of each operation: create + sale, buy, pause/resume, close sale, withdraw, claim refund. + Note the LEZ testnet version against which measurements were + taken. + +#### Supportability + +Proposals must include separate milestones for testnet 0.2, testnet 0.3, +and mainnet deployment. + +1. The tiered sale program is deployed and tested on LEZ testnet 0.2. +2. End-to-end integration tests run against a LEZ sequencer + (standalone mode) and are included in CI. CI must be green on + the default branch. +3. Every hard requirement in Functionality, Usability, Reliability, + and Performance has at least one corresponding test. Test + coverage must include: happy-path buy across multiple tiers, + tier allocation exhaustion, per-wallet limit enforcement (accept + and reject), allowlist gate accept and reject, minimum raise met + (creator withdrawal), minimum raise not met (refund flow), + sale pause during active tier, tier time window expiry. +4. A README documents end-to-end usage: deployment steps, program + addresses, and step-by-step instructions for both creators and + participants via CLI and mini-app. +5. Provide a privacy and anonymisation properties document covering: + what on-chain state and transaction data is visible to observers; + what data is protected when the private account path is used; + trust assumptions, specifying which guarantees are enforced by + the on-chain program and which depend on correct client + behaviour; and what happens if a user bypasses the expected + interaction path. +6. The program is updated and verified on LEZ testnet 0.3. +7. The program is deployed to LEZ mainnet. + +#### + Privacy + +1. The mini-app and SDK must support both direct public account + interaction and the deshield→buy→re-shield pattern for private + account interaction. When a user chooses the private account + path, the SDK must enforce the complete deshield→buy→re-shield + pattern; the re-shield step must not be skippable. +2. When using the private account path, the mini-app must display + the pre-confirmation privacy summary described in the Usability + section before each buy operation, identifying what is visible + on-chain (buy amount, tier, sale address, ephemeral intermediary + account) and what remains private (the originating private + account, the destination of re-shielded tokens, and any link + between separate buys by the same user). +3. When using the private account path, the SDK must validate that + the re-shield target for purchased tokens is a private (shielded) + account before submitting the transaction, and reject with an + explicit error if it is not. +4. The ephemeral public account created during the deshield step + must never be reused across operations. Each buy from a private + account must use a freshly generated account with no prior + on-chain history. + +### Privacy Architecture + +All tiered sale state is public on-chain (tier configuration, prices, +allocation limits, collateral raised per tier, tokens remaining per +tier, open/closed status per tier, minimum raise target, refund state). +This is a deliberate architectural choice: public state enables +permissionless price verification (participants can confirm the +exact price and allocation before buying), composability with other +LEZ programs, and verifiable sale analytics without cryptographic +complexity in the sale program itself. + +User privacy is optionally enforced at the UX layer. The mini-app +and SDK support both direct public account interaction and private +account interaction via the deshield→buy→re-shield pattern. When +users opt to interact from a private account, the SDK must enforce +the complete pattern as described below. + +#### Interaction flow + +For every buy from a private account: + +1. The buyer initiates from their private account. The SDK + deshields to a **fresh, single-use** public account (account A) + with no prior on-chain history. The deshield atomically + transfers both the collateral token and enough native token for + gas in a single indivisible action. +2. Account A executes the buy against the active tier. +3. Account A re-shields the purchased project tokens to the buyer's + private account. Account A is never reused. + +> **Gas:** Both collateral and gas must come exclusively from the +> deshield in step 1. Funding account A from any external source +> (such as a CEX withdrawal or a known wallet) creates an +> on-chain link to an existing identity and breaks the privacy +> guarantee. The SDK must make this impossible; the atomic deshield +> is a single, indivisible user action. + +#### What is public (observable on-chain) + +- All sale state: token pair, tier configuration (names, prices, + allocations, time windows), collateral raised per tier, tokens + remaining per tier, minimum raise target, sale status. +- All buy transactions: collateral spent, tokens received, tier, + and timestamp. When using the private account path, the buyer's + address is an ephemeral intermediary account with no prior + on-chain history. +- Allowlist gate configuration per tier and whether the gate is + enabled, but not the list of eligible addresses. +- Sale close, creator withdrawal, and refund transactions. + +#### What is private (when using the private account path) + +- Which private account originated the collateral for a buy. +- Where purchased tokens go after re-shielding. +- Any link between multiple buys by the same buyer (no on-chain + linkability across ephemeral accounts). +- Whether a specific private account participated in the sale + at all. +- Which tier a specific private account participated in (buys + across tiers from the same private account use different + ephemeral accounts). + +#### Trust assumptions + +The privacy guarantees above depend on the buyer using an SDK or +client that correctly implements the full deshield→buy→re-shield +pattern. The tiered sale program itself cannot enforce the re-shield +step: a buyer who calls the program directly or uses a non-conforming +client could skip the re-shield, leaving purchased tokens in the +ephemeral public account and breaking their own anonymity. The +program enforces correctness of the buy (price computation, tier +validation, allocation limits); the privacy pattern is enforced by +the SDK, not by the on-chain program. Buyers who bypass the SDK +accept full responsibility for any resulting privacy loss. + +### Known Limitations + +**Per-wallet allocation limits are not enforceable for the private +account path.** Enforcing a cap on cumulative spend per participant +requires tracking spend per address. For public account interactions +this is straightforward, but is fundamentally incompatible with the +private account path: each buy from a private account uses a fresh +ephemeral public address with no prior history, so the program +cannot link multiple buys to the same underlying participant. The +allowlist gate with nullifier-based single-use entries is the +recommended mitigation: each allowlist entry permits one buy per +tier, bounding total allocation per eligible participant regardless +of how many ephemeral accounts they use. Projects that need strict +concentration limits for all participants should use the allowlist +gate on all tiers. + +### Soft Requirements + +- **Buyer token vesting**: at sale close, purchased tokens can be + routed directly into a vesting schedule (see + [RFP-017](./RFP-017-token-vesting.md)) rather than transferred + to the buyer immediately, enabling a sale-plus-vesting flow in a + single operation. +- **Partial fills**: instead of reverting when the remaining tier + allocation is less than the requested buy amount, the program + fills the order partially (selling only the remaining tokens) and + returns the excess collateral. This improves UX for the last buyer + in a tier. +- **Creator collateral vesting**: the sale creator can configure an + optional vesting schedule for the raised collateral at sale + creation time. When configured, the close or withdraw operation + deposits collateral into the vesting program (see + [RFP-017](./RFP-017-token-vesting.md)) instead of transferring + it directly to the creator's account, providing participants with + assurance that the project will not receive all funds immediately. + +## ⚠ Platform Dependencies + +This RFP is open for proposals. However, full implementation is +blocked until the hard dependencies below are delivered. Proposers +may begin design and development work, but a working on-chain +deployment requires both LP-0015 and an on-chain clock to be +available. + +### Hard blockers + +#### On-chain clock / timestamp + +The tiered sale mechanism is time-driven: each tier becomes active +at its start timestamp and closes at its end timestamp, and the +minimum raise target is evaluated when the final tier closes. +Without a reliable on-chain timestamp, tier activation and close +cannot be enforced. LEZ does not yet have on-chain block time (see +also [RFP-016](./RFP-016-lbp-launchpad.md), which has the same +dependency for LBP weight progression). + +#### General cross-program calls (LP-0015) + +A buy operation must: (1) call the token program to transfer +collateral from the buyer into the sale account, (2) compute the +token output using the tier's fixed price, (3) call the token program +again to transfer project tokens to the buyer, and (4) update sale +state (collateral raised, tokens remaining, per-wallet allocation +tracking). Without general cross-program calls, the execution cannot +continue after the first token program call, making it impossible to +complete the full buy atomically. + +[LP-0015](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0015.md) +(General cross-program calls via tail calls) solves this. This prize +is currently **open**. + +### Soft blockers + +#### Event emission (LP-0012) + +Analytics dashboards and sale monitoring services need to react to +sale events (buy executed, tier opened, tier closed, sale entered +refund state). Without structured events, off-chain services must +poll all accounts. + +[LP-0012](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md) +(Structured events for LEZ program execution) is currently **open**. + +## 👤 Recommended Team Profile + +Team experienced with: + +- Fixed-price token sale and IDO smart contract design +- Solana or SVM program development (Anchor or native) +- DeFi smart contract security and auditing practices +- Escrow and refund mechanism design +- Front-end development for token sale applications + + +## ⏱ Timeline Expectations + +Estimated duration: **10-12 weeks** + + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + +## Evaluation Criteria + +Proposals that meet all hard requirements will be ranked on the +following criteria. + +| Criterion | Weight | What we look for | +|-----------|--------|-----------------| +| Technical design quality | 30% | Formal specification of tier state management, refund mechanism, allocation tracking, integer arithmetic strategy, audit plan | +| Privacy architecture | 25% | Strength of anonymity properties in the private account path, completeness of the deshield→buy→re-shield flow, allowlist privacy interaction (if applicable), nullifier-based allocation enforcement | +| Team experience | 20% | Prior token sale, IDO, or escrow protocol work, smart contract security track record, familiarity with SVM or similar execution environments | +| Timeline and milestones | 15% | Realistic schedule with concrete deliverables, risk identification, dependency management (especially LP-0015) | +| Ecosystem alignment | 10% | Open source commitment, composability with other LEZ programs (vesting, DEX), community engagement plan | + +## Resources + +- [Logos Documentation](https://github.com/logos-co/logos-docs) +- [RFP-015: Privacy-Preserving Token Launchpad (Bonding Curve)](./RFP-015-bonding-curve-launchpad.md) + (companion launchpad RFP using the bonding curve mechanism) +- [RFP-016: Privacy-Preserving Token Launchpad (LBP)](./RFP-016-lbp-launchpad.md) + (companion launchpad RFP using the LBP mechanism) +- [RFP-008: Lending & Borrowing Protocol](./RFP-008-lending-borrowing-protocol.md) + (reference for the public/private account interaction pattern used + across LEZ applications) +- [RFP-017: Privacy-Preserving Token Vesting](./RFP-017-token-vesting.md) + (soft requirement: post-sale vesting integration) +- [Appendix: Token Launchpad Ecosystem](../appendix/token-launchpad-ecosystem.md) + (survey of existing launchpad protocols, scale data, refund + mechanisms, and tiered sale data) + +- [LP-0013: Token program improvements: mint authorities](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0013.md) +- [LP-0014: Token program improvements: ATAs + wallet tooling](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0014.md) +- [Fjord Foundry tiered sale documentation](https://help.fjordfoundry.com/fjord-foundry-docs/for-sale-creators/seed-private-and-public-rounds) +- [SPEL framework](https://github.com/logos-co/spel) + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, +please use **Discussions**. diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md new file mode 100644 index 0000000..38abd1b --- /dev/null +++ b/appendix/token-launchpad-ecosystem.md @@ -0,0 +1,772 @@ +# Appendix: Token Launchpad Ecosystem + +This appendix surveys existing token launchpad protocols and related +infrastructure across the Ethereum and Solana ecosystems. It serves +as a reference for +[RFP-015](../RFPs/RFP-015-bonding-curve-launchpad.md), +[RFP-016](../RFPs/RFP-016-lbp-launchpad.md), and +[RFP-018](../RFPs/RFP-018-tiered-sale-launchpad.md), providing +context on current market participants, their mechanisms, and design +trade-offs. + +## Protocols Considered + +Protocols are ordered by cumulative scale (largest first) and this +order is maintained throughout the document. + +| Protocol | Ecosystem | Mechanism | Website | +| ---------------- | ---------------------- | ---------------------------------------------------------- | ------------------------------------------------- | +| Pump.fun | Solana | Constant-product bonding curve | [pump.fun](https://pump.fun/) | +| Fjord Foundry | Ethereum (multi-chain) | LBP (Balancer-based), tiered sales (Seed/Private/Public) | [fjordfoundry.com](https://www.fjordfoundry.com/) | +| Metaplex Genesis | Solana | Launch Pool (proportional), presale, uniform price auction | [metaplex.com](https://www.metaplex.com/) | +| DAO Maker | Ethereum | SHO (Strong Holder Offering), DYCO | [daomaker.com](https://daomaker.com/) | +| Flaunch | Base (Ethereum L2) | Bonding curve via Uniswap V4 hooks | [flaunch.gg](https://flaunch.gg/) | +| Polkastarter | Ethereum, BNB Chain | Fixed-price IDO with lottery allocation | [polkastarter.com](https://polkastarter.com/) | +| DAOs.fun | Solana | Fixed-price fair launch for investment DAOs | [daos.fun](https://daos.fun/) | + +Balancer is the protocol layer that provides the weighted pool +primitive underlying the LBP mechanism. Fjord Foundry (originally +Copper, rebranded after merger) is the primary launchpad platform +built on Balancer LBPs. LBPs can also be deployed directly on +Balancer via smart contract interaction; Fjord provides the no-code +interface used by most projects. The LBP mechanism has been in +continuous production use since 2021, with 717 LBPs launched, +106,762 cumulative participants, and over $1.1B in funds raised +across the Fjord Foundry platform [5][6]. + +## Scale and Traction + +The tables below use cumulative volume (trading volume or total +funds raised, depending on availability) and protocol revenue as +scale metrics. + +DAOs.fun is omitted from this section due to insufficient +quantitative data. + +### Cumulative scale + +Protocols ranked by cumulative volume (trading volume or total +funds raised, depending on availability). + +| Protocol | Cumulative Volume | Cumulative Revenue | Tokens Launched | Data as of | +|---|---|---|---|---| +| Pump.fun | >$150B (trading volume) [1] | $818M+ (protocol fees) [1][2] | 11.7M (H1 2025) [4] | Early 2026 | +| Fjord Foundry | ~$1.5B (swap volume) [22] | ~$55M (est.) [a] | 717 LBPs; 106,762 participants [6] | Sep 2025 | +| Metaplex Genesis | ~$55-70M (est. funds raised) [d] | $36M+ (all Metaplex products) [7] | 20M+ fungible tokens [7] | Nov 2025 | +| DAO Maker | $90M+ (total raised) [8] | ~$4.5M (est.) [b] | N/A | Undated | +| Flaunch | N/A | $3.1M [9] | N/A | Q1 2026 | +| Polkastarter | $46M+ (total raised) [10] | ~$460K (est.) [c] | 105+ projects [10] | Q1 2022 | + +\[a] Estimated as 5% fee [11] applied to $1.1B cumulative raised [5]. +\[b] Estimated as 5% fee [12] applied to $90M+ cumulative raised [8]. +\[c] Estimated as 1% fee [13] applied to $46M+ cumulative raised [10]. +Figure is from Q1 2022; no updated aggregate has been published. +\[d] Estimated from Genesis protocol revenue ($1.1M, Jul to Nov 2025) +divided by 2% deposit fee [16]. Genesis launched in July 2025 (alpha); +no 2024 data exists. + +### Yearly breakdown + +Where per-year data exists. Blank cells indicate no data available +for that period. + +| Protocol | Metric | 2024 | 2025 | 2026 (YTD) | +|---|---|---|---|---| +| Pump.fun | Trading volume (est.) | ~$32B [e] | ~$58B [e] | ~$8B (Q1) [e] | +| Pump.fun | Protocol revenue | ~$321M [14] | ~$583M [14] | ~$82M (Q1) [14] | +| Metaplex Genesis | Funds raised (est.) | N/A (launched Jul 2025) | ~$55-70M [d] | | +| Metaplex | Protocol revenue (all products) | ~$12-15M (est.) [7] | ~$27-30M (est.) [7] | | +| Flaunch | Protocol revenue | | ~$3.1M [9] | $100.6K (Q1) [9] | +| Fjord Foundry | Cumulative raised (all sales) | >$1.1B (since 2021; no per-year split) [5] | | | +| DAO Maker | Total raised | $90M+ (cumulative; no per-year split) [8] | | | +| Polkastarter | Total raised | $46M+ (cumulative as of Q1 2022; stale) [10] | | | + +\[e] Implied from quarterly protocol fees divided by 1% fee rate [14]. +Actual trading volume may differ due to fee-exempt transactions or +variable fee tiers. + +**Caveats:** + +- Metric types differ across protocols (trading volume vs. funds + raised vs. protocol revenue). Cross-category comparisons should + account for this. Pump.fun's trading volume includes secondary DEX + trading on Pumpswap, not only bonding curve sales. +- Fjord Foundry, DAO Maker, and Polkastarter do not publish per-year + breakdowns. +- Polkastarter's aggregate figure dates from Q1 2022; current + cumulative total is likely higher but unpublished. +- Metaplex Genesis launchpad revenue is a small fraction of total + Metaplex protocol revenue; most Metaplex revenue comes from Token + Metadata fees charged to platforms like Pump.fun [7]. + +## Refund Mechanisms + +Most crypto-native launchpads treat purchases as final: once a buyer +executes a swap or deposit, there is no platform-level refund. Notable +exceptions exist: Fjord Foundry's tiered sales (Seed, Private, Public +rounds) support a minimum cap with automatic refunds if the target is +not met [33]; DAO Maker's DYCO product offers a 16-month post-purchase +refund window [15]; and DAOs.fun allows redemption during the +fundraising phase with a 10% penalty [21]. Regulatory frameworks are moving in +the opposite direction: EU MiCA mandates a 14-day cooling-off period +for white paper offerings [19], and US Reg CF requires a 48-hour +cancellation window plus a mandatory minimum raise threshold [20]. + +### Summary + +| Protocol | Post-purchase refund | Minimum raise (soft cap) | Cancellation during sale | +|---|---|---|---| +| Pump.fun | No | No | No | +| Fjord Foundry (LBP) | No [11] | No [11] | Sell back at market price (buy+sell mode only) [11] | +| Fjord Foundry (tiered sales) | No | Yes (minimum cap; auto-refund if unmet) [33] | No | +| Metaplex Genesis | No [d] | Yes (Launch Pool only) [16] | Yes (Launch Pool: withdraw before claim window; 2% fee) [16] | +| DAO Maker (DYCO) | Yes: 16 months, USDC-backed, burn on refund [15] | No | Yes: unconditional within window [15] | +| DAO Maker (SHO) | No [12] | No | No | +| Flaunch | No [17] | No | No | +| Polkastarter | No [18] | No | No | +| DAOs.fun | No (AMM exit + mandatory expiry distribution) [21] | Yes (hard cap; refund if unmet) [21] | Yes: redeem during fundraising (10% penalty) [21] | + +\[d] Metaplex Genesis Launch Pool allows withdrawal during the deposit +window (before tokens are distributed). If the funding goal is not +met, depositors receive a full refund [16]. Once the claim window +opens and tokens are distributed, purchases are final. + +### Per-protocol detail + +**Pump.fun.** No refund mechanism. Bonding curve purchases are +irreversible AMM swaps. Once a token graduates to Pumpswap, it trades +on the open market with no platform-level buyer protection. + +**Fjord Foundry.** Refund properties differ by sale type. For LBPs: +no refund mechanism [11]. LBP purchases are AMM swaps and are final +once executed. In buy+sell mode, participants can sell tokens back +into the pool during the sale at the current market price (not at +their purchase price). After the LBP ends, tokens are distributed +and there is no refund path. No minimum raise threshold exists; the +sale runs regardless of demand. For tiered sales (Seed, Private, +Public rounds): Fjord supports a minimum cap setting; if the target +is not met, contributions are automatically refunded [33]. This +refund feature does not apply to LBPs. + +**Metaplex Genesis.** The Launch Pool mechanism provides partial buyer +protection: depositors can withdraw during the deposit window (subject +to a 2% fee), and if the funding goal is not met, all deposits are +refunded [16]. However, once the claim window opens and tokens are +distributed, there is no refund. Presale and Uniform Price Auction +modes have no refund mechanism. + +**DAO Maker (DYCO).** The Dynamic Coin Offering is the only +crypto-native mechanism with a post-purchase performance refund [15]. +All tokens sold are backed 1:1 by USDC in a smart contract for 16 +months after the Token Generation Event. Participants can return +tokens at any time within this window to receive the original USDC +price; returned tokens are burned, reducing circulating supply. If the +token price falls below the refund price on the secondary market, +arbitrageurs can buy cheaply and refund at the higher price, creating +a reliable price floor. DYCO is a specialized product; most DAO Maker +sales use the SHO model, which has no refund mechanism. + +**Flaunch.** No refund mechanism [17]. The 30-minute fixed-price fair +launch phase is one-directional (buyers cannot sell during this +window). After graduation to standard AMM pricing, tokens trade freely +with no platform-level refund. + +**Polkastarter.** No refund mechanism [18]. Fixed-price IDO purchases +are atomic swaps and are final once executed. Participants who are +allowlisted but have not yet purchased can choose not to participate, +but there is no post-purchase cancellation. + +**DAOs.fun.** Structured refund mechanism with three phases [21]. +During the 7-day fundraising window, contributors can redeem their SOL +at any time, subject to a 10% early redemption penalty. If the +fundraising hard cap is not reached, contributors receive a full +refund. After a successful raise, there is no direct refund: token +holders can sell on the virtual AMM at market price, or wait for the +mandatory fund expiration (3 months to 1 year, set by the creator at +launch), at which point remaining assets are distributed +proportionally and token holders can burn tokens to redeem underlying +SOL. + +### Regulatory context + +Two regulatory frameworks mandate buyer refund rights for token sales: + +- **EU MiCA** (Markets in Crypto-Assets Regulation): requires a 14-day + right of withdrawal for crypto-asset purchases made under a white + paper offering [19]. This applies to any platform operating in the + EU. +- **US Regulation CF** (crowdfunding): requires a 48-hour cancellation + window before the offering deadline, a mandatory minimum raise + threshold (all funds returned if the target is not met), and + automatic cancellation if material changes are made to the offering + terms (investors must reconfirm within 5 business days) [20]. + +Neither framework applies directly to permissionless, non-custodial +on-chain launchpads. However, they indicate a regulatory direction +toward mandatory cooling-off periods for token sales. + +## Allowlist & Access Control + +Launchpad access models range from fully permissionless (any wallet +can participate) to fully gated (mandatory KYC and token staking). +Among the crypto-native launchpads surveyed, the majority default to +open access; gating is either absent or optional. + +### Summary + +| Protocol | Default access | Gating method | Enforcement | +|---|---|---|---| +| Pump.fun | Open (permissionless) | None | N/A | +| Fjord Foundry | Open; optional project whitelist | CSV whitelist upload by creator [11] | Off-chain (platform UI) | +| Metaplex Genesis | Configurable per-launch | Wallet allowlist, optional KYC, geo-blocking [16] | On-chain (smart contract) | +| DAO Maker (SHO) | $DAO stakers + KYC | Token staking (min 2,000 $DAO) + mandatory platform KYC [12] | Hybrid (on-chain staking, off-chain KYC) | +| Flaunch | Open (permissionless) | None | N/A | +| Polkastarter | $POLS stakers + per-project KYC | Token staking (min 1,000 POLS) + lottery + per-project KYC [10] | Hybrid (on-chain staking, off-chain KYC) | +| DAOs.fun | Creators: invitation-only; Buyers: open | Invite codes for creators; none for buyers [21] | Platform-level | + +### Per-protocol detail + +**Pump.fun.** Fully permissionless [1]. No allowlist, KYC, or access +restrictions. Any wallet can create or buy tokens. + +**Fjord Foundry.** Permissionless by default for LBPs [11]. Project +creators can optionally upload a CSV whitelist to restrict +participation, enforced at the platform UI level (not on-chain). +The $FJO token is not required for participation. LBPs also provide +structural anti-bot protection via high starting price. + +**Metaplex Genesis.** Most configurable access control among the +platforms studied [16]. Creators can choose open access, wallet +allowlist, or KYC-gated launches, all enforced on-chain at the +smart contract level. Supports per-wallet deposit limits and +geo-blocking. The Launch Pool's proportional distribution mechanism +provides some natural Sybil resistance: allocation is proportional +to deposit size, so splitting across wallets yields no advantage. + +**DAO Maker.** Mandatory $DAO staking (minimum 2,000 $DAO) plus +platform-level KYC [12]. A seven-tier system based on staked amount +(250 to 100,000 $DAO) assigns non-linear bonus multipliers (DAO +Power). Higher tiers receive disproportionate allocation advantages. +SHO priority rounds serve high-tier holders first, then remaining +allocation opens as FCFS. + +**Flaunch.** Fully permissionless [17]. Built on Uniswap V4 hooks +with no access restrictions. No allowlist, KYC, or token-gating. + +**Polkastarter.** $POLS staking (minimum 1,000 POLS Power) with a +7-day minimum hold requirement [10]. A lottery system weighted by +POLS Power allocates spots. KYC is delegated to individual projects +(not centralized by the platform). Guaranteed allocation is +available only at the highest tier (50,000+ POLS). + +**DAOs.fun.** Creator access is invitation-only (invite codes from +the team) [21]. Buyer participation is open once a DAO is live, +with no KYC or staking requirement. The 10% early redemption penalty +serves as an economic Sybil deterrent during the fundraising window. + +### Per-buyer allocation limits + +Per-wallet or per-buyer allocation limits are available on platforms +that use fixed-price or proportional distribution mechanisms. No +bonding curve platform (Pump.fun, Flaunch, Meteora DBC) implements +per-buyer limits; bonding curves are open AMM pools where any wallet +can submit unlimited buy transactions, and the mechanism does not +track cumulative spend per address. + +Among fixed-price and tiered sale platforms: + +- **Fjord Foundry tiered sales** support explicit per-user minimum + and maximum allocation limits, configurable independently per tier + (Seed, Private, Public) [33]. The creator sets the min/max at sale + creation time. Enforcement is on-chain: the smart contract tracks + cumulative spend per address per tier and reverts buys that would + exceed the maximum. +- **Metaplex Genesis** supports per-wallet deposit limits enforced + on-chain at the smart contract level [16]. The Launch Pool's + proportional distribution also provides natural Sybil resistance: + allocation is proportional to deposit size, so splitting across + wallets yields no advantage. +- **DAO Maker** enforces allocation limits indirectly through its + seven-tier staking system [12]. Allocation per participant is a + function of DAO Power (a non-linear multiplier derived from staked + $DAO amount), not an explicit min/max cap. Higher tiers receive + disproportionate allocation advantages; the minimum staking + threshold (2,000 $DAO) functions as a de facto minimum allocation + gate. +- **Polkastarter** uses $POLS Power weighted lottery allocation [10]. + Guaranteed allocation requires staking 50,000+ POLS. Below this + threshold, allocation is probabilistic (lottery). The staking + requirement functions as an implicit per-user limit, but the + platform does not expose explicit min/max configuration to the + sale creator. + +## Tiered Sale Mechanisms + +Four of the surveyed protocols support multi-round or tiered +distribution: Fjord Foundry (Seed, Private, Public rounds), DAO +Maker (SHO priority tranches then public), Polkastarter (fixed-price +IDO with lottery allocation), and Metaplex Genesis (multiple inflow +buckets per launch). The table below compares the tiered or phased +sale features of each. + +| Feature | Fjord Foundry [33] | DAO Maker SHO [12] | Polkastarter [10] | Metaplex Genesis [16] | +|---|---|---|---|---| +| Round structure | Seed, Private, Public (sequential) | Priority tranches by tier, then FCFS public | Single round with lottery allocation | Multiple inflow buckets (presale + launch pool) | +| Per-tier pricing | Yes (fixed price per round) | Fixed price per round | Single fixed price | Fixed price (presale); proportional (launch pool) | +| Per-user allocation limits | Min/max per tier | Tier-weighted allocation (DAO Power multiplier) | POLS Power weighted lottery | Per-wallet deposit limits (on-chain) | +| Minimum raise / auto-refund | Yes (minimum cap; auto-refund if unmet) | No | No | Yes (Launch Pool: refund if funding goal not met) | +| Allowlist per round | Yes (sale-level CSV whitelist; not per-tier) | Implicit via $DAO staking tiers | Implicit via $POLS staking + lottery | Yes (per-launch: wallet allowlist, optional KYC, geo-blocking) | +| Pause capability | Yes (creator pauses swaps) | Platform-level only | Not documented | Not documented | + +### Per-platform detail + +**Fjord Foundry tiered sales.** Fjord's tiered sale product supports +three sequential rounds (Seed, Private, Public), each with +independently configurable token amounts, prices, and per-user +min/max allocation limits [33]. Wallet limits apply per tier, not +across the entire sale: a participant can buy from multiple tiers +up to each tier's individual cap. A minimum cap can be set for the +entire sale; if the target is not met, contributions are +automatically refunded [33]. The whitelist (CSV upload) applies at +the sale level, not per tier; all whitelisted addresses have access +to all tiers. Tiered sale volume is not broken out from Fjord's +overall platform statistics (717 LBPs, $1.1B+ cumulative raised +[5][6]), so the scale of tiered sales specifically is unknown. + +**DAO Maker SHO.** The Strong Holder Offering uses a seven-tier +system based on staked $DAO amount (250 to 100,000 $DAO), with +non-linear bonus multipliers (DAO Power) that determine allocation +size [12]. Higher tiers receive priority access in early tranches; +remaining allocation opens as first-come-first-served. Allocation +per participant is a function of tier level, not an explicit min/max +cap. The cumulative raised across all SHO sales is $90M+ [8]. No +minimum raise or auto-refund mechanism exists; purchases are final. + +**Polkastarter IDO.** Fixed-price IDOs with a single price per sale +and hard cap [10]. Participation requires $POLS staking (minimum +1,000 POLS Power) and a lottery weighted by staked amount. Guaranteed +allocation is available only at the highest tier (50,000+ POLS). The +mechanism is effectively single-round with tiered access priority +rather than sequential rounds with different prices. No minimum raise +or auto-refund. Cumulative raised: $46M+ across 105+ projects [10]. + +**Metaplex Genesis.** Supports multiple inflow buckets per launch, +enabling a presale round (allowlisted wallets, fixed price) followed +by a public launch pool (open, proportional distribution) [16]. The +Launch Pool distributes tokens proportionally to all depositors +rather than on a first-come-first-served basis, providing natural +Sybil resistance: splitting across wallets yields no advantage. +Per-wallet deposit limits are enforced on-chain. If the funding goal +is not met, depositors receive a full refund [16]. Estimated total +funds raised during the alpha period (July to November 2025): +$55-70M [d]. + +### Design patterns + +Across the four platforms, three patterns emerge that inform the +design of a tiered sale on LEZ: + +1. **Sequential rounds with independent pricing.** Fjord is the only + platform that supports per-round fixed pricing in a multi-round + structure [33]. DAO Maker and Polkastarter use a single price with + tiered access priority. Metaplex separates presale (fixed price) + from launch pool (proportional), but these are different mechanisms + rather than sequential rounds of the same type. + +2. **Minimum raise with auto-refund.** Fjord tiered sales [33] and + Metaplex Genesis Launch Pool [16] both support a minimum raise + threshold with automatic refund if unmet. This is the standard + buyer protection for fixed-price sales. DAO Maker SHO and + Polkastarter do not offer this. + +3. **Per-user allocation enforcement.** All four platforms enforce + allocation limits, but through different mechanisms: explicit + min/max caps (Fjord [33], Metaplex [16]), staking-tier-weighted + allocation (DAO Maker [12], Polkastarter [10]). On a + privacy-preserving platform where per-wallet tracking is + incompatible with the private account path, the allowlist gate + with nullifier-based single-use entries is the closest analogue + to explicit per-user caps. + +4. **Per-tier access control.** No surveyed platform supports + per-tier allowlists: Fjord's CSV whitelist applies at the sale + level (all whitelisted addresses can access all tiers) [33], + and Metaplex's allowlist is per-launch rather than per-bucket + [16]. DAO Maker and Polkastarter gate access via staking tiers, + which function as implicit access control but are not + configurable per round. A per-tier allowlist (e.g., a seed tier + restricted to investors while the public tier is open) is a + natural extension of the tiered sale concept that none of these + platforms currently implement. + +## Fee Structures + +Fee models vary widely across launchpad protocols, from zero-fee +permissionless deployment to enterprise pricing tiers exceeding +$50,000. The table below summarises fee structures for the seven +crypto-native launchpads surveyed in this appendix. + +| Protocol | Issuer Fee | Buyer Fee | Setup Cost | Staking Required | +|---|---|---|---|---| +| Pump.fun | 0% | 1% (protocol fee on trades) [1][2] | Free | None | +| Fjord Foundry | 5% of collateral raised [11] | Swap fee only (1–2% typical) [11] | Free | None | +| Metaplex Genesis | 0% (fee on deposits) [16] | 2% on deposits [16] | Free | None | +| DAO Maker | 5% of tokens [12] | 5% (DAO SHO) / 30% (Public SHO) [12] | Undisclosed | 2,000–100,000 $DAO ($28–$1,400+) [12] | +| Flaunch | Undisclosed | Swap fee (Uniswap V4) [17] | Free (gas only) | None | +| Polkastarter | ~1% of raised [13] | Network gas only [10] | Undisclosed | 1,000–50,000 POLS ($300–$25,000) [10] | +| DAOs.fun | 10% early redemption penalty [21] | None during fundraise; AMM fee post-launch [21] | Free | None | + +### Per-protocol detail + +**Pump.fun.** Zero issuer fee for token creation; the protocol +charges a 1% fee on all trades executed through its bonding curve and +Pumpswap DEX [1][2]. This buyer-side-only model minimises friction +for token creators and has been a primary driver of Pump.fun's scale +(11.7M tokens launched in H1 2025). The fee is collected per +transaction at swap time. + +**Fjord Foundry.** Charges issuers 5% of collateral raised at sale +close [11]. Buyers pay only the pool swap fee, typically configured +at 1–2% by the sale creator. No upfront setup cost and no native +token requirement ($FJO is not needed for participation). The 5% +issuer fee is competitive for a managed platform that provides a +no-code UI and marketing distribution. + +**Metaplex Genesis.** Zero issuer fee; the protocol charges a 2% +fee on buyer deposits [16]. Setup is free (gas costs only on +Solana). No native token requirement. The depositor-pays model is +unusual: it makes launches maximally cheap for issuers while +shifting costs to participants. + +**DAO Maker.** Charges issuers 5% of tokens allocated to the sale +[12]. Buyer fees depend on tier: DAO SHO participants pay 5% of +allocated tokens; Public SHO participants pay 30% unless they hold +at least 2,000 $DAO [12]. Setup costs are undisclosed and negotiated +per project. The staking requirement (2,000 to 100,000 $DAO) is the +primary access gate and functions as an additional implicit cost. + +**Flaunch.** Built on Uniswap V4 hooks with no disclosed +platform-level fee beyond Uniswap swap fees [17]. Token creation +costs only gas. No staking requirement. Revenue is generated through +swap fee accumulation in the hook mechanism. + +**Polkastarter.** Charges issuers approximately 1% of funds raised +[13]. Buyers pay only network gas. However, participation requires +staking 1,000 to 50,000 POLS tokens ($300 to $25,000), which +functions as a significant implicit cost [10]. Guaranteed allocation +requires 50,000+ POLS. + +**DAOs.fun.** No traditional issuer or buyer fee during the +fundraise window [21]. The 10% early redemption penalty during the +7-day fundraise serves as both a Sybil deterrent and a revenue +mechanism. After a successful raise, tokens trade on a virtual AMM +with standard swap fees. + +### Design implications + +Across the seven protocols, the sustainable fee range clusters +around 1–2% per transaction or 5% at close. Pump.fun (1% buyer +fee) and Metaplex Genesis (2% deposit fee) represent the low end; +Fjord Foundry (5% issuer fee) represents the upper bound for +crypto-native platforms. Fees above 5% are found only in +enterprise-regulated platforms (Republic, Securitize) serving +institutional markets [23]. Staking requirements (DAO Maker, +Polkastarter) function as hidden fees: they impose a capital lockup +cost of $300 to $25,000+ and create plutocratic access barriers +where participation rights scale with token holdings rather than +genuine interest in the project. + +## Sale Lifecycle and Close Mechanics + +Sale lifecycle controls span a wide spectrum, from fully +centralised platform management to immutable on-chain parameters +with no admin override. The table below summarises close triggers, +pause capabilities, and post-close behaviour for the surveyed +protocols. + +| Protocol | Auto-Close Triggers | Emergency Pause | Post-Close Behaviour | Enforcement | +|---|---|---|---|---| +| Pump.fun | Supply target (bonding curve graduation) [1] | No | Auto-migration to Pumpswap DEX [1] | On-chain (Solana program) | +| Fjord Foundry | Time expiry; optional hardcap [11] | Yes (creator pauses swaps) [11] | Manual claim; collateral to creator minus 5% fee [11] | Hybrid (on-chain pause + platform UI) | +| Metaplex Genesis | Deposit window close (time-based) [16] | Not documented | Auto-distribute proportional (Launch Pool); FCFS (Presale); refund if goal not met [16] | On-chain (Solana program) | +| DAO Maker | Time window expiry [12] | Platform-level only [12] | Manual claim; vesting per project [12] | Hybrid (off-chain allocation + on-chain claim) | +| Flaunch | 30-minute fixed-price window expiry [17] | Not documented | Auto-graduation to Uniswap V4 AMM [17] | On-chain (Uniswap V4 hook) | +| Polkastarter | Hardcap reached; time expiry [10] | Not documented | Atomic swap (immediate token receipt) [10] | On-chain (swap) + off-chain (allowlist) | +| DAOs.fun | Fundraise hard cap; 7-day window expiry [21] | Not documented | Fund manager deploys capital; mandatory expiry distribution [21] | On-chain (Solana program) | + +### Centralisation spectrum + +The protocols studied fall along a spectrum from fully +decentralised to fully centralised lifecycle control [24]: + +- **Permissionless immutable** (Pump.fun, Metaplex Genesis): + parameters locked at creation; no admin override possible. The + sale runs to completion or fails according to on-chain rules. +- **Creator-controlled** (Fjord Foundry, Flaunch): smart contract + gives the sale creator pause and resume capability; the platform + adds a UI layer but does not override on-chain state. +- **Platform-controlled** (DAO Maker, Polkastarter): the platform + manages the full lifecycle with off-chain allocation and + on-chain claim. Issuers have limited on-chain autonomy. + +DAOs.fun occupies a middle position: fundraise parameters are set +at creation and enforced on-chain, but post-raise fund deployment +is delegated to a human fund manager with discretionary authority. + +### Per-protocol detail + +**Pump.fun.** The bonding curve closes automatically when the supply +target is reached (graduation threshold), triggering migration of +liquidity to Pumpswap [1]. There is no pause, no manual close, no +time-based expiry, and no admin override. Post-graduation, the token +trades on the open DEX market. Curves that never reach the graduation +threshold remain as dormant on-chain accounts indefinitely. The +graduation rate is very low: approximately 1.4% historically [30], +dropping to 0.7% to 0.8% in mid-2025 [31]. This means over 98% of +launched tokens become zombie sales with no close mechanism and no +way for the creator to reclaim deposited tokens. No bonding curve +platform in the ecosystem (Pump.fun, Meteora DBC, Flaunch, Raydium +LaunchLab) implements an optional time-based close to address this +[32]. + +**Fjord Foundry.** The sale creator can pause swaps during an LBP +(reversible) or cancel a Fixed Price Sale before it starts [11]. +LBPs close when the time window expires or when an optional hardcap +is reached. After close, participants manually claim tokens through +the platform; the creator receives collateral minus the 5% platform +fee. + +**Metaplex Genesis.** Deposit windows close on a time basis [16]. +The Launch Pool distributes tokens proportionally to all depositors; +if the funding goal is not met, depositors receive a full refund. +No documented emergency pause or admin override exists at the +protocol level. + +**DAO Maker.** Lifecycle is fully platform-controlled [12]. Sales +open and close on a schedule managed by the DAO Maker team. Buyers +claim tokens after the sale; vesting schedules are project-specific. +The DYCO variant adds a 16-month refund window backed by USDC +reserves [15]. + +**DAOs.fun.** The 7-day fundraise window closes automatically on +time expiry or when the hard cap is reached [21]. If the cap is +not met, contributors receive a full refund. After a successful +raise, the fund manager deploys capital; at the mandatory expiry +date (3 months to 1 year), remaining assets are distributed +proportionally to token holders. + +## LBP Pricing Mechanism + +The Liquidity Bootstrapping Pool pricing mechanism originates from +Balancer's weighted pool primitive. Fjord Foundry uses the same +underlying formulas. The core components are weight interpolation, +a spot price function, and a swap output function. + +### Weight interpolation + +At any point in time `t`, the token weight is linearly interpolated +between its start and end values: + +``` +w_token(t) = w_start + (w_end - w_start) × (t - t_start) / (t_end - t_start) +w_collateral(t) = 1 - w_token(t) +``` + +Where `w_start` is the initial token weight (e.g., 0.99), `w_end` +is the final token weight (e.g., 0.01), `t_start` and `t_end` are +the sale start and end timestamps, and `t` is the current block +timestamp. The function is linear and continuous over the sale +duration [29]. + +### Spot price + +At any reserve state, the spot price of the project token in terms +of collateral is: + +``` +price = (reserve_collateral × w_token) / (reserve_token × w_collateral) +``` + +As weights shift (`w_token` decreases, `w_collateral` increases), +the price naturally falls even if reserves are unchanged. This is +the mechanism behind the LBP's declining price curve [29]. + +### Swap output (buy formula) + +Given a collateral input `C_in`, the token output is computed using +the Balancer weighted pool swap formula: + +``` +tokens_out = reserve_token × (1 - (reserve_collateral / (reserve_collateral + C_in)) ^ (w_collateral / w_token)) +``` + +After each buy, `reserve_token` decreases by `tokens_out` and +`reserve_collateral` increases by `C_in` [29]. + +### Lazy weight computation + +Modern Balancer (v2/v3) and Fjord Foundry use lazy computation: +every swap triggers weight recalculation based on the block +timestamp and the stored weight schedule. No external `pokeWeights` +call is required for correct pricing; the on-chain price always +reflects the current weight at transaction time [29]. Older Balancer +v1 implementations required explicit poke transactions to advance +the weight schedule, which created stale-weight arbitrage +opportunities when pokes were delayed. + +### Pause and weight progression + +When a sale creator pauses swaps (available on Fjord Foundry and +Balancer pools created with the `canPauseSwapping` permission), +the weight schedule continues to advance because weights are +time-based, not trade-based [11][29]. This prevents a creator from +pausing at a weight that is artificially favourable and resuming +after detecting large buy orders. + +## Allowlist Privacy in Shielded Execution Environments + +On a transparent chain, an allowlist directly degrades participant +privacy: if the allowlist contains 50 addresses and a purchase is +observed on-chain, the observer knows the buyer is one of 50. +The anonymity set equals the allowlist size, potentially reducing +k-anonymity from millions of active wallets to a small, enumerable +group [25][26]. + +In a shielded execution environment such as LEZ, this framing is +misleading. LEZ private account activity is shielded by +construction: an observer sees that some private account performed +an action, but cannot determine which account or what action. The +relevant anonymity set is therefore all private accounts in the +zone, not the allowlist [25]. The allowlist determines eligibility, +not visibility. + +### Privacy-permissioning tradeoff + +The privacy properties of an allowlist depend on both the allowlist +design and the execution environment. + +| Allowlist Design | Observer can enumerate allowlist? | Observer can link buyer to entry? | Anonymity set | +|---|---|---|---| +| Public address list on transparent chain | Yes | Yes (via transaction origin) | Size of allowlist | +| Public address list on ZK private zone (LEZ) | Yes | No (shielded execution) | All private accounts in zone | +| Private allowlist with ZK set membership | No | No | All accounts that could prove membership | +| No allowlist on transparent chain | N/A | Yes (public transaction) | All active wallets | +| No allowlist on ZK private zone (LEZ) | N/A | No | All private accounts in zone | + +In LEZ, both a public address allowlist and a private ZK +allowlist achieve the same practical privacy level as no allowlist +at all, because the execution environment's shielding prevents +linking buyers to allowlist entries. The allowlist restricts +eligibility without degrading privacy [25]. + +### ZK set membership proofs + +The recommended approach for allowlist enforcement in a privacy- +preserving context is a ZK set membership proof based on a Merkle +tree commitment [25][27][28]: + +1. The sale creator builds a Merkle tree over hashed allowlist + entries and publishes only the Merkle root on-chain. +2. A participant proves knowledge of a leaf and a Merkle path such + that `MerkleVerify(root, leaf, path) = true`, without revealing + which leaf they hold. +3. A nullifier (derived from the leaf) prevents the same allowlist + entry from participating twice, providing Sybil resistance + without revealing identity. + +This construction is a standard cryptographic primitive, used in +production by Tornado Cash (withdrawal proofs), Semaphore (anonymous +group signalling), and proposed for privacy-preserving KYC in +zk-creds [27]. For implementations on LEZ, this approach avoids +publishing the allowlist on-chain and preserves the zone-wide +anonymity set regardless of allowlist size. + +## References + +1. CoinDesk, "Most Influential: Pump.fun," Dec 2025. + https://www.coindesk.com/coindesk-news/2025/12/10/most-influential-pump-fun +2. Tokenomics.com, "Pump.fun Tokenomics: How Pump Distributes $45M + Monthly to Holders," Feb 2026. + https://tokenomics.com/articles/pumpfun-tokenomics-how-pump-distributes-45m-monthly-to-holders +3. CoinLaunch, "Pump.fun Overview," Jul 2025. + https://coinlaunch.space/projects/pumpfun/ +4. Metaplex Foundation, "H1 2025 Recap." + https://www.metaplex.foundation/blog/articles/metaplex-1h-25-recap +5. Fjord Foundry homepage (cumulative raised figure), accessed Apr + 2026. https://www.fjordfoundry.com/ +6. Bitbond, "Fjord Foundry Review," Sep 2025. +7. Messari, "State of Metaplex" quarterly reports; Metaplex Foundation + blog monthly roundups, 2023-2025. + https://www.metaplex.foundation/blog/ +8. CoinMarketCap, "What is DAO Maker." + https://coinmarketcap.com/alexandria/article/what-is-dao-maker +9. DefiLlama, "Flaunch Protocol," accessed Apr 2026. + https://defillama.com/protocol/flaunch +10. Polkastarter blog, "How to Participate in a Polkastarter IDO" and + "All You Need to Know About POLS Power." + https://blog.polkastarter.com/how-to-participate-in-a-polkastarter-ido/ +11. Fjord Foundry, "LBP FAQ." + https://help.fjordfoundry.com/fjord-foundry-docs/for-sale-creators/faqs-creators/lbp-faq +12. DAO Maker, GitBook documentation. + https://dao-maker-1.gitbook.io/dao-maker +13. Polkastarter fee details partially inferred from CryptoRank and + platform documentation; exact percentage not prominently published. +14. Yahoo Finance, "Pump.fun Quarterly Revenue," Dec 2025; AInvest, + Jan 2026. +15. DAO Maker, "DYCO: Dynamic Coin Offering." + https://learn.daomaker.com/dyco +16. Metaplex, "Genesis: Launch Pool" developer documentation. + https://developers.metaplex.com/smart-contracts/genesis +17. Flaunch documentation and Bankless, "How to Launch Better + Memecoins on Flaunch." + https://docs.flaunch.gg/ ; + https://www.bankless.com/read/how-to-launch-better-memecoins-on-flaunch +18. Polkastarter, "How to Participate in a Polkastarter IDO." + https://blog.polkastarter.com/how-to-participate-in-a-polkastarter-ido/ +19. EU Markets in Crypto-Assets Regulation (MiCA), right of withdrawal + provisions; Shoosmiths, "Consumer Protection for Crypto Assets." + https://www.shoosmiths.com/insights/articles/heating-up-consumer-protection-for-crypto-assets +20. US Regulation CF, 17 CFR §227. + https://www.ecfr.gov/current/title-17/chapter-II/part-227 +21. ChainCatcher, "daos.fun: The next liquidity black hole?" Oct 2024; + Bitget News, "daos.fun: The next liquidity black hole?" Oct 2024; + Blocmates, "Daos.fun is Shaking Up the Crypto Memecoin Space," + Jan 2025. + https://www.chaincatcher.com/en/article/2149146 +22. RootData, "Fjord Foundry" project page (swap volume figure), + accessed Apr 2026. +23. Fee Structure Comparison research note (internal), compiled from + official documentation for each platform, Apr 2026. Sources: + DAO Maker GitBook, Fjord Foundry LBP FAQ, Metaplex Genesis docs, + Balancer protocol fee docs, Republic issuer pricing, Securitize + fee schedule. +24. Sale Lifecycle & Close Mechanics research note (internal), + compiled from official documentation and smart contract + repositories, Apr 2026. Sources: Balancer CRP source code, + Fjord Foundry LBP FAQ, Metaplex Genesis docs, Securitize DS + Protocol, Republic early close help, TokenSoft token contracts. +25. Allowlist Privacy and K-Anonymity Analysis research note + (internal), Apr 2026. +26. zk-X509: Practical Anonymous Credentials for X.509 Certificates, + arXiv:2603.25190, Mar 2026 (Merkle anonymity set analysis). + https://arxiv.org/html/2603.25190v1 +27. Choudhuri et al., "zk-creds: Flexible Anonymous Credentials + from zkSNARKs," IEEE S&P 2023. + https://obj.umiacs.umd.edu/ieeesp23/zk-creds.pdf +28. Privacy-Preserving Smart Contracts using zkSNARKs, + arXiv:2501.03391, Jan 2025. + https://arxiv.org/pdf/2501.03391 +29. Balancer, "Weighted Math" and "Liquidity Bootstrapping FAQ," + Balancer v2 documentation. + https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-math.html ; + https://balancer.gitbook.io/balancer/smart-contracts/smart-pools/liquidity-bootstrapping-faq +30. Bitget, "Pump.fun statistics," citing Dune Analytics, Aug 2024. + https://www.bitget.com/news/detail/12560604442705 +31. The Defiant, "Pump.fun graduation rate drops," mid-2025. + https://www.thedefiant.io/news/defi/pump-fun-graduation-rate-drops +32. Bonding Curve Time-Based Close Mechanisms research note + (internal), compiled from Pump.fun, Meteora DBC, Flaunch, + Raydium LaunchLab documentation, Apr 2026. +33. Fjord Foundry, "Seed, Private and Public Rounds: Can I refund + participants if my sale doesn't hit the minimum cap?" + https://help.fjordfoundry.com/fjord-foundry-docs/for-sale-creators/seed-private-and-public-rounds#can-i-refund-participants-if-my-sale-doesnt-hit-the-minimum-cap