From 3c4e8f7b07d33a5d1f1a3f3323eebe254e90d337 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 27 Mar 2026 16:43:10 +1100 Subject: [PATCH 01/30] Token launchpads and vesting --- README.md | 3 + RFPs/RFP-015-bonding-curve-launchpad.md | 564 ++++++++++++++++++++++++ RFPs/RFP-016-lbp-launchpad.md | 512 +++++++++++++++++++++ RFPs/RFP-017-token-vesting.md | 458 +++++++++++++++++++ 4 files changed, 1537 insertions(+) create mode 100644 RFPs/RFP-015-bonding-curve-launchpad.md create mode 100644 RFPs/RFP-016-lbp-launchpad.md create mode 100644 RFPs/RFP-017-token-vesting.md diff --git a/README.md b/README.md index a82a03b..b81d6cd 100644 --- a/README.md +++ b/README.md @@ -62,6 +62,9 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | 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-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 | draft | Applications & Integrations | — | +| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | $XXXXX | draft | Applications & Integrations | — | +| RFP-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | $XXXXX | draft | Applications & Integrations | — | | 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-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md new file mode 100644 index 0000000..34f2a9f --- /dev/null +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -0,0 +1,564 @@ +--- +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. An optional private allowlist gate enables +projects to restrict participation without exposing the eligibility set +on-chain. + +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 processed over $1B in 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 now the dominant 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. + +The virtual-reserve model enables automatic post-sale liquidity +seeding: the creator deposits the full token supply `Vt` upfront, of +which `Vt − D` tokens are held in reserve alongside the accumulated +collateral at graduation, forming a complete AMM pool that can be +seeded to a DEX without any post-close action from the creator. This +removes the coordination failure risk present in manual post-sale +liquidity provisioning. + +## 🏗 Design Rationale + +### Constant product AMM with virtual reserves + +The required pricing mechanism is the **constant product AMM with +virtual reserves**, as used by pump.fun and Meteora's Dynamic Bonding +Curve. It is chosen 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 +Functionality requirement 1. + +### 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. Time-based end is retained as a soft +requirement for projects that need a hard deadline. + +### One-directional sale + +The sale is one-directional: buyers purchase tokens from the curve; +there is no sell-back path during the sale. This is the correct choice +for a token launch: it prevents reflexive sell pressure during the +distribution window, simplifies pool accounting, and removes the attack +surface of circular buy-sell cycles. The accumulated collateral reserve +is locked until close and either withdrawn by the creator or used to +seed a DEX pool (see auto-graduation in Soft Requirements). + +Optional sell-back (two-way curve) is a soft requirement for projects +that want continuous liquidity from day one rather than a bounded +sale-plus-DEX-seed model. + +### 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. + +### Optional allowlist + +The allowlist gate is optional: many projects want permissionless open +sales. 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. + +### 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. The allowlist gate (restricted early access) and +per-transaction buy limits (see Functionality requirement 2) are +available mitigations, but neither eliminates the advantage entirely. +Projects seeking the strongest bot-deterrence properties should use +RFP-016 instead. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Implement a bonding curve program on LEZ using the constant product + AMM with virtual reserves. The program must maintain the invariant + `Vt × Vc = k` across all buy operations, where `Vt` is the virtual + token reserve and `Vc` is the virtual collateral reserve. The buy + instruction accepts a collateral input `C_in`; the token output + must be computed as: + + ``` + tokens_out = Vt - k / (Vc + C_in) + ``` + + The SDK must also expose the inverse: the exact collateral cost + for a buyer who requests a specific token quantity `Q`: + + ``` + C_in = k / (Vt - Q) - Vc + ``` + + After each buy, `Vt` and `Vc` must be updated to preserve `k`. + The real token reserve decreases by `tokens_out`; the real + collateral reserve increases by `C_in`. If the computed + `tokens_out` would exceed the remaining real token reserve, the + transaction must revert. The invariant `k` must never change after + creation. +2. A sale creator can configure a sale with the following parameters: + - Token pair (project token + collateral token). + - Virtual token reserves `Vt`: the total project token supply + deposited by the creator into the curve program at creation. + All `Vt` tokens must be transferred from the creator at sale + creation. + - Virtual collateral reserves `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`. + - Sale quantity `D`: the number of tokens made available for + purchase (`D < Vt`). The remaining `Vt − D` tokens are held + in reserve within the program for post-graduation DEX seeding. + `D` is also the supply target: the sale auto-closes when `D` + tokens have been sold. + - Optional: minimum raise threshold (see item 6 below). + - Optional: per-transaction buy limit (maximum collateral amount + spendable in a single buy transaction). + - Optional: private allowlist gate (see item 8 below). +3. Participants buy project tokens from the curve 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), 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 real token reserve reaches + zero (supply target `D` reached). The creator can also close the + sale manually at any time before the target is reached. +5. After the sale closes, the creator can withdraw: + - The real collateral raised (net of fees). + - The reserved `Vt − D` tokens (if not used for auto-graduation). +6. The sale creator may configure an optional minimum raise threshold + at creation time. If the creator closes the sale manually before + the supply target is reached, and the real collateral reserve is + below this threshold, the sale enters a **refund state**: no + further withdrawals are permitted by the creator, and buyers who + purchased via a public account may submit a refund claim to + recover their collateral (see Reliability requirement 4). Refunds + for buyers who used the private account path are not supported + (see Known Limitations). If the supply target is reached + automatically (full sell-through), the minimum raise check is + skipped; a complete sell-through always succeeds. +7. Slippage protection: 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. +8. The sale creator can enable an optional allowlist gate. When + enabled, only participants who can prove inclusion in the + committed eligibility set may buy from the curve. The proposing + team must specify and justify their allowlist mechanism in their + application. +9. The sale creator can pause buying at any time during the sale + (emergency stop). Pausing does not affect the curve state, the + virtual reserves, or the invariant `k`. +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 + 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, + 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 current spot + price, real token 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`, allowlist configuration), + monitor an active sale (live supply progress, collateral + raised), 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: collateral to spend, exact tokens to be received + (computed using the constant product 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, sale paused, allowlist gate rejected, slippage + exceeded, per-transaction buy limit 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 real token reserve reaches zero, the sale must close + atomically in the same transaction. No additional close + instruction should be required; no further buys must be accepted + after close. +4. If a sale enters refund state (minimum raise not met after manual + close), the program must maintain per-buyer purchase records for + all public-account purchases, enabling each buyer to claim their + collateral refund independently. Refund claims must be + idempotent: a buyer cannot claim the same purchase twice. +5. The creator cannot withdraw collateral while the sale is in + refund state. + +#### 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, refund claim (if applicable). + Note the LEZ testnet version against which measurements were + taken. + +#### Supportability + +1. The bonding curve program is deployed and tested on LEZ + devnet/testnet. +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), allowlist gate accept and reject, auto-close on supply + target, manual close with minimum raise met, manual close with + minimum raise not met (refund path), refund claim by buyer, + pause/resume, per-transaction buy limit enforcement. +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. + +#### + 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 constant product +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`, real token 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. +- 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. + +### Known Limitations + +**Per-wallet buy limits are not supported for the private account +path.** Enforcing a cap on cumulative spend per participant requires +tracking spend per address. For public account interactions this is +feasible, but is 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 per-transaction buy limit (Functionality +requirement 2) is a partial mitigation: it bounds the collateral +spendable in a single buy, which raises the cost of rapid accumulation, +but it does not prevent a single participant from submitting many +transactions. Projects that need strong concentration limits should +use the allowlist gate to restrict the eligible set. + +**Refunds are not supported for the private account path.** If a sale +enters refund state (minimum raise not met after a manual close), +collateral refunds can only be processed for buyers who transacted via +a public account. Buyers who used the private account path have no +on-chain link between their private account and their purchase, so +the program cannot route a refund to them. The mini-app must display +a disclosure when buying via the private path if a minimum raise is +configured. + +**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. The allowlist gate and +per-transaction buy limit reduce the impact but do not eliminate it. +Projects requiring stronger bot deterrence should use +[RFP-016](./RFP-016-lbp-launchpad.md) instead. + +### Soft Requirements + +- **Alternative curve formula**: teams may propose a different + pricing model (such as a polynomial integral, the Bancor power + function, or a piecewise constant product as used in Meteora + DBC) in their application. Alternative formulas must be + accompanied by a formal specification, a security argument for + the invariant being preserved, and citations to existing + production implementations or audits. Proposals using the + specified constant product model require no additional + justification. +- **Two-way (sell-back) curve**: after purchasing tokens, holders + can sell them back to the curve, receiving collateral from the + real reserve. The sell formula is the inverse of the buy formula: + `C_out = Vc - k / (Vt + tokens_in)`. This transforms the bonding + curve from a one-time sale vehicle into a continuous liquidity + source, but introduces reflexive sell pressure during the sale + window; proposals including this feature must address the + implications for the minimum raise mechanism. +- **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 reserved `Vt − D` + 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. +- **Time-based sale end**: support an optional end timestamp in + addition to the supply target, closing the sale at whichever + condition is reached first. +- **Integration with 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. This enables a sale-plus-vesting flow + in a single operation. + +## ⚠ 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, refund claimed). 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**. + + +## 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-017: Privacy-Preserving Token Vesting](./RFP-017-token-vesting.md) + (soft requirement: post-sale vesting integration) +- [RFP-004: Privacy-Preserving DEX](./RFP-004-privacy-preserving-dex.md) + (soft requirement: auto-graduation target) + +- [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..e991ad5 --- /dev/null +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -0,0 +1,512 @@ +--- +id: RFP-016 +title: "Privacy-Preserving Token Launchpad: LBP" +tier: XL +funding: $XXXXX +status: draft +category: Applications & Integrations +--- + + +# RFP-016: Privacy-Preserving Token Launchpad: LBP + +## 🧭 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. The team building this should have strong experience in +AMM or order-book design, SVM program development, and DeFi +application security. Familiarity with weighted AMM pool mechanics +(Balancer-style) and the Logos privacy interaction model is strongly +recommended. + +## 🔥 Why This Matters + +LBPs have become the dominant mechanism for fair, permissionless token +price discovery. 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)). +The mechanism deters bots (price starts above fair value and falls +unless buying pressure counteracts it) 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 over bonding curves, fixed-price, Dutch auction, and sealed-bid auction + +Four alternative mechanisms exist for token sales: bonding curve, +fixed-price (set a price upfront, sell until allocation runs out), +Dutch auction (price declines on a curve until all tokens clear), and +sealed-bid auction +([LP-0004](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0004.md)). +LBP is chosen as the primary mechanism because it is the only one +that does not require the project to pre-set a valuation. + +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) 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. + +LBP addresses these problems by running 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 strong empirical track record (Fjord Foundry, +Copper, Balancer) and is well understood by the DeFi builder +community. + +A bonding curve (constant product AMM with virtual reserves, as used +by pump.fun and Meteora DBC) is a proven supply-driven mechanism and +is available as a companion launchpad in +[RFP-015](./RFP-015-bonding-curve-launchpad.md). It is not chosen +as the primary mechanism here for two reasons. First, a bonding curve +opens at its lowest price: buyers who act first pay the least, +rewarding speed over conviction and creating a strong incentive for +bots to snipe at the first block of the sale. An LBP opens above +estimated fair value and the price falls over time, making early +sniping unprofitable. Second, bonding curve pricing is +formula-driven (price is a deterministic function of supply) rather +than market-driven: the curve cannot reflect what buyers collectively +believe fair value to be, only where they are willing to buy relative +to the formula. Projects where early-entry incentives are intentional +(rewarding founding community members with a lower entry price) are a +better fit for RFP-015. + +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 optional: 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. + +### 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. + +### Minimum raise as an optional parameter + +The minimum raise threshold protects buyers: if a sale fails to reach +the floor, all collateral is returned and the project does not receive +funds from a failed launch. This mirrors standard crowdfunding +protections and prevents projects from extracting liquidity from +low-conviction raises. + +## ✅ 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: + - Token pair (project token + collateral token). + - Start and end weights (e.g., 99/1 → 1/99 for the + token/collateral ratio). + - Sale start and end timestamps. + - Initial token deposit amount. + - Optional: minimum raise (sale is considered failed and + collateral is refunded to the creator if the minimum is not + reached by close). + - 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, or when the sale creator + explicitly closes the sale, the creator can withdraw: + - The collateral raised (net of fees). + - 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. +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. +4. The minimum raise check at close time must be evaluated against + final pool state, not an intermediate snapshot. If the minimum + is not met, all collateral is returned to the creator and all + project tokens are returned to the creator (not burned). + +#### 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 + +1. The launchpad program is deployed and tested on LEZ + devnet/testnet. +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, minimum raise + not met refund path, 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. + +#### + 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. + +### 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. +- Integration with the token vesting program (see + [RFP-017](./RFP-017-token-vesting.md)): at sale close, purchased + tokens can be routed directly into a vesting schedule rather than + returned to the buyer's private account. This enables + sale-plus-vesting in a single flow. +- Support for a Dutch auction mode (price declines on a configurable + curve over time; buyers transact at the current price as it falls, + with earlier buyers paying more than later ones). + +## ⚠ Platform Dependencies + +This RFP remains in **draft** until the dependencies below are +resolved. LEZ has similar programming capabilities to Solana but +several primitives required by a token launchpad are not yet +available. + +### Hard blockers + +These must be available on LEZ before this RFP can open. + +#### 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**. + +### Soft blockers + +Desirable but the RFP can open without them. + +#### 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) + +- [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-017-token-vesting.md b/RFPs/RFP-017-token-vesting.md new file mode 100644 index 0000000..de622b5 --- /dev/null +++ b/RFPs/RFP-017-token-vesting.md @@ -0,0 +1,458 @@ +--- +id: RFP-017 +title: Privacy-Preserving Token Vesting +tier: L +funding: $XXXXX +status: draft +category: Applications & Integrations +--- + + +# RFP-017: Privacy-Preserving Token Vesting + +## 🧭 Overview + +Build a token vesting program on LEZ that locks project, team, or +investor tokens against configurable time-based schedules (cliff, +linear, or milestone-based). Recipients can claim vested tokens +directly from a public account, or via a deshield→claim→re-shield +pattern for private account interaction: when the private path is +used, the claim is executed from a fresh, single-use public account, +and the output is immediately re-shielded to the recipient's private +account, making the link between the claim and the recipient's +private identity untraceable on-chain. + +Token vesting is a prerequisite for credible token launches. Every +protocol that issues a token must lock some allocation for founders, +early contributors, or ecosystem reserves. The team building this +should have experience with SVM program development and DeFi token +mechanics. Familiarity with the optional public/private account +interaction pattern (see +[RFP-008](./RFP-008-lending-borrowing-protocol.md)) is strongly +recommended. + +## 🔥 Why This Matters + +On transparent chains, vesting contracts (Streamflow, Sablier, +Team.Finance) are surveillance tools: every cliff unlock, every +linear release, and every claim is publicly linkable to a beneficiary +address, exposing token unlock schedules to the market and enabling +adversarial trading against known unlock events. A Solana founder's +vesting cliff is trivially queryable on-chain; traders index these +events and position against them before the beneficiary can act. + +On LEZ, the optional deshield→claim→re-shield pattern makes claims +unlinkable to the recipient's private identity. Observers see that +tokens were claimed from a vesting schedule; they cannot determine +which private account holds those tokens or trace subsequent +movements. This makes LEZ the only environment where teams can vest +tokens without creating a public unlock calendar for adversarial +front-running. + +Vesting is also a composition primitive. A launchpad (see +[RFP-016](./RFP-016-lbp-launchpad.md)) or investor round on LEZ +needs vesting to be in place before tokens can be distributed to +contributors and early backers. This RFP is a direct prerequisite +for a credible token economy on LEZ. + +## 🏗 Design Rationale + +### Three schedule types: cliff+linear, fully linear, milestone + +These three types cover the full range of real-world vesting +relationships without unnecessary complexity. + +**Cliff + linear** is the industry standard for team and investor +allocations. The cliff (commonly 1 year) prevents immediate selling +at TGE and signals that insiders have a long-term commitment. Linear +release after the cliff aligns incentives continuously over the +remaining period; recipients have ongoing reason to contribute. +This pattern is used in virtually every serious protocol's team +allocation. + +**Fully linear** (no cliff) is appropriate for ongoing contributors +(advisors, contractors) where there is no fixed start date requiring +a binary lock-up, or for grant programmes where disbursement should +begin immediately. + +**Milestone-based** serves deliverable-oriented relationships: +grants, partnerships, or service agreements where time-based vesting +is economically incorrect. Unlocking tokens when a milestone is +achieved rather than when a date passes better reflects the nature +of the obligation. Importantly, milestone authority stays with the +creator, not an on-chain oracle; this is intentional: the +conditions for milestone completion are often qualitative and cannot +be reliably evaluated on-chain. + +### Beneficiary as public account address + +A ZK commitment-based beneficiary (where the schedule creator +commits to a hash of the beneficiary's key and the recipient proves +knowledge of the preimage at claim time) would hide who is in the +schedule. This is excluded as a hard requirement for two reasons. + +First, in virtually all vesting contexts the parties already know +each other: a project knows its co-founders, investors, and grant +recipients. Hiding the beneficiary's address from on-chain observers +does not change the information available to the other party in the +relationship. + +Second, the infrastructure required (a ZK membership proof +compatible with the LEZ account model) overlaps with LP-0003, which +is itself a draft prize not yet delivered. Building on an undelivered +dependency would block this RFP. + +The principal privacy concern (adversarial trading against known +unlock events) is addressed by the re-shield claim pattern. Even +if an observer knows that a specific address holds a vesting +schedule, they cannot track where claimed tokens go or link +subsequent on-chain activity to that address. A future RFP or +upgrade can introduce commitment-based beneficiaries once LP-0003 +is complete. + +### Cancellation semantics + +Unvested tokens return to the creator on cancellation; already- +vested but unclaimed tokens remain claimable by the beneficiary. +This reflects the economic reality of the relationship: vested +tokens are earned compensation that cannot be revoked. Unvested +tokens represent future commitment not yet earned, and returning +them to the creator on early termination is the industry standard, +as used by Streamflow, Sablier, and Team.Finance alike. Burning +unvested tokens would destroy value unnecessarily and make the +program harder to adopt. + +### Transferable positions as a creation-time flag + +Whether a vesting position is transferable to a new beneficiary +address is set at creation and cannot be changed afterwards. For +employment vesting, the incentive is personal; the position should +be non-transferable so the token lock applies specifically to the +individual. For investor positions, secondary transfers may be +needed (assignment of rights, secondary market sales of locked +tokens). Allowing this to be configured at creation but frozen +afterwards avoids mid-schedule ambiguity: all parties know the +rules when the schedule is created and cannot change them +unilaterally later. + +### Batch creation + +Token launches routinely create 10–50 vesting schedules +simultaneously (co-founders, advisors, early contributors, investor +tranches). Creating them one-by-one is gas-expensive and +error-prone. Batch creation is a practical necessity, not a +nice-to-have, for any real-world launch. The batch size is bounded +by the LEZ transaction size limit, which the implementation must +document. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Implement a vesting program on LEZ that locks tokens in escrow + against a configured schedule. The program must support: + - **Cliff + linear vesting**: tokens become claimable in a lump + sum at the cliff date, then linearly over the remaining + duration (e.g., 1-year cliff, 3-year linear release). + - **Fully linear vesting**: no cliff; tokens accrue continuously + from the start date. + - **Milestone-based vesting**: the schedule creator explicitly + signals completion of discrete tranches; each signal unlocks + a fixed token amount for the beneficiary to claim. +2. The schedule creator specifies the beneficiary as a public + account address at schedule creation. Recipients can claim + vested tokens directly from that public account, or via a + deshield→claim→re-shield flow: a gas-only deshield funds a + fresh single-use public account that submits the claim and + immediately re-shields the output to the recipient's private + account. The schedule creator does not learn the recipient's + private account address from this interaction. +3. The schedule creator can cancel an active schedule at any time, + returning the unclaimed, unvested token balance to the creator's + account. Tokens already vested but not yet claimed remain + claimable by the beneficiary after cancellation. +4. The schedule creator can configure whether the vesting position + (beneficiary rights) is transferable to a new public account + address. Transferability must be set at schedule creation and + cannot be changed afterwards. +5. Multi-recipient batch creation: a creator can set up vesting + schedules for multiple recipients in a single operation, up to + the LEZ transaction size limit. Document the maximum number of + recipients achievable in one transaction. +6. The program emits a log event (using the LEZ event/log mechanism; + see + [LP-0012](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md)) + for each state transition: schedule creation, claim, + cancellation, milestone signal, and beneficiary transfer. Event + schema must be documented. + +#### Usability + +1. Provide an SDK that can be used to build Logos modules + interacting with the vesting program. The SDK must expose the + full lifecycle: create schedule, query claimable amount, claim, + cancel, signal milestone, and transfer beneficiary. The SDK must + support both direct public account interaction and the + deshield→claim→re-shield pattern for private account + interaction. When the private account path is used, the SDK must + handle the gas-only deshield as a single indivisible 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 at minimum: + - **Recipient view**: current vesting position, total locked, + amount claimable now, next unlock event, claim action. + - **Creator view**: create a new schedule (all parameters), + list active schedules, cancel a schedule, signal a milestone. +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: create schedule, claim, + cancel, signal milestone, and query claimable amount. +4. The mini-app must display a pre-claim confirmation summary: + claimable amount and estimated transaction fee. When using the + private account path, it must also confirm that the recipient's + shielded balance covers the gas-only deshield; a clear, + actionable error must be shown if the balance is insufficient. +5. When using the private account path, the mini-app must display + a privacy disclosure before each claim, identifying what will + be visible on-chain (claim amount, ephemeral public account + address, vesting schedule program address) and what will not be + traceable (the recipient's private account and the subsequent + destination of claimed tokens). +6. Provide an IDL for the vesting program using the + [SPEL framework](https://github.com/logos-co/spel). +7. Failed claims must return clear, actionable error messages, + including the case where nothing is yet claimable (with the + next unlock time displayed). + +#### Reliability + +1. A claim is atomic: a failed or rejected claim does not consume + vested tokens and leaves the claimant able to retry without + loss. +2. A schedule cancellation is atomic: partial failure leaves the + schedule in its prior state, not an undefined one. +3. Concurrent claims against independent schedules must not corrupt + shared program state. +4. Milestone signalling is idempotent per milestone index: + signalling the same milestone twice must be rejected with a + deterministic error and must not double-unlock tokens. + +#### Performance + +1. A single claim completes within one LEZ transaction. +2. Document the compute unit (CU) cost of each operation: create + schedule, claim, cancel, signal milestone, transfer beneficiary. + Note the LEZ testnet version against which measurements were + taken, as the per-transaction compute budget may change. + +#### Supportability + +1. The vesting program is deployed and tested on LEZ devnet/testnet. +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. +4. A README documents end-to-end usage: deployment steps, program + addresses, and step-by-step instructions for creating a + schedule, claiming, and cancelling via CLI and mini-app. + +#### + Privacy + +1. The mini-app and SDK must support both direct public account + interaction and the deshield→claim→re-shield pattern for private + account interaction. When a user chooses the private account + path, the SDK must enforce the complete deshield→claim→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 disclosure described in the + Usability section before each claim, identifying what is visible + on-chain (claim amount, ephemeral intermediary account) and what + remains private (the originating private account, the + destination of re-shielded tokens, and any link between separate + claims by the same recipient). +3. When using the private account path, the SDK must validate that + the re-shield target 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 claim from a + private account must use a freshly generated account with no + prior on-chain history. + +### Privacy Architecture + +Vesting schedule parameters (token, total amount, schedule type, +cliff date, end date, beneficiary public address) are public +on-chain state. This is a deliberate architectural choice: public +state enables permissionless observability of schedule terms and +composability with other programs. + +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→claim→re-shield pattern. When +users opt to interact from a private account, the SDK must enforce +the complete pattern as described below. + +#### Direct private account receipt (preferred if supported) + +If LEZ supports program-initiated shielding (that is, a program can +directly credit a beneficiary's shielded balance without routing +through a public intermediary), this is the preferred claim design. +The beneficiary's private account address would be registered in the +vesting schedule at creation; at claim time the program shields the +vested amount directly into that address. The beneficiary never needs +to expose a public account, and all subsequent token usage remains +entirely within the private sphere via the normal +deshield→action→re-shield flow. + +The implementer must investigate whether LEZ's shielding primitive +can be invoked by a program (not only by the account owner). If it +can, the direct shielding path must be used as the primary claim +flow. If it cannot, fall back to the ephemeral public account pattern +described below. + +#### Ephemeral public account fallback + +Where program-initiated shielding is not supported, the vesting +program can only release tokens to public token accounts; it cannot +write directly to a shielded balance. Re-shielding is then a +separate operation performed by the account owner after receiving +the tokens. This is the same fundamental constraint as the lending +protocol. + +#### Interaction flow + +For every claim from a private account: + +1. The recipient initiates the action from their private account. + The SDK deshields a small amount of native token for gas to a + **fresh, single-use** public account (account A) with no prior + on-chain history. Unlike the DEX, the recipient does not deshield + any project token; the vested tokens come *from* the program, + not from the recipient. +2. Account A submits the claim to the vesting program. The program + releases the vested amount to account A's token account. +3. Account A re-shields the claimed tokens to the recipient's + private account. Account A is never reused. + +> **Gas:** 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. + +#### What is public (observable on-chain) + +- All vesting schedule parameters: token, total amount, schedule + type, cliff date, end date, beneficiary public address. +- All claims: amount claimed, the ephemeral intermediary account + address, and timestamp. +- Cancellations and milestone signals. + +#### What is private (when using the private account path) + +- Which private account the claimed tokens are re-shielded into. +- Any link between multiple claims by the same recipient (no + on-chain linkability across ephemeral accounts). +- Subsequent movements of claimed tokens after re-shielding. + +### Soft Requirements + +- The creator can nominate a separate cancellation authority + distinct from the creator wallet (useful when vesting is managed + by a multisig or DAO). + +## ⚠ Platform Dependencies + +This RFP remains in **draft** until the dependencies below are +resolved. LEZ has similar programming capabilities to Solana but +several primitives required by a vesting protocol are not yet +available. + +### Hard blockers + +These must be available on LEZ before this RFP can open. + +#### On-chain clock / timestamp + +LEZ does not yet have on-chain block time. Vesting schedules are +fundamentally time-based: the cliff date, linear accrual rate, and +total vested amount at any moment are all functions of elapsed time. +Without a reliable on-chain timestamp, the program cannot determine +how much of a schedule has vested, making cliff + linear and fully +linear schedule types impossible to implement correctly. +Milestone-based vesting does not require an on-chain timestamp and +is unaffected by this blocker, but it represents only a subset of +the required functionality. + +#### General cross-program calls (LP-0015) + +LEZ uses a tail-call execution model with no return. A claim +operation must: (1) verify the schedule and compute the claimable +amount, (2) call the token program to transfer the vested tokens to +the beneficiary, and then (3) update the schedule state (recording +the claimed amount and timestamp). Without general cross-program +calls, step 3 cannot execute after step 2: any account could call +the update entrypoint directly, bypassing the token transfer. + +[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 + +Desirable but the RFP can open without them. + +#### Event emission (LP-0012) + +Off-chain dashboards and notification services need to react to +vesting events (schedule created, cliff reached, tokens claimed, +schedule cancelled). Without structured events, these 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: + +- Solana or SVM program development (Anchor or native) +- Token program and account model (ATAs, PDAs, token accounts) +- DeFi smart contract security and testing +- Front-end development for wallet/DeFi applications +- Familiarity with privacy interaction patterns (shielded accounts, + deshield/re-shield, see RFP-008) + +## ⏱ Timeline Expectations + +Estimated duration: **10–12 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) +- [LP-0012: Event/Log mechanism for LEZ](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md) +- [LP-0013: Token program improvements: mint authorities](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0013.md) +- [Streamflow Finance (vesting reference)](https://streamflow.finance/) + +## ✏️ 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**. From db8684eac418aeaa039ad2c1a93b757b99ec3330 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 12:48:17 +1100 Subject: [PATCH 02/30] define all the way to mainnet --- RFPs/RFP-015-bonding-curve-launchpad.md | 40 +++++++++++++++---------- RFPs/RFP-016-lbp-launchpad.md | 8 +++-- RFPs/RFP-017-token-vesting.md | 7 ++++- 3 files changed, 36 insertions(+), 19 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 34f2a9f..9389920 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -198,11 +198,13 @@ RFP-016 instead. at creation time. If the creator closes the sale manually before the supply target is reached, and the real collateral reserve is below this threshold, the sale enters a **refund state**: no - further withdrawals are permitted by the creator, and buyers who - purchased via a public account may submit a refund claim to - recover their collateral (see Reliability requirement 4). Refunds - for buyers who used the private account path are not supported - (see Known Limitations). If the supply target is reached + further withdrawals are permitted by the creator, and buyers may + submit a refund claim to recover their collateral (see Reliability + requirement 4). For buyers who used the private account path, + the refund is credited to the ephemeral public account used during + the buy; the SDK must persist the ephemeral account keypair, or + delegate that persistence to the wallet module, so the buyer can + submit the refund claim. If the supply target is reached automatically (full sell-through), the minimum raise check is skipped; a complete sell-through always succeeds. 7. Slippage protection: buyers specify the collateral amount to spend @@ -296,7 +298,8 @@ RFP-016 instead. after close. 4. If a sale enters refund state (minimum raise not met after manual close), the program must maintain per-buyer purchase records for - all public-account purchases, enabling each buyer to claim their + all public-account purchases, including ephemeral accounts used + in private account buys, enabling each buyer to claim their collateral refund independently. Refund claims must be idempotent: a buyer cannot claim the same purchase twice. 5. The creator cannot withdraw collateral while the sale is in @@ -314,8 +317,10 @@ RFP-016 instead. #### Supportability -1. The bonding curve program is deployed and tested on LEZ - devnet/testnet. +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. @@ -330,6 +335,8 @@ RFP-016 instead. 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. The program is updated and verified on LEZ testnet 0.3. +6. The program is deployed to LEZ mainnet. #### + Privacy @@ -422,14 +429,15 @@ but it does not prevent a single participant from submitting many transactions. Projects that need strong concentration limits should use the allowlist gate to restrict the eligible set. -**Refunds are not supported for the private account path.** If a sale -enters refund state (minimum raise not met after a manual close), -collateral refunds can only be processed for buyers who transacted via -a public account. Buyers who used the private account path have no -on-chain link between their private account and their purchase, so -the program cannot route a refund to them. The mini-app must display -a disclosure when buying via the private path if a minimum raise is -configured. +**Refunds on the private account path require local keypair retention.** +If a sale enters refund state, the refund is credited to the ephemeral +public account used during the original buy. The buyer can reclaim their +collateral by signing the refund claim with that ephemeral account's +keypair. The SDK must persist all ephemeral keypairs used in buy +transactions, or delegate that persistence to the wallet module. If the keypair is lost, the refund +cannot be claimed. The mini-app must clearly communicate this dependency +when a minimum raise is configured and the buyer is using the private +account path. **Front-running at sale open.** Unlike the LBP mechanism, which opens at a price above estimated fair value and declines over time, a bonding diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index e991ad5..ac65e5d 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -292,8 +292,10 @@ low-conviction raises. #### Supportability -1. The launchpad program is deployed and tested on LEZ - devnet/testnet. +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. @@ -306,6 +308,8 @@ low-conviction raises. 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. The program is updated and verified on LEZ testnet 0.3. +6. The program is deployed to LEZ mainnet. #### + Privacy diff --git a/RFPs/RFP-017-token-vesting.md b/RFPs/RFP-017-token-vesting.md index de622b5..7e4f98d 100644 --- a/RFPs/RFP-017-token-vesting.md +++ b/RFPs/RFP-017-token-vesting.md @@ -249,7 +249,10 @@ document. #### Supportability -1. The vesting program is deployed and tested on LEZ devnet/testnet. +Proposals must include separate milestones for testnet 0.2, testnet 0.3, +and mainnet deployment. + +1. The vesting 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. @@ -258,6 +261,8 @@ document. 4. A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for creating a schedule, claiming, and cancelling via CLI and mini-app. +5. The program is updated and verified on LEZ testnet 0.3. +6. The program is deployed to LEZ mainnet. #### + Privacy From 02f55f94dcc381fd6295dc9cd0413f6e790ffd19 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 12:56:33 +1100 Subject: [PATCH 03/30] improve motivation sections --- RFPs/RFP-015-bonding-curve-launchpad.md | 25 ++++++++ RFPs/RFP-016-lbp-launchpad.md | 82 +++++++++++-------------- RFPs/RFP-017-token-vesting.md | 7 +-- 3 files changed, 62 insertions(+), 52 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 9389920..b7cdcb3 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -120,6 +120,31 @@ eligibility set at creation time and restrict buys to participants who can prove inclusion. The implementation approach is left to the proposing team. +### 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 diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index ac65e5d..5ef06b4 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -27,11 +27,7 @@ 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. The team building this should have strong experience in -AMM or order-book design, SVM program development, and DeFi -application security. Familiarity with weighted AMM pool mechanics -(Balancer-style) and the Logos privacy interaction model is strongly -recommended. +established. ## 🔥 Why This Matters @@ -64,49 +60,43 @@ anything available on existing launchpad platforms. ## 🏗 Design Rationale -### LBP over bonding curves, fixed-price, Dutch auction, and sealed-bid auction - -Four alternative mechanisms exist for token sales: bonding curve, -fixed-price (set a price upfront, sell until allocation runs out), -Dutch auction (price declines on a curve until all tokens clear), and -sealed-bid auction -([LP-0004](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0004.md)). -LBP is chosen as the primary mechanism because it is the only one -that does not require the project to pre-set a valuation. - -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) hides individual bids and is well-suited to -single-item auctions, but clears at one moment rather than over days, +### 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 strong empirical track record (Fjord Foundry, Copper, Balancer) and +is well understood by the DeFi builder community. + +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) 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. -LBP addresses these problems by running 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 strong empirical track record (Fjord Foundry, -Copper, Balancer) and is well understood by the DeFi builder -community. - -A bonding curve (constant product AMM with virtual reserves, as used -by pump.fun and Meteora DBC) is a proven supply-driven mechanism and -is available as a companion launchpad in -[RFP-015](./RFP-015-bonding-curve-launchpad.md). It is not chosen -as the primary mechanism here for two reasons. First, a bonding curve -opens at its lowest price: buyers who act first pay the least, -rewarding speed over conviction and creating a strong incentive for -bots to snipe at the first block of the sale. An LBP opens above -estimated fair value and the price falls over time, making early -sniping unprofitable. Second, bonding curve pricing is -formula-driven (price is a deterministic function of supply) rather -than market-driven: the curve cannot reflect what buyers collectively -believe fair value to be, only where they are willing to buy relative -to the formula. Projects where early-entry incentives are intentional -(rewarding founding community members with a lower entry price) are a -better fit for RFP-015. +### LBPs and bonding curves as complementary mechanisms + +The Logos ecosystem provides both an LBP launchpad (this RFP) and a +bonding curve launchpad +([RFP-015](./RFP-015-bonding-curve-launchpad.md)). The two mechanisms +are not redundant: they suit different project profiles and together +provide a complete token launch toolkit. + +An LBP opens above estimated fair value and lets the market discover +price over the sale duration. It does not require the project to +pre-set a valuation, and it discourages bots by making early entry the +most expensive. This suits projects that want broad, patient +participation and market-driven price discovery. + +A bonding curve opens at its lowest price and rewards early +participation: price rises deterministically with each purchase. This +suits projects where early-entry incentives are intentional, rewarding +founding community members with a lower entry price and providing a +fully predictable, supply-driven raise trajectory. Fixed-price mode is retained as a soft requirement for projects that have an existing community with a known clearing price and prefer diff --git a/RFPs/RFP-017-token-vesting.md b/RFPs/RFP-017-token-vesting.md index 7e4f98d..4866153 100644 --- a/RFPs/RFP-017-token-vesting.md +++ b/RFPs/RFP-017-token-vesting.md @@ -24,12 +24,7 @@ private identity untraceable on-chain. Token vesting is a prerequisite for credible token launches. Every protocol that issues a token must lock some allocation for founders, -early contributors, or ecosystem reserves. The team building this -should have experience with SVM program development and DeFi token -mechanics. Familiarity with the optional public/private account -interaction pattern (see -[RFP-008](./RFP-008-lending-borrowing-protocol.md)) is strongly -recommended. +early contributors, or ecosystem reserves. ## 🔥 Why This Matters From b8b2d01a091eb008ec4109ba029f0c4e67579f5a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 13:02:32 +1100 Subject: [PATCH 04/30] reduce content --- RFPs/RFP-016-lbp-launchpad.md | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 5ef06b4..7eb7dba 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -78,25 +78,12 @@ poor UX. LP-0004 (sealed-bid) 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. -### LBPs and bonding curves as complementary mechanisms - -The Logos ecosystem provides both an LBP launchpad (this RFP) and a -bonding curve launchpad -([RFP-015](./RFP-015-bonding-curve-launchpad.md)). The two mechanisms -are not redundant: they suit different project profiles and together -provide a complete token launch toolkit. - -An LBP opens above estimated fair value and lets the market discover -price over the sale duration. It does not require the project to -pre-set a valuation, and it discourages bots by making early entry the -most expensive. This suits projects that want broad, patient -participation and market-driven price discovery. - -A bonding curve opens at its lowest price and rewards early -participation: price rises deterministically with each purchase. This -suits projects where early-entry incentives are intentional, rewarding -founding community members with a lower entry price and providing a -fully predictable, supply-driven raise trajectory. +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 From 6ecf2565d3897d9e512b0c45c2b90a3c30ffc1c2 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 13:07:55 +1100 Subject: [PATCH 05/30] reduce content --- RFPs/RFP-015-bonding-curve-launchpad.md | 8 -------- RFPs/RFP-016-lbp-launchpad.md | 5 ++--- 2 files changed, 2 insertions(+), 11 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index b7cdcb3..14f9313 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -46,14 +46,6 @@ model underpins Uniswap, Balancer, and virtually every major AMM; the formula is the most audited and best-understood pricing primitive in DeFi. -The virtual-reserve model enables automatic post-sale liquidity -seeding: the creator deposits the full token supply `Vt` upfront, of -which `Vt − D` tokens are held in reserve alongside the accumulated -collateral at graduation, forming a complete AMM pool that can be -seeded to a DEX without any post-close action from the creator. This -removes the coordination failure risk present in manual post-sale -liquidity provisioning. - ## 🏗 Design Rationale ### Constant product AMM with virtual reserves diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 7eb7dba..9ebd3f2 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -38,9 +38,8 @@ 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)). -The mechanism deters bots (price starts above fair value and falls -unless buying pressure counteracts it) and removes the need for -project teams to pre-set a valuation for their token. +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 From dafb34767ad30267d35696512534f0c5fb4d853f Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 14:34:31 +1100 Subject: [PATCH 06/30] fix sources --- RFPs/RFP-015-bonding-curve-launchpad.md | 4 ++-- RFPs/RFP-016-lbp-launchpad.md | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 14f9313..9e0cd16 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -37,10 +37,10 @@ toolkit. ## 🔥 Why This Matters Bonding curves are one of the most proven token distribution mechanisms -in DeFi. pump.fun processed over $1B in volume on Solana using a +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 now the dominant open-source SVM launchpad primitive, used in +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 diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 9ebd3f2..3cd208b 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -37,7 +37,8 @@ April 2024 ([DL News](https://www.dlnews.com/articles/defi/fjord-foundry-raises- 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)). +([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. @@ -65,7 +66,7 @@ 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 strong empirical track record (Fjord Foundry, Copper, Balancer) and +a strong empirical track record (Fjord Foundry, Balancer) and is well understood by the DeFi builder community. Among other token sale mechanisms, fixed-price forces a binary gamble: From a00d3b2c547797c168ed7260f5f379a7b8114161 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 15:07:40 +1100 Subject: [PATCH 07/30] open RFP --- README.md | 6 +++--- RFPs/RFP-016-lbp-launchpad.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index b81d6cd..70d11b6 100644 --- a/README.md +++ b/README.md @@ -62,9 +62,9 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | 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-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 | draft | Applications & Integrations | — | -| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | $XXXXX | draft | Applications & Integrations | — | -| RFP-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | $XXXXX | draft | Applications & Integrations | — | +| 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-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | $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-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 3cd208b..82253de 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -3,7 +3,7 @@ id: RFP-016 title: "Privacy-Preserving Token Launchpad: LBP" tier: XL funding: $XXXXX -status: draft +status: open category: Applications & Integrations --- From 9f23fef79317bb2d451bfd4c78c7606e7efd6cd4 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 15:16:05 +1100 Subject: [PATCH 08/30] remove vesting --- README.md | 1 - RFPs/RFP-017-token-vesting.md | 458 ---------------------------------- 2 files changed, 459 deletions(-) delete mode 100644 RFPs/RFP-017-token-vesting.md diff --git a/README.md b/README.md index 70d11b6..68678c0 100644 --- a/README.md +++ b/README.md @@ -64,7 +64,6 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | 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-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | $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-017-token-vesting.md b/RFPs/RFP-017-token-vesting.md deleted file mode 100644 index 4866153..0000000 --- a/RFPs/RFP-017-token-vesting.md +++ /dev/null @@ -1,458 +0,0 @@ ---- -id: RFP-017 -title: Privacy-Preserving Token Vesting -tier: L -funding: $XXXXX -status: draft -category: Applications & Integrations ---- - - -# RFP-017: Privacy-Preserving Token Vesting - -## 🧭 Overview - -Build a token vesting program on LEZ that locks project, team, or -investor tokens against configurable time-based schedules (cliff, -linear, or milestone-based). Recipients can claim vested tokens -directly from a public account, or via a deshield→claim→re-shield -pattern for private account interaction: when the private path is -used, the claim is executed from a fresh, single-use public account, -and the output is immediately re-shielded to the recipient's private -account, making the link between the claim and the recipient's -private identity untraceable on-chain. - -Token vesting is a prerequisite for credible token launches. Every -protocol that issues a token must lock some allocation for founders, -early contributors, or ecosystem reserves. - -## 🔥 Why This Matters - -On transparent chains, vesting contracts (Streamflow, Sablier, -Team.Finance) are surveillance tools: every cliff unlock, every -linear release, and every claim is publicly linkable to a beneficiary -address, exposing token unlock schedules to the market and enabling -adversarial trading against known unlock events. A Solana founder's -vesting cliff is trivially queryable on-chain; traders index these -events and position against them before the beneficiary can act. - -On LEZ, the optional deshield→claim→re-shield pattern makes claims -unlinkable to the recipient's private identity. Observers see that -tokens were claimed from a vesting schedule; they cannot determine -which private account holds those tokens or trace subsequent -movements. This makes LEZ the only environment where teams can vest -tokens without creating a public unlock calendar for adversarial -front-running. - -Vesting is also a composition primitive. A launchpad (see -[RFP-016](./RFP-016-lbp-launchpad.md)) or investor round on LEZ -needs vesting to be in place before tokens can be distributed to -contributors and early backers. This RFP is a direct prerequisite -for a credible token economy on LEZ. - -## 🏗 Design Rationale - -### Three schedule types: cliff+linear, fully linear, milestone - -These three types cover the full range of real-world vesting -relationships without unnecessary complexity. - -**Cliff + linear** is the industry standard for team and investor -allocations. The cliff (commonly 1 year) prevents immediate selling -at TGE and signals that insiders have a long-term commitment. Linear -release after the cliff aligns incentives continuously over the -remaining period; recipients have ongoing reason to contribute. -This pattern is used in virtually every serious protocol's team -allocation. - -**Fully linear** (no cliff) is appropriate for ongoing contributors -(advisors, contractors) where there is no fixed start date requiring -a binary lock-up, or for grant programmes where disbursement should -begin immediately. - -**Milestone-based** serves deliverable-oriented relationships: -grants, partnerships, or service agreements where time-based vesting -is economically incorrect. Unlocking tokens when a milestone is -achieved rather than when a date passes better reflects the nature -of the obligation. Importantly, milestone authority stays with the -creator, not an on-chain oracle; this is intentional: the -conditions for milestone completion are often qualitative and cannot -be reliably evaluated on-chain. - -### Beneficiary as public account address - -A ZK commitment-based beneficiary (where the schedule creator -commits to a hash of the beneficiary's key and the recipient proves -knowledge of the preimage at claim time) would hide who is in the -schedule. This is excluded as a hard requirement for two reasons. - -First, in virtually all vesting contexts the parties already know -each other: a project knows its co-founders, investors, and grant -recipients. Hiding the beneficiary's address from on-chain observers -does not change the information available to the other party in the -relationship. - -Second, the infrastructure required (a ZK membership proof -compatible with the LEZ account model) overlaps with LP-0003, which -is itself a draft prize not yet delivered. Building on an undelivered -dependency would block this RFP. - -The principal privacy concern (adversarial trading against known -unlock events) is addressed by the re-shield claim pattern. Even -if an observer knows that a specific address holds a vesting -schedule, they cannot track where claimed tokens go or link -subsequent on-chain activity to that address. A future RFP or -upgrade can introduce commitment-based beneficiaries once LP-0003 -is complete. - -### Cancellation semantics - -Unvested tokens return to the creator on cancellation; already- -vested but unclaimed tokens remain claimable by the beneficiary. -This reflects the economic reality of the relationship: vested -tokens are earned compensation that cannot be revoked. Unvested -tokens represent future commitment not yet earned, and returning -them to the creator on early termination is the industry standard, -as used by Streamflow, Sablier, and Team.Finance alike. Burning -unvested tokens would destroy value unnecessarily and make the -program harder to adopt. - -### Transferable positions as a creation-time flag - -Whether a vesting position is transferable to a new beneficiary -address is set at creation and cannot be changed afterwards. For -employment vesting, the incentive is personal; the position should -be non-transferable so the token lock applies specifically to the -individual. For investor positions, secondary transfers may be -needed (assignment of rights, secondary market sales of locked -tokens). Allowing this to be configured at creation but frozen -afterwards avoids mid-schedule ambiguity: all parties know the -rules when the schedule is created and cannot change them -unilaterally later. - -### Batch creation - -Token launches routinely create 10–50 vesting schedules -simultaneously (co-founders, advisors, early contributors, investor -tranches). Creating them one-by-one is gas-expensive and -error-prone. Batch creation is a practical necessity, not a -nice-to-have, for any real-world launch. The batch size is bounded -by the LEZ transaction size limit, which the implementation must -document. - -## ✅ Scope of Work - -### Hard Requirements - -#### Functionality - -1. Implement a vesting program on LEZ that locks tokens in escrow - against a configured schedule. The program must support: - - **Cliff + linear vesting**: tokens become claimable in a lump - sum at the cliff date, then linearly over the remaining - duration (e.g., 1-year cliff, 3-year linear release). - - **Fully linear vesting**: no cliff; tokens accrue continuously - from the start date. - - **Milestone-based vesting**: the schedule creator explicitly - signals completion of discrete tranches; each signal unlocks - a fixed token amount for the beneficiary to claim. -2. The schedule creator specifies the beneficiary as a public - account address at schedule creation. Recipients can claim - vested tokens directly from that public account, or via a - deshield→claim→re-shield flow: a gas-only deshield funds a - fresh single-use public account that submits the claim and - immediately re-shields the output to the recipient's private - account. The schedule creator does not learn the recipient's - private account address from this interaction. -3. The schedule creator can cancel an active schedule at any time, - returning the unclaimed, unvested token balance to the creator's - account. Tokens already vested but not yet claimed remain - claimable by the beneficiary after cancellation. -4. The schedule creator can configure whether the vesting position - (beneficiary rights) is transferable to a new public account - address. Transferability must be set at schedule creation and - cannot be changed afterwards. -5. Multi-recipient batch creation: a creator can set up vesting - schedules for multiple recipients in a single operation, up to - the LEZ transaction size limit. Document the maximum number of - recipients achievable in one transaction. -6. The program emits a log event (using the LEZ event/log mechanism; - see - [LP-0012](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md)) - for each state transition: schedule creation, claim, - cancellation, milestone signal, and beneficiary transfer. Event - schema must be documented. - -#### Usability - -1. Provide an SDK that can be used to build Logos modules - interacting with the vesting program. The SDK must expose the - full lifecycle: create schedule, query claimable amount, claim, - cancel, signal milestone, and transfer beneficiary. The SDK must - support both direct public account interaction and the - deshield→claim→re-shield pattern for private account - interaction. When the private account path is used, the SDK must - handle the gas-only deshield as a single indivisible 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 at minimum: - - **Recipient view**: current vesting position, total locked, - amount claimable now, next unlock event, claim action. - - **Creator view**: create a new schedule (all parameters), - list active schedules, cancel a schedule, signal a milestone. -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: create schedule, claim, - cancel, signal milestone, and query claimable amount. -4. The mini-app must display a pre-claim confirmation summary: - claimable amount and estimated transaction fee. When using the - private account path, it must also confirm that the recipient's - shielded balance covers the gas-only deshield; a clear, - actionable error must be shown if the balance is insufficient. -5. When using the private account path, the mini-app must display - a privacy disclosure before each claim, identifying what will - be visible on-chain (claim amount, ephemeral public account - address, vesting schedule program address) and what will not be - traceable (the recipient's private account and the subsequent - destination of claimed tokens). -6. Provide an IDL for the vesting program using the - [SPEL framework](https://github.com/logos-co/spel). -7. Failed claims must return clear, actionable error messages, - including the case where nothing is yet claimable (with the - next unlock time displayed). - -#### Reliability - -1. A claim is atomic: a failed or rejected claim does not consume - vested tokens and leaves the claimant able to retry without - loss. -2. A schedule cancellation is atomic: partial failure leaves the - schedule in its prior state, not an undefined one. -3. Concurrent claims against independent schedules must not corrupt - shared program state. -4. Milestone signalling is idempotent per milestone index: - signalling the same milestone twice must be rejected with a - deterministic error and must not double-unlock tokens. - -#### Performance - -1. A single claim completes within one LEZ transaction. -2. Document the compute unit (CU) cost of each operation: create - schedule, claim, cancel, signal milestone, transfer beneficiary. - Note the LEZ testnet version against which measurements were - taken, as the per-transaction compute budget may change. - -#### Supportability - -Proposals must include separate milestones for testnet 0.2, testnet 0.3, -and mainnet deployment. - -1. The vesting 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. -4. A README documents end-to-end usage: deployment steps, program - addresses, and step-by-step instructions for creating a - schedule, claiming, and cancelling via CLI and mini-app. -5. The program is updated and verified on LEZ testnet 0.3. -6. The program is deployed to LEZ mainnet. - -#### + Privacy - -1. The mini-app and SDK must support both direct public account - interaction and the deshield→claim→re-shield pattern for private - account interaction. When a user chooses the private account - path, the SDK must enforce the complete deshield→claim→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 disclosure described in the - Usability section before each claim, identifying what is visible - on-chain (claim amount, ephemeral intermediary account) and what - remains private (the originating private account, the - destination of re-shielded tokens, and any link between separate - claims by the same recipient). -3. When using the private account path, the SDK must validate that - the re-shield target 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 claim from a - private account must use a freshly generated account with no - prior on-chain history. - -### Privacy Architecture - -Vesting schedule parameters (token, total amount, schedule type, -cliff date, end date, beneficiary public address) are public -on-chain state. This is a deliberate architectural choice: public -state enables permissionless observability of schedule terms and -composability with other programs. - -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→claim→re-shield pattern. When -users opt to interact from a private account, the SDK must enforce -the complete pattern as described below. - -#### Direct private account receipt (preferred if supported) - -If LEZ supports program-initiated shielding (that is, a program can -directly credit a beneficiary's shielded balance without routing -through a public intermediary), this is the preferred claim design. -The beneficiary's private account address would be registered in the -vesting schedule at creation; at claim time the program shields the -vested amount directly into that address. The beneficiary never needs -to expose a public account, and all subsequent token usage remains -entirely within the private sphere via the normal -deshield→action→re-shield flow. - -The implementer must investigate whether LEZ's shielding primitive -can be invoked by a program (not only by the account owner). If it -can, the direct shielding path must be used as the primary claim -flow. If it cannot, fall back to the ephemeral public account pattern -described below. - -#### Ephemeral public account fallback - -Where program-initiated shielding is not supported, the vesting -program can only release tokens to public token accounts; it cannot -write directly to a shielded balance. Re-shielding is then a -separate operation performed by the account owner after receiving -the tokens. This is the same fundamental constraint as the lending -protocol. - -#### Interaction flow - -For every claim from a private account: - -1. The recipient initiates the action from their private account. - The SDK deshields a small amount of native token for gas to a - **fresh, single-use** public account (account A) with no prior - on-chain history. Unlike the DEX, the recipient does not deshield - any project token; the vested tokens come *from* the program, - not from the recipient. -2. Account A submits the claim to the vesting program. The program - releases the vested amount to account A's token account. -3. Account A re-shields the claimed tokens to the recipient's - private account. Account A is never reused. - -> **Gas:** 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. - -#### What is public (observable on-chain) - -- All vesting schedule parameters: token, total amount, schedule - type, cliff date, end date, beneficiary public address. -- All claims: amount claimed, the ephemeral intermediary account - address, and timestamp. -- Cancellations and milestone signals. - -#### What is private (when using the private account path) - -- Which private account the claimed tokens are re-shielded into. -- Any link between multiple claims by the same recipient (no - on-chain linkability across ephemeral accounts). -- Subsequent movements of claimed tokens after re-shielding. - -### Soft Requirements - -- The creator can nominate a separate cancellation authority - distinct from the creator wallet (useful when vesting is managed - by a multisig or DAO). - -## ⚠ Platform Dependencies - -This RFP remains in **draft** until the dependencies below are -resolved. LEZ has similar programming capabilities to Solana but -several primitives required by a vesting protocol are not yet -available. - -### Hard blockers - -These must be available on LEZ before this RFP can open. - -#### On-chain clock / timestamp - -LEZ does not yet have on-chain block time. Vesting schedules are -fundamentally time-based: the cliff date, linear accrual rate, and -total vested amount at any moment are all functions of elapsed time. -Without a reliable on-chain timestamp, the program cannot determine -how much of a schedule has vested, making cliff + linear and fully -linear schedule types impossible to implement correctly. -Milestone-based vesting does not require an on-chain timestamp and -is unaffected by this blocker, but it represents only a subset of -the required functionality. - -#### General cross-program calls (LP-0015) - -LEZ uses a tail-call execution model with no return. A claim -operation must: (1) verify the schedule and compute the claimable -amount, (2) call the token program to transfer the vested tokens to -the beneficiary, and then (3) update the schedule state (recording -the claimed amount and timestamp). Without general cross-program -calls, step 3 cannot execute after step 2: any account could call -the update entrypoint directly, bypassing the token transfer. - -[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 - -Desirable but the RFP can open without them. - -#### Event emission (LP-0012) - -Off-chain dashboards and notification services need to react to -vesting events (schedule created, cliff reached, tokens claimed, -schedule cancelled). Without structured events, these 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: - -- Solana or SVM program development (Anchor or native) -- Token program and account model (ATAs, PDAs, token accounts) -- DeFi smart contract security and testing -- Front-end development for wallet/DeFi applications -- Familiarity with privacy interaction patterns (shielded accounts, - deshield/re-shield, see RFP-008) - -## ⏱ Timeline Expectations - -Estimated duration: **10–12 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) -- [LP-0012: Event/Log mechanism for LEZ](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md) -- [LP-0013: Token program improvements: mint authorities](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0013.md) -- [Streamflow Finance (vesting reference)](https://streamflow.finance/) - -## ✏️ 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**. From d16af8fb35418a9779b9f1fa13d29edae80de6c9 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 15:19:39 +1100 Subject: [PATCH 09/30] remove blocke --- RFPs/RFP-016-lbp-launchpad.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 82253de..f58ca0d 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -396,11 +396,6 @@ gate to restrict the eligible set instead. ## ⚠ Platform Dependencies -This RFP remains in **draft** until the dependencies below are -resolved. LEZ has similar programming capabilities to Solana but -several primitives required by a token launchpad are not yet -available. - ### Hard blockers These must be available on LEZ before this RFP can open. From edc2e6415eca95cbdee0059f156aec464c178135 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 10:32:14 +1100 Subject: [PATCH 10/30] move curve formula to a recommendation --- RFPs/RFP-015-bonding-curve-launchpad.md | 95 ++++++++++++++----------- 1 file changed, 55 insertions(+), 40 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 9e0cd16..c20ac4f 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -50,15 +50,16 @@ DeFi. ### Constant product AMM with virtual reserves -The required pricing mechanism is the **constant product AMM with +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 chosen over alternatives (polynomial integral curves, +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 -Functionality requirement 1. +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 @@ -156,30 +157,20 @@ RFP-016 instead. #### Functionality -1. Implement a bonding curve program on LEZ using the constant product - AMM with virtual reserves. The program must maintain the invariant - `Vt × Vc = k` across all buy operations, where `Vt` is the virtual - token reserve and `Vc` is the virtual collateral reserve. The buy - instruction accepts a collateral input `C_in`; the token output - must be computed as: - - ``` - tokens_out = Vt - k / (Vc + C_in) - ``` - - The SDK must also expose the inverse: the exact collateral cost - for a buyer who requests a specific token quantity `Q`: - - ``` - C_in = k / (Vt - Q) - Vc - ``` - - After each buy, `Vt` and `Vc` must be updated to preserve `k`. - The real token reserve decreases by `tokens_out`; the real - collateral reserve increases by `C_in`. If the computed - `tokens_out` would exceed the remaining real token reserve, the - transaction must revert. The invariant `k` must never change after - creation. +1. Implement a bonding curve program on LEZ with a deterministic, + supply-driven pricing mechanism that maintains a well-defined + invariant across all buy 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`. After each buy, the curve state must + be updated to preserve the pricing invariant. The real token + reserve decreases by `tokens_out`; the real collateral reserve + increases by `C_in`. If the computed `tokens_out` would exceed the + remaining real token reserve, the transaction must revert. The + pricing invariant must never change after creation. See the + Reference Implementation section for the recommended formula and + the deviation standard for alternative mechanisms. 2. A sale creator can configure a sale with the following parameters: - Token pair (project token + collateral token). - Virtual token reserves `Vt`: the total project token supply @@ -270,7 +261,7 @@ RFP-016 instead. pause/resume, 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 constant product formula), current spot price + (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 @@ -380,8 +371,8 @@ 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 constant product -formula independently), composability, and sale analytics without +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 @@ -465,17 +456,41 @@ per-transaction buy limit reduce the impact but do not eliminate it. 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 +``` + +After each buy, `Vt` and `Vc` are updated to preserve `k`. `k` is +computed at creation as `Vt × Vc` 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 -- **Alternative curve formula**: teams may propose a different - pricing model (such as a polynomial integral, the Bancor power - function, or a piecewise constant product as used in Meteora - DBC) in their application. Alternative formulas must be - accompanied by a formal specification, a security argument for - the invariant being preserved, and citations to existing - production implementations or audits. Proposals using the - specified constant product model require no additional - justification. - **Two-way (sell-back) curve**: after purchasing tokens, holders can sell them back to the curve, receiving collateral from the real reserve. The sell formula is the inverse of the buy formula: From 54885a30bbd1f3b8f83a0a27f3df7eef3df995e0 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 10:34:23 +1100 Subject: [PATCH 11/30] tokens go to token vesting at end of sale --- RFPs/RFP-015-bonding-curve-launchpad.md | 13 +++++++++++-- RFPs/RFP-016-lbp-launchpad.md | 19 ++++++++++++++----- 2 files changed, 25 insertions(+), 7 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index c20ac4f..8bb29d6 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -509,11 +509,20 @@ production deployments or audits. - **Time-based sale end**: support an optional end timestamp in addition to the supply target, closing the sale at whichever condition is reached first. -- **Integration with token vesting**: at sale close, purchased - tokens can be routed directly into a vesting schedule (see +- **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. This enables a sale-plus-vesting flow in a single operation. +- **Creator collateral vesting**: the sale creator can optionally + configure a 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. The creator then claims + collateral over time per the schedule terms. This provides + accountability to buyers by preventing immediate lump-sum + withdrawal of raised funds. ## ⚠ Platform Dependencies diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index f58ca0d..4820780 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -385,11 +385,20 @@ gate to restrict the eligible set instead. - 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. -- Integration with the token vesting program (see - [RFP-017](./RFP-017-token-vesting.md)): at sale close, purchased - tokens can be routed directly into a vesting schedule rather than - returned to the buyer's private account. This enables - sale-plus-vesting in a single flow. +- **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 returned to + the buyer's private account. This enables sale-plus-vesting in a + single flow. +- **Creator collateral vesting**: the sale creator can optionally + configure a 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. The creator then claims + collateral over time per the schedule terms. This provides + accountability to buyers by preventing immediate lump-sum + withdrawal of raised funds. - Support for a Dutch auction mode (price declines on a configurable curve over time; buyers transact at the current price as it falls, with earlier buyers paying more than later ones). From 8337c74fb94575e64a85c8acfc19a2fc2379f28c Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 10:43:43 +1100 Subject: [PATCH 12/30] creator collateral vesting option is a hard requirement --- RFPs/RFP-015-bonding-curve-launchpad.md | 21 ++++++++++++--------- RFPs/RFP-016-lbp-launchpad.md | 21 ++++++++++++--------- 2 files changed, 24 insertions(+), 18 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 8bb29d6..401df24 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -231,6 +231,17 @@ RFP-016 instead. 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). +11. 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. The creator then claims + collateral over time per the schedule terms. When + milestone-based vesting is used, milestone authority must be + held by a party other than the sale creator (e.g., a governance + body or multisig) to prevent the creator from approving + milestones and draining funds unilaterally. #### Usability @@ -514,15 +525,7 @@ production deployments or audits. [RFP-017](./RFP-017-token-vesting.md)) rather than transferred to the buyer immediately. This enables a sale-plus-vesting flow in a single operation. -- **Creator collateral vesting**: the sale creator can optionally - configure a 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. The creator then claims - collateral over time per the schedule terms. This provides - accountability to buyers by preventing immediate lump-sum - withdrawal of raised funds. + ## ⚠ Platform Dependencies diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 4820780..fa09f62 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -187,6 +187,17 @@ low-conviction raises. 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). +10. 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. The creator then claims + collateral over time per the schedule terms. When + milestone-based vesting is used, milestone authority must be + held by a party other than the sale creator (e.g., a governance + body or multisig) to prevent the creator from approving + milestones and draining funds unilaterally. #### Usability @@ -390,15 +401,7 @@ gate to restrict the eligible set instead. [RFP-017](./RFP-017-token-vesting.md)) rather than returned to the buyer's private account. This enables sale-plus-vesting in a single flow. -- **Creator collateral vesting**: the sale creator can optionally - configure a 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. The creator then claims - collateral over time per the schedule terms. This provides - accountability to buyers by preventing immediate lump-sum - withdrawal of raised funds. + - Support for a Dutch auction mode (price declines on a configurable curve over time; buyers transact at the current price as it falls, with earlier buyers paying more than later ones). From acba292e35db03bee32660f5e45ed484dfdbb169 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 10:46:39 +1100 Subject: [PATCH 13/30] clarify rounding --- RFPs/RFP-015-bonding-curve-launchpad.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 401df24..5ed90a9 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -167,8 +167,12 @@ RFP-016 instead. be updated to preserve the pricing invariant. The real token reserve decreases by `tokens_out`; the real collateral reserve increases by `C_in`. If the computed `tokens_out` would exceed the - remaining real token reserve, the transaction must revert. The - pricing invariant must never change after creation. See the + remaining real token reserve, the transaction must revert. All + arithmetic must use integer-only operations and round against + the trader: `tokens_out` rounds down, `C_in` rounds up. 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 formula and the deviation standard for alternative mechanisms. 2. A sale creator can configure a sale with the following parameters: From 2ab5814eb7f9a0d023aabe71cc834e7cef416514 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 10:53:58 +1100 Subject: [PATCH 14/30] make time closure a hard requirement --- RFPs/RFP-015-bonding-curve-launchpad.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 5ed90a9..76889da 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -73,8 +73,9 @@ 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. Time-based end is retained as a soft -requirement for projects that need a hard deadline. +Supply-based close avoids this. An optional end timestamp is +supported for projects that need a hard deadline, preventing +zombie sales that sit open indefinitely if demand is low. ### One-directional sale @@ -201,8 +202,15 @@ RFP-016 instead. this interaction model for LEZ applications). Both paths must be supported by the program and SDK. 4. The sale closes automatically when the real token reserve reaches - zero (supply target `D` reached). The creator can also close the - sale manually at any time before the target is reached. + zero (supply target `D` reached), or when an optional end + timestamp configured at creation time is reached, whichever + comes first. The creator can also close the sale manually at + any time before either condition is met. 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. 5. After the sale closes, the creator can withdraw: - The real collateral raised (net of fees). - The reserved `Vt − D` tokens (if not used for auto-graduation). @@ -306,7 +314,6 @@ RFP-016 instead. messages (e.g., insufficient balance, supply target already reached, sale paused, allowlist gate rejected, slippage exceeded, per-transaction buy limit exceeded). - #### Reliability 1. Curve state (`Vt`, `Vc`, `k`, real reserves) must remain @@ -521,9 +528,6 @@ production deployments or audits. [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. -- **Time-based sale end**: support an optional end timestamp in - addition to the supply target, closing the sale at whichever - condition is reached first. - **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 From 8d00bfd58e516889e3575d5558daca547148d424 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 11:26:22 +1100 Subject: [PATCH 15/30] request documentation of privacy and anonymity properties --- RFPs/RFP-000-template.md | 7 +++++++ RFPs/RFP-015-bonding-curve-launchpad.md | 24 ++++++++++++++++++++++-- RFPs/RFP-016-lbp-launchpad.md | 24 ++++++++++++++++++++++-- 3 files changed, 51 insertions(+), 4 deletions(-) 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-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 76889da..0c44b76 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -365,8 +365,15 @@ and mainnet deployment. 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. The program is updated and verified on LEZ testnet 0.3. -6. The program is deployed to LEZ mainnet. +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 @@ -444,6 +451,19 @@ For every buy from a private account: 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 **Per-wallet buy limits are not supported for the private account diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index fa09f62..7ed5b23 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -296,8 +296,15 @@ and mainnet deployment. 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. The program is updated and verified on LEZ testnet 0.3. -6. The program is deployed to LEZ mainnet. +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 @@ -377,6 +384,19 @@ For every buy from a private account: - 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 From 2b434591665c4dca35b8affde08fa4544717fbcb Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 11:28:20 +1100 Subject: [PATCH 16/30] add per block sales limit --- RFPs/RFP-015-bonding-curve-launchpad.md | 42 ++++++++++++++----------- RFPs/RFP-016-lbp-launchpad.md | 24 ++++++++------ 2 files changed, 39 insertions(+), 27 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 0c44b76..8a6b448 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -177,24 +177,30 @@ RFP-016 instead. Reference Implementation section for the recommended formula and the deviation standard for alternative mechanisms. 2. A sale creator can configure a sale with the following parameters: - - Token pair (project token + collateral token). - - Virtual token reserves `Vt`: the total project token supply - deposited by the creator into the curve program at creation. - All `Vt` tokens must be transferred from the creator at sale - creation. - - Virtual collateral reserves `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`. - - Sale quantity `D`: the number of tokens made available for - purchase (`D < Vt`). The remaining `Vt − D` tokens are held - in reserve within the program for post-graduation DEX seeding. - `D` is also the supply target: the sale auto-closes when `D` - tokens have been sold. - - Optional: minimum raise threshold (see item 6 below). - - Optional: per-transaction buy limit (maximum collateral amount - spendable in a single buy transaction). - - Optional: private allowlist gate (see item 8 below). + 1. Token pair (project token + collateral token). + 2. Virtual token reserves `Vt`: the total project token supply + deposited by the creator into the curve program at creation. + All `Vt` tokens must be transferred from the creator at sale + creation. + 3. Virtual collateral reserves `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`. + 4. Sale quantity `D`: the number of tokens made available for + purchase (`D < Vt`). The remaining `Vt − D` tokens are held + in reserve within the program for post-graduation DEX seeding. + `D` is also the supply target: the sale auto-closes when `D` + tokens have been sold. + 5. Optional: minimum raise threshold (see item 6 below). + 6. Optional: per-transaction buy limit (maximum collateral amount + spendable in a single buy transaction). + 7. 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. + 8. Optional: private allowlist gate (see item 8 below). 3. Participants buy project tokens from the curve using either a public account directly, or via the deshield→buy→re-shield pattern for private account interaction (see diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 7ed5b23..346ed88 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -148,15 +148,21 @@ low-conviction raises. 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: - - Token pair (project token + collateral token). - - Start and end weights (e.g., 99/1 → 1/99 for the - token/collateral ratio). - - Sale start and end timestamps. - - Initial token deposit amount. - - Optional: minimum raise (sale is considered failed and - collateral is refunded to the creator if the minimum is not - reached by close). - - Optional: private allowlist gate (see item 7 below). + 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: minimum raise (sale is considered failed and + collateral is refunded to the creator if the minimum is not + reached by close). + 6. 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. + 7. 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 From 2ffa32803f1df1a509428bc9b50284f47badb5af Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 11:31:25 +1100 Subject: [PATCH 17/30] fix sale reserve maths --- RFPs/RFP-015-bonding-curve-launchpad.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 8a6b448..4044c15 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -168,7 +168,7 @@ RFP-016 instead. be updated to preserve the pricing invariant. The real token reserve decreases by `tokens_out`; the real collateral reserve increases by `C_in`. If the computed `tokens_out` would exceed the - remaining real token reserve, the transaction must revert. All + remaining sale reserve, the transaction must revert. All arithmetic must use integer-only operations and round against the trader: `tokens_out` rounds down, `C_in` rounds up. This ensures the pool remains solvent and the pricing invariant is @@ -187,10 +187,12 @@ RFP-016 instead. `Vt`, determines `k = Vt × Vc` (computed and stored at creation) and the starting spot price `p₀ = Vc / Vt`. 4. Sale quantity `D`: the number of tokens made available for - purchase (`D < Vt`). The remaining `Vt − D` tokens are held - in reserve within the program for post-graduation DEX seeding. - `D` is also the supply target: the sale auto-closes when `D` - tokens have been sold. + purchase (`D < 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 `Vt − D`, untouched until close). `D` is the + supply target: the sale auto-closes when the sale reserve is + exhausted. 5. Optional: minimum raise threshold (see item 6 below). 6. Optional: per-transaction buy limit (maximum collateral amount spendable in a single buy transaction). @@ -207,8 +209,8 @@ RFP-016 instead. [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 real token reserve reaches - zero (supply target `D` reached), or when an optional end +4. The sale closes automatically when the sale reserve is exhausted + (all `D` tokens have been sold), or when an optional end timestamp configured at creation time is reached, whichever comes first. The creator can also close the sale manually at any time before either condition is met. When an end timestamp @@ -276,7 +278,7 @@ RFP-016 instead. 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, real token reserve as a percentage of the supply + 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 @@ -328,7 +330,7 @@ RFP-016 instead. 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 real token reserve reaches zero, the sale must close + 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. @@ -439,8 +441,9 @@ For every buy from a private account: #### What is public (observable on-chain) - All curve state: token pair, virtual reserves (`Vt`, `Vc`), - invariant `k`, real token reserve, real collateral reserve, - sale quantity `D`, current spot price, open/closed status. + 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 From 7a6af3fd567a6c56912817beb317c9d0f2ad972b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 11:42:57 +1100 Subject: [PATCH 18/30] fix Vt --- RFPs/RFP-015-bonding-curve-launchpad.md | 47 ++++++++++++++----------- 1 file changed, 27 insertions(+), 20 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 4044c15..b8cb644 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -178,31 +178,37 @@ RFP-016 instead. 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. Virtual token reserves `Vt`: the total project token supply - deposited by the creator into the curve program at creation. - All `Vt` tokens must be transferred from the creator at sale - creation. - 3. Virtual collateral reserves `Vc`: a synthetic starting value; - no real collateral is deposited by the creator. Together with - `Vt`, determines `k = Vt × Vc` (computed and stored at + 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`. - 4. Sale quantity `D`: the number of tokens made available for - purchase (`D < 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 `Vt − D`, untouched until close). `D` is the - supply target: the sale auto-closes when the sale reserve is - exhausted. - 5. Optional: minimum raise threshold (see item 6 below). - 6. Optional: per-transaction buy limit (maximum collateral amount + + 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. + 6. Optional: minimum raise threshold (see item 6 below). + 7. Optional: per-transaction buy limit (maximum collateral amount spendable in a single buy transaction). - 7. Optional: per-block token allocation ceiling (maximum number + 8. 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. - 8. Optional: private allowlist gate (see item 8 below). + 9. Optional: private allowlist gate (see item 8 below). 3. Participants buy project tokens from the curve using either a public account directly, or via the deshield→buy→re-shield pattern for private account interaction (see @@ -221,7 +227,8 @@ RFP-016 instead. public-path buyers. 5. After the sale closes, the creator can withdraw: - The real collateral raised (net of fees). - - The reserved `Vt − D` tokens (if not used for auto-graduation). + - The DEX seed reserve `R` tokens (if not used for + auto-graduation). 6. The sale creator may configure an optional minimum raise threshold at creation time. If the creator closes the sale manually before the supply target is reached, and the real collateral reserve is @@ -552,7 +559,7 @@ production deployments or audits. implications for the minimum raise mechanism. - **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 reserved `Vt − D` + 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 From f0c555d6466ccbdb57ba2c741a743a688988ca3f Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 11:57:50 +1100 Subject: [PATCH 19/30] refund --- RFPs/RFP-015-bonding-curve-launchpad.md | 37 +++++++++++++--------- RFPs/RFP-016-lbp-launchpad.md | 42 ++++++++++++++++++++----- 2 files changed, 58 insertions(+), 21 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index b8cb644..cca1e7b 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -236,10 +236,13 @@ RFP-016 instead. further withdrawals are permitted by the creator, and buyers may submit a refund claim to recover their collateral (see Reliability requirement 4). For buyers who used the private account path, - the refund is credited to the ephemeral public account used during - the buy; the SDK must persist the ephemeral account keypair, or - delegate that persistence to the wallet module, so the buyer can - submit the refund claim. If the supply target is reached + the buyer submits a refund claim by signing with the ephemeral + account keypair used during the original buy (as proof of + purchase) and specifying a refund destination address. The + refund is sent to the specified destination, not to the + ephemeral account itself. The SDK must persist ephemeral + keypairs, or delegate that persistence to the wallet module, + so the buyer can submit the claim. If the supply target is reached automatically (full sell-through), the minimum raise check is skipped; a complete sell-through always succeeds. 7. Slippage protection: buyers specify the collateral amount to spend @@ -496,14 +499,15 @@ transactions. Projects that need strong concentration limits should use the allowlist gate to restrict the eligible set. **Refunds on the private account path require local keypair retention.** -If a sale enters refund state, the refund is credited to the ephemeral -public account used during the original buy. The buyer can reclaim their -collateral by signing the refund claim with that ephemeral account's -keypair. The SDK must persist all ephemeral keypairs used in buy -transactions, or delegate that persistence to the wallet module. If the keypair is lost, the refund -cannot be claimed. The mini-app must clearly communicate this dependency -when a minimum raise is configured and the buyer is using the private -account path. +If a sale enters refund state, the buyer submits a refund claim by +signing with the ephemeral account keypair used during the original +buy (as proof of purchase) and specifying a refund destination. The +ephemeral keypair is used only for authentication, not as the refund +recipient. The SDK must persist all ephemeral keypairs used in buy +transactions, or delegate that persistence to the wallet module. If +the keypair is lost, the refund cannot be claimed. The mini-app must +clearly communicate this dependency when a minimum raise is +configured and the buyer is using the private account path. **Front-running at sale open.** Unlike the LBP mechanism, which opens at a price above estimated fair value and declines over time, a bonding @@ -555,8 +559,13 @@ production deployments or audits. `C_out = Vc - k / (Vt + tokens_in)`. This transforms the bonding curve from a one-time sale vehicle into a continuous liquidity source, but introduces reflexive sell pressure during the sale - window; proposals including this feature must address the - implications for the minimum raise mechanism. + window. A two-way curve may be incompatible with other sale + properties, particularly the minimum raise mechanism (sell-backs + can drain the collateral reserve below the threshold) and the + refund path (buyers could sell back instead of claiming refunds). + Proposals including this feature must explicitly address these + interactions and specify which properties are disabled or + modified. - **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` diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 346ed88..9c70d61 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -130,8 +130,8 @@ they detect large buy orders. ### Minimum raise as an optional parameter The minimum raise threshold protects buyers: if a sale fails to reach -the floor, all collateral is returned and the project does not receive -funds from a failed launch. This mirrors standard crowdfunding +the floor, all collateral is refundable to the buyers who deposited it, +and the project does not receive funds from a failed launch. This mirrors standard crowdfunding protections and prevents projects from extracting liquidity from low-conviction raises. @@ -153,9 +153,11 @@ low-conviction raises. token/collateral ratio). 3. Sale start and end timestamps. 4. Initial token deposit amount. - 5. Optional: minimum raise (sale is considered failed and - collateral is refunded to the creator if the minimum is not - reached by close). + 5. Optional: minimum raise threshold. If the sale closes + (manually or by end timestamp) and the collateral raised is + below this threshold, the sale enters a **refund state**: no + withdrawals are permitted by the creator, and buyers may + submit refund claims to recover their collateral. 6. 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 @@ -272,8 +274,22 @@ low-conviction raises. pool state. 4. The minimum raise check at close time must be evaluated against final pool state, not an intermediate snapshot. If the minimum - is not met, all collateral is returned to the creator and all - project tokens are returned to the creator (not burned). + is not met, the sale enters refund state: the program must + maintain per-buyer purchase records for all public-account + purchases, including ephemeral accounts used in private account + buys, enabling each buyer to claim their collateral refund + independently. Refund claims must be idempotent: a buyer cannot + claim the same purchase twice. The creator cannot withdraw + collateral while the sale is in refund state. Unsold project + tokens are returned to the creator. +5. For refund claims on the private account path, the buyer submits + a refund claim by signing with the ephemeral account keypair + used during the original buy (as proof of purchase) and + specifying a refund destination address. The refund is sent to + the specified destination, not to the ephemeral account itself. + The SDK must persist ephemeral keypairs, or delegate that + persistence to the wallet module, so the buyer can submit the + claim. #### Performance @@ -417,6 +433,18 @@ introducing off-chain coordination that reintroduces centralisation. Projects that need whale concentration limits should use the allowlist gate to restrict the eligible set instead. +**Refunds on the private account path require local keypair +retention.** If a sale enters refund state, the buyer submits a +refund claim by signing with the ephemeral account keypair used +during the original buy (as proof of purchase) and specifying a +refund destination. The ephemeral keypair is used only for +authentication, not as the refund recipient. The SDK must persist +all ephemeral keypairs used in buy transactions, or delegate that +persistence to the wallet module. If the keypair is lost, the +refund cannot be claimed. The mini-app must clearly communicate +this dependency when a minimum raise is configured and the buyer +is using the private account path. + ### Soft Requirements - Support for a fixed-price sale mode (no weight shift; constant From f81874833c0580451d8df8f172d975844ded63c8 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 16:26:13 +1100 Subject: [PATCH 20/30] Remove refund --- RFPs/RFP-015-bonding-curve-launchpad.md | 72 ++------ RFPs/RFP-016-lbp-launchpad.md | 54 +----- appendix/token-launchpad-ecosystem.md | 233 ++++++++++++++++++++++++ 3 files changed, 255 insertions(+), 104 deletions(-) create mode 100644 appendix/token-launchpad-ecosystem.md diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index cca1e7b..2395885 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -199,16 +199,15 @@ RFP-016 instead. 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. - 6. Optional: minimum raise threshold (see item 6 below). - 7. Optional: per-transaction buy limit (maximum collateral amount + 6. Optional: per-transaction buy limit (maximum collateral amount spendable in a single buy transaction). - 8. Optional: per-block token allocation ceiling (maximum number + 7. 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. - 9. Optional: private allowlist gate (see item 8 below). + 8. Optional: private allowlist gate (see item 7 below). 3. Participants buy project tokens from the curve using either a public account directly, or via the deshield→buy→re-shield pattern for private account interaction (see @@ -229,39 +228,23 @@ RFP-016 instead. - The real collateral raised (net of fees). - The DEX seed reserve `R` tokens (if not used for auto-graduation). -6. The sale creator may configure an optional minimum raise threshold - at creation time. If the creator closes the sale manually before - the supply target is reached, and the real collateral reserve is - below this threshold, the sale enters a **refund state**: no - further withdrawals are permitted by the creator, and buyers may - submit a refund claim to recover their collateral (see Reliability - requirement 4). For buyers who used the private account path, - the buyer submits a refund claim by signing with the ephemeral - account keypair used during the original buy (as proof of - purchase) and specifying a refund destination address. The - refund is sent to the specified destination, not to the - ephemeral account itself. The SDK must persist ephemeral - keypairs, or delegate that persistence to the wallet module, - so the buyer can submit the claim. If the supply target is reached - automatically (full sell-through), the minimum raise check is - skipped; a complete sell-through always succeeds. -7. Slippage protection: buyers specify the collateral amount to spend +6. Slippage protection: 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. -8. The sale creator can enable an optional allowlist gate. When +7. The sale creator can enable an optional allowlist gate. When enabled, only participants who can prove inclusion in the committed eligibility set may buy from the curve. The proposing team must specify and justify their allowlist mechanism in their application. -9. The sale creator can pause buying at any time during the sale +8. The sale creator can pause buying at any time during the sale (emergency stop). Pausing does not affect the curve state, the virtual reserves, or the invariant `k`. -10. Use Associated Token Accounts (ATAs) for all token interactions, +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). -11. The sale creator can configure an optional vesting schedule for +10. 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 @@ -344,14 +327,6 @@ RFP-016 instead. atomically in the same transaction. No additional close instruction should be required; no further buys must be accepted after close. -4. If a sale enters refund state (minimum raise not met after manual - close), the program must maintain per-buyer purchase records for - all public-account purchases, including ephemeral accounts used - in private account buys, enabling each buyer to claim their - collateral refund independently. Refund claims must be - idempotent: a buyer cannot claim the same purchase twice. -5. The creator cannot withdraw collateral while the sale is in - refund state. #### Performance @@ -359,7 +334,7 @@ RFP-016 instead. 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, refund claim (if applicable). + sale, buy, close sale, withdraw. Note the LEZ testnet version against which measurements were taken. @@ -377,9 +352,8 @@ and mainnet deployment. coverage must include: invariant preservation across multiple buys, happy-path buy, slippage revert (tokens_out below minimum), allowlist gate accept and reject, auto-close on supply - target, manual close with minimum raise met, manual close with - minimum raise not met (refund path), refund claim by buyer, - pause/resume, per-transaction buy limit enforcement. + target, manual close, pause/resume, per-transaction buy limit + enforcement. 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. @@ -498,17 +472,6 @@ but it does not prevent a single participant from submitting many transactions. Projects that need strong concentration limits should use the allowlist gate to restrict the eligible set. -**Refunds on the private account path require local keypair retention.** -If a sale enters refund state, the buyer submits a refund claim by -signing with the ephemeral account keypair used during the original -buy (as proof of purchase) and specifying a refund destination. The -ephemeral keypair is used only for authentication, not as the refund -recipient. The SDK must persist all ephemeral keypairs used in buy -transactions, or delegate that persistence to the wallet module. If -the keypair is lost, the refund cannot be claimed. The mini-app must -clearly communicate this dependency when a minimum raise is -configured and the buyer is using the private account path. - **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 @@ -559,13 +522,8 @@ production deployments or audits. `C_out = Vc - k / (Vt + tokens_in)`. This transforms the bonding curve from a one-time sale vehicle into a continuous liquidity source, but introduces reflexive sell pressure during the sale - window. A two-way curve may be incompatible with other sale - properties, particularly the minimum raise mechanism (sell-backs - can drain the collateral reserve below the threshold) and the - refund path (buyers could sell back instead of claiming refunds). - Proposals including this feature must explicitly address these - interactions and specify which properties are disabled or - modified. + window. Proposals including this feature must address the + interaction between sell-backs and the collateral reserve. - **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` @@ -609,7 +567,7 @@ is currently **open**. #### Event emission (LP-0012) Analytics dashboards and monitoring services need to react to curve -events (buy executed, sale closed, refund claimed). Without structured +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) @@ -648,6 +606,8 @@ All code must be released under the **MIT+Apache2.0 dual License**. (soft requirement: post-sale vesting integration) - [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) diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 9c70d61..97c4f5c 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -127,14 +127,6 @@ 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. -### Minimum raise as an optional parameter - -The minimum raise threshold protects buyers: if a sale fails to reach -the floor, all collateral is refundable to the buyers who deposited it, -and the project does not receive funds from a failed launch. This mirrors standard crowdfunding -protections and prevents projects from extracting liquidity from -low-conviction raises. - ## ✅ Scope of Work ### Hard Requirements @@ -153,18 +145,13 @@ low-conviction raises. token/collateral ratio). 3. Sale start and end timestamps. 4. Initial token deposit amount. - 5. Optional: minimum raise threshold. If the sale closes - (manually or by end timestamp) and the collateral raised is - below this threshold, the sale enters a **refund state**: no - withdrawals are permitted by the creator, and buyers may - submit refund claims to recover their collateral. - 6. Optional: per-block token allocation ceiling (maximum number + 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. - 7. Optional: private allowlist gate (see item 7 below). + 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 @@ -272,24 +259,6 @@ low-conviction raises. 3. Weight updates (pokes) must be idempotent: submitting multiple pokes within the same block or timestamp window must not corrupt pool state. -4. The minimum raise check at close time must be evaluated against - final pool state, not an intermediate snapshot. If the minimum - is not met, the sale enters refund state: the program must - maintain per-buyer purchase records for all public-account - purchases, including ephemeral accounts used in private account - buys, enabling each buyer to claim their collateral refund - independently. Refund claims must be idempotent: a buyer cannot - claim the same purchase twice. The creator cannot withdraw - collateral while the sale is in refund state. Unsold project - tokens are returned to the creator. -5. For refund claims on the private account path, the buyer submits - a refund claim by signing with the ephemeral account keypair - used during the original buy (as proof of purchase) and - specifying a refund destination address. The refund is sent to - the specified destination, not to the ephemeral account itself. - The SDK must persist ephemeral keypairs, or delegate that - persistence to the wallet module, so the buyer can submit the - claim. #### Performance @@ -312,9 +281,8 @@ and mainnet deployment. 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, minimum raise - not met refund path, weight poke at multiple points in the - schedule. + 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. @@ -433,18 +401,6 @@ introducing off-chain coordination that reintroduces centralisation. Projects that need whale concentration limits should use the allowlist gate to restrict the eligible set instead. -**Refunds on the private account path require local keypair -retention.** If a sale enters refund state, the buyer submits a -refund claim by signing with the ephemeral account keypair used -during the original buy (as proof of purchase) and specifying a -refund destination. The ephemeral keypair is used only for -authentication, not as the refund recipient. The SDK must persist -all ephemeral keypairs used in buy transactions, or delegate that -persistence to the wallet module. If the keypair is lost, the -refund cannot be claimed. The mini-app must clearly communicate -this dependency when a minimum raise is configured and the buyer -is using the private account path. - ### Soft Requirements - Support for a fixed-price sale mode (no weight shift; constant @@ -535,6 +491,8 @@ All code must be released under the **MIT+Apache2.0 dual License**. 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) diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md new file mode 100644 index 0000000..95896f8 --- /dev/null +++ b/appendix/token-launchpad-ecosystem.md @@ -0,0 +1,233 @@ +# 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) and +[RFP-016](../RFPs/RFP-016-lbp-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) | [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/) | +## Scale and Traction + +Launchpads do not hold persistent TVL the way lending or staking +protocols do: capital flows through them during a sale and then moves +on. The tables below use the best available scale metric for each +protocol (cumulative protocol revenue where available, otherwise +cumulative volume raised or AUM). TVL is shown where it applies. + +DAOs.fun is omitted from this section due to insufficient +quantitative data. + +### Cumulative scale + +Protocols ranked by cumulative protocol revenue (or estimated +revenue where only total raised and fee rate are available). + +| Protocol | Cumulative Revenue | TVL / AUM | Tokens Launched | Data as of | +|---|---|---|---|---| +| Pump.fun | $818M+ (protocol fees) [1][2] | $140M (Pumpswap DEX) [3] | 11.7M (H1 2025) [4] | Early 2026 | +| Fjord Foundry | ~$55M (est.) [a] | N/A | 717 LBPs [6] | Sep 2025 | +| Metaplex (all products) | $36M+ [7] | N/A | 20M+ fungible tokens [7] | Sep 2025 | +| DAO Maker | ~$4.5M (est.) [b] | N/A | N/A | Undated | +| Flaunch | $3.1M [9] | $2.03M [9] | N/A | Q1 2026 | +| Polkastarter | ~$460K (est.) [c] | $3.31M (POLS liquidity) [10] | 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. + +### Yearly breakdown + +Where per-year data exists. Blank cells indicate no data available +for that period. + +| Protocol | Metric | 2024 | 2025 | 2026 (YTD / projected) | +| ---------------- | ------------------------------- | ----------------------------------------------------- | -------------------------- | ---------------------- | +| Pump.fun | Protocol revenue | ~$358M [14] | ~$460M+ [14] | | +| Pump.fun | Cumulative trading volume | | >$150B (Dec 2025) [1] | | +| Metaplex | Protocol revenue (all products) | ~$12-15M (est.) [7] | ~$27-30M (est.) [7] | | +| Metaplex Genesis | Launchpad revenue | | $422K/month (Aug 2025) [7] | | +| Flaunch | Protocol revenue | | ~$3.1M [9] | $100.6K (Q1) [9] | +| Fjord Foundry | Cumulative raised (all sales) | >$1.1B (cumulative 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] | | | + +**Caveats:** + +- Metric types differ across protocols (protocol revenue vs. AUM vs. + cumulative volume raised). Cross-category comparisons should account + for this. +- 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. Two +notable exceptions exist: 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 | No [11] | No [11] | Sell back at market price (buy+sell mode only) [11] | +| 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.** 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. + +**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. + +## 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 From 2f1da2f65309bd4d113e9f1058d6ab58eb32a63d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 2 Apr 2026 17:49:03 +1100 Subject: [PATCH 21/30] use trading volume, not TVL --- appendix/token-launchpad-ecosystem.md | 62 +++++++++++++++------------ 1 file changed, 35 insertions(+), 27 deletions(-) diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md index 95896f8..d8f2604 100644 --- a/appendix/token-launchpad-ecosystem.md +++ b/appendix/token-launchpad-ecosystem.md @@ -23,55 +23,61 @@ order is maintained throughout the document. | DAOs.fun | Solana | Fixed-price fair launch for investment DAOs | [daos.fun](https://daos.fun/) | ## Scale and Traction -Launchpads do not hold persistent TVL the way lending or staking -protocols do: capital flows through them during a sale and then moves -on. The tables below use the best available scale metric for each -protocol (cumulative protocol revenue where available, otherwise -cumulative volume raised or AUM). TVL is shown where it applies. +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 protocol revenue (or estimated -revenue where only total raised and fee rate are available). +Protocols ranked by cumulative volume (trading volume or total +funds raised, depending on availability). -| Protocol | Cumulative Revenue | TVL / AUM | Tokens Launched | Data as of | +| Protocol | Cumulative Volume | Cumulative Revenue | Tokens Launched | Data as of | |---|---|---|---|---| -| Pump.fun | $818M+ (protocol fees) [1][2] | $140M (Pumpswap DEX) [3] | 11.7M (H1 2025) [4] | Early 2026 | -| Fjord Foundry | ~$55M (est.) [a] | N/A | 717 LBPs [6] | Sep 2025 | -| Metaplex (all products) | $36M+ [7] | N/A | 20M+ fungible tokens [7] | Sep 2025 | -| DAO Maker | ~$4.5M (est.) [b] | N/A | N/A | Undated | -| Flaunch | $3.1M [9] | $2.03M [9] | N/A | Q1 2026 | -| Polkastarter | ~$460K (est.) [c] | $3.31M (POLS liquidity) [10] | 105+ projects [10] | Q1 2022 | +| 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 [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 / projected) | -| ---------------- | ------------------------------- | ----------------------------------------------------- | -------------------------- | ---------------------- | -| Pump.fun | Protocol revenue | ~$358M [14] | ~$460M+ [14] | | -| Pump.fun | Cumulative trading volume | | >$150B (Dec 2025) [1] | | -| Metaplex | Protocol revenue (all products) | ~$12-15M (est.) [7] | ~$27-30M (est.) [7] | | -| Metaplex Genesis | Launchpad revenue | | $422K/month (Aug 2025) [7] | | -| Flaunch | Protocol revenue | | ~$3.1M [9] | $100.6K (Q1) [9] | -| Fjord Foundry | Cumulative raised (all sales) | >$1.1B (cumulative 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] | | | +| 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 (protocol revenue vs. AUM vs. - cumulative volume raised). Cross-category comparisons should account - for this. +- 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 @@ -231,3 +237,5 @@ toward mandatory cooling-off periods for token sales. 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. From c3ac0e6783705ac93783c3d5d9effaf940e8ed38 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 7 Apr 2026 10:07:27 +1000 Subject: [PATCH 22/30] start appendix --- appendix/token-launchpad-ecosystem.md | 59 +++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md index d8f2604..fbe317c 100644 --- a/appendix/token-launchpad-ecosystem.md +++ b/appendix/token-launchpad-ecosystem.md @@ -185,6 +185,65 @@ 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. + ## References 1. CoinDesk, "Most Influential: Pump.fun," Dec 2025. From 46f73e68ab667e63d095d440884eaebfb0150978 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 7 Apr 2026 10:26:28 +1000 Subject: [PATCH 23/30] address PR #24 review comments: fee structure, allowlist privacy, LBP formulas, evaluation criteria Co-Authored-By: Claude Opus 4.6 --- RFPs/RFP-015-bonding-curve-launchpad.md | 55 +++++- RFPs/RFP-016-lbp-launchpad.md | 147 ++++++++++++++- appendix/token-launchpad-ecosystem.md | 227 ++++++++++++++++++++++++ 3 files changed, 423 insertions(+), 6 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 2395885..70ab411 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -107,13 +107,43 @@ state. ### Optional allowlist -The allowlist gate is optional: many projects want permissionless open +The allowlist gate is opt-in: many projects want permissionless open sales. 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. + +### 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) @@ -225,7 +255,9 @@ RFP-016 instead. disadvantage private-path buyers on price relative to public-path buyers. 5. After the sale closes, the creator can withdraw: - - The real collateral raised (net of fees). + - 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: buyers specify the collateral amount to spend @@ -236,7 +268,10 @@ RFP-016 instead. enabled, only participants who can prove inclusion in the committed eligibility set may buy from the curve. The proposing team must specify and justify their allowlist mechanism in their - application. + 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. The sale creator can pause buying at any time during the sale (emergency stop). Pausing does not affect the curve state, the virtual reserves, or the invariant `k`. @@ -594,6 +629,20 @@ Estimated duration: **10–12 weeks** 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, allowlist privacy interaction (if applicable) | +| 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, vesting), community engagement plan | + + ## Resources - [Logos Documentation](https://github.com/logos-co/logos-docs) diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 97c4f5c..04ac992 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -110,13 +110,31 @@ purchase without requiring private pool state. ### Optional allowlist -The allowlist gate is optional: many projects want permissionless open +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, @@ -127,6 +145,18 @@ 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 @@ -165,7 +195,9 @@ they detect large buy orders. occurred. 5. After the sale end timestamp passes, or when the sale creator explicitly closes the sale, the creator can withdraw: - - The collateral raised (net of fees). + - 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 @@ -174,7 +206,10 @@ they detect large buy orders. 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. + 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. @@ -416,6 +451,98 @@ gate to restrict the eligible set instead. curve over time; buyers transact at the current price as it falls, with earlier buyers paying more than later ones). +### 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 ### Hard blockers @@ -483,6 +610,20 @@ Estimated duration: **14–16 weeks** 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 (weight-shifting AMM or alternative), 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, allowlist privacy interaction (if applicable) | +| 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, vesting), community engagement plan | + + ## Resources - [Logos Documentation](https://github.com/logos-co/logos-docs) diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md index fbe317c..c58738d 100644 --- a/appendix/token-launchpad-ecosystem.md +++ b/appendix/token-launchpad-ecosystem.md @@ -244,6 +244,212 @@ 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. +## 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, and +no admin override. Post-graduation, the token trades on the open +DEX market. + +**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. + +## 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. @@ -298,3 +504,24 @@ serves as an economic Sybil deterrent during the fundraising window. 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 From c34d9957650b7fcc5b4d22f3acc6bdfea0137029 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 8 Apr 2026 11:20:07 +1000 Subject: [PATCH 24/30] lbp: ensure all claims and design choicesare supported --- RFPs/RFP-016-lbp-launchpad.md | 62 ++++--------------- appendix/token-launchpad-ecosystem.md | 85 ++++++++++++++++++++++++++- 2 files changed, 95 insertions(+), 52 deletions(-) diff --git a/RFPs/RFP-016-lbp-launchpad.md b/RFPs/RFP-016-lbp-launchpad.md index 04ac992..e2ffbcb 100644 --- a/RFPs/RFP-016-lbp-launchpad.md +++ b/RFPs/RFP-016-lbp-launchpad.md @@ -10,6 +10,8 @@ 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 @@ -31,8 +33,9 @@ established. ## 🔥 Why This Matters -LBPs have become the dominant mechanism for fair, permissionless token -price discovery. Fjord Foundry's own FJO token LBP raised $15.35M in +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 @@ -65,16 +68,16 @@ anything available on existing launchpad platforms. 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 strong empirical track record (Fjord Foundry, Balancer) and -is well understood by the DeFi builder community. +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) hides individual bids and is well-suited +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. @@ -193,8 +196,7 @@ protocols. 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, or when the sale creator - explicitly closes the sale, the creator can withdraw: +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). @@ -217,17 +219,6 @@ protocols. 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). -10. 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. The creator then claims - collateral over time per the schedule terms. When - milestone-based vesting is used, milestone authority must be - held by a party other than the sale creator (e.g., a governance - body or multisig) to prevent the creator from approving - milestones and draining funds unilaterally. #### Usability @@ -441,15 +432,6 @@ gate to restrict the eligible set instead. - 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. -- **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 returned to - the buyer's private account. This enables sale-plus-vesting in a - single flow. - -- Support for a Dutch auction mode (price declines on a configurable - curve over time; buyers transact at the current price as it falls, - with earlier buyers paying more than later ones). ### Reference Implementation @@ -545,10 +527,8 @@ existing production deployments or audits. ## ⚠ Platform Dependencies -### Hard blockers - -These must be available on LEZ before this RFP can open. +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 @@ -575,10 +555,6 @@ making it impossible to complete the full buy atomically. (General cross-program calls via tail calls) solves this. This prize is currently **open**. -### Soft blockers - -Desirable but the RFP can open without them. - #### Event emission (LP-0012) Analytics dashboards and sale monitoring services need to react to @@ -608,22 +584,6 @@ Estimated duration: **14–16 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 (weight-shifting AMM or alternative), 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, allowlist privacy interaction (if applicable) | -| 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, vesting), community engagement plan | - - ## Resources - [Logos Documentation](https://github.com/logos-co/logos-docs) diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md index c58738d..0b32d7b 100644 --- a/appendix/token-launchpad-ecosystem.md +++ b/appendix/token-launchpad-ecosystem.md @@ -21,6 +21,17 @@ order is maintained throughout the document. | 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 @@ -38,7 +49,7 @@ 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 [6] | Sep 2025 | +| 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 | @@ -392,6 +403,74 @@ 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 @@ -525,3 +604,7 @@ anonymity set regardless of allowlist size. 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 From df4e925b97efbb59c7f086dd09fe1ad20b4df42a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 8 Apr 2026 11:20:19 +1000 Subject: [PATCH 25/30] ignore llm files --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) 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/ From 1fc7303af8ffda39ca69c6edb5f20f6ff3101121 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 8 Apr 2026 11:58:46 +1000 Subject: [PATCH 26/30] bonding curve: ensure all claims are backed --- RFPs/RFP-015-bonding-curve-launchpad.md | 268 ++++++++++-------------- appendix/token-launchpad-ecosystem.md | 68 ++++-- 2 files changed, 159 insertions(+), 177 deletions(-) diff --git a/RFPs/RFP-015-bonding-curve-launchpad.md b/RFPs/RFP-015-bonding-curve-launchpad.md index 70ab411..8cca6cb 100644 --- a/RFPs/RFP-015-bonding-curve-launchpad.md +++ b/RFPs/RFP-015-bonding-curve-launchpad.md @@ -23,9 +23,7 @@ or, for privacy, via a deshield→buy→re-shield pattern (see 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. +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 @@ -73,23 +71,29 @@ 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. An optional end timestamp is -supported for projects that need a hard deadline, preventing -zombie sales that sit open indefinitely if demand is low. - -### One-directional sale - -The sale is one-directional: buyers purchase tokens from the curve; -there is no sell-back path during the sale. This is the correct choice -for a token launch: it prevents reflexive sell pressure during the -distribution window, simplifies pool accounting, and removes the attack -surface of circular buy-sell cycles. The accumulated collateral reserve -is locked until close and either withdrawn by the creator or used to -seed a DEX pool (see auto-graduation in Soft Requirements). - -Optional sell-back (two-way curve) is a soft requirement for projects -that want continuous liquidity from day one rather than a bounded -sale-plus-DEX-seed model. +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 @@ -105,33 +109,6 @@ privacy is enforced at the UX layer via the optional deshield→buy→re-shield pattern, which does not require private pool state. -### Optional allowlist - -The allowlist gate is opt-in: many projects want permissionless open -sales. 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. - ### Fee structure This RFP does not mandate a specific fee rate. Proposals must @@ -176,10 +153,9 @@ 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. The allowlist gate (restricted early access) and -per-transaction buy limits (see Functionality requirement 2) are -available mitigations, but neither eliminates the advantage entirely. -Projects seeking the strongest bot-deterrence properties should use +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 @@ -190,22 +166,27 @@ RFP-016 instead. 1. Implement a bonding curve program on LEZ with a deterministic, supply-driven pricing mechanism that maintains a well-defined - invariant across all buy 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`. After each buy, the curve state must - be updated to preserve the pricing invariant. The real token - reserve decreases by `tokens_out`; the real collateral reserve - increases by `C_in`. If the computed `tokens_out` would exceed the + 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: `tokens_out` rounds down, `C_in` rounds up. 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 formula and - the deviation standard for alternative mechanisms. + 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 @@ -229,67 +210,31 @@ RFP-016 instead. 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. - 6. Optional: per-transaction buy limit (maximum collateral amount - spendable in a single buy transaction). - 7. 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. - 8. Optional: private allowlist gate (see item 7 below). -3. Participants buy project tokens from the curve 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), which defines - this interaction model for LEZ applications). Both paths must be - supported by the program and SDK. +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), or when an optional end - timestamp configured at creation time is reached, whichever - comes first. The creator can also close the sale manually at - any time before either condition is met. 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. + (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: 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. -7. The sale creator can enable an optional allowlist gate. When - enabled, only participants who can prove inclusion in the - committed eligibility set may buy from the curve. 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. The sale creator can pause buying at any time during the sale - (emergency stop). Pausing does not affect the curve state, the - virtual reserves, or the invariant `k`. -9. Use Associated Token Accounts (ATAs) for all token interactions, +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). -10. 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. The creator then claims - collateral over time per the schedule terms. When - milestone-based vesting is used, milestone authority must be - held by a party other than the sale creator (e.g., a governance - body or multisig) to prevent the creator from approving - milestones and draining funds unilaterally. #### Usability @@ -297,7 +242,7 @@ RFP-016 instead. 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, - pause/resume, close, withdraw). The SDK must support both direct + 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 @@ -310,14 +255,14 @@ RFP-016 instead. 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`, allowlist configuration), + `Vt`, `Vc`, sale quantity `D`), monitor an active sale (live supply progress, collateral - raised), pause/resume, close sale, and withdraw proceeds. + 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, - pause/resume, close, withdraw). + 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 @@ -348,8 +293,8 @@ RFP-016 instead. [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, sale paused, allowlist gate rejected, slippage - exceeded, per-transaction buy limit exceeded). + reached, slippage + exceeded). #### Reliability 1. Curve state (`Vt`, `Vc`, `k`, real reserves) must remain @@ -386,9 +331,8 @@ and mainnet deployment. 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), allowlist gate accept and reject, auto-close on supply - target, manual close, pause/resume, per-transaction buy limit - enforcement. + 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. @@ -467,8 +411,6 @@ For every buy from a private account: block height. 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) @@ -494,27 +436,14 @@ SDK accept full responsibility for any resulting privacy loss. ### Known Limitations -**Per-wallet buy limits are not supported for the private account -path.** Enforcing a cap on cumulative spend per participant requires -tracking spend per address. For public account interactions this is -feasible, but is 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 per-transaction buy limit (Functionality -requirement 2) is a partial mitigation: it bounds the collateral -spendable in a single buy, which raises the cost of rapid accumulation, -but it does not prevent a single participant from submitting many -transactions. Projects that need strong concentration limits should -use the allowlist gate to restrict the eligible set. - **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. The allowlist gate and -per-transaction buy limit reduce the impact but do not eliminate it. -Projects requiring stronger bot deterrence should use -[RFP-016](./RFP-016-lbp-launchpad.md) instead. +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 @@ -537,8 +466,16 @@ The inverse (exact collateral cost for a requested token quantity `Q`): C_in = k / (Vt - Q) - Vc ``` -After each buy, `Vt` and `Vc` are updated to preserve `k`. `k` is -computed at creation as `Vt × Vc` and must never change. +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, @@ -551,14 +488,13 @@ production deployments or audits. ### Soft Requirements -- **Two-way (sell-back) curve**: after purchasing tokens, holders - can sell them back to the curve, receiving collateral from the - real reserve. The sell formula is the inverse of the buy formula: - `C_out = Vc - k / (Vt + tokens_in)`. This transforms the bonding - curve from a one-time sale vehicle into a continuous liquidity - source, but introduces reflexive sell pressure during the sale - window. Proposals including this feature must address the - interaction between sell-backs and the collateral reserve. +- **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` @@ -566,11 +502,19 @@ production deployments or audits. [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. -- **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. This enables a sale-plus-vesting flow - in a single operation. +- **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 @@ -637,10 +581,10 @@ 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, allowlist privacy interaction (if applicable) | +| 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, vesting), community engagement plan | +| Ecosystem alignment | 10% | Open source commitment, composability with other LEZ programs (DEX), community engagement plan | ## Resources @@ -651,8 +595,6 @@ following criteria. - [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) - [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) diff --git a/appendix/token-launchpad-ecosystem.md b/appendix/token-launchpad-ecosystem.md index 0b32d7b..f11ce96 100644 --- a/appendix/token-launchpad-ecosystem.md +++ b/appendix/token-launchpad-ecosystem.md @@ -100,10 +100,12 @@ variable fee tiers. ## Refund Mechanisms Most crypto-native launchpads treat purchases as final: once a buyer -executes a swap or deposit, there is no platform-level refund. Two -notable exceptions exist: 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 +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]. @@ -113,7 +115,8 @@ cancellation window plus a mandatory minimum raise threshold [20]. | Protocol | Post-purchase refund | Minimum raise (soft cap) | Cancellation during sale | |---|---|---|---| | Pump.fun | No | No | No | -| Fjord Foundry | No [11] | No [11] | Sell back at market price (buy+sell mode only) [11] | +| 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 | @@ -132,12 +135,16 @@ opens and tokens are distributed, purchases are final. irreversible AMM swaps. Once a token graduates to Pumpswap, it trades on the open market with no platform-level buyer protection. -**Fjord Foundry.** 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. +**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 @@ -255,6 +262,21 @@ 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: +Metaplex Genesis supports per-wallet deposit limits enforced on-chain +[16]; Fjord Foundry tiered sales (Seed, Private, Public rounds) +support per-user min/max allocation per tier [33]; DAO Maker and +Polkastarter enforce allocation limits through their staking tier +systems [12][10]. + +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; the mechanism does not track +cumulative spend per address. + ## Fee Structures Fee models vary widely across launchpad protocols, from zero-fee @@ -373,9 +395,17 @@ is delegated to a human fund manager with discretionary authority. **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, and -no admin override. Post-graduation, the token trades on the open -DEX market. +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]. @@ -608,3 +638,13 @@ anonymity set regardless of allowlist size. 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 From 6464fbd905b45ea00bc6956579792ae55ce2e5bf Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 31 Mar 2026 14:44:23 +1100 Subject: [PATCH 27/30] RFP-001 & RFP-002: ask for libraries, not PoCs --- README.md | 6 +- ...-poc.md => RFP-001-admin-authority-lib.md} | 49 ++++---- RFPs/RFP-002-freeze-authority-lib.md | 107 ++++++++++++++++++ RFPs/RFP-002-freeze-authority-poc.md | 103 ----------------- RFPs/RFP-008-lending-borrowing-protocol.md | 3 +- RFPs/RFP-012-advanced-lending-features.md | 3 +- 6 files changed, 138 insertions(+), 133 deletions(-) rename RFPs/{RFP-001-admin-authority-poc.md => RFP-001-admin-authority-lib.md} (55%) create mode 100644 RFPs/RFP-002-freeze-authority-lib.md delete mode 100644 RFPs/RFP-002-freeze-authority-poc.md diff --git a/README.md b/README.md index 68678c0..36dd807 100644 --- a/README.md +++ b/README.md @@ -58,9 +58,9 @@ 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) | diff --git a/RFPs/RFP-001-admin-authority-poc.md b/RFPs/RFP-001-admin-authority-lib.md similarity index 55% rename from RFPs/RFP-001-admin-authority-poc.md rename to RFPs/RFP-001-admin-authority-lib.md index 071d03e..94396d2 100644 --- a/RFPs/RFP-001-admin-authority-poc.md +++ b/RFPs/RFP-001-admin-authority-lib.md @@ -1,6 +1,6 @@ --- id: RFP-001 -title: Admin Authority +title: Admin Authority Library tier: XS funding: $XXXXX status: open @@ -8,21 +8,17 @@ category: Developer Tooling & Infrastructure --- -# RFP-001 — Admin Authority +# RFP-001 — Admin Authority Library ## 🧭 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. +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. -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. +The library must be importable as a dependency by any LEE program and ship +with documentation and usage examples so teams can integrate the pattern +without re-implementing it from scratch. ## 🔥 Why This Matters @@ -31,13 +27,9 @@ 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 +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. 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. +authority patterns, accelerating the pace at which new programs ship. ## ✅ Scope of Work @@ -47,14 +39,19 @@ environments. 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). +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. There can only be one admin authority (signer) at a time. +2. 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. +3. Documentation includes at least one end-to-end usage example showing + how a SPEL program gates its own instructions behind the admin authority. #### Supportability -1. Demonstrated as a sample app; the program's core functionality does - not matter — the focus is on the admin authority pattern. +1. Unit and integration tests cover all hard requirements and run in CI. +2. 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 @@ -69,10 +66,11 @@ Developer experienced with: - 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: **2 weeks** +Estimated duration: **4 weeks** ## 🌍 Open Source Requirement @@ -82,7 +80,8 @@ All code must be released under the **MIT+Apache2.0 dual License**. ## Resources -TODO: LEE official doc +- [SPEL framework](https://github.com/logos-co/spel) +- TODO: LEE official doc ## ✏️ How to Apply diff --git a/RFPs/RFP-002-freeze-authority-lib.md b/RFPs/RFP-002-freeze-authority-lib.md new file mode 100644 index 0000000..26c3595 --- /dev/null +++ b/RFPs/RFP-002-freeze-authority-lib.md @@ -0,0 +1,107 @@ +--- +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 importable as a dependency by any LEE program and ship +with documentation and usage examples so teams can integrate the pattern +without re-implementing it from scratch. + +## 🔥 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 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. +2. 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. +3. Documentation includes at least one end-to-end usage example showing + how a SPEL program integrates the freeze check. +#### Supportability +1. Unit and integration tests cover all hard requirements and run in CI. +2. 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. + +### 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) +- Library/crate packaging and documentation + +## ⏱ Timeline Expectations + +Estimated duration: **4 weeks** + + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual 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 From 69b0b5eb65f3f9f2c74c85cfd75b71f13b292f3b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 31 Mar 2026 14:50:48 +1100 Subject: [PATCH 28/30] match to template --- RFPs/RFP-001-admin-authority-lib.md | 50 ++++++++++++++++-------- RFPs/RFP-002-freeze-authority-lib.md | 57 ++++++++++++++++++---------- 2 files changed, 72 insertions(+), 35 deletions(-) diff --git a/RFPs/RFP-001-admin-authority-lib.md b/RFPs/RFP-001-admin-authority-lib.md index 94396d2..4f4a712 100644 --- a/RFPs/RFP-001-admin-authority-lib.md +++ b/RFPs/RFP-001-admin-authority-lib.md @@ -16,9 +16,9 @@ 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 importable as a dependency by any LEE program and ship -with documentation and usage examples so teams can integrate the pattern -without re-implementing it from scratch. +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 @@ -34,29 +34,49 @@ 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. + 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). + exposed by the library (demonstrated via a gated `config` PDA update). + #### Usability -1. There can only be one admin authority (signer) at a time. -2. 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. + +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. + 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. Unit and integration tests cover all hard requirements and run in CI. -2. A sample program that imports the library is included to validate the - integration path and serve as a reference for consumers. + +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. + or deployed PDA), when set or initialised. ## 👤 Recommended Team Profile @@ -75,7 +95,7 @@ Estimated duration: **4 weeks** ## 🌍 Open Source Requirement -All code must be released under the **MIT+Apache2.0 dual License**. +All code must be released under the **MIT+Apache2.0 License**. ## Resources diff --git a/RFPs/RFP-002-freeze-authority-lib.md b/RFPs/RFP-002-freeze-authority-lib.md index 26c3595..cf19a33 100644 --- a/RFPs/RFP-002-freeze-authority-lib.md +++ b/RFPs/RFP-002-freeze-authority-lib.md @@ -16,9 +16,9 @@ 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 importable as a dependency by any LEE program and ship -with documentation and usage examples so teams can integrate the pattern -without re-implementing it from scratch. +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 @@ -31,41 +31,58 @@ 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 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. +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. + 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. -2. 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. + +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. + 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. Unit and integration tests cover all hard requirements and run in CI. -2. A sample program that imports the library is included to validate the - integration path and serve as a reference for consumers. + +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. + or deployed PDA), when set or initialised. -### Out-of-scope +### 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. @@ -89,7 +106,7 @@ Estimated duration: **4 weeks** ## 🌍 Open Source Requirement -All code must be released under the **MIT+Apache2.0 dual License**. +All code must be released under the **MIT+Apache2.0 License**. ## Resources From 69eb7d7e30b341aad7b1bb50392026681fed0d10 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 1 Apr 2026 12:22:05 +1100 Subject: [PATCH 29/30] freeze per account --- RFPs/RFP-002-freeze-authority-lib.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/RFPs/RFP-002-freeze-authority-lib.md b/RFPs/RFP-002-freeze-authority-lib.md index cf19a33..f50cada 100644 --- a/RFPs/RFP-002-freeze-authority-lib.md +++ b/RFPs/RFP-002-freeze-authority-lib.md @@ -47,6 +47,11 @@ catastrophic loss. 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 @@ -82,12 +87,6 @@ If possible. 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 From 00111aa07cbf1bce68e835e3895940ebc2e5f328 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 8 Apr 2026 14:21:36 +1000 Subject: [PATCH 30/30] RFP-18: Tiered Sale Launchpad --- RFPs/RFP-018-tiered-sale-launchpad.md | 663 ++++++++++++++++++++++++++ appendix/token-launchpad-ecosystem.md | 152 +++++- 2 files changed, 800 insertions(+), 15 deletions(-) create mode 100644 RFPs/RFP-018-tiered-sale-launchpad.md 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 index f11ce96..38abd1b 100644 --- a/appendix/token-launchpad-ecosystem.md +++ b/appendix/token-launchpad-ecosystem.md @@ -3,9 +3,11 @@ 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) and -[RFP-016](../RFPs/RFP-016-lbp-launchpad.md), providing context on -current market participants, their mechanisms, and design trade-offs. +[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 @@ -15,7 +17,7 @@ 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) | [fjordfoundry.com](https://www.fjordfoundry.com/) | +| 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/) | @@ -265,17 +267,137 @@ 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: -Metaplex Genesis supports per-wallet deposit limits enforced on-chain -[16]; Fjord Foundry tiered sales (Seed, Private, Public rounds) -support per-user min/max allocation per tier [33]; DAO Maker and -Polkastarter enforce allocation limits through their staking tier -systems [12][10]. - -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; the mechanism does not track -cumulative spend per address. +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