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
Redemption calculations are based on on-chain state at execution time. Estimated values can change before confirmation. If the estimate moves, review the updated amount before signing.

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.