Liquidity depth, measured on-chain.

On Robinhood Chain every Pons launch graduates into a Uniswap v4 pool, and every one of those pools reports a TVL. Total value locked was a reasonable proxy for tradeable liquidity when every pool was a constant-product curve. Concentrated liquidity ended that. Liquidity providers now choose the price range their capital covers, and a large share of it can sit well away from the current price, where it earns nothing and absorbs nothing. Two pools with identical TVL can differ by an order of magnitude in how much they can take before slipping one percent.

Routers and market makers already know this because they simulate every trade before sending it. Everyone else — treasuries sizing a rebalance, protocols choosing a collateral pool, traders judging whether an exit is realistic — is still reading TVL. beepbewp is an attempt to replace that number with executable depth, computed from pool state, agreed by independent indexers and written to a feed contract on Robinhood Chain. None of that exists yet; this page describes what is being built and why.

Price oracles answer one question: what is a unit worth right now. They do not say how many units you can move at that price. A lending protocol that liquidates a position into a pool with little 1% depth will not get the oracle price on a large sale; it will get something considerably worse, and the difference is bad debt. A treasury that rebalances into a thin pool pays the same tax.

Depth is the missing half of the oracle problem. It is harder to compute — you need the whole tick map, not a single price — and nobody publishes it in a form a contract can consume. That is the gap beepbewp is designed for, with the same quorum and staking ideas people expect from a price feed.

Every block, each indexer reads the full tick map of every tracked pool: not a sample, not the last snapshot, the whole thing. From the current tick it walks outward in both directions, adding the liquidity in each initialised range and converting it to notional at that range's price, until the cumulative price impact, fee included, reaches the threshold. That gives four numbers per pool per block — down and up at 1%, down and up at 2% — plus the reference price from the deepest stable pools. The result is signed and gossiped; a rotating leader batches the signatures and submits them once a quorum of stake agrees. The loop is designed to run in well under a block on ordinary hardware, which is why a 150-block ceiling on staleness looks achievable without a large operator set.

The intended feed interface is three functions, with no proxy and no admin key. Reading a value should cost one SLOAD group. If your protocol already reads a price oracle, adding a depth check would be a two-line change: fetch the depth for the pool you are about to trade into, and refuse or resize when your order exceeds a fraction of it. The quickstart shows the shape of that call, and the feed contracts page will carry addresses when there are any.

BEEP launched on Pons, the Robinhood Chain launchpad, and graduated into its Uniswap v4 pool from there. It is intended to be the stake behind the indexer set: operators would lock it to join, earn it per accepted report, and lose a slice of it for signing values that disagree with the network. Fixed supply of 100 million, no inflation, intended allocations on the tokenomics page. The contract is at 0x0000000000000000000000000000000000000000 on Robinhood Chain. It does not do anything yet beyond existing.

The preview explorer and this documentation are what exists today. Next comes the reference indexer, then a testnet feed contract, then a small indexer set on Robinhood Chain, then pool proposals. Other chains are ideas, not commitments. The plan, with what has and has not happened, is on the roadmap.