The lifecycle
Create
A creator calls the launch message. The contract instantiates a standard CW20 token with a fixed 100,000-token supply and sets up a bonding curve for it. Opening valuation is ~$1,000.
Trade on the curve
Anyone buys and sells against the curve. Price rises as tokens are bought and falls as they are sold, deterministically, there is no order book and no counterparty needed.
The bonding curve
It is a constant-product curve (the samex * y = k shape as Uniswap and pump.fun), run against virtual reserves so a brand-new token starts at a sane price instead of zero. Each token’s curve stores virtual_bwick_start, virtual_tokens_start, and the invariant curve_k = virtual_bwick * virtual_tokens. A buy adds BWICK to the reserve and removes the tokens that keep k constant; a sell does the reverse. You can read the exact arithmetic in contract.rs (calculate_buy / calculate_sell).
Where the supply goes
Of the 100,000 tokens minted at launch:| Allocation | Tokens | Share |
|---|---|---|
| Sold on the curve | 79,310 | 79.31% |
| Reserved for the AMM LP at graduation | 20,690 | 20.69% |
Graduation is BWICK-denominated
A token graduates when its BWICK raised crosses the threshold, not when a USD figure is hit. The threshold is set at deploy time and ratchets (only ever increases) per curve. This is why graduation is unaffected by oracle staleness: it is measured in BWICK that genuinely flowed in, not in a price estimate.Fees and limits
- Buy/sell fees are configurable in basis points and hard-capped by the contract (buy ≤ 5%, sell ≤ 10%); a share goes to the token’s creator (
creator_fee_share_bps). - A creation fee is charged to launch a token.
- A max-wallet cap (
max_wallet_bps, currently 2.25% of supply) limits how much any single address can hold, checked on every buy by querying the CW20 balance. Set to 0 to disable.
Interface
The full set of messages, launch, buy, sell, query curve state, graduate, admin config, lives inmsg.rs. The handlers that enforce all of the above are in contract.rs.
