A short field note. The Geometric Siphon formalised a capital-flow mechanism that was first noticed by chance in live operations. This note records the first time the mechanism has been built into a production system by someone else, Crossbow Finance, a concentrated-liquidity vault protocol on Robinhood Chain. The focus is the mechanism rather than the protocol. Crossbow is used here as evidence that the siphon is a property of the pool mathematics independent of the instance that first surfaced it.
Disclosure: I hold a position in the XBOW token, obtained in its public launch on Robinhood Chain. I have no paid relationship with the Crossbow team beyond sharing research findings with them.
Where the mechanism came from
The siphon mechanism became apparent when observing a discrepancy in a rebalancer’s books. Every time a concentrated liquidity position was moved from one tick range to another, the tokens returned by the burn did not fit the ratio the new range wanted, and the surplus had to go somewhere. When left in a balance that several positions could draw from, this residual moved between pools.
The Geometric Siphon (April 2026) turned that observation into six theorems and a conjecture.1 The residual is forced by the Uniswap V3 amount equations. It vanishes only when the old and new ranges demand the same token ratio at the current price. Under a shared balance it becomes a transfer channel between positions in independent pools. Same-pool positions sharing a balance converge in value. Without a swap path, a position bleeds geometrically to extinction. The residual grows with displacement from the range midpoint, and on volatile-stable pairs it is directionally asymmetric, with below-range exits retaining less than above-range exits. A 16-test Foundry suite checked all of this against unmodified V3 contracts on Base, and two operational datasets anchored the existence and directional claims.
The siphon mechanism in one paragraph
Recentre a position by burning it at whatever ratio the price drift produced, then mint a balanced position from what is in hand. The scarcer token is the bound and sets the size. The surplus of the other token is the residual. Swap it back and you pay spread and routing at every event. Keep it in a balance that neighbouring positions can draw from, and the surplus released by one pool becomes the input to another pool’s next mint. That last choice is the siphon. Everything in the paper follows from it.
What Crossbow built
Crossbow is a customer facing vault protocol on Robinhood Chain, built by a team I have worked adjacently to since the original paper’s pilot phase.2 Each user gets their own vault and only the vault owner can move principal. An off-chain manager acts as operator and may rebalance, rotate and harvest fees, but only inside bounds enforced on-chain by a verifier library. That is a very different shape from the single-operator book the paper was measured on.
Inside each vault the siphon’s precondition is met exactly. The dust ledger is keyed by portfolio and token, rather than by pool, so a residual released in one pool is visible to every other position in the vault. An absorb path pulls that dust into the next mint and emits an event when it does; the public event reference lists dust absorption as its own event family alongside mint, rebalance and rotation.3 The rebalance sequence in Crossbow’s own whitepaper reads as the paper’s first theorem written as an operating procedure: trigger before the price leaves range, burn at the drifted ratio, mint balanced from the tokens available, park the surplus as dust rather than swapping it, restake. Their phrasing is that skipping the swap is not an optimisation detail but the strategy. The public documentation says the same in two lines: re-centring releases skewed inventory, geometry rather than error, and where a single-pool vault swaps it back through the market and pays impact, the mesh routes it to an adjacent pool that wants it.4
Two further pieces of the paper appear in their code. Exotic dust with no absorbing neighbour is routed toward the most connected token in the vault, which is the Connector Rule. Idle hub dust is held until a neighbouring position can absorb it, and swapped only when the expected yield during the wait is below the cost of the swap, which is the right economics for a manager that retains residuals. The public docs state the same rule as swaps happening only where the cost inequality says they pay.4
The paper gave the mechanism a name and the closed form. The Robinhood Chain deployment is the first time it has been carried to a new chain, a new source of yield and a new custody model by an independent operator.
Considerations for the paper
A mechanism that only works in the system that discovered it is a feature of that system. Between the paper’s setting and Crossbow’s, the following changed:
- Chain and venue. Aerodrome on Base against a set of venues on Robinhood Chain, including tokenised stock pools that earn nothing outside market hours.
- Source of income. The paper’s book was paid in gauge emissions. Most of Crossbow’s yield comes from swap fees on pools with no gauge at all.
- Custody. A single operator against per-user vault clones with an on-chain verifier bounding what the operator may do.
- Cadence and team. Different trigger rules, different rebalance budgets, independent build.
What is present in both is the same residual, the shared ledger and the absorption. That is exactly what one expects if the siphon is a property of the V3 amount equations rather than of any manager built on top of them.
The paper found a crossover in position size relative to pool liquidity, below which a position absorbs dust and above which it donates. Later work showed that crossover falls as more positions share a ledger, and that it has shifted a long way in the 2026 regime. Numbers like these are calibrations separate from the underlying theorems, so Crossbow has to measure its own. Every rebalance it emits records what was burned, what was minted and the new range, and that is all the accounting form of the multi-pool law in Master Equation needs to run on its chain data directly.5
The same ledger, one contract per user
It would be easy to read the per-user vault as a departure from the paper’s setting. It is not. The paper’s production data came from five independent portfolios on one position manager, each with its own dust ledger, so residuals moved between a portfolio’s own positions and never across portfolios. A Crossbow vault is that portfolio ledger given its own contract and its own owner. The isolation between users that the vault model provides is the isolation the paper similarly measured between portfolios.
The per-user deployment already answers the narrower question this note set out to record. The mechanism runs outside the programme, in production and on someone else’s contracts.
References
- Ryan, K. R. The Geometric Siphon: Existence, Equilibrium, and Directional Properties of the Residual in Concentrated Liquidity Portfolios. SSRN Preprint (April 2026). https://dx.doi.org/10.2139/ssrn.6686798
- Crossbow Finance. Product documentation. docs.crossbow.finance (2026). Vault model: https://docs.crossbow.finance/vault/private-vaults and https://docs.crossbow.finance/vault/what-the-agent-can-and-cannot-do. Canonical contract addresses on Robinhood Chain: https://docs.crossbow.finance/reference/contracts/addresses
- Crossbow Finance. Events. Strategy activity table, “Dust absorption / compound: loose balances are folded back into positions.” https://docs.crossbow.finance/reference/contracts/events
- Crossbow Finance. Quantitative approach. Sections “The mesh” and “The cost of moving”. https://docs.crossbow.finance/strategies/quantitative-approach. The whitepaper and the April 2026 scoping note on pooled-vault implications referred to in the body were shared privately and are not published.
- Ryan, K. R. The Hidden Microstructure of Shared Balance Concentrated Liquidity: A Master Equation for the Dust Ledger and Propagation of Chaos. SSRN Preprint (May 2026, revised July 2026). https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6745218. On why a residual-retaining manager removes the main rebalancing cost, see also Local Time Against Deployed Code.