# Bamboo Riot — economic design

Decision recorded September 21, 2026. **The documented StonkBrokers activation economy replaces the earlier 33,000-token / 100%-burn proposal.** Bamboo Riot retains its 4,000 existing NFTs, original identity, approved sprites and 20 environments. Its NFT mint remains free; activation is a separate paid action in the future project token.

This package is an original local model and interactive workbench. The reference values were checked against current official documentation and frontend code. Deployed contract storage was not independently verified. No token, contract, swap integration or reward program has been deployed by this work.

## 1. Exact activation parameters

| Tier | Full activation, project tokens | Relative weight | Compared with Base | Upgrade from preceding tier | Burn / protocol on full activation |
|---|---:|---:|---:|---:|---:|
| Base | 66,666 | 100 | 1.00× | — | 33,333 / 33,333 |
| T1 | 166,666 | 125 | 1.25× | 100,000 | 83,333 / 83,333 |
| T2 | 366,666 | 160 | 1.60× | 200,000 | 183,333 / 183,333 |
| T3 | 666,666 | 200 | 2.00× | 300,000 | 333,333 / 333,333 |
| T4 | 1,666,666 | 333 | 3.33× | 1,000,000 | 833,333 / 833,333 |

Every panda can select a tier, including the ten 1/1 artworks. Artwork rarity, outfit, bamboo production, scenery and grove size add no weight. There is no extra quantity bonus.

An active panda upgrading to a higher tier pays `target fee − current tier fee`. Skipping tiers is allowed for that difference. Base → T4 therefore costs 1,600,000 additional tokens. The original payment plus this upgrade equals a direct T4 activation. An equal or lower tier is not an upgrade.

Each activation and upgrade payment uses **50% burn / 50% protocol**, the default split stated by the reference. Its documentation and ABI indicate configurability; this is a chosen Bamboo Riot parameter, not a claim that Stonk's split is immutable.

T4 costs approximately 25 times Base for 3.33 times its weight. A higher tier does not mean a better return per token spent. These multipliers describe relative allocation, not yield, APR, dollars or a repayment period.

## 2. Ownership and the NFT vault

The reference describes activation and an ERC-6551 token-bound wallet. This is not enough evidence to describe its core mechanic as a conventional custodial staking contract with a deposit and an unstake timer.

- Activation is recorded against the existing NFT ID. No additional NFT is minted.
- A true change of NFT ownership clears activation. An inactive NFT is quoted at the full price of the newly selected tier. Prior payments do not create a permanent transferable fee credit.
- Assets already delivered to the NFT's wallet travel with the NFT. The current owner controls them; the previous owner does not retain withdrawal authority after selling.
- A transfer does not erase already held assets. The reference homepage says seeded stock can be withdrawn at any time; asset-specific permissions still require implementation verification.
- Holders may select up to three approved reward assets and allocation percentages totalling 100%. Without an election, the default is ETH.

There is no independently verified rule yet for whether elections survive a transfer, which activation snapshot controls a pending round, or whether every kind of undelivered credit follows a sale. These are explicitly model choices in section 7, not claims of exact contract parity. A seller can also change a vault balance before selling unless a marketplace transaction enforces a minimum balance atomically.

## 3. Funded distribution, separate from activation

The reference's Clock In v2 mechanism waits until its accrued ETH pot reaches a threshold. A caller pays gas to trigger processing, the system tallies reward choices, acquires demanded assets and credits activated NFTs proportionally by tier weight. Delivery may be pushed or resumed through a Deliver action. Its former Overtime royalty program has merged into this flow.

Conceptually, within a given asset demand group:

`allocation = actually acquired asset inventory × eligible elected weight / total eligible elected weight`

Exact eligibility timing, acquisition ordering and rounding need contract-level confirmation. This workbench uses the reproducible method described below. It does not invent an exact threshold, periodic emission rate, stock price or exchange rate.

The money flow is:

1. Actual net fees arrive at the reward fund.
2. A funded amount is reserved for a round.
3. The allocated ETH is delivered directly or spent to acquire selected assets.
4. Only confirmed acquired amounts become distribution inventory.
5. Integer allocations are credited to the corresponding NFT vaults.

The 50% of activation payments held by the protocol remains **project tokens**. It is not automatically ETH, cash, Stock Tokens or holder-owned assets. Burning the other 50% does not purchase rewards. If treasury tokens are later sold to fund acquisitions, only the realized proceeds count as funding. No new fees means no new funded distribution; already credited balances remain accounted for.

Stock Token rewards are not automatically direct share ownership or corporate dividends. The official reference calls its distributions marketing rewards funded by fees and royalties. Bamboo Riot's instruments, issuer permissions, supported recipients and available acquisition routes remain to be verified for Robinhood Chain.

## 4. Revenue map — reproduce the correct base

Different Stonk products have different rules. A blanket 70/30 split is not its complete economy.

| Reference product | Charge | Documented destination | Bamboo Riot status |
|---|---|---|---|
| Activation / upgrade | Table above, in project tokens | Default 50% burn / 50% protocol | Exact local arithmetic implemented |
| Core Anvil NFT marketplace | 666,666-token trade principal plus an ETH fee: 10% swap or 15% snipe | **ETH fee only:** 70% StockBooster / 30% protocol | Reference venue economics documented; no Bamboo marketplace or reserve exists |
| Broker loans | ETH fee described using 15% APR on market ETH notional and duration, with duration/fee floors | Fee: 70% StockBooster / 30% protocol | Separate unimplemented product; this APR is a borrowing charge, not holder yield |
| Safety Deposit Box | Selected mode: 0.5% upfront liquidity fee or 20% share of eligible collected swap fees; legacy withdrawal rules differ | Locker fee router: 90% community / 10% protocol, with asset-dependent delivery | Separate unimplemented product |
| Broker Box ticket | 10% ticket edge | 2.5% creator, 2.5% StockBooster, 5% protocol; official creators also direct their share to StockBooster | Separate unimplemented product |
| Broker Box certificate | $2 service charge | $1 StockBooster / $1 treasury | Separate unimplemented product |
| Broker Box other charges | 5% sell-back spread; 3.33% deed royalty | Spread to bankroll; royalty to treasury | Separate unimplemented product |
| Launcher | Separate curve, LP fees and buyback design | Its own documented waterfall | Separate unimplemented product |

For the Anvil example, at an ETH fee notional of `N`, a 10% fee contributes `0.07N` to rewards and `0.03N` to protocol. A 15% fee contributes `0.105N` and `0.045N`. The principal is separate. Current oracle settings, bootstrap fee settings and deployed configuration have not been independently read.

Launching a token on Pons does not create an NFT AMM, loan business, locker or their trading activity. These are additional products required for complete revenue-source parity. No fees from those products are attributed to Bamboo Riot in the lab. Adopting the table does not reproduce Stonk's audience, volume or results.

## 5. Pons and supply compatibility

The Pons site and documentation endpoints could not be reached during this review. Its launch supply, decimals, creator fees, fee recipient configuration, graduation behavior and real burn support therefore remain unconfirmed from a primary source. A secondary creator guide reports a fixed one-billion supply; this is a verification lead, not an adopted Bamboo Riot parameter.

| One activation cycle across 4,000 NFTs | Gross project-token charges | Burn at 50% | Protocol tokens at 50% |
|---|---:|---:|---:|
| Every panda at Base | 266,664,000 | 133,332,000 | 133,332,000 |
| Every panda reaches T4 | 6,666,664,000 | 3,333,332,000 | 3,333,332,000 |

**If Pons mandates a fixed one-billion token supply, it cannot support all 4,000 pandas reaching T4 under this exact burn schedule.** Reusing the protocol half does not restore the burned half. Transfers and fresh activation cycles consume additional tokens. Gross payments may include recirculated units; burned units cannot recirculate. Prices or token decimals do not resolve the raw-unit shortfall when the fees are stated in whole project tokens.

A literal Anvil-style full simultaneous redemption reserve would separately require `4,000 × 666,666 = 2,666,664,000` settlement tokens. This is not a reserve Bamboo Riot currently has, and no redemption promise is made.

The project owner has accepted limited aggregate capacity at the highest tiers and does not expect all 4,000 pandas to reach T4. The exact activation prices remain the chosen design; universal access to T4 is not a design requirement.

The implementation must still verify the actual Pons factory and launch settings before a token is created. Token ticker, address, supply, allocation and liquidity are not guessed. The accepted scarcity assumption does not change the raw-unit arithmetic above or establish the factory's burn support.

The reference ERC-20 supports Burnable and Permit. A different factory may not. Sending tokens to a dead address can retire them from circulation without reducing `totalSupply`; those actions must not be represented as identical on-chain burns without verification.

## 6. Collection size, concentration and the grove

Bamboo Riot keeps 4,000 NFTs; the reference has a different supply. With the same tier across all activated NFTs, weight share follows NFT count. With 100 T4 pandas against 3,900 Base pandas, the T4 group has `33,300 / 423,300`, approximately **7.8668%** of the funded pool despite being 2.5% of the collection. This is arithmetic, not a revenue estimate.

Each additional activated weight dilutes shares of a fixed pool. No wallet cap or rarity bonus is added. The animation is a visual interpretation of participation: pandas harvest bamboo, districts handle large collections, and 20 environments unlock visually. Harvest count, browser uptime and animation speed never create financial balances.

## 7. What the local model implements

`economy.mjs` is independently written JavaScript with no wallet or network calls. It uses BigInt accounting and an illustrative 18-decimal project token. Real asset decimals require adapters. `ETH`, `STOCK_A` and `STOCK_B` are ledger keys; the latter two are mock assets, not identified securities or deployed contracts.

Implemented and tested:

- Exact five-tier fees, weights, differential upgrades, ownership checks and the 50/50 activation split.
- Distinct project-token, net-ETH-funding and reward-inventory ledgers.
- Up to three asset choices totalling 10,000 basis points.
- Funded rounds with bounded delivery batches and replay prevention.
- NFT-bound balances, current-owner-only example withdrawals and transfer deactivation.
- Conservation at raw-unit precision, including tiny budgets and 4,000 participants.

Explicit model choices awaiting reference contract verification:

- Round opening fixes the active ID list, tier weights and elections. It uses all net available ETH; the reference's pot threshold and timing are not modeled.
- ETH is first divided by NFT weight, then by each NFT's asset election. Asset acquisitions are allocated using those funded portions. Largest-remainder rounding conserves every raw unit with rotating tie order. This algorithm is ours, not a claim about Stonk bytecode.
- A transfer does not alter an already opened round. Pending credits stay attached to the NFT; elections persist. Public evidence confirms only that delivered vault assets travel with the NFT. These pending/election policies must be resolved before production.
- Self-transfer to the identical owner string preserves activation. Any genuine owner change clears it. No custody, bridge or same-human wallet exception is invented.
- An acquisition receipt is a trusted demo boundary: the model accepts amounts recorded as spent/received, releases unused reserved ETH, then allocates actual recorded inventory. A production adapter must derive these values from verified token balance changes and authenticated execution, with slippage and asset allowlists.
- Positive round-opening balance is sufficient in the model. The reference's accrued threshold, caller gas costs, swaps and failed-acquisition recovery are not deployed here.

The UI exercises the default ETH route. Tests also cover mixed elections and 12,000 credit entries for 4,000 NFTs × three assets. Public JS maps and string owners are a local modeling convenience, not a secure smart-contract authorization scheme.

The default-zero calculator starts without projected income. It shows one-cycle aggregate costs, group shares and per-NFT ETH from a user-entered funded pool. Displayed amounts round down; real model settlement conserves integer units separately.

## 8. Production integration sequence

1. Verify Pons factory/supply/fees/burn compatibility against the exact table, or resolve the launch-venue conflict explicitly.
2. Establish the real sources of Bamboo revenue and their fee recipients. Implement a marketplace only if its reserves and fee notional are funded and specified.
3. Verify reference contract eligibility and transfer semantics; settle the pending-round/election policies before claiming full parity.
4. Specify original activation/vault/fee adapters, actual token and NFT addresses, supported stock instruments and acquisition routes. Keep received funds and liabilities reconciled.
5. Test on the chosen network's test environment, including ownership changes, failed swaps, replays, paused assets, gas limits, decimal differences and emergency handling; independently review custody and economic invariants.
6. Integrate authenticated activation state with the approved grove. Publish terms and exact fee quotes before enabling any real payment.

The local model is ready for design review, not for handling user funds. Stonk's BUSL-1.1 protocol licensing is distinct from The Rig's MIT license; no Stonk protocol source was copied into this implementation.

## Sources

Observed September 21, 2026. See `source-evidence.json` for response hashes and matched quotations.

- [StonkBrokers official activation and Clock In documentation](https://www.stonkbrokers.cash/docs#activation)
- [NFT and token-bound wallet documentation](https://www.stonkbrokers.cash/docs#nft)
- [Official marketplace and activation interface](https://www.stonkbrokers.cash/marketplace?tab=activate)
- [Current official marketplace bundle: upgrade quotation and fee note](https://www.stonkbrokers.cash/_next/static/chunks/app/marketplace/page-8a3eea6ad20243b4.js)
- [Official ERC-20 paper](https://www.stonkbrokers.cash/docs/stonkbroker-token)
- [Loans](https://www.stonkbrokers.cash/docs#loans), [Locker](https://www.stonkbrokers.cash/docs#locker), [Broker Box](https://www.stonkbrokers.cash/docs#broker-box), [Launcher](https://www.stonkbrokers.cash/docs#launcher)
- [Protocol licensing](https://www.stonkbrokers.cash/docs#protocol-license)
- [Secondary Pons creator guide — unconfirmed launch-setting leads](https://airdropalert.com/blogs/launch-token-on-pons/)

Official RPC and explorer calls returned HTTP 403. No on-chain configuration values were inferred from failed reads. The historical 33,000-token prototype and earlier design files have been preserved; this document supersedes their economic parameters.