Specimen 05 · Fees to holders · 88% graduate
One inflow, three exits, forward only.
Fees to holders graduates at 88%, burn at 67%, permanent liquidity underwrites both. Split runs all three off one router, with the weights voted, bounded, and impossible to apply backwards.
The split is normally a number one wallet can change.
Three of the best-converting mechanics on the board are the same transaction seen from different angles: route fees to holders, mint permanent liquidity, burn supply. Fee routing graduates at 88%, burn at 67%.
The reason projects rarely run all three is that the split between them is a deployer parameter, and a deployer parameter is a thing that gets moved at the worst possible moment. Usually toward the deployer.
Split makes the ratio a governed number with hard bounds. Every leg sits between 20% and 60%, so no leg can ever be starved or made everything. Weights are voted per epoch, and a passed vote applies from the next epoch — it can never reach back and re-route fees that already settled.
The router
One entry point, three exits, and a boundary that votes cannot cross.
Holders
Routed in USDG and accrued per share, continuously. No snapshot and no distribution transaction to time.
Liquidity
Paired and added as LP, and the LP tokens are burned on receipt. The depth is permanent because nobody holds the position.
Burn
Supply is destroyed at the point of receipt. It is not sent to a dead address to be counted twice; it is gone from the total.
The epoch line
Weights are voted inside the bound and take effect at the next epoch boundary. Fees already routed are final.
Four steps, in this order, every time
A fee lands on the router
One entry point. Nothing else in the system receives fees.
Current weights apply
The weights in force for this epoch, not the ones being voted on.
Three legs settle
USDG to holders, LP minted and burned, supply destroyed. Same transaction.
The next epoch may differ
A passed vote changes the weights from the boundary onward, never before it.
Where a year of fees actually goes
A worked example on the router weights. Volume here is your input, not measured.
The whole mechanism, one step at a time
It plays on a loop. Click a dot to jump to a step, or pause it and read.
Split settles on Robinhood Chain.
Split runs on the USDG-native L2, an Arbitrum Orbit rollup, chain id 4663, fully EVM. All three legs settle inside one transaction, so there is no window where a fee is in flight and unaccounted for.
The router, in motion
A live render of the mechanism, drawn in the browser at sixty frames a second. Nothing is pre-recorded and nothing is loaded from anywhere.
What this actually runs on
Three pieces, and none of them are ours: the rollup, the unit it settles in, and the venue the liquidity sits in.
Robinhood Chain
An Arbitrum Orbit rollup, chain id 4663, EVM equivalent throughout. Testnet is 46646 and runs the same bytecode.
USDG, natively
The chain settles and charges gas in USDG, eighteen decimals. Nothing here has to be wrapped on the way in or out.
Uniswap v4 pools
Liquidity lives in ordinary v4 pools on the same chain, so any router, wallet or explorer can read the market without a special integration.
The values you need before you point a wallet at it
Click any value to copy it. These are the live Robinhood Chain values, not placeholders.
Ordinary machinery, unusual wiring
Nothing exotic holds this together. The interesting part is the rule, not the infrastructure under it.
Three, always
Holders, liquidity, burn. No leg can be switched off, only turned down to 20%.
20% to 60%
Checked on the vote and again on execution. A passing vote outside the bound reverts.
Forward only
A change applies from the next boundary. Settled fees are never re-routed.
LP burned on receipt
Nobody holds the position, so nobody can pull it.
Destroyed, not parked
Supply leaves the total. It is not sent to a dead address and still counted.
Robinhood Chain
USDG-native Arbitrum Orbit rollup, chain id 4663, EVM equivalent.
Six things that stay true at every setting
Properties of how this is built, including the inconvenient ones.
No leg goes below 20% or above 60%
Enforced in the contract on both the vote and the execution.
Weights are forward-only
A vote cannot re-route a fee that has already settled. There is no retroactive path.
The three legs sum to 100%
Nothing is held back in a treasury on the way through. The router keeps nothing.
Burned LP has no owner
There is no address that can withdraw the liquidity, including a governance address.
Burned supply is gone
Total supply falls. It is not a transfer to a wallet nobody watches.
The router has no other exit
There is no fourth path out of it. Three legs is the whole surface.
What the token does, and what it does not
- It votes the three weights inside the bound and accrues the holders' leg in USDG.
- It is not a treasury claim, not collateral, and not a promise about the burn rate.
- The ticker has not been announced. Nothing trading under a Split name is this.
It is a claim, not collateral
Nothing in this system is written against the token, and no position anywhere depends on its price. That is deliberate: a token that backstops the mechanism fails exactly when the mechanism is needed.
Contract address
Nothing is deployed. There is no address to copy, and any address circulating under this name today is not ours. When it exists it is published here first.
Four phases, no dates
Each phase ships when the one before it has been live long enough to be boring.
Distribution
- Fair launch, no presale
- Router contract published
- Bound written into the contract
- Testnet epochs running
Live router
- Mainnet fees through all three legs
- Public per-leg history
- First epoch vote
- Burn and LP receipts on chain
Depth
- Per-epoch turnout floor
- Holder proposals, not just votes
- Leg-level analytics
- Second fee source
Openness
- Any contract can route in
- Full parameter governance
- Bound tightened by vote only
- Contracts frozen
The ones people actually ask
Including the ones with answers you may not like.
Why bound the weights at all?
Because an unbounded vote is a governance attack waiting for enough turnout. A holders leg of 100% starves the liquidity that makes the token tradable, and a burn leg of 100% pays nobody. The bound makes the worst outcome boring.
Can a vote redirect fees that already went out?
No. Weights apply from the next epoch boundary and the contract has no path to re-route a settled fee.
Where does the liquidity go?
It is paired, added, and the LP tokens are burned in the same transaction. Nobody holds them, so nobody can remove them — including whoever holds the most tokens.
Is the burn real?
Supply is destroyed and total supply falls. It is not a transfer to a dead address that still shows in the supply figure.
Is there a contract address yet?
No. Nothing is deployed. The address goes here first when it is.
Where do 88% and 67% come from?
The Pons specimen sample of 954 tokens: 8 described fee routing (88% graduated) and 15 described burn or deflation (67%). They describe the categories, not this project.
Three mechanics, one transaction, no discretionary wallet.
Leave an address and you get the router contract, the bound, and the first epoch schedule.
This is a design mockup. The form does not submit anywhere.