How Agio works

The route, the guarantee, and where every percent of a trade goes.

The two-layer route

A token launched through Agio gets its own router contract, deployed with the token and installed as its creator-fee recipient on Pons. Fees accrue in the Pons escrow until someone calls poke() on the router. That call is permissionless — anyone may make it, so the route does not depend on the creator staying interested. It pays no bounty: the router can pay the caller a fixed percentage of the claim, taken off the top before anything else — a share of the money, not a refund of the gas, because nothing in the contract measures gas — and Agio sets that percentage to zero, so every figure on the review screen is the figure the creator gets. The router then splits the claim through two layers.

Layer 1 divides the stream into buckets, each with one target asset. A bucket whose target is not the asset the fees arrived in converts its share first, so a route can say “half of this becomes the launch token, half stays in the quote asset”. Layer 2 splits each bucket among its sinks — a wallet, a vesting contract, or a burn that calls the token’s own burn and checks total supply actually fell — each of which must be a contract the sink registry has approved. Every share is a basis-point weight, and a weight is either a fixed number or a schedule that moves between two values across a window.

Each sink is also asked, once, in the router’s constructor, whether it will take the asset the bucket pays in. A sink that says no stops the deployment rather than failing later, which matters most for a burn: a burn that reverted at payout time would park the slice and, after the rescue delay, pay it to the creator — the exact inversion of what the row promised. So a burn bucket has to pay in the launch token, and a route that says otherwise never exists.

Ether is an asset here, not an exception

The chain’s own ether is the asset most Pons tokens are paired against, and the router handles it as a first-class currency rather than through a wrapper. The contracts write it as address zero: a launch quoted in it, a bucket that pays out in it, and the claim that fetches it are all the same calls with that address. The Pons escrow keeps ether on a ledger of its own, so the router claims it with a different call and measures its own balance to know what arrived; a slice is paid as value, and a sink is paid and instructed in one call rather than two.

The one place the wrapper appears is the swap boundary. The adapter that reaches Uniswap takes ERC-20s, so a slice of ether is dressed as wrapped ether to cross it and undressed on the way back. That is plumbing, not a choice a creator makes — the wrapped token is not a pairing Pons approves, and it is not in the picker. It has one visible consequence: a bucket that names the wrapper on an ether-quoted route, or the reverse, is a wrap rather than a trade. It touches no pool, has no price, and comes out at exactly what went in.

Ether cannot be burned, and that is the single thing it cannot do. There is no burn function on it and sending it to a dead address does not reduce anything, so a burn bucket paying in ether is refused when the route is built rather than quietly turned into a donation to an unspendable account.

Who may convert, and why that is a question at all

A conversion needs a minimum acceptable output, or the swap can be sandwiched. Robinhood Chain cannot supply one: the Uniswap v4 pools Pons graduates into keep no price history, a pool’s hook is part of its immutable identity and the Pons hook records none, and there is no working oracle. A price read in the same transaction as the swap is a price the swap’s own caller can move, so a floor derived from it binds nothing.

So the router takes the floor from whoever calls it, and each route names one immutable converter who is allowed to supply it — or the all-ones address, which means anyone may price a conversion and nobody may ever name the pools it routes through. The two are not a strict ordering; the next section says why. Claiming and paying stay permissionless forever, because neither involves a price; only conversion is gated, and only per bucket. A converting bucket poked by anyone else parks its slice in the asset it arrived in — and parking is a clock, not a resting place. If nobody ever converts it, the rescue delay runs out and the slice settles to the creator’s payout address rather than to the recipients the bucket names.

The same call also carries the swap path, one per bucket, for a related reason: Uniswap v4 has no factory, no registry and no getPool, so a pool’s key is its identity and nothing on chain can be asked to produce it. Leaving a path empty tells the adapter to derive the pool from Pons’ own launch record — the launch token against the asset it was paired with, which is the only pool that record describes. That is what every route this app builds sends. Supplying a path names the pools explicitly, up to three hops, and it is the only way to reach anything the Pons record does not describe: an equity fee slice on its way to ether, for instance, whose best route is two hops through USDG.

Choosing the all-ones address gives that up, permanently. A router whose converter is the sentinel refuses every non-empty path, from every caller, for the rest of its life — acceptsRouteHints() reads the choice back. The reason is that naming the pool is authority of a different kind from naming the floor. A one-wei floor against a pool the caller does not control still fills at that pool’s price, and capturing the difference means sandwiching the fill with real capital. But v4 pools are permissionless to create, so a caller who may name the key can name one they are the sole LP of, priced to absorb the whole input and pay one wei: every defence still passes and the slice is gone, with no capital at risk. A named converter keeps paths in full, because they could already floor that router’s conversions at one wei and the creator named them before a fee accrued.

The floor is enforced either way, afterwards, against the router’s own balance rather than on the adapter’s word. What that catches is a path that pays less than promised; what it cannot catch is a path that pays exactly the one wei it was asked for. That is why the refusal is a rule about who may route, not a check on the route.

The claim that buys is precise and worth stating precisely: the creator chose who prices these fees. Not that they cannot be mispriced. Naming a converter turns a price problem into an authority problem rather than solving one, and the value is that the authority is named, immutable and readable from the chain before anyone accepts a share of the route. Every token’s viewer prints it beside the address a rescued slice would settle to.

What immutable means here

It means the router has no setters. Not restricted setters, not timelocked setters — none. Every address, weight and schedule is written into the contract at construction. Its ABI has no owner, no admin role, no upgrade path and no function that hands the fee-recipient role on to anyone else; besides poke, all it exposes are the retry and rescue calls that exist to unstick a payout that reverted or a conversion that did not go through, plus an argument-less door that lets it be paid in ether at all. The rescues have one destination and it is not a parameter: the creator’s payout address, fixed at construction, reachable only after the rescue delay has run. That is the single published escape valve, and it is the one way a slice reaches somewhere the route did not name.

So the guarantee is not a promise about our conduct, and it does not rest on trusting the creator either. Neither party can redirect the stream after launch. A route that carries a schedule does change over time, but only along a curve that was published on day one — the schedule itself is as fixed as everything else.

The fee model

Pons charges a base curve fee of 1.00% on every trade and keeps 30.00% of it. The remaining 0.70% of volume is the creator’s, and Pons pays it whatever else happens. On top of that the creator sets their own tax. Agio requires at least 2.00%, because below roughly 1.30% the stream cannot pay both the creator and AGIO one percent of volume. At that minimum the stream is 2.70% of volume.

The router takes its skim first and routes what is left. AGIO’s allocation is a named recipient inside the published route rather than a hidden cut — anyone reading the router can see it — and it is what makes the target of 1.00% of volume add up. The allocation is computed from whatever tax the creator picks, so a higher tax produces a smaller allocation and AGIO still lands on the same number.

What these numbers do not cover

Three caveats, all of them permanent. The keeper bounty is a percentage of the claim taken before anything else — not a gas reimbursement, which the contract has no way to compute — so every figure above is measured before it. Every division in the allocation math floors, which means AGIO can land up to 0.00103% of volume under its target, never over it. And the 1.00% figure is pre-graduation: when a token leaves the bonding curve for a Uniswap v4 pool the fee structure changes, the stream-to-volume ratio moves with it, and the allocation cannot follow, because the route is immutable. That is the price of the guarantee, and stating it is cheaper than someone else discovering it.