Overview
S3ND (s3nd.fun) is a thin Solana launchpad wrapper around audited Meteora primitives: Dynamic Bonding Curve (DBC) for pricing and fee accounting, DAMM v2 for the post-graduation pool, and a small Anchor wrapper for ticker locks and the 3 SOL skin-in-the-game deploy deposit. See the architecture section for the layered breakdown.
The design goal is one line: reward conviction, price out the flip-and-dump rotation. Meteora's FeeSchedulerLinear charges the same fee on buys and sells — 10% at minute 0, decaying to 1% at minute 60, then flat forever — so round-tripping in the first hour costs ~20 % of position value while a holder past hour one pays the same 1%every long-term holder pays. The wrapper just adds a refundable deploy deposit (with creator self-recovery after 30 days if a launch never bonds) and a ticker lock so squatters don't hog popular names.
Deploy deposit
3 SOL
Refunded at graduation, creator-recoverable after 30 d
Bond target
100 SOL
Auto-migrates to Meteora DAMM v2
Total supply
1,000,000,000
700M curve / 300M LP reserve, fixed
Trade fee
10% → 1%
Linear decay over 60 min, then flat
How a launch works
- 1
Deploy
The creator calls reserve_launch on the S3ND wrapper, paying 3 SOL into a DeploySeed PDA, and atomically initialises a Meteora DBC pool against the S3ND DBC config. The ticker is locked. The deployer may optionally bundle a first DBC swap in the same transaction at curve price; that buy pays the same 10% first-swap fee any other minute-zero wallet would pay.
- 2
Trade
Buyers and sellers swap directly against the Meteora DBC pool. Every swap pays a single time-decayed fee — 10% at minute 0, gliding linearly down to 1% at minute 60 and staying flat thereafter. Today the entire fee flows to the S3ND treasury; the creator's declining post-bond share is paid out by the custom Creator Vault rolling out in Phase 3.0.6. No separate sell tax, no per-wallet hold cap, no transfer hook.
- 3
Bond
When net curve deposits reach ~100 SOL, DBC graduates the launch. In one atomic instruction the curve closes, 300M reserved tokens and the curve SOL are deposited into a fresh DAMM v2 pool, and the LP position is created with partnerPermanentLockedLiquidityPercentage = 100. The creator then claims their 3 SOL deploy deposit themselves — the wrapper's claim_deploy_refund instruction inspects the DBC pool's is_migrated byte on-chain, so no off-chain bot is in the loop. Bonded launches stay claimable by the creator forever; only abandoned (≥ 60 d unbonded) deposits get swept to the treasury.
Tokenomics
Every S3ND launch has the same fixed supply schedule encoded into the S3ND DBC config. No free dev allocation, no team unlocks, no surprise mint authority. The deployer can optionally bundle a first DBC swap with the launch transaction, but it pays curve price and the same 10% first-swap fee every other minute-zero wallet faces.
1B
Total supply
Mint authority burned at graduation by Meteora DBC
Two buckets, one billion tokens, locked at deploy. The 700M curve supply funds price discovery pre-bond on the Meteora DBC pool. The 300M LP reserve never touches the curve — at graduation it pairs with the collected SOL and is permanent-locked (100 %) into a Meteora DAMM v2 pool.
No third bucket exists. There is no team allocation, no marketing reserve, no future unlock, no governance treasury. The freeze authority is set to Noneon the SPL mint, and the mint authority is held by the DBC program for the lifetime of the curve and burned after graduation by DBC's migration instruction.
| Bucket | Tokens | Share | Use |
|---|---|---|---|
| Bonding curve | 700M | 70% | Sold continuously along the DBC's constant-product curve. |
| Post-bond liquidity | 300M | 30% | Reserved for the permanent-locked DAMM v2 LP created at graduation. |
| Total supply | 1B | 100% | Hard-capped. Mint authority burned by DBC at migration. |
No new tokens are ever minted after deploy. The 300M reserved tokens never enter the curve and never enter the deployer wallet. They sit in a DBC-owned vault until the migration instruction pairs them with the remaining curve SOL to seed the DAMM v2 pool with 100 % permanently locked liquidity.
Bonding curve
Pricing is delegated to Meteora's Dynamic Bonding Curve (DBC). Every S3ND launch shares the same on-chain DBC config we deployed once at bootstrap — fee schedule, curve geometry, partner-fee split, and migration parameters all live in that account. The wrapper program does not duplicate any of that math; it just signs `reserve_launch` and creates the DBC pool with our config.
The S3ND DBC config
The config sells exactly 700M tokens between SOL-collected = 0 and SOL-collected = 100. The remaining 300M tokens are paired with the bonded SOL to seed the post-bond DAMM v2 pool. Total supply is fixed at 1B; nothing beyond that ever mints.
baseDecimals = 6 totalSupply = 1,000,000,000 curveSupply = 700,000,000 reservedSupply = 300,000,000 graduationQuoteThreshold = 100 SOL collectFeeMode = 2 # keep some swap fee in pool creatorTradingFeePct = 35 partnerLpLockedAtBondPct = 100 # LP unwithdrawable feeScheduler = LinearFee(10% → 1% over 6 steps / 60 min, symmetric) enableFirstSwapWithMinFee = true # first swap pays the start fee
The 3SOL deploy seed is escrowed in the S3ND wrapper's `DeploySeed` PDA (separate from the DBC pool). It is refunded to the creator after DBC graduates the pool to DAMM v2 — see the Deploy refund section.
Approximate sample points
The DBC config's actual curve has multiple segments (it's built via Meteora's `buildCurve` helper). The table below uses a constant-product approximation calibrated to the same endpoints — close enough for headline numbers and chart axes, but the live quote at signing comes from DBC directly.
| SOL collected | Tokens issued (~) | Marginal price (SOL/token, ~) |
|---|---|---|
| 0 | 0.0M | 3.30e-8 |
| 10 | 70.0M | 5.86e-8 |
| 25 | 175.0M | 1.11e-7 |
| 50 | 350.0M | 2.34e-7 |
| 75 | 525.0M | 4.04e-7 |
| 95 | 665.0M | 5.72e-7 |
| 100 | 700.0M | 6.19e-7 |
After bond
Once the curve hits 100 SOL, DBC graduates the pool into a Meteora DAMM v2 pool in the same instruction. The remaining 300M tokens pair with the curve's SOL to seed the new pool. The S3ND config's `partnerPermanentLockedLiquidityPercentage: 100` makes the resulting LP position permanently locked — no party, including the deployer or the protocol, can ever withdraw the underlying liquidity.
From that point trading lives on DAMM v2 and is visible on every Solana aggregator (Jupiter, Axiom, Photon, ...). The fee schedule continues to apply — at minute 60+ that means a flat 1 % trade fee on every swap (buys and sells), routed entirely to the S3ND treasury today (creator share = 0 in Phase 3.0.5b; the declining 0.5 % → 0.3 % creator schedule lights up with the Custom Creator Vault in Phase 3.0.6).
The creator can claim back the 3 SOL deploy deposit any time after graduation by signing a claim_deploy_refund instruction in the frontend (see Deploy refund). The wrapper verifies the DBC pool's is_migrated byte on-chain — no monitor bot involved.
Trading fee schedule
Every swap on a S3NDlaunch pays a single trading fee that decays linearly with the launch's age. The schedule is symmetric on buys and sells, identical pre-bond (DBC virtual pool) and post-bond (DAMM v2 pool), and identical regardless of which aggregator (Jupiter, Axiom, Photon, ...) routed the order. The on-chain source of truth is DBC's FeeSchedulerLinear encoded in the S3ND DBC config.
What does change at bond is the underlying pool: pre-bond all swaps go through the DBC virtual pool; post-bond they go through a Meteora DAMM v2 pool with the LP position 100 % permanently locked. The fee schedule is continuous across the migration — no surprise jump.
Why the same fee on buys and sells?
Most launchpads only protect against one direction (early sell taxes, mostly). DBC does not natively support direction-asymmetric fees, and forking it would break compatibility with the audited Meteora programs we rely on for graduation and LP locking. Symmetry turned out to be the better mechanism anyway:
- The fee a buyer sees in minute 0 (10%) is the same fee they will pay on the way out if they flip immediately. Round-tripping in the first hour costs ~20 % of position value. Holding past hour one drops you into the same 1% every long-term holder pays.
- The cost of being a sniper is paid up front, in a number the buyer can read on the swap UI before signing. No “rug pull via tax” surprise on the way out.
- Anyone who actually intends to hold pays the smallest fee in the schedule. The protocol economically rewards conviction rather than reaction time.
The fee curve
10% at minute 0, decaying in 6 discrete steps to 1% at minute 60, and held flat at 1% forever after. The early steps make rapid round-trips materially expensive; the long-tail floor is a normal DEX trade fee.
| Minutes since launch | Trade fee | Trader receives |
|---|---|---|
| 0–10 min | 8.5% | 91.5% |
| 10–20 min | 7% | 93% |
| 20–30 min | 5.5% | 94.5% |
| 30–40 min | 4% | 96% |
| 40–50 min | 2.5% | 97.5% |
| 50–60 min | 1% | 99% |
| 60+ min (perpetual floor) | 1% | 99% |
Where does the fee go?
DBC's creatorTradingFeePercentage is fixed at 0at the DBC level — 100 % of every collected fee flows into DBC's partner-fee account. From there a permissionless wrapper instruction (claim_partner_fees_split) drains the account on a fixed split: pre-bond, half goes to the protocol treasury and half accrues in a per-launch BuybackVault PDA that swap-and-burns the launched token at the moment of graduation. Post-bond the split rotates to a 3-way decay between the creator's vault, LP-Compound, and the treasury, summing to the flat 1 % DAMM v2 fee at every age.
| Recipient | Pre-bond | Post-bond at bond | Post-bond floor |
|---|---|---|---|
| S3ND treasury | 50 % of fee | 0.2 % of swap | 0.5 % of swap |
| BuybackVault (swap-and-burn at bond) | 50 % of fee | — | — |
| LP-Compound (locked DAMM v2 add) | n/a (no LP yet) | 0.3 % of swap | 0.2 % of swap |
| Launch creator (Custom Vault) | 0 % | 0.5 % of swap | 0.3 % of swap |
There is no separate Token-2022 transfer hook, no per-phase re-routing, and no manual compound step. Pre-bond fees split 50/50 into protocol treasury and BuybackVault; the latter burns its accumulated SOL into the launched token the moment the curve graduates, atomically with the bond record itself.
What if the token bonds in 8 minutes?
A common worry: launches with very strong demand bond extremely fast. If the trading fee reset on bond, snipers could front-load their position during the high-fee bonding minutes, wait three minutes for migration, then dump on a fresh low fee in the DAMM v2 pool.
DBC closes the loophole at the protocol level. The FeeSchedulerLinear is a pure function of now − launch.created_at — bond does not reset it, the migration to DAMM v2 does not reset it, and aggregators cannot evade it by routing through a different pool. A token that bonds in 8 minutes is still under full snipe protection until minute 60, exactly like a token that bonds in 8 days.
Worked examples — buy and sell are symmetric
| Scenario | Fee on this swap | Treasury / Buyback split | Trader gets |
|---|---|---|---|
| Minute 5, buy 1 SOL of token | 8.5 % | 0.0425 SOL treasury / 0.0425 SOL BuybackVault | 0.915 SOL of token |
| Minute 5, sell 1 SOL worth of token | 8.5 % | 0.0425 SOL treasury / 0.0425 SOL BuybackVault | 0.915 SOL |
| Minute 35, sell 1 SOL worth of token | 4 % | 0.02 SOL treasury / 0.02 SOL BuybackVault | 0.96 SOL |
| Minute 75 (post-bond DAMM v2, at bond) | 1 % | 0.005 creator / 0.003 LP-Compound / 0.002 treasury | 0.99 SOL |
| Minute 240 (long-term floor) | 1 % | 0.003 creator / 0.002 LP-Compound / 0.005 treasury | 0.99 SOL |
Across every row the buyer and seller pay an identical fee at the same minute. A trader who buys 1 SOL of a token in minute 0 and immediately sells loses ~20 % of position value to fees; the same trader who holds for an hour and sells pays ~11 % round-trip; from minute 60 onward the round-trip cost is a normal 2 %. Pre-bond, half of every fee accumulates in the BuybackVault — when the launch graduates, those lamports are spent buying the launched token and burning it forever. The DBC fee schedule itself never changes; only the split applied on top of it rotates from a 50/50 pre-bond mix to a 3-way post-bond decay.
Creator rewards
Two reward streams unlock for the launch creator: the deploy refund (claimable the moment the curve bonds) and a declining share of post-bond trade fees. Both are fully on-chain, both are claimable any time, and the trading-fee stream is tied to actual volume — no vesting, no discretionary tip jar. Pre-bond, the creator earns 0 % from trades — bonding itself is the proof of work that unlocks the post-bond share. Half of every pre- bond fee instead funds a per-launch BuybackVault that swap-and-burns the launched token at the moment of graduation, shrinking total supply on day zero of post-bond trading.
Deploy refund (creator-claimed)
claim_deploy_refund from the launch detail page; the wrapper inspects the DBC pool's is_migrated byte on-chain and releases the deposit. There is no off-chain bot in the loop. State is recorded on-chain in the seed's outcome field (`pending` → `refunded`).Declining post-bond fee share
creatorTradingFeePercentage stays at 0at the DBC level, so 100 % of the DBC fee routes into the wrapper's partner-fee account. From there a wrapper-owned Custom Creator Vault pays the creator a declining share of post-bond trades only: 0.5 % at graduation, decaying linearly to 0.3 % long-term. Pre-bond, the creator earns nothing — the equivalent slice of the fee instead funds the BuybackVault described below, so when the launch graduates its supply shrinks before the first DAMM v2 swap settles.Pre-bond fees fund a buyback-and-burn
Half of every pre-bond trade fee accumulates in a per- launch BuybackVault PDA — wrapper-owned SOL that nobody can withdraw, including the protocol team. The vault has exactly two ways out, both encoded directly in the on-chain program:
- Happy path — launch bonds.Atomically with the bond record, the wrapper's
record_bond_and_buybackinstruction wraps the vault's SOL into WSOL, swaps it for the launched token via the brand-new DAMM v2 pool, and burns the entire output via SPL Tokenburn. Total supply shrinks for every holder, permanently. Atomic with the bond stamp so MEV bots can't front-run a predictable buy in a separate Jito bundle. - Sad path — launch dies. If the launch never bonds, the vault accumulates indefinitely until day 60+, when the permissionless
sweep_buyback_vaultinstruction routes the lamports to the protocol treasury. There's no token to buy back if the launch never graduated, so the lamports become protocol revenue — same garbage-collection rule the 3 SOL deploy seed already follows.
Both settlement paths flip a single drained flag on the vault, making them mutually exclusive at the on-chain level. There is no third path; the protocol can never re-route the BuybackVault to anything else after deployment.
Pre-bond split
The DBC fee scheduler decays from 10% at minute 0 to 1% at minute 60. The wrapper's claim_partner_fees_split instruction drains the DBC partner-fee account and splits the collected lamports two ways pre-bond:
| Recipient | Pre-bond share of the fee | Drained by |
|---|---|---|
| S3ND treasury | 50 % | Wrapper claim instruction (immediate transfer to treasury wallet). |
| BuybackVault PDA | 50 % | Accumulates in SOL until bond, then record_bond_and_buyback swaps it into the launched token via DAMM v2 and burns the result. 60-day fallback sweep to treasury if the launch never bonds. |
| Launch creator | 0 % | Creator earns 0 % from pre-bond trades. The deploy-refund mechanic + post-bond share are the alignment. |
Post-bond split
Once DBC migrates the launch to DAMM v2, the fee schedule flattens at 1% and the split rotates: the creator unlocks their share, the LP keeps growing through compounding, and the treasury share rises gradually as the other two decay.
| Recipient | At bond (share of swap volume) | Long-term floor |
|---|---|---|
| Launch creator (CreatorVault) | 0.5 % | 0.3 % |
| LP-Compound (locked DAMM v2 add) | 0.3 % | 0.2 % |
| S3ND treasury | 0.2 % | 0.5 % |
| Sum | 1.0 % (= the DAMM v2 pool fee) | 1.0 % (= the DAMM v2 pool fee) |
| Phase | Trade fee | Creator earns | BuybackVault accrues |
|---|---|---|---|
| 0–10 min (high-fee window, pre-bond) | 10% | 0 % | 50 % of every fee |
| ~30 min (mid-decay, pre-bond) | ~5.5 % | 0 % | 50 % of every fee |
| Bond (graduation event) | 1% | 0.5 % of swap | Drained: swap-and-burn fires atomically with the bond record |
| Long-term (post-bond floor) | 1% | 0.3 % of swap | n/a (drained at bond, never refilled) |
The creator share is not a tax on top of trades — it is a slice of the same fee the DAMM v2 pool already charges, paid out by the Custom Creator Vault. The deliberate floor at 0.3 % is set low enough that the creator is incentivised to keep building (volume grows the cheque) but never to milk holders the way classical 5–10 % creator-fee schemes do. LP-Compound on the same swap means the locked liquidity grows permanently with every trade — nobody can pull it out, ever.
Anti-vamp protections
S3NDruns on Meteora's Dynamic Bonding Curve (DBC) instead of a custom AMM. Anti-vamp pressure comes from two primitives baked into the DBC config we deploy, plus one wrapper rule that gates ticker reuse:
10% hold-friendly start
Linear fee decay
Ticker lock
Why bias the protocol toward holders?
Most launchpads optimise for the fastest hands. The first second after deploy is a flat-out scramble: snipers grab 10–20 % of supply, dump within minutes, and walk away with the bulk of price discovery. By the time anyone else arrives, the chart is already a tombstone.
S3ND's 10 % → 1 % symmetric fee schedule inverts that incentive. It is genuinely expensive to be the first buyer, but it is even more expensive to be the first seller — because both sides of the round-trip pay the same fee at the same minute. A sniper who buys 10 SOL in minute 0 pays 1 SOL in fees on the way in, and 1 SOL again on the way out if they flip immediately. Net cost of the flip: 20 % of the position. The same wallet that holds for an hour pays 1 % each way — 2 % round-trip. Long-term holders pay roughly the same fee people pay on any DEX trade.
- No per-wallet hold cap (which would have required a Token-2022 transfer hook DAMM v2 doesn't currently accept on the quote side, and would have silently broken at graduation). Concentration pressure comes from the fee schedule alone — same outcome, simpler primitive, survives migration cleanly.
- Symmetric on buys and sells, by design. DBC does not natively support direction-asymmetric fees, and forking it would break compatibility with the audited Meteora programs we rely on for graduation and LP locking. Symmetry turned out to be the better mechanism anyway — it makes the cost of flipping legible at the moment of the buy.
Sybil sweeps remain possible in principle but each additional wallet pays the same time-decayed fee on every token bought and on every token sold, and the curve's constant-product shape pushes price up for the next attacker too. Loud and expensive.
On-chain vs UI: where do these rules actually live?
Most S3ND trading happens through aggregator frontends like Axiom, Photon, Jupiter, or Phantom — not on s3nd.fun directly. That is fine because every hard rule lives on-chain, not on the website. Aggregators just build transactions that call DBC; if a rule fails, the transaction fails, regardless of which frontend submitted it.
- Fee schedule — `FeeSchedulerLinear` encoded in the DBC config we deploy and pin to every S3ND launch.
- Partner-fee routing (100 % treasury today) — `creatorTradingFeePercentage = 0` in Phase 3.0.5b, so every fee flows into the DBC partner-fee account (S3ND treasury). The declining post-bond creator share (0.5 % → 0.3 %) is paid out of the wrapper-owned Custom Creator Vault from Phase 3.0.6 onward.
- 3 SOL deploy seed escrow — `DeploySeed` PDA owned by the S3NDwrapper program. Four settlement paths, all recorded on-chain in the seed's `outcome` field: creator self-claims after graduation (`claim_deploy_refund`, on-chain is_migrated check), creator self-recovers after a 30-day grace window if the launch never bonds (`recover_dead_launch`), anyone permissionlessly sweeps still-unbonded deposits to the treasury at day 60 (`sweep_deploy_seed`), or — rarely — the protocol authority forfeits the seed in confirmed-abuse cases (`forfeit_deploy_seed`).
- Ticker lock — `TickerLock` PDA on the wrapper, expires after 60 minutes.
- Bond → DAMM v2 migration — fully automated by DBC. The S3ND config sets `partnerPermanentLockedLiquidityPercentage` to 100%, so the resulting LP is unwithdrawable.
The website handles UX (warnings, disabled buttons, pretty stats) and discovery (trending, search, new launches). It cannot relax the rules even if it wanted to.
Ticker lock
Once a ticker is launched, the same string is reserved for 60 minutes. Any further launch attempt with the same ticker (case-insensitive, whitespace stripped) is rejected. This is brand protection against the same-ticker rug-and-relaunch cycle within the same hour.
On-chain the lock is a PDA seeded by the upper-cased ticker bytes with an `expires_at` timestamp. Anyone can read it via RPC; the program rejects any `create_launch` instruction that finds the lock still live.
Deploy refund
The 3 SOL deploy cost is not a platform fee. It is curve seed liquidity. It is paid back to the creator wallet automatically the moment the curve crosses 100 SOL — no claim step, no extra transaction. This realigns incentives:
- A deployer who runs away early loses 3 SOL.
- A deployer whose token actually fills the curve gets the full 3 SOL back the second the bond instruction lands.
- The refund flows in the same on-chain instruction that flips the launch to bonded. The state tracks
deployRefundPaidso the UI can render the resulting state, but no user action ever sets it. - Funds always go to the original creator wallet recorded on the launch — there is no claimer parameter to spoof.
Bond and migration
When the DBC pool reaches its graduation threshold (configured to ~100SOL of net curve deposits in the S3ND DBC config), Meteora's migration instruction fires automatically the next time any wallet calls the appropriate keeper or scheduled cranker. The migration is one atomic transaction that ends bonding-curve trading and stands up a permanent Meteora DAMM v2 pool.
- The DBC pool closes for swaps. Any in-flight buy or sell on the curve fails after this point.
- Curve SOL plus the 300M reserved tokens are deposited into a new Meteora DAMM v2 pool that the migration instruction creates in the same call.
- The DAMM v2 position NFT is minted with
partnerPermanentLockedLiquidityPercentage = 100%— no party (deployer, protocol, governance) can ever withdraw the underlying liquidity. The permanent-lock flag is directly readable on-chain. - The creator clicks Claim 3 SOL on the launch detail page in the S3ND frontend. The button signs a
claim_deploy_refundinstruction; the wrapper inspects the DBC pool'sis_migratedbyte on-chain, releases the 3 SOL DeploySeed PDA back to the creator wallet, and emits aDeployRefundClaimedevent. There is no off-chain monitor bot involved. - Trading continues on DAMM v2. The DBC FeeSchedulerLinear keeps applying for the lifetime of the token: post-minute-60 every swap pays a flat 1%fee. Today every fee flows into DBC's partner-fee account (S3ND treasury); the creator's declining post-bond share is paid out by the custom Creator Vault rolling out in Phase 3.0.6.
What does "net SOL collected" mean here?
DBC's graduation threshold is denominated in quote-token reserves inside the curve (i.e. SOL on our side). Trade fees do notsit inside the curve; they accumulate in DBC's partner-fee accounts, separate from the bonding reserves. So 100 SOL of curve deposits means 100 SOL of net buyer pressure— fees collected during bonding don't count toward the threshold and don't end up in the LP either.
One consequence: there is no "LP boost" mechanic anymore. The LP is exactly what the DBC config schedules — 100 SOL on the SOL side and 300Mtokens on the token side. The trade fee that previously doubled as a liquidity injector now lives entirely in DBC's partner-fee stream and is claimed in SOL by the creator and the treasury.
What the LP is actually made of
A Meteora DAMM v2 pool is a constant-product AMM holding two assets and running x * y = k on real reserves. Every swap rebalances the reserves; the underlying assets stay locked.
| Side | Asset | Source |
|---|---|---|
| Token side | 300M launch tokens | Reserved supply that never touched the curve. Minted by the wrapper at launch and held by the DBC config-mint authority until migration. |
| SOL side | ~100 SOL | Net curve buyer pressure at graduation. The 3 SOL deploy seed lives in the wrapper's DeploySeed PDA, not in the curve, so it does not reduce the LP. |
| LP position NFT | 100% permanent-locked | Minted by DAMM v2 in the same migration instruction. The lock flag is enforced by DAMM v2 itself; withdraw instructions against this position are rejected forever. |
The 300Mtoken reserve is not a dev allocation and was never anyone's to claim. It exists for one reason: a pool needs something on the token side to swap against. Without it, the SOL collected by the curve would have nothing to pair with and the token would have no post-bond market at all. Reserved supply is the liquidity floor under the token, not insider tokens with a vesting cliff.
Are the reserved tokens still tradable after migration?
Yes — but only through swaps, never withdrawn. When someone buys the token on Jupiter, Axiom, Photon, or any other Solana frontend, the swap routes through the DAMM v2 pool: SOL flows in, tokens flow out, the pool price moves up the curve. When someone sells, the opposite. The reserves on both sides constantly shift with trading, but no party can pull them out and walk away.
Why the LP position is permanently locked
When you deposit two assets into a DAMM v2 pool, the program mints you a position NFT that represents your share of the pool. Holding the position NFT means you can redeem it later for your underlying assets pro rata. That is the standard withdrawal mechanism.
For a launch pool that has to outlive any single party, that withdrawal mechanism is a rug vector. S3ND eliminates it by setting partnerPermanentLockedLiquidityPercentage = 100 in the DBC config. From that point on:
- No party — not the creator, not the protocol, not a governance vote — can ever withdraw the underlying liquidity again. The DAMM v2 program rejects every withdraw instruction against a permanent-locked position.
- The pool can only shrink or grow through normal trading. The 300M tokens and ~100 SOL are mathematically locked into the curve forever.
- The lock is verifiable on-chain by anyone reading the position state. There is no "trust us" component.
Walk-through: a concrete bond
Suppose a launch graduates after volatile trading. Net curve deposits at graduation = ~100SOL. On the way there, traders churned ~50 SOL of gross trade volume (buys and sells together) across the time-decayed schedule, paying an average ~6 % fee. That fee flowed entirely into DBC's partner-fee account (the S3ND treasury). At the moment graduation fires:
- Creator wallet — claimable: 3SOL deploy refund (one click in the frontend; wrapper verifies migration on-chain). The creator's declining trading-fee share starts accruing post-bond into the custom Creator Vault rolling out in Phase 3.0.6.
- New Meteora DAMM v2 pool — created with 300M launch tokens on the token side and ~100 SOL on the SOL side. Initial price ≈ 100 / 300M ≈ 3.33e-7 SOL per token.
- Position NFT — minted by DAMM v2, flagged 100 % as
permanentLockedLiquidityin the same instruction. Withdraw instructions against this position are rejected by the program forever. - DBC pool — flipped to
migrated = true; swaps stop. The 700 M tokens previously sold on the curve remain in their buyers' wallets and now trade against the new DAMM v2 pool from any Solana frontend (Jupiter, Axiom, Photon, Phantom).
The key invariant: graduation is gated on net curve deposits hitting the threshold and the LP being created with partnerPermanentLockedLiquidityPercentage = 100. If either fails the transaction reverts — there is no path that produces an unlocked or partially-locked LP.
Fee accounting and claiming
S3ND does not run a custom transfer-hook or compounding bot. Every trade fee on a S3NDlaunch is collected and accounted for by Meteora's Dynamic Bonding Curve program directly, using its partner-feeprimitive. The wrapper's job is purely to drain that partner-fee account on a fixed split into three streams: the protocol treasury, the launch's Creator Vault, and a per-launch BuybackVault that swap-and-burns the launched token at the moment of graduation.
Half of every pre-bond fee accumulates in a wrapper-owned BuybackVault PDA per launch. At the moment the DBC pool graduates, the wrapper's record_bond_and_buyback instruction stamps the bond timestamp andin the same atomic transaction wraps the vault's SOL into WSOL, swaps it for the launched token via the new DAMM v2 pool, and burns the entire output via SPL Token burn. Total supply shrinks for every existing holder the instant the curve graduates.
Why atomic.Solana has no public mempool for non-Jito transactions, so the buyback can't be front-run on a public tip. Bundling the bond stamp and the buyback into one instruction also closes the only durable Jito-bundle window: there's no separate "bond observed → buy in " gap to insert into.
Why this isn't a tax on holders. The buyback is funded entirely by trading fees collected before bond — fees that would otherwise have gone to the protocol treasury. The protocol voluntarily redirects half its pre-bond revenue into something that benefits every holder. The remaining pre-bond fees still fund treasury operations (50/50 split).
Why the supply migration % bumped. Phase 3.0.6c also moves percentageSupplyOnMigration from 20 % to 30% on the DBC config — a deeper migration LP means the buyback burns more launched tokens for the same SOL spend before the swap's own price impact eats into its effectiveness.
Where fees live
DBC routes the configured trade-fee bps from every swap into two internal accounts attached to the pool. The wrapper sets creatorTradingFeePercentage = 0 at the DBC level, so 100 % of the DBC fee flows into the partner-feeaccount that the wrapper's permissionless claim instruction drains. The accounts continue to receive fees post-graduation on the DAMM v2 pool, because DBC's FeeSchedulerLinear is a function of the launch's age and is preserved across migration.
| Account | Receives | Drained by |
|---|---|---|
| DBC partner-fee account | 100 % of every trade fee on this launch (collected by DBC). | claim_partner_fees_split — permissionless wrapper CPI that signs the inner DBC claim as the protocol's PartnerAuthority PDA, then routes the lamports to treasury / CreatorVault / BuybackVault per the schedule. |
| Wrapper DeploySeed PDA | 3 SOL skin-in-the-game deposit, paid by the creator at reserve_launch. | claim_deploy_refund (creator self-claims on graduation), recover_dead_launch (creator self-recovers ≥ 30 d unbonded), sweep_deploy_seed (anyone routes to treasury after 60 d unbonded), or forfeit_deploy_seed (authority anti-abuse escape hatch). |
| Wrapper BuybackVault PDA (pre-bond) | 50 % of every collected fee, in SOL, accumulating until bond. | record_bond_and_buyback (happy path: swap into the launched token via DAMM v2 + SPL burn) or sweep_buyback_vault (sad path: ≥ 60 d unbonded → treasury). |
| Wrapper CreatorVault PDA (post-bond) | Declining slice of every post-bond fee on the schedule below. | claim_creator_rewards — creator signs, drains the vault to its rent-exempt minimum. |
Fee split by phase
Pre-bond the split is a flat 50/50 between the protocol treasury and the per-launch BuybackVault. Post-bond it rotates to a 3-way decay between creator, LP-Compound, and treasury that converges on the long-term floor over the first hour after graduation.
| Account | Pre-bond receives | Post-bond receives |
|---|---|---|
| S3ND treasury (DBC partner) | 50 % of every trade fee. | 0.2% of swap volume at bond, rising to 0.5% long-term. |
| Wrapper BuybackVault PDA | 50 % of every trade fee, accumulating in SOL until bond. | 0 %. Drained exactly once via record_bond_and_buyback at migration: swap into the launched token + SPL burn. |
| Wrapper CreatorVault PDA | 0 %. Creator earns nothing from pre-bond trades — bonding is the proof. | 0.5% of swap volume at bond, decaying to 0.3% long-term. |
| LP-Compound (locked DAMM v2 position) | n/a (no DAMM v2 LP exists yet pre-bond). | 0.3% of swap volume at bond, decaying to 0.2% long-term, single-sided SOL inject into the same locked position. |
Why no transfer hook
Earlier iterations of S3ND used a Token-2022 transfer hook to skim a sell tax on every transfer. That design produced two unsolvable problems:
- DAMM v2 incompatibility.Meteora's pools currently do not support tokens with a Transfer Hook extension. Migration would have failed at graduation, defeating the entire point of using DAMM v2 for the post-bond LP.
- Audit surface. Hooks run inside every transfer, including unrelated wallet-to-wallet sends. Bugs in a hook are catastrophic. The DBC fee scheduler confines fee logic to the swap path only and is already audited by Sec3 and Halborn.
DBC's scheduler gives us the same time-decayed fee curve we wanted without any custom hook code or per-transfer compute. The Custom Creator Vault adds the declining post- bond schedule DBC's flat percentage cannot natively express, and the BuybackVault adds the supply-shock-at-bond narrative on top — both layered on the same partner-fee account, no per-transfer instrumentation required.
How claiming works
Creator deploy refund: the launch detail page surfaces a Claim 3 SOL button to the creator the moment the DBC pool flips to migrated. The button signs a claim_deploy_refund instruction; the wrapper inspects the pool's is_migrated byte on-chain, releases the deposit, and emits a DeployRefundClaimed event. There is no protocol-authority signature in this flow.
Partner-fee split (continuous, permissionless): anyone can call claim_partner_fees_split on a launch — the wrapper signs the inner DBC claim_trading_fee CPI as the singleton PartnerAuthority PDA, unwraps the WSOL output, and routes the lamports to treasury / CreatorVault / BuybackVault per the schedule. A keeper bot fires this regularly so the streams stay fresh.
Bond + buyback (atomic, permissionless): record_bond_and_buyback stamps the bond timestamp on the CreatorVault and, in the same instruction, drains the BuybackVault via a DAMM v2 swap (WSOL → launched token) followed by an SPL Token burn. Idempotent — once drained is true on the vault, a second call rejects.
Creator rewards: a separate claim_creator_rewards instruction pays out the creator's share from the CreatorVault on the schedule above. Pre-bond claims always return 0 — the share only starts accruing after graduation.
Sweep (sad path): if a launch never bonds within 60 days, sweep_buyback_vault and sweep_deploy_seed both unlock — anyone can route the dead launch's BuybackVault and deploy seed to the protocol treasury. The vault's drained flag flips to true, making the buyback path and the sweep path mutually exclusive on-chain.
What this guarantees, end to end
- The S3ND wrapper holds no SOL it can rug. The only wrapper-owned PDAs that hold lamports are the 3 SOL DeploySeed (refunded on bond), the BuybackVault (drained on bond into a burn), and the CreatorVault (drained by the creator).
- Refunds are creator-driven and verified on-chain. There is no off-chain monitor bot.
- The bond event triggers a permanent supply reduction by design. The buyback fires atomically with the bond record, so the supply on day-zero post-bond trading is already smaller than the supply on the curve.
- On-chain footprint stays small: one TickerLock + one DeploySeed + one CreatorVault + one BuybackVault PDA per launch, plus the singleton ProtocolConfig and PartnerAuthority program-wide.
On-chain architecture
S3NDis deliberately a thin layer on top of Meteora's Dynamic Bonding Curve and DAMM v2. We don't reinvent the bonding-curve wheel; we orchestrate audited Meteora programs with a small wrapper that adds ticker locks and a deploy-seed escrow. The total amount of S3ND-authored Anchor code is in the low hundreds of lines.
The two layers
| Program | Owner | Responsibility |
|---|---|---|
| S3ND Wrapper | S3ND (us) | One-shot ticker lock, 3 SOL deploy-seed escrow with creator-recoverable grace window, protocol authority management. Six instructions, three PDAs (TickerLock, DeploySeed, ProtocolConfig). No curve math, no fee math, no AMM logic. |
| Meteora DBC + DAMM v2 | Meteora | Curve geometry, FeeSchedulerLinear, partner-fee split (35/65 creator/treasury), automatic migration into DAMM v2 with 100 % permanently locked LP. Fully audited, deployed at dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN. |
How a launch + first buy actually flows
User wallet signs ONE atomic transaction:
│
├─▶ S3ND Wrapper · reserve_launch
│ • derives TickerLock PDA from sha256(ticker)
│ • opens DeploySeed PDA, escrows 3 SOL
│ • emits LaunchReserved event
│
├─▶ Meteora DBC · createPool(config = S3ND_DBC_CONFIG, mint, base/quote)
│ • initializes VirtualPool with FeeSchedulerLinear
│ • mints token supply into the pool's base reserve
│
└─▶ Meteora DBC · swap(quote→base, dev_buy_sol, slippage) [optional]
• applies first-swap fee (10 %)
• Phase 3.0.5b: 100 % of fee → DBC partner-fee account
(S3ND treasury). Creator share = 0 until Custom
Creator Vault ships in Phase 3.0.6
Subsequent buys / sells: a single DBC swap instruction signed by the
trader. The wrapper is no longer in the call path.
When quoteReserve >= 100 SOL:
│
└─▶ Meteora DBC · graduate (anyone permissionless)
• drains pool, creates DAMM v2 pool with reserved tokens
• partnerPermanentLockedLiquidityPercentage = 100
⇒ LP position is permanently locked
• flips pool state to "graduated" (is_migrated = 1)
After graduation, any time:
│
└─▶ Creator wallet · S3ND Wrapper · claim_deploy_refund
• creator-signed; no admin or off-chain bot
• wrapper inspects DBC pool's is_migrated byte on-chain
• returns the 3 SOL deploy seed to the creator wallet
• marks DeploySeed.outcome = Refunded
If the launch never bonds, day 30 onward:
│
└─▶ Creator wallet · S3ND Wrapper · recover_dead_launch
• permissionless on the creator side, no admin signature
• wrapper enforces created_at + 30 days <= now
• returns the 3 SOL deposit to the creator
• marks DeploySeed.outcome = Recovered
If still unbonded and unclaimed at day 60:
│
└─▶ Anyone · S3ND Wrapper · sweep_deploy_seed
• permissionless; routes the 3 SOL to the protocol treasury
• wrapper checks pool is_migrated == 0 and seed_age >= 60d
• marks DeploySeed.outcome = SweptWhy a wrapper at all?
DBC alone gives you a pool with a fee schedule and a graduation path. It does not give you ticker uniqueness, it does not enforce a deploy-seed deposit, and it does not pin a canonical configuration so every launch on the platform shares the same anti-vamp tuning. The S3ND wrapper provides exactly those three:
- Ticker lock.The first launch to claim a ticker holds it for 60 minutes. Phishers can't instantly clone a viral ticker the moment it trends.
- Deploy-seed escrow. 3 SOL skin-in-the-game. Refunded automatically at graduation. If the launch never bonds, the creator can self-recover the deposit any time after 30 days via `recover_dead_launch` — no admin signature, no slashing-by-default. Pure economic friction; no on-chain VM tricks.
- S3ND DBC config pinning. Every S3ND launch references the same DBC config we deployed once. Fee schedule, partner split, graduation threshold, and LP lock all come from that single account — they cannot be relaxed launch-by-launch.
Why no transfer hook?
Earlier S3ND drafts used a Token-2022 transfer hook for post-bond fee enforcement and a custom 4-phase tax split. The Meteora pivot retired both, for two reasons:
- DAMM v2 quote-side hook constraint.Meteora DAMM v2 does not currently support transfer hooks on the quote token, which would have meant the hook silently broke at migration. Better to drop it and rely on DBC's native FeeSchedulerLinear, which works identically pre- and post-graduation.
- Audit surface. Removing the transfer-hook program plus the custom 4-phase split logic shrank theS3ND-authored Anchor code by ~80 %. Smaller surface, cheaper audit, fewer paths for bugs.
DBC's `collectFeeMode: 2` keeps a portion of every swap fee inside the pool to thicken liquidity over time, so the compound-into-LP behaviour we previously implemented as a keeper bot is now a property of the pool itself. No external actor needed.
What lives where
| Concern | Layer |
|---|---|
| Curve geometry (multi-segment) | Meteora DBC config |
| Fee schedule (10 % → 1 % over 60 min, symmetric) | Meteora DBC config |
| First-swap minimum fee | Meteora DBC config |
| Partner-fee split (100 % treasury, Phase 3.0.5b) | Meteora DBC config |
| Creator share (declining post-bond, Phase 3.0.6) | S3ND Wrapper · Custom Creator Vault (planned) |
| Graduation at 100 SOL → DAMM v2 | Meteora DBC |
| 100 % permanently locked LP | Meteora DAMM v2 |
| Ticker uniqueness (60 min) | S3ND Wrapper · TickerLock PDA |
| 3 SOL deploy seed escrow + graduation claim + 30-day creator recovery + 60-day permissionless sweep + anti-abuse forfeit | S3ND Wrapper · DeploySeed PDA |
| Protocol authority + treasury + DBC config pubkey | S3ND Wrapper · ProtocolConfig PDA |
| Refund delivery on graduation | Creator self-claim, wrapper verifies on-chain (no bot) |
Wallets and demo mode
S3ND uses the Solana Wallet Standard. Phantom, Solflare, Backpack and others appear in the connect modal automatically when installed.
While the on-chain program is not yet deployed, the app runs in demo mode. State persists in your browser only and no real Solana transactions are submitted. If no wallet is connected, a deterministic guest identity is used instead so the demo still works end-to-end.
Roadmap
| Phase | Status | Description |
|---|---|---|
| 1 | Shipped | S3ND Wrapper Anchor program: TickerLock PDA, DeploySeed escrow, reserve_launch / claim_deploy_refund (creator-signed, on-chain DBC graduation check) / recover_dead_launch / sweep_deploy_seed / forfeit_deploy_seed / update_protocol_config / transfer_authority — full integration test coverage |
| 2 | Shipped | S3ND DBC config + tooling: scripts/s3nd-dbc-config.ts deploys the DBC config (FeeSchedulerLinear 10%→1% over 60 min, symmetric on buys and sells, creatorTradingFeePercentage = 0 with 100 % to the partner / treasury, partnerPermanentLockedLiquidityPercentage = 100), idempotent devnet-deploy bootstrap, ops run-book. The standalone refund-monitor bot is gone — refunds are creator-driven |
| 3 | In progress | Frontend ↔ on-chain wiring: ENV-driven RPC config, OnChainAdapter (read paths first), Irys image upload, real-wallet integration. Read flows ship first; write flows (deploy / buy / sell / claim) follow |
| 3.0.6 | Planned | Custom Creator Vault: wrapper-owned PDA per launch + record_bond + claim_creator_rewards instructions implementing a declining post-bond schedule (0 % pre-bond, 0.5 % at bond, decaying to 0.3 % long-term) that DBC's flat creatorTradingFeePercentage cannot natively express |
| 4 | Planned | Devnet end-to-end smoke: real bonding cycle through DBC, real DAMM v2 graduation, claim_deploy_refund confirmed against a live graduated pool, indexer for trending / volume / holder distribution |
| 5 | Planned | Audit of the S3ND wrapper (Meteora DBC + DAMM v2 are already audited by Sec3 + Halborn). Production hardening: rate limits, circuit breaker on protocol authority, alarm on layout-drift between DBC's VirtualPool and our hard-coded byte offsets |
| 6 | Planned | Mainnet deploy with audited wrapper, audited DBC config, public indexer. No bots required for refunds — the wrapper's on-chain graduation check is permissionless |
The pivot to Meteora DBC + DAMM v2 collapsed three originally separate phases — custom AMM, custom sell-tax transfer hook, and migration logic — into a single configuration step (the S3ND DBC config). The remaining Anchor surface is small enough to fit in one audit pass, which materially accelerates the path to mainnet.
FAQ
Is anything I do on s3nd.fun real today?+
Read flows are real (browse explore, view a launch detail page) once a S3ND DBC config is deployed on the active cluster. Write flows (deploy, buy, sell, claim) ship in Phase 3.2 — the adapter currently throws "not implemented yet" to avoid silently lying to users. Everything is wired against the on-chain wrapper program; the build target is a real devnet end-to-end pass.
Why 3 SOL? Is this a platform fee?+
The 3 SOL is not a fee. It is a skin-in-the-game deposit escrowed in the wrapper's DeploySeed PDA. Four settlement paths, all triggered explicitly: graduation claim (DBC migrates → creator self-claims any time via claim_deploy_refund; the wrapper inspects the DBC pool's is_migrated byte on-chain), self-recovery (launch never bonded for 30 days → creator pulls the deposit back permissionlessly via recover_dead_launch), permissionless treasury sweep (still unbonded and unclaimed at day 60 → anyone can call sweep_deploy_seed and route the 3 SOL to the protocol treasury), or anti-abuse forfeit (rare; protocol authority sweeps confirmed-abuse cases).
Why Meteora DBC and not a custom AMM?+
Smaller audit surface, identical creator UX, native graduation into DAMM v2 with a permanently locked LP. Meteora's curve and fee scheduler already handle bonding-curve math, time-decayed trade fees, partner-fee splits, and migration. We layer ticker locks and a deploy-seed escrow on top via a thin wrapper. ~80 % less S3ND-authored Anchor code to audit; one less dependency on a custom Token-2022 transfer hook.
Why is the trade fee 10 % at minute 0?+
To make rapid flip-trading materially expensive without being abusive. DBC's FeeSchedulerLinear is symmetric on buys and sells — a buy at minute 0 pays 10 %, but so does a sell at minute 0. Round-trip cost is roughly 20 % of position value if you flip in the first hour. The fee decays linearly to 1 % over 60 minutes, so anyone planning to hold past the first hour pays the same 1 % every long-term holder pays. Net effect: holders are not punished, snipers and scalpers are.
Can the deployer buy supply at launch?+
Yes — by bundling a DBC swap into the same transaction as reserve_launch + dbc.createPool. The buy pays curve price like every other buy and incurs the 10 % first-minute fee from the FeeSchedulerLinear (the same fee any wallet would pay in minute 0). There is no discount, no allocation, no carve-out. The DBC config sets a maximum first-swap amount; over-the-cap requests are rejected at signing.
Can someone bypass the protocol by using multiple wallets?+
Each additional wallet pays the same time-decayed fee on every token bought. A sniper trying to corner 20 % of supply via 4 sybil wallets pays the maximum 10 % fee on every token they grab — and pays the same 10 % again on the way out if they try to flip. A wallet that buys an hour later pays 1 % each way. The constant-product curve also pushes price up for the next attacker. Sybil sweeps remain technically possible but they are loud, expensive, and lose money to the protocol fee.
What stops the deployer from rugging right after bond?+
DBC's S3ND config sets partnerPermanentLockedLiquidityPercentage to 100 %. At graduation the entire DAMM v2 LP position is permanently locked — no party (deployer, protocol, governance) can ever withdraw the underlying liquidity. The pool can only shrink or grow through trading. In Phase 3.0.5b the deployer's ongoing trading-fee share is 0; in Phase 3.0.6 a custom Creator Vault unlocks a declining post-bond stream (0.5 % of every swap at bond, decaying to 0.3 % long-term) — modest by design and tied directly to volume, so the deployer only earns if people keep trading.
What is the post-bond LP made of?+
Two assets, paired into a single Meteora DAMM v2 pool: 300,000,000 launch tokens on the token side (the reserved supply that never touched the curve) and roughly 100 SOL on the SOL side (the full curve buyer pressure — the 3 SOL deploy deposit is parked separately in the wrapper's DeploySeed PDA and refunded to the creator, so it doesn't eat into the LP). The DAMM v2 position is created with the permanent-locked-liquidity flag set to 100 %, so no party can ever withdraw the underlying assets.
Are the 300M reserved tokens still tradable after bond?+
Yes, but only through swaps against the pool — never as a direct withdrawal. When someone buys the token on Jupiter, Axiom, Photon, or any other Solana frontend, the swap routes through the DAMM v2 pool: SOL flows in and tokens flow out; when someone sells, the opposite happens. The pool reserves shift constantly with trading, but no party can pull the underlying assets out. The 300M is the liquidity floor under the token, not insider supply.
Does the trade fee keep applying after migration?+
Yes. The DBC FeeSchedulerLinear is a pure function of the launch's age, identical pre- and post-graduation. After minute 60 the fee is a flat 1 % on every swap (DAMM v2 included). Today (Phase 3.0.5b) 100 % of that fee routes to the S3ND treasury through DBC's partner-fee accounting; the creator share is paid separately from the Custom Creator Vault that ships in Phase 3.0.6. There is no separate Token-2022 transfer hook — the trade fee lives entirely in the DBC config.
What happens if a launch never bonds?+
The DeploySeed PDA stays in the "pending" state until one of three events: (a) the creator calls recover_dead_launch any time after 30 days from reserve_launch and pulls their 3 SOL back permissionlessly, (b) at day 60 onward, anyone can call sweep_deploy_seed and route the unclaimed deposit to the S3ND treasury (the wrapper still verifies on-chain that the pool never migrated), or (c) the protocol authority sweeps the deposit via forfeit_deploy_seed in confirmed-abuse cases (rare). The DBC pool is left as-is — anyone can keep trading on it (paying the 1 % floor fee), but it never graduates and never migrates to DAMM v2. The token effectively becomes a perpetual constant-product DBC pool with no LP lock guarantee.
What exactly is recover_dead_launch?+
A permissionless instruction on the wrapper program. The original creator (the wallet that signed reserve_launch) can call it any time once 30 days have elapsed since the deposit was made. No protocol-authority signature is required — the wrapper enforces the 30-day window directly. Calling it transfers the 3 SOL back to the creator and marks the seed as "recovered". Designed so devs running honest experiments that simply did not gain traction never lose their deposit to slashing.
Where is the code?+
The frontend lives under app/. The Anchor wrapper lives under programs/wrapper. The Meteora DBC and DAMM v2 programs are upstream from Meteora and audited by Sec3 + Halborn. See README.md for the full layout.