$BUBBLE flywheel

What the flywheel is

$BUBBLE is Bubble Shot's token on Robinhood Chain, launched on Pons. Two small contracts close a loop around it. BubbleRewards pays a little $BUBBLE for every real scan you make with a wallet connected. BubbleBurner takes the creator's share of the trading fee and turns it into a buy-and-burn that anyone can trigger. Scans hand out supply; trading fees take it back out. Neither contract can send anything to a person.

$BUBBLE

0xfd02314b2cdbedbaabff028d4ebec55b7a262381

BubbleRewards

0x3439d92de26759D751C7153E489C75f4478da712

BubbleBurner

0x867d3F0cEFd622CB86F9c9Fc0f1811aFe3f55117

Pons curve

0x8c156206b7c4810d04f26Cb19B0cAdFe0a7D66B3

Pons FeeEscrow

0xd3AFEB2a57f70eF218Aa82451c51B2fb0416Ac9e

Where the fee goes

A Pons launch lives in two places over its life. First it trades on a bonding curve: every buy and sell there pays a 1% curve fee and a 2% creator tax, both taken off the input. The tax is the creator's; the fee is split 30% to Pons and 70% back to the creator side (a launch can route that 70% half to a buyback vault, but $BUBBLE launched with buyback off), so 2.7% of curve volume ends up on the creator side. Once 4.2 ETH has been raised the curve closes and the whole position moves into a Uniswap v4 pool whose liquidity is locked forever. That pool charges no LP fee; instead the Pons hook takes 1% of every swap and splits it three ways: 30% to Pons, and the remaining 70% half to Pons's buyback vault and half to the token's creator. The creator ends up with 0.35% of pool volume.

In both phases the creator's share is not paid out directly. It accrues in the Pons FeeEscrow under the launch's creatorFeeRecipient, in ETH, and the recipient pulls it with claim(). On the curve, a Pons operator sweeps the accrued fees into the escrow every so often; in the pool the hook credits the escrow itself.

The burner

BubbleBurner is a contract with no owner and no withdraw. ETH gets in three ways: it pulls its own escrow credit once the creator has made it the creatorFeeRecipient, the creator wallet forwards fees to it, or anyone sends ETH to it. Then anyone, a keeper bot or you, calls a burn.

1. 1

   Claim

   If the FeeEscrow holds credit for the burner, claim() pulls it. Nothing to claim is fine.
2. 2

   Tip

   0.2% of the ETH about to be swapped, capped at 0.001 ETH, is set aside for whoever called. That pays the keeper's gas, and it is the only ETH that ever leaves the contract to a person.
3. 3

   Buy

   On the curve, burnViaCurve(minOut) calls the curve's buy with the whole balance. After graduation, burnAll(commands, inputs, deadline, minOut) runs the caller's Universal Router route, and minOut has to sit within 3% of the V4Quoter's price for the real pool, so a route that does not really buy $BUBBLE reverts.
4. 4

   Burn

   Every $BUBBLE the contract holds is destroyed with the token's own burn, which lowers total supply. totalBurned() keeps the running count and Burned is emitted.

function burnViaCurve(uint256 minOut) external returns (uint256 burned);
function burnAll(bytes commands, bytes[] inputs, uint256 deadline, uint256 minOut) external returns (uint256 burned);
function burnBalance() external returns (uint256 burned);   // $BUBBLE already here, e.g. swept rewards
function claimFromEscrow() public returns (uint256 amount);
function totalBurned() external view returns (uint256);
event Burned(address indexed caller, uint256 ethIn, uint256 bubbleBurned, uint256 totalBurned);

The rewards

BubbleRewards holds an allocation of $BUBBLE that anyone can top up. It pays out only against a voucher signed by Bubble Shot's server: an EIP-712 message in the domain Bubble Shot Rewards, version 1, over (to, amount, dayIndex, scanId, deadline).

1. 1

   Scan

   You scan an object with a wallet connected. POST /api/identify returns the basket and a fresh scanId, remembered on the server for ten minutes.
2. 2

   Voucher

   POST /api/rewards/claim with { scanId, address }. The server checks the scan is recent, from the same connection, and not already vouched, then signs. One voucher per scan.
3. 3

   Claim

   Your wallet sends claim(...). The contract checks the signature, that the scan id was never paid, that dayIndex is today, that the amount is under the per-claim cap and that your address is still under today's cap, then transfers.

What the owner can do

Rotate the signer, pause new claims, and sweep unclaimed tokens to the burner. The sweep destination is fixed at construction; there is no function that moves tokens anywhere else. Rewards are a gift from the allocation, not a right: if the pool runs dry, claims revert until someone tops it up.

What can go wrong

• Burns are public, so a burn can be sandwiched on the curve. The keeper tip is proportional and small, so keepers have a reason to burn little and often, which keeps each burn's price impact tiny.
• Pons can redirect a creator-fee stream with a three-day timelock. The burner reads its escrow credit every time and simply has nothing to claim if that happens; ETH already in the burner is unaffected.
• Pointing the fee stream at the burner is a one-way street from the burner's side. The creator wallet can keep the stream and forward ETH by hand instead. See contracts/script/FLYWHEEL.md.
• The server signer is a hot key. If it leaks, the owner rotates it; the damage is bounded by the daily cap per address and the allocation in the contract.

The full trust review is in contracts/SECURITY.md. Buying the basket itself is unchanged; see Buying a basket.