RFP-15 & RFP-16: Token Launchpads

[fryorcraken]

No description provided.

[fryorcraken]

I am not familiar with bonding curve so I need someone to check this is all correct.

[mart1n-xyz]

That's another bot of mine 😄

Given these issues, maybe we should involve our expert on curves @juanpmcianci

[roxanneen]

How does this account for rounding errors? Standard practice was/is to round against the trader ('tokens_out' value round "-", 'C_in' value rounds "+") like in Uniswap V2, Curve etc. This is done by design (integer-only).
In V3 for e.g., all rounding errors favour the pool via asymmetric rounding, and some other stuff that ensures the pool stays solvent.
In V4, you can have these "hooks", where you can customise the logic. There's some V4 launchpads like Flaunch, worth looking at, btw. Key design choices in Flaunch, summarised:

• Uses V4 hooks to create a bonding curve within a Uniswap pool (not a separate contract).
• Auto-graduates to a standard V4 pool at threshold (similar to RFP-015 DEX seeding).
• Fee routing is handled via hooks, where fees can go to creators, LPs, or a treasury.
• Revenue share model where the token itself earns trading fees perpetually.

This means bonding curve → AMM graduation can be atomic and trustless. The token never leaves a single venue.

On LEZ, this would mean the bonding curve program itself transforms into (or seeds) a DEX pool at close, rather than requiring a separate DEX program and a multi-step process.

You could however create an ICO model where raised funds are diverted to a separate vesting/timelock contract and funds are released to project team on a defined schedule (linear over "n" months, cliff + linear, milestone-gated via oracle/governance):

Raised-collateral protection: Both RFP-015 and RFP-016 send collateral directly to the creator at close. This leaves buyers exposed: launch -> close -> receive all collateral ->rug pull. Which can be avoided with a standalone vesting program ("composition primitive") for launchpads, independent on type of launchpad we go for, then an integration spec is needed between programs.

i.e. Bonding curve withdrawal interface should accept a vesting program account as the collateral destination, so at close, raised funds flow into an RFP-017 schedule rather than the creator's wallet. Both programs share cross-program calls dependencies.

Gap here would be milestone authority is creator-controlled by design in token vesting programs. That's appropriate for team vesting but counterproductive for buyer protection as the creator could approve their own milestones and drain funds immediately. If vesting is used to protect launch participants, milestone authority should be delegable to a governance body or multisig that excludes the creator.
Token vesting program requires for separate cancellation authority, but milestone authority needs similar treatment.

[mart1n-xyz]

I think these may be important additions. We can either have them delivered as Lambda prizes on top of the core RFP, or wait for the big Lambda prize for the launchpad that conditions on the actual traction and building on top of this RFP outcome. This would assume the entity that attempts to commertialize this os code will package it in a way to maximise PMF. Given that, I wouldn't introduce further functional requirements at this stage, so that we leave enough space for PMF explorations.

[fryorcraken]

You could however create an ICO model where raised funds are diverted to a separate vesting/timelock contract and funds are released to project team on a defined schedule (linear over "n" months, cliff + linear, milestone-gated via oracle/governance):

This does not exist in Solana and Ethereum ecosystems so I prefer to leave it out of the initial RFP. As per @mart1n-xyz 's comment.

[roxanneen]

I see no time-bounding mechanism, was this intentional? The sale opens at creation and closes only when supply D is exhausted or the creator manually closes. This creates two risks:

a. Zombie sales. IF a sale fails to attract demand, it sits open indefinitely with collateral locked and no resolution path (other than the creator remembering to close it).
b. Asymmetric close timing. Since manual close is an off-chain decision, the creator (or anyone watching the creator's wallet) could have informational advantage over when graduation/DEX seeding will occur. What sort of protections do we have here?

Please consider adding an optional deadline parameter at sale creation. In bonding curve launchpad we don't need continuous time interpolation (we'd need weight curve in LBP RFP-016), a block-height deadline is sufficient and avoids dependency on the on-chain clock primitive that is currently unresolved (? when would this be resolved btw?).

The close condition then becomes:

sale_completion = (tokens_sold >= D) OR (creator_closed) OR (block.height >= deadline_block).

Separately: if an optional deadline is added, the minimum sale duration should be long enough (suggest ≥ 4 hours) that random delays in the deshield→buy→re-shield privacy path don't systematically disadvantage private-path buyers on price relative to public buyers.

[fryorcraken]

There is a time-bounding mechanism, but set as a soft-requirement. see Time-based sale end. Moved to hard requirement.

[fryorcraken]

No bonding curve platform implements time-based close. All use supply or price targets exclusively:

• Pump.fun: Closes on supply target (graduation threshold) only. No time expiry. Curves that never graduate remain as dormant on-chain accounts
  indefinitely. Graduation rate is ~0.7%–1.4%, meaning over 98% of bonding curves become zombie sales with no close mechanism.
• Meteora DBC, Flaunch, Raydium LaunchLab: Same pattern. Supply target only, no time-based close.

So keeping it as as soft requirements, as the zombie sales on pump.fun could use such a parameter.

[roxanneen]

Would there be no refund state enabled even if minimum target is reached? Usually, a participant is offered a 3-day period for refunds if performance is bad. Wondering how this limited refund feature would co-exist with the exit ideology of Logos.

[fryorcraken]

Will look into what other protocols do.

[fryorcraken]

Removed the minimum raise threshold and refund state from both RFP-015 and RFP-016.

Post-purchase refunds are not common in the ecosystem: of the seven crypto-native launchpads surveyed, five have no refund mechanism at all (Pump.fun, Fjord Foundry, Flaunch, Polkastarter, DAO Maker SHO). The two that do (DAO Maker DYCO, DAOs.fun) use specialized models (16-month USDC-backed buyback; ragequit with 10% penalty) that are not comparable to a bonding curve or LBP.

See the Token Launchpad Ecosystem appendix for the full comparison.

Collateral vesting (Functionality item 10/9) remains as the buyer protection mechanism: it prevents the creator from withdrawing all raised funds immediately.

[roxanneen]

Fjord has some refund options for pre-TGE if the sale fails to meet the project’s minimum raise goal (soft or hard floor).
Polkastarter has a flexible refund policy, on a case by case.
DAO Maker actually had required a large budget from projects to list their sale there, and offered those refundable formats (DYCO), max. 3 days post launch if token performance plummeted drastically.
Pump.fun has no vesting and it's a straight out memecoin / ico style launch, so it's irrelevant.

Note: refunds was an item only for tokens with vesting schedules part of the sale. doesn't make much sense for straight up ICO.

[fryorcraken]

Fjord has some refund options for pre-TGE if the sale fails to meet the project’s minimum raise goal (soft or hard floor).

Yes, but not for their LBP sales.

The question is whether we want a RFP For "Seed, Private & Public Rounds"

[fryorcraken]

Collateral vesting (Functionality item 10/9) remains as the buyer protection mechanism: it prevents the creator from withdrawing all raised funds immediately.

Not standard practice from my research, so leaving it out.

[roxanneen]

Allowlists work against a "fair launch" model, I'd argue against them on ideology beyond breaking our privacy assumptions. As for the proof system, we know that the anonymity set is bounded by the allowlist size.
i.e. ZK proof with an allowlist of 50 means an observer knows the buyer is one of 50.
i.e. ZK proof with an allowlist of 10,000 means an observer knows the buyer is one of 10,000
No allowlist = anonymity set is everyone on the network.

If they're implemented, it should be an opt-in mode that explicitly documents privacy tradeoffs.

[fryorcraken]

I'll look into what other protocols do.

Not sure the privacy comment is correct. The allow list could use private accounts as an id, so the k-anonymity set is among all private accounts in the zone.

Martin made a good point in a recent call. We should not see LEZ as a transparent chain, where k-anonymity set is per program. Any interaction using a private account fits in the anonymity set of the whole chain.

[roxanneen]

"Martin made a good point in a recent call. We should not see LEZ as a transparent chain, where k-anonymity set is per program. Any interaction using a private account fits in the anonymity set of the whole chain."

It looks like the base chain is transparent (except for the private proof of stake component and separation of validator identity & staked amounts), so it's not clear to me if LEZ is private by default. I thought it could be either, depending on the state architecture required?

If it's private by default, then the k-anonymity set should function like in the FCMP++ in Monero. Either way, this needs to be documented, otherwise it will confuse builders.

[roxanneen]

"Account A is never reused."
The SDK should absolutely make it impossible to accidentally reuse an ephemeral account.

Regarding 're-shield' function, this doesn't happen onchain, correct? If a buyer uses a different SDK or calls the program directly, they could skip the re-shield and leave tokens in the ephemeral public account, which results in deanonymisation. Looks like the program wouldn't be able to enforce it, which means the privacy guarantee depends entirely on the buyer using the correct SDK. The trust assumption should be clearly documented, unless it can be enforced.

[fryorcraken]

Regarding 're-shield' function, this doesn't happen onchain, correct?

It does. It will be a public account to private account transfer.

If a buyer uses a different SDK or calls the program directly, they could skip the re-shield and leave tokens in the ephemeral public account, which results in deanonymisation.

Yes, they could leave the token in a public account.

Looks like the program wouldn't be able to enforce it, which means the privacy guarantee depends entirely on the buyer using the correct SDK. The trust assumption should be clearly documented, unless it can be enforced.

Yes

[roxanneen]

Does this mean that LEZ transaction model supports multi-asset atomic transfers in a single indivisible action? :D

[fryorcraken]

Good Q. https://discord.com/channels/973324189794697286/1462844746140618753/1489043307089887392

[roxanneen]

Seems it does / will. Good stuff.

[roxanneen]

Another option would be a global per-block token allocation ceiling.
If you have D = 1,000,000 and max_tokens_per_block = 5,000, accumulating the entire supply requires a minimum of 200 blocks, regardless of how many ephemeral accounts the buyer uses. This could slow down capital allocation. Would require a high activity chain to work as intended.

[roxanneen]

I need to check Fjord Foundry papers, the Balancer LBP formula is: a any time 't', the weight of token 'A' is:

w_A(t) = w_start + (w_end - w_start) × (t - t_start) / (t_end - t_start)

The spot price is then:

price = (reserve_collateral / w_collateral) / (reserve_token / w_token)

Note that this is more complex than the bonding curve formula in RFP-015, as it requires timestamps reliability (as opposed to block height); weight interpolation at arbitrary points; price computation for both reserves & weights. So every buy tx needs to know the current time to compute the correct weight. If the weight curve stops being continuous it could create arbitrage opportunities.
(it's not clear how that is solved)

[fryorcraken]

See new reference implementation

[roxanneen]

Does the program compute weights lazily (at each buy, compute current weight from timestamp) or does it require explicit poke transactions to update stored state? explicit poke tx's add additional state management.

[fryorcraken]

The RFP specifies both: the program computes weights lazily at each buy (Functionality req 4: "The LBP program must apply the correct weight at transaction time regardless of how recently the last poke occurred"), and explicit poke transactions are available so any account can advance the stored state independently of a buy.

[roxanneen]

Possible trust issue in LBP: the creator receives the collateral back; buyers trust the creator to return funds. So buyer protection is weaker in LBP than in bonding curve model where we have individual refund claims. This can be addressed if LBP refund path supports direct buyer claims. (would be great if someone could clarify this possibility)

[fryorcraken]

Refund removed, as aligned with ecosystem.

[roxanneen]

These requirements imply LEZ supports cross-program calls and offers an onchain timestamp mechanism. Would require both for an LBP launchpad to work.

[fryorcraken]

we explicitly statement those technical dependencies. the LBP launchpad cannot be built without them.

[juanpmcianci]

I think this is incorrect. At sale close (all D tokens sold), the program still holds Vt − D tokens reserved for DEX seeding.

IMO, the correct close condition is: the sale portion of the token reserve is exhausted (D tokens have been sold). There should be two distinct accounting buckets:

• sale_reserve: starts at D, decreases with each purchase
• dex_seed_reserve: starts at (Vt − D), untouched until close

[juanpmcianci]

This should go back to the buyers, not the creator, i believe.

In a standard LBP, the creator deposits project tokens and zero (or near-zero) initial collateral. However, every unit of collateral in the pool at close was paid by buyers. Returning it to the creator in a failed sale is returning buyer funds to the project team.

As written, the minimum raise parameter is a mechanism by which a creator can run a sale, collect some collateral, close manually before the minimum is hit, and receive all buyer funds with no recourse.

[fryorcraken]

removed as not common practice for LBP token launchpads.

[juanpmcianci]

Another general comment for RFPs: Should we include a "scorecard" of sorts? if there are N submissions, all of them would, by definition, need to meet the hard requirements, but how do we decide which proposal to choose, and more importantly, how can we guide the proposers in their design into what is best for us?

[fryorcraken]

@hackyguru please review/advise

[mart1n-xyz]

This would be an internal tool, right?

[fryorcraken]

🔴 2. Allowlist + Privacy = Unresolved Conflict (Lines 106-112, 231-234)

Going to ignore that, see #24 (comment)

I think it's misdirected here and confused with the transparent Ethereum account system. You could have Private accounts in the allow list, you could even have empty public accounts, and use gas from a private account and just sign with a public account. What matters is that the properties are properly documented.