Stonkmon protocol rules

$STONK uses DN404 to represent one balance as both ERC-20 tokens and NFT cards. For each complete 1,000,000 $STONK held by an address, the contract assigns one card NFT. If the balance later supports fewer complete units, the contract removes the corresponding number of unprotected cards.

The protocol defines 100 card species. Each species is associated with a tokenized stock on Robinhood Chain. Part of the trading fees accumulates in the protocol and is later used to buy those stock tokens in batches. Purchased assets are recorded under the corresponding species.

Each revealed card has a claimable stock balance based on its species and token ID. The current owner can permanently burn the card and its associated 1,000,000 $STONK to receive that balance.

Cards are not pre-funded. A newly revealed card has no claim on stock deposits made before its reveal.

Stock purchases do not occur in the card assignment transaction. Fees first accumulate as engine ETH. Public execution functions later use part of that balance to purchase stock tokens in batches. At 0% overall vault fill, 80% of engine ETH is allocated to stock purchases and 20% to the floor reserve. The allocation changes linearly to 40% and 60% as the vaults reach their targets.

A stock deposit is recorded for one species and divided equally among that species' active prints. A card begins participating in later deposits when it is revealed. Target values differ by tier; the values are shown in the probability table above.

The site displays the stock balance currently claimable by each card.

Only the current card owner can call burnToClaim for that token ID. A successful call permanently destroys the NFT and 1,000,000 $STONK, then transfers the card's claimable stock balance to the owner's address. The retired token ID is not issued again.

Part of engine ETH is recorded as floorReserves. A holder can call redeem to permanently burn a specified amount of unfrozen $STONK. The contract calculates the ETH payment as the burned amount multiplied by the current floorPrice. This transaction is settled by the contract rather than through the trading pool. It reverts if the reserve cannot cover the payment.

The candidate floor price is calculated as 90% of floorReserves divided by the redeemable token supply. The contract updates floorPrice only when the candidate is higher than the stored value, so the stored floorPrice cannot decrease.

The protocol does not use the reserve to buy $STONK from the market. Market participants may compare the market purchase cost with the available redemption payment, including trading fees and gas costs. The protocol does not execute this trade and does not guarantee that it will be profitable.

DN404 keeps the number of card NFTs consistent with the number of complete 1,000,000-token units held by an address. If a token transfer or protocol redemption reduces the supported card count, the contract removes an unprotected card from that address. Its token ID enters the reuse queue, while its species and vault accounting remain attached to the token ID. A later complete-unit holder may receive that token ID with its existing claimable balance.

A holder can freeze selected cards. Each frozen card reserves one complete token unit that cannot be transferred as fungible $STONK. A transfer that would use the reserved balance reverts. Transferring the selected NFT itself moves the card and its token unit to the recipient, and the freeze does not continue at the recipient address. The trading interface is intended to list affected cards before a sale is submitted.

The hook charges 1% on buys and 3% on sells. These rates are constants in the deployed contract.

For each collected fee, 30% is recorded as creatorAccrued and can be withdrawn by the configured creator address. The remaining 70% is recorded as engine ETH. The engine allocation between stock purchases and floorReserves changes from 80%/20% at 0% vault fill to 40%/60% at full target fill.