Economics
Redemption mechanics
Redemption releases a proportional slice of the reserve to eligible holders. Tokens are never burned — the protocol permanently records how much SOL each wallet has already claimed.
Who can redeem — buyer-only eligibility
Only the wallet that originally bought the token can redeem SOL backing. Eligibility is derived from verified on-chain purchase history, not from the wallet's current token balance.
- Buying tokens increases your eligible balance.
- Sending or transferring tokens to another wallet gives the receiver zero redemption eligibility — received tokens never count.
- Selling or sending away your tokens reduces your eligible balance accordingly.
- Buying more tokens later increases your eligible balance again.
- You can never redeem against another wallet's purchase history.
Example: Alice buys 10,000 $ASSET and sends 5,000 to Bob. Alice's eligible balance drops to 5,000. Bob holds 5,000 $ASSET but has 0 eligible balance — he can trade the tokens, but he cannot redeem any SOL backing. Only the original buyer's wallet carries redemption rights.
Execution sequence
- Read reserve balance and total supply at the current slot inside the program.
- Verify the caller's signature and their eligible balance from verified purchase history.
- Compute gross claim, subtract the wallet's cumulative redeemed total, and apply the 10% daily cap — never from a client-supplied figure.
- Transfer SOL and increment the wallet's cumulative redeemed total atomically; either both happen or neither does.
- Start the 24-hour cooldown and record the payout in redemption history.
Accounting rules
- Available claim = max(0, gross claim − total already redeemed); it can never go negative.
- Daily maximum = 10% of the available claim, with a 24-hour cooldown per wallet.
- Cumulative redeemed totals are permanent and are never reset when the pool changes.
- Only wallets with verified on-chain purchase history are eligible; received transfers carry no eligibility.
- Checked arithmetic on every operation; rounding always favours the pool, never the caller.
- Supply is read from the mint, not from a mutable cached value.
- State updates precede transfers, and the instruction is non-reentrant.
- Slippage bound: if state moved beyond the caller's accepted minimum, the transaction reverts.
Example
pool 150 SOL supply 1,000,000,000 $ASSET eligible balance 10,000,000 $ASSET → 1.00% ownership gross claim 1.00% × 150 SOL = 1.50 SOL already redeemed 0.10 SOL available claim 1.40 SOL maximum today 0.14 SOL (10% of available) executed computed by the program at the confirming slot
Availability
Redemption is only executable when a redemption program is deployed and configured for the environment. Until then the interface computes and displays estimates but keeps the execution path disabled rather than simulating a transaction.
