Bonding Curve & Tokenomics

How the curve prices a token

ZecPad uses a constant-product bonding curve, the same family of curve used by automated market makers, seeded with virtual reserves so a token has a real, non-zero starting price:

price = virtual_sol_reserves / virtual_token_reserves

Every buy adds SOL to virtual_sol_reserves and removes tokens from virtual_token_reserves (and vice versa for sells), holding the product k = virtual_sol_reserves × virtual_token_reserves constant. Because virtual_token_reserves shrinks as tokens are bought, each subsequent token costs slightly more than the last — this is what makes the curve self-pricing with no order book.

Curve shapes

At creation, a creator picks a curve shape, which sets the starting virtual reserve ratio and therefore how steeply price rises as the curve fills:

Shape	Behavior
`STEEP`	Cheap early, price accelerates sharply near the end of the curve — rewards early buyers most, discourages late large buys
`LINEAR`	Price rises roughly proportionally to tokens sold
`FLAT`	Price stays closer to constant across the curve, smaller spread between early and late buyers

The token page visualizes this as a 12-tier staircase: each step is a price tier, and the chart doubles as a buy ladder — filled steps are sold, dim steps are what's left.

Fees

Fee	When charged	Notes
Mint fee	Once, at token creation	Flat SOL fee, configurable by the platform
Shield setup fee	Once, only if Privacy Mode is on	Covers the Confidential Transfer account initialization
Trading fee	Every buy/sell on the curve	Percentage of trade size (shown in-app as "Slippage · fee"); split between the platform treasury and the token's creator

Exact fee percentages and the platform treasury address are configured on-chain in the program's global config account and are readable by anyone — see Developer Docs.

Migration to a DEX

A token's migration target (set at creation, in SOL) is the real SOL reserve threshold that ends the bonding-curve phase:

Trigger: the curve's real SOL reserves reach the migration target.
Trading halts on the curve — no more buys or sells against it.
Liquidity moves: the remaining SOL and a proportional share of the token supply are deposited into a new Raydium or Orca pool via a single on-chain instruction.
Mint authority is revoked. Total supply is fixed from this point forward — nobody, including the creator or ZecPad, can mint more.

There's no deadline: a token that never reaches its migration target continues trading on the curve indefinitely.

Anti-bot / anti-snipe mechanics

To reduce the advantage of bots front-running a launch:

Per-wallet buy limits apply for a fixed window of slots immediately after a token is created (roughly the first minute).
Cooldowns enforce a minimum number of slots between consecutive buys from the same wallet.
Per-transaction size limits prevent a single buy from taking an outsized share of the curve at launch.

These limits are enforced on-chain, inside the program's buy instruction — not as an off-chain filter — so they can't be bypassed by calling the RPC directly instead of using the ZecPad UI. They do not prevent one operator from splitting a large buy across multiple wallets; that is a known, inherent limitation of any purely on-chain anti-bot mechanism (see Security & Audits).