The problem, measured rather than asserted

On Robinhood Chain, tokenized NVDA trades in ten pools. Three v3 books against WETH, two v3 books against USDG, four v4 pools against native ETH. Seven have liquidity. Three are empty.

This is not a theoretical inefficiency. When these docs were written, the price gap between the live ETH-denominated books was 35.6 bps for the same asset, on the same chain, in the same block. And NVDA is the best-supplied asset here. The rest are worse. The board on the front page reads those same pools live, so the number is checkable rather than quoted.

That gap is not lost. It is collected every block by whoever is fastest, and not by whoever provided the depth.

What an AMM does, and its one real weakness

A pool quotes a price it cannot update. It does not know the asset moved somewhere else; it finds out by being taken. Every time a price moves on another venue, someone serves the pool its own stale quote, and the difference comes out of the liquidity providers. That is the one structural cost of providing liquidity, and no fixed fee tier addresses it: a fixed fee charges the passer-by exactly what it charges the arbitrageur.

1 · Vertex prices the asymmetry

A v4 hook that gives the pool a view of the other venues for the same asset, and moves its fee with what the counterparty knows and the pool does not.

• Pool in line with the chain: base fee, 5 bps. The passer-by pays almost nothing.
• Pool has drifted, and the trade closes the gap: that is an arbitrage, and it pays a surcharge proportional to the gap it came to collect.

Direction is the mechanism, not a detail. A trade that widens the gap pays the base fee: it has no informational edge, and it will be arbitraged itself. Only the trade collecting the gap pays for the gap.

fee = max( genesis ramp , base + drift × 25% ) , capped at 2500 bps

2 · Vertex takes none of it

In v4 the dynamic fee a hook returns is the pool's LP fee. It goes to the liquidity. There is no treasury, no collection address and no protocol cut anywhere in this contract, deliberately: the claim being made is that the leak is returned to the LPs, not redirected to a team.

That is what makes the word coordination literal. The pool imposes nothing on the other venues. It agrees with them about a price, and charges the people who profit from the disagreement.

3 · The genesis is an asymmetry like any other

The first 180 seconds of a pool are not a market, they are a race. Whoever lands in the opening block knows the one thing the pool does not: that nobody has quoted yet.

So the same hook applies a launch ramp: 25 % decaying in a straight line to 1 % over 180 seconds, armed by the arrival of the liquidity itself. It is not a second feature; it is the same principle at the one moment the drift cannot be measured, because there is nothing yet to compare against.

The clock starts on the seeder's afterAddLiquidity, and the seeder is the LP manager contract, not the EOA behind it: v4 reports the caller of modifyLiquidity as the sender, so naming the EOA would leave the ramp permanently unarmed and the pool stuck at the opening rate forever.

What the protocol cannot do

• The venue registry is immutable. The reference venues for an asset are fixed at deployment. Nobody can add one, so nobody can manufacture a consensus.
• No lever can go up. MAX_FEE_BPS is a hard cap in code, the ramp only descends, and the owner's single lever is a ceiling that only descends. The rate at deployment is the worst rate the pool will ever charge.
• Coordination can never halt a market. Reading a venue is a bounded staticcall: a venue that reverts, returns the wrong shape, empties out or quotes a price outside the tick range is skipped, and if nothing at all is readable the pool charges its base fee. A broken third-party pool must not be able to stop this one.
• No mint after genesis on $VERTEX, and no owner on the token.

What we assume, said plainly

• The consensus is a liquidity-weighted mean of the readable venues. A venue deep enough to carry weight and crooked enough to lie would skew the surcharge. That is exactly why the registry is immutable and why empty books are dropped.
• The surcharge makes arbitrage more expensive, not impossible — and it must not: an arbitrage that never happens leaves the pool stale, which is the thing this contract exists to prevent. It takes about a quarter of the gap and leaves the rest.
• The reference is the mid of the other venues, not their executable price. On a very thin venue those differ.
• The genesis ramp is spent once. A pool relaunched on the same key no longer has one.
• Only ETH-denominated venues are in scope. The USDG books quote the same assets, but comparing them needs an ETH/USDG price, and importing that would make the contract depend on a second consensus in order to compute the first.

Contracts

• Vertex.sol — bare ERC-20, 1 000 000 000, minted once, no owner.
• VenueRegistry.sol — the immutable venue set; reads v3 pools with slot0() and v4 pools with extsload, and returns one liquidity-weighted mid.
• VertexHook.sol — the dynamic fee: base plus drift surcharge, plus the genesis ramp. Address carries AFTER_ADD_LIQUIDITY | BEFORE_SWAP, low 14 bits 0x0480. No delta bits: the hook never takes a cut of its own.
• VertexLpManager.sol — the single-side launch position, owner-only removal.

Parameters

chain            Robinhood Chain (4663)
supply           1 000 000 000 VERTEX
base fee         5 bps
surcharge        25 % of the measured drift
hard cap         2500 bps
genesis ramp     2500 -> 100 bps over 180 s
registry         immutable, ETH-denominated venues only