v0.1.0 pre-launch Robinhood Chain engine 17 tests 0000000

Every creator reward buys the coin back and burns it.

Robinhood is a token launched on Pons, on Robinhood Chain. The creator rewards Pons pays the dev wallet are not kept. Each cycle the engine spends everything above a small gas reserve buying the token on the DEX, and the swap delivers the tokens straight to the burn address. They never sit in a wallet anyone controls.

Every burn is a single public transaction. This page renders the ledger the engine wrote.

Token not yet deployed
Flow 72% drag the handle
Burned 0 ROBIN
  • Rewards spent 0 ETH 100% of creator rewards, less gas reserve
  • Tokens burned 0 ROBIN delivered by the swap to 0x…dEaD
  • Supply burned of total supply at the last cycle
  • Burn cycles 0 one transaction each, all public

Source: data/faucet.json, written by faucet burn --write-site.

Mechanism

One inlet, one outlet, no wallet in between.

Pons pays creator rewards to the dev wallet in ETH. Each cycle the engine reads the balance, keeps a fixed gas reserve, and sends the rest into a single router call: swapExactETHForTokens with the recipient set to the burn address. The tokens go from the pool to 0x…dEaD in the same transaction. The engine then checks the wallet moved by exactly the amount sent plus gas, and refuses to record the cycle if it did not.

Creator rewards paid by Pons on every trade, in ETH DEV WALLET balance − gas reserve 100% to the swap DEX SWAP ETH → ROBIN, one router call ≤ 3.00% slippage bound, or it reverts BURN swap recipient 0x000…dEaD nothing leaves this address Conservation check after every cycle: balance before − spent − gas = balance after, to the wei.

Policy

One rule, fixed in code.

The routing policy is a single entry in engine/src/config.ts. The engine imports it to settle and refuses to start if it does not sum to 10,000 basis points; this page reads a generated copy. Changing it is a commit that changes both at once.

100.00%

Buyback & burn

Every creator reward the dev wallet receives is swapped for the token on the DEX, with the swap output sent directly to the burn address.

Recipient 0x000000000000000000000000000000000000dEaD · policy sha256

Gas reserve
0.002 ETHkept in the wallet so the next cycle can always pay for gas
Minimum buyback
0.005 ETHbelow this nothing is bought; a tiny swap is mostly gas
Slippage bound
3.00%minOut = quote × (1 − bound); the router reverts below it
Deadline
180 sa signed swap that is not mined in time is void
Router call
swapExactETHForTokensSupportingFeeOnTransferTokens; recipient is the burn address
Conservation
to the weibefore − spent − gas must equal after, or the cycle is not recorded

Burn log

Every cycle, on the record

One row per burn, newest first. Open a row for the quote, the bound, the balances and the block.

Burn cycles with ETH spent, tokens burned, realised slippage, gas and transaction
#WhenSpentBurned vs quoteGasTransaction Details
Loading…

Verify

Check a burn on the chain, not here.

A burn is a normal transaction. On the explorer, the token's Transfer event in that transaction has the burn address as its recipient, and the transaction's value is the ETH spent. Paste a hash to look it up in the ledger and get the explorer link; or check it with the CLI, which reads the receipt from the chain.

No lookup yet. Nothing you paste leaves this page.

Why the swap delivers to the burn address

If tokens landed in the dev wallet first, there would be a moment where they could go somewhere else. Setting the router's recipient to 0x…dEaD removes that moment. The buy and the burn are one atomic transaction.

Why a slippage bound

A swap with no minimum output is an invitation to be sandwiched. The engine quotes first, sets minOut at the quote less 3%, and the router reverts rather than fill below it. A revert costs gas and nothing else.

Why a gas reserve

Spending the wallet to zero would strand the next cycle. A fixed reserve stays behind, and the conservation check confirms gas came out of it, not out of the buyback.

Notes

Things worth knowing before you buy.

What "all creator rewards" means

Everything Pons pays the dev wallet, above a fixed gas reserve, is spent on the token and burned. There is no team allocation from rewards and no second recipient. Gas for the swap comes out of the reserve, which is itself refilled by the next reward.

What is actually live

The engine is real and tested. The token has not launched, so the burns on this page come from an in-memory mock chain with deterministic rewards, and the ledger says so. Once the token, router and dev wallet addresses are configured, the same code runs against Robinhood Chain and the ledger fills with real transaction hashes.

Who holds the key

The dev wallet's key is needed only to sign the swap. The engine reads it from the environment at run time, never from a file in the repository, and checks the signer matches the configured wallet before it will send.

Quiet cycles

If the spendable balance is under the minimum, nothing is bought and the rewards wait for the next cycle. Spending most of a small reward on gas would be a worse outcome than waiting.

When a swap reverts

If the pool moves more than the bound between quote and fill, the router reverts. The ETH stays in the wallet, gas is spent, and the engine reports it rather than retrying blind. The next cycle quotes again.

Risk

This is an experimental token with no promise of value, liquidity, or return, and a real chance of going to zero. A buyback does not change that. Nothing here is financial advice. Read the code before you touch it.

Status

Where the project is

Enginev0.1.0 · 17 tests passing · one runtime dependency (ethers)ok
ChainRobinhood Chain · chain id unsetunset
Tokennot yet deployedunset
Dev walletto be providedunset
Burns0 cycles · mock chainsynthetic
SiteStatic, built from 0000000 on main, todaylive
  1. Engine: plan, execute, conserve; mock chain; test suite
  2. Swap output delivered to the burn address in one transaction
  3. Set Robinhood Chain RPC, chain id, router and WETH from the launch docs
  4. Deploy the token on Pons; set the token and dev wallet addresses
  5. faucet doctor clean, then the first live cycle
  6. Schedule cycles (cron or a Vercel cron hitting a small runner) once rewards flow