S3ND. The manual.

S3ND (s3nd.fun) is a Solana token launchpad with a continuous constant-product bonding curve, a sliding anti-vamp sell tax, perpetual creator rewards, a 60-minute ticker lock and a recoverable 3 SOL deploy. The MVP runs entirely in your browser; the on-chain layer is a thin S3ND Wrapper program composed on top of audited Meteora primitives — see the architecture section for the full breakdown.

The design goal is one line: make snipe-and-dump expensive while keeping fair retail entry cheap. Every primitive on this page exists to nudge launches toward that outcome.

1. 1

   Deploy

   Pay exactly 3 SOL. The full amount is injected into the bonding curve as starting liquidity. The curve begins at 3 SOL collected with zero tokens sold. The ticker is reserved for 60 minutes. The deployer may optionally bundle a buy in the same transaction at curve price, capped at 3.5% of supply (≈ 1 SOL at curve start).

2. 2

   Trade

   Buyers pay SOL to receive tokens off the curve. Sellers pay a sliding tax that starts at 30% and decays to 1%. A hard 3.5% per-wallet hold cap (35M tokens) is enforced on every buy — the only per-wallet limit during bonding. No SOL spend caps, no cooldowns.

3. 3

   Bond

   When the curve hits 100 SOL the launch bonds. Trading on the curve closes. The 3 SOL deploy seed is refunded to the creator wallet automatically inside the same instruction — no claim step. Remaining liquidity plus 200,000,000 reserved tokens are used to seed a Meteora DAMM v2 pool.

Every S3ND launch has the same fixed supply schedule. No free dev allocation, no team unlocks, no surprise mint authority. The deployer can optionally bundle a buy with the launch transaction, but it pays curve price and is capped at the same 3.5% every other wallet faces.

No new tokens are ever minted after deploy. The 200,000,000 reserved tokens never enter the curve and never enter the deployer wallet. They sit in a program-owned vault until the bond instruction pairs them with the remaining curve SOL to seed the DEX pool.

The pricing function is a constant-product AMM curve with virtual reserves. The same x * y = k math that powers Uniswap, applied to a one-sided launch curve. Price discovery is continuous and smooth — every SOL added shifts the marginal price slightly, with the shift growing as the curve approaches bond.

S_v = 30 + (solCollected - 3)
T_v = 1047422680 - tokensSold

Invariant kept across every trade:
S_v * T_v = K  =  31422680412

Sample points along the curve

Visual zones (UI only)

The three zones below are not pricing tiers, not cap tiers, and not tax tiers. The hold cap stays at 3.5% from minute 0 until bond, the sell tax decays purely by minutes since launch (not by SOL collected), and the curve is one continuous x*y=k formula. Zones exist only so a progress bar can communicate roughly where the launch is on its journey from deploy to migration. They never change anything about the trade.

Sells pay a tax that decays with time, not with bond status. Whether the launch is still on the bonding curve or has already migrated to a DAMM v2 pool, the rate any seller pays at minute t after launch is the same. Bonding does not reset the schedule, and bonding does not switch the token into a low-tax regime. This is the single most important thing to understand about S3ND taxation: a token that bonds in eight minutes is still under full snipe-protection until minute sixty, exactly like a token that bonds in eight days.

What does change at bond is who receives the cut and how it is routed. Pre-bond the cut funds the LP-boost reserve and the protocol treasury. Post-bond the cut feeds creator rewards, an LP buyback, and treasury — with a deliberate smooth transition that prevents a discontinuous jump in creator share when the rate hits the long-term floor.

The protection schedule

The total tax rate is a step function of the launch's age. The first ten minutes are deliberately punishing; the curve relaxes from there as organic holders accumulate. After the sixtieth minute the rate drops to the perpetual floor of 1% and stays there forever, enforced by the Token-2022 transfer hook on every transfer of the token.

Same rate, four routing phases

The total tax rate paid by a seller is fully determined by the schedule above. What changes across a launch's lifetime is where the cut goes. S3ND ships four phases. Phases A and B share the schedule; phases C and D both sit on the perpetual floor with only the routing migrating across them.

Phase A — pre-bond (any minute)

Creator gets 0%. The active rate is split 70% into the LP-boost reserve (paired with the migration LP at bond, compounding pool depth) and 30% into the protocol treasury. The creator earns nothing until they actually deliver a launch that bonds — the deploy-fee refund and the post-bond fee stream are the sole creator rewards.

Phase B — post-bond, schedule still active (minute 0–60)

Creator earns a flat 0.5% absolute fee on every transfer — the same skim regardless of where the schedule sits. The remainder of the active rate (rate minus 0.5%) is split 70% LP-buyback / 30% treasury. At a 30% rate that means 0.5% creator / 20.65% LP / 8.85% treasury; at 8% it's 0.5% / 5.25% / 2.25%. Bonding into the high-tax window does not penalise the creator: their share scales with volume, not with the decay of the rate.

Phase C — post-bond transition window (minute 60–90)

At minute 60 the rate hits the 1% floor. If the creator share stayed at 0.5% that would be 50% of the entire cut — defensible, but a discontinuous jump in routing. Phase C linearly interpolates all three absolute fractions over a 30-minute glide:

Total stays at 1% across the entire window — only the routing migrates. At minute 75 (midpoint) the cut is exactly 0.4% creator / 0.375% LP / 0.225% treasury.

Phase D — perpetual floor (minute 90+)

Steady-state forever after. 0.3% creator / 0.4% LP-buyback / 0.3% treasury, all expressed as absolute fractions of the gross transfer. The Token-2022 transfer hook continues to enforce these on Jupiter, Axiom, the DAMM v2 pool, every wallet-to-pool transfer.

Why the hook taxes swaps, not wallet sends

The Token-2022 transfer hook fires on every transfer of a token, by design. A naive implementation would mean a friend-to-friend send of 100 tokens would arrive as 70 tokens at high-tax minutes. That is wrong UX — the schedule is meant to discourage dumping into a market, not gift-giving between wallets.

The hook resolves this by inspecting the destination account on every transfer and applying tax only when the destination is a registered AMM pool for the launch. Roughly:

hook on_transfer(source, dest, amount):
  pool_set = launch.registered_amm_pools

  if dest in pool_set:
      # tokens flowing into a pool = a sell
      apply tax according to schedule + active phase
  elif source in pool_set:
      # tokens flowing out of a pool = a buy
      no tax (the AMM swap fee already covers the pool side)
  else:
      # wallet -> wallet, gift, sweep, anything else
      no tax

The set of registered pools is small and on-chain. At launch it contains the DBC bonding pool. At migration the DAMM v2 pool is appended automatically. If a future AMM gets traction and the protocol decides to register pools there too, governance can extend the set; nothing else about the token changes.

Net effect: every actionable sell is taxed by the schedule, every legitimate transfer is free. The hook cannot be bypassed by routing through aggregators (Jupiter, Axiom, Photon all eventually deposit into the AMM pool, which still triggers the hook).

Worked examples

Notice the symmetry between row one and row two: identical seller proceeds, identical total tax, only the recipients differ. That is the entire S3ND tax design distilled into one comparison. Rows five and six show the smooth glide of phase C terminating in phase D — the seller still pays exactly 1% across the transition, only the routing moves.

Perpetual creator fees, with one important guardrail: the creator gets nothing pre-bond. Pre-bond is a probation phase. If the launch never bonds, the deployer loses 3 SOL and earns no fees. If the launch bonds, two reward streams unlock at once:

How the creator share is computed

The creator's post-bond cut is an absolutefraction of the gross transfer, not a relative share of the active tax rate. That keeps the creator's revenue tied to volume rather than to the decay of the schedule.

• Pre-bond (any minute) — creator earns 0%. Probation period.
• Post-bond, minute 0–60 — creator earns a flat 0.5% of every taxed transfer. The remaining tax (rate minus 0.5%) splits 70 / 30 to LP-buyback and treasury.
• Post-bond, minute 60–90 — creator share linearly glides from 0.5% down to 0.3% so the routing transitions smoothly into steady state. Total tax stays at 1%.
• Post-bond, minute 90+ — creator earns a perpetual 0.3% of every transfer, paired with 0.4% LP-buyback and 0.3% treasury. Total = 1%.

A token that bonds at minute 8 captures the full 0.5% skim for the remaining 52 minutes of the high-rate window — a structural reward for shipping a launch with strong demand. From minute 60 the glide begins, and from minute 90 onward the creator earns the steady 0.3% per transfer indefinitely.

The creator share never adds tax on top of what holders already pay for anti-vamp protection. The post-bond split is purely a re-allocation of the existing schedule.

S3ND ships one per-wallet rule during bonding, not a stack of overlapping caps. The sliding sell tax handles dump pressure; the hold cap handles concentration; the Token-2022 hook handles post-bond enforcement. Three orthogonal primitives, no redundant friction:

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.

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 deployRefundPaid so 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.

The bond instruction fires when the cumulative SOL collected hits 100. It is a single atomic step that wraps up the bonding phase and stands up a permanent Meteora DAMM v2 pool in one transaction.

1. The curve closes. Buys and sells on S3ND stop.
2. The 3 SOL deploy seed is refunded to the creator wallet automatically — same instruction, no claim step.
3. The remaining curve SOL plus the LP-boost reserve plus the 200,000,000 reserved tokens are paired into a new Meteora DAMM v2 pool.
4. The LP position is 100% permanently locked inside the DAMM v2 program — no one can withdraw the underlying liquidity, ever. Equivalent to burning, with the bonus that DAMM v2's permanent-lock state is directly readable on-chain by indexers and wallets.
5. Trading continues on DAMM v2. The Token-2022 transfer hook keeps the 1% sell tax alive on every swap and transfer.

What the LP is actually made of

A Meteora DAMM v2 pool is just a smart contract holding two assets and running the same x * y = k math the bonding curve uses, but with real reserves instead of virtual ones. Every swap rebalances the reserves; the pool itself never moves.

The 200,000,000 token 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 200M 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.

Concretely, the pool might hold anywhere from 50M to 350M tokens at any given time depending on net buy or sell pressure, and the SOL side adjusts in lockstep. The total k stays constant up to swap fees, which the pool keeps as a depth-compounding rebate.

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 allocating 100% of the position to DAMM v2's permanentLockedLiquidity flag inside the same migration instruction. 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 200M tokens and 97+ 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.

The Token-2022 transfer hook deliberately does the cheapest possible thing on every taxed sell: classify the transfer, compute the phase split, write SOL into per-recipient vault PDAs, return. It does not add liquidity, swap tokens, or pay creator wallets directly — those operations happen later, in dedicated instructions.

This page documents the four vaults the wrapper program owns, how each one is drained, and why a permissionless compound_lp_buyback with a keeper bounty is the design that makes the post-bond LP-buyback actually work on Solana.

Why per-transfer compounding is impossible

A naive design would fold the LP-share back into the locked LP on the same transaction that triggered the tax. It does not work, for three concrete reasons:

1. Two-sided LP. Adding to a SOL/Token LP requires both sides. The hook has only SOL (the tax skim). Producing tokens means swapping half the SOL via the same DAMM v2 pool — i.e. a nested CPI back into the AMM during a transfer that is itself triggered by an AMM swap. AMM programs reject that as re-entrancy.
2. Compute budget. A DAMM v2 swap costs roughly 60k compute units; an add_liquidity call costs roughly 50k. Doing both inside the hook on every transfer adds about 110k CU on top of the swap that already triggered the hook. The 200k CU limit would be blown on busy launches.
3. Atomicity risk. If the swap or add-liquidity reverts (slippage, sandwich, pool imbalance), the entire user-facing sell would revert. Users would experience random sell failures with no visible cause.

So the hook stays minimal and writes SOL into vaults; we lift it back into the LP via a separate instruction on a different cadence. This is the same pattern Marinade, Jito, Kamino, and Meteora's own auto-compounders use.

The four vaults

Every launch ships with three per-launch vault PDAs plus a single program-wide treasury vault. All hold SOL only.

Account size for each is just a SOL holder + a 1-byte bump. They do not store state beyond the lamport balance.

The LP-buyback compound mechanism

The post-bond LP-share is the most interesting of the four because it has to fold back into the locked LP, but the hook cannot do it directly. compound_lp_buyback is the instruction that closes that loop.

compound_lp_buyback(launch, keeper):
  require launch.bonded
  available = LpBuybackVault.balance - rent_min
  require available >= MIN_COMPOUND_SOL    (= 0.5 SOL)

  bounty = available × 1%               (= 1% keeper fee)
  pay bounty to keeper

  to_compound = available - bounty
  half_sol    = to_compound / 2

  swap half_sol  → tokens     via locked DAMM v2 pool
  add_liquidity (half_sol, tokens) into the locked LP position
                                with slippage cap 2%

  emit LpBuybackCompounded { sol_added, tokens_added, bounty }

The compound is permissionless: anyone can call it. The keeper-bounty structure means triggering it is profitable for any wallet running a basic indexer, so we do not depend on any single operator to keep the LP growing.

The three constants

Why permissionless instead of protocol-run

• No single point of failure.If our own keeper bot dies, anyone else's bot fills the gap. The vault SOL is never at risk; it sits in the PDA until someone triggers.
• Bounty pays for action. 1%of the compound amount goes to the keeper. At the threshold that's already several multiples of a typical priority-fee tx, and it scales linearly with size.
• Implicit arbitrage.The compound temporarily moves the pool's SOL/token ratio. Sophisticated keepers run compound + arb in the same tx, capturing the arb spread on top of the bounty — which makes them call it even faster.
• Trustless. Bounty is paid first inside the same atomic transaction. If the swap or add-liquidity reverts, the bounty payment reverts too. No way for a keeper to drain bounty without doing the work.

What happens when volume spikes

Concrete worry: a hot launch can generate tens of SOL of tax in seconds. Does the system keep up?

Edge cases and failure modes

• Pool too thin for compound. If the DAMM v2 pool depth is so low that swapping half the compound SOL would move price by more than 2%, the swap reverts. The vault keeps its SOL. The compound can be retried later — this only happens immediately post-bond on a quiet launch.
• Wrong pool passed. A malicious keeper might try to call compound with a fake DAMM v2 pool. The wrapper validates that damm_pool == launch.damm_v2_pool (set at migration) and rejects anything else.
• Concurrent compounds. Two keepers race. The first one to land settles; the second finds the vault below threshold and reverts. No double-spend.
• Re-entrancy. The compound makes two CPIs (swap and add-liquidity) into the locked DAMM v2 pool. The DAMM v2 program does not call back into the wrapper, and our hook does not fire on the DAMM v2 LP-token mint (only on the launch token). Re-entrancy is structurally impossible.
• Buy-leg of compound is tax-free.The compound's swap step is a buy of the launch token from the pool. Our transfer hook fires on that incoming transfer but classifies it as a buy (source ∈ registered pools) and applies no tax. No double-counting.
• Unhandled vault.If for some reason no keeper ever calls compound (truly anaemic volume), the SOL just sits safely in the PDA until the next activity spike triggers a profitable compound. The worst case is "LP grows slower", never "funds lost".

Creator and treasury vaults

The other two vaults work the same way as LpBuybackVault — hook deposits, explicit instruction drains — but with different access control:

• claim_creator_rewards is creator-only. No keeper, no bounty, no threshold. The creator picks when to claim and receives the entire vault balance above rent-exempt minimum.
• sweep_treasury is multisig-only (the protocol treasury authority set at program deploy). No keeper, no bounty, no threshold. Optional partial-amount argument; defaults to "everything above rent-exempt minimum".

Permissionless drains are reserved for the LP-buyback because (a) it benefits everyone holding the token, and (b) it produces an arb opportunity that incentivises outside actors. Creator and treasury drains are private flows where permissionless triggering would just leak timing data without solving any problem.

What this guarantees, end to end

• The hook stays cheap regardless of how many sells land per second. S3ND never breaks under load.
• Every lamport routed by the hook lands in a PDA the wrapper program owns. No SOL is ever in flight.
• Each share is drained by exactly one instruction with one well-defined caller class. No ambiguity over who can claim what.
• The locked DAMM v2 LP only grows. Every compound permanently increases pool depth — 1% floor or 30% schedule rate, the buyback never shrinks the LP.
• On-chain state is fully deterministic. Off-chain indexers (Helius, our own) can reconstruct vault balances, compound history, and creator claims by replaying instructions.

S3ND does not reinvent the bonding-curve wheel. The on-chain layer is built by composing three Solana programs that each do one thing well and call each other via Cross-Program Invocation (CPI). This keeps our own surface area small and audit-friendly.

The three layers

How a buy actually flows

1. User wallet signs ONE transaction
       │
       ▼
2. S3ND Wrapper Program
       │   • validates 3.5% hold cap
       │   • validates Clock::slot > launch.created_slot
       │   • CPI into Meteora DBC
       ▼
3. Meteora DBC Program
       │   • pure curve math (fee = 0%)
       │   • emits SPL transfer to pool
       ▼
4. Token-2022 Transfer Hook (fires on the SPL transfer)
       │
       │   destination classifier:
       │     dest ∉ registered pools → no tax (gift / sweep)
       │     dest ∈ registered pools → tax = schedule[age]
       │
       │   phase A — pre-bond, any age
       │     creator 0%    /  LP-boost 70%  /  treasury 30%   (relative)
       │   phase B — post-bond, min 0–60
       │     creator 0.5% abs, remainder split 70 / 30 LP / treasury
       │   phase C — post-bond, min 60–90 (transition)
       │     linear glide from phase B end-state to phase D
       │   phase D — post-bond, min 90+ (floor)
       │     creator 0.3%  /  LP 0.4%        /  treasury 0.3%  (absolute)
       ▼
5. Tokens land in pool, SOL / tokens to seller

Everything happens inside one Solana transaction. If any step fails — the hold cap check, the slot check, the curve math, anything — the entire transaction reverts and no state changes. The user only pays the network fee for the failed attempt. Nothing else.

Why the tax lives in the hook, not in DBC

Meteora DBC has its own fee scheduler. We could plug the S3NDschedule into it directly and skip the transfer hook for pre-bond. We deliberately don't. Reasons:

• One source of truth. The same hook computes pre-bond and post-bond tax, so the schedule cannot drift between layers. There is exactly one place to audit.
• Continuity across migration. When DBC migrates the launch into a DAMM v2 pool, the tax does not skip a beat. A sniper selling at minute 9 pays the same 30% whether the pool is still DBC or already DAMM v2.
• Bond-aware split.The hook reads the launch's bonded flag and switches between the pre-bond split (LP-boost / treasury) and the post-bond split (creator / LP-buyback / treasury) automatically. DBC's scheduler cannot do that — it has no concept of S3ND's creator PDA.
• Gift exemption. Routing all tax through one hook lets us cleanly skip the cut on wallet-to-wallet transfers using the registered-pool whitelist. A DBC-side fee would only fire on DBC swaps, leaving us to either add another mechanism for post-bond, or live with inconsistent semantics.

DBC's fee scheduler is configured to 0% inside S3ND. We use DBC for what it is genuinely best at — curve math, virtual reserves, and one-shot migration into DAMM v2 — and keep all tax decisions in our own hook.

Why CPI, not a monolith?

• Smaller audit surface. The S3ND Wrapper is roughly a few hundred lines of Anchor code — far cheaper to audit than a full bonding curve plus AMM plus migration logic.
• Audited dependencies. Meteora DBC and DAMM v2 already have multiple audits (Sec3, Halborn) and have processed many millions of dollars in volume. We inherit that battle-testing for free.
• Free indexing. Because tokens live inside a real DBC pool from day zero, every Solana trading frontend (Jupiter Pro, Axiom, Photon, BullX, Phantom Swap) picks them up automatically. We do not need to ship integrations.
• Token-2022 native. DBC supports Token-2022 mints directly. Our Transfer Hook attaches at the mint level, so the 1% floor enforces uniformly across DBC swaps, DAMM v2 swaps, and direct transfers — no special integration with each DEX.
• Composability. If a future Solana AMM ships with better mechanics, we can extend the wrapper to optionally route there. The migration target is configuration, not architecture.

What lives where

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.

Phase 2 and 3 are intentionally split. The wrapper program ships first because it is the smaller, more critical surface — it owns every single trade validation. The Transfer Hook ships second because it only matters post-bond, which gives us extra time to tune the split logic against real market data.