What we measured on Robinhood Chain
These figures come from our own sampling of the chain on 14 September 2026 using the public RPC endpoint, not from a third party.
| Measurement | Value |
|---|---|
| Block time | About 0.10 seconds over 100 consecutive blocks |
| ERC-20 Transfer logs in a 400 block window | 7,872, roughly 200 per second |
| Distinct addresses touched in that window | 1,980 |
| v4 PoolManager | Single contract, the busiest venue in the sample |
| v3 pools seen | 97 distinct pools |
| v2 style pairs seen | 21 distinct pairs |
The concentration matters. On chains where liquidity is spread across dozens of factories, a copy engine has to keep an integration list. Here, one contract carries the majority of the interesting flow, which is convenient right up to the moment you try to read a trader out of it.
The singleton design, in one paragraph
Where v2 and v3 deploy a separate contract per pair or per fee tier, v4 keeps every pool inside one PoolManager contract. Pools are identified by a key rather than by an address, liquidity changes are ModifyLiquidity events, and swaps are Swap events emitted by that single contract. It is cheaper to deploy and cheaper to route through, and it changes what an observer sees: pool identity moves from the log address into the log topics.
Why the swap event names a router
In v4 the account that calls the PoolManager is normally a router contract, because routing, permit handling and multi-hop execution live outside the core. The Swap event therefore records the router as the sender. On Robinhood Chain the routers we identified in our sample include the Universal Router at 0x8876789976decbfcbbbe364623c63652db8c0904 with its execute selector 0x3593564c, and the v3 SwapRouter at 0xcaf681a66d020601342297493863e78c959e5cb2 with exactInputSingle.
The second layer of the problem is account abstraction. The ERC-4337 EntryPoint at 0x4337084d9e255ff0702461cf8895ce9e3b5ff108 sees steady use on this chain, which means the transaction sender can be a bundler shared by many unrelated users. Reading tx.from gives you the bundler, and reading the swap event gives you the router. Neither is the wallet you wanted to follow.
Detecting a v4 trade by reading the wallet
The primitive is the ERC-20 Transfer log with the followed address as an indexed topic. Two filters cover both directions.
- Buys: Transfer logs where the third topic, the recipient, is the leader address. Tokens arriving at the wallet.
- Sells: Transfer logs where the second topic, the sender, is the leader address. Tokens leaving the wallet.
- Many leaders at once: a topic OR list packs every followed address into the same filter, so 200 wallets cost the same two calls per poll as one wallet.
Size is the one thing transfer logs do not give you. In our measurements the buys were paid in native ETH rather than a wrapped token, so the amount comes from the transaction itself, which is one extra read per candidate rather than per wallet.
Hooks, and what they change about a copy
Hooks are contracts attached to a pool that run at defined points: before or after a swap, before or after a liquidity change. They are what makes v4 flexible, and they are also why two v4 pools can behave completely differently.
| Hook behaviour | Effect on a copied trade |
|---|---|
| Dynamic fees | Your copy can pay a different fee from the leader's trade seconds earlier |
| Custom curves | Price impact does not follow the constant-product intuition |
| Limits or gating | A copy can revert for reasons unrelated to slippage |
| Fee routing to third parties | Part of every trade leaves the pool, raising the break-even move |
The practical response is not to model hooks. It is to keep a slippage ceiling and treat reverts as information: a pool that rejects your copy for non-obvious reasons is a pool to skip, and the rejection log is where that pattern becomes visible.
Slippage, flash accounting and why reverts are cheap
v4 settles balances at the end of a transaction rather than moving tokens at each step, which makes multi-hop routes cheaper and makes a failed route fail as a unit. For a copier this is mildly good news: a copy that would have executed at an unacceptable price reverts rather than filling badly, provided you set the ceiling.
The corollary is that chasing is expensive. Raising the slippage ceiling until copies always fill converts every bad fill into a real loss, which is the most common self-inflicted wound in copy trading.
Settings for v4 heavy wallet lists
| Setting | Starting point | Reason |
|---|---|---|
| Buy slippage | Firm, reject rather than chase | Flash accounting makes a revert cheap and a bad fill permanent |
| Maximum trade age | Short | Ten blocks per second means price moves while you decide |
| Minimum pool size | On | Hook-driven pools can be thin in the range that matters |
| Size rule | Fixed or percent of theirs | Both work once slippage is bounded |
| Exit mode | Mirror, partial mirroring on | The leader is in the same pool with the same hooks |
| Contract filters | All on | Hooks and taxes are different problems with the same symptom |
Copying a wallet that trades v4 pools
- 01Follow the wallet, not the poolPool identity in v4 lives in topics rather than addresses, and routers hide the trader. Address-level detection is the only stable approach.
- 02Set the slippage ceiling before anything elseDecide the worst price you will accept and let copies revert above it.
- 03Keep the trade age shortAt ten blocks per second, a candidate that is a minute old belongs to a different market.
- 04Use a minimum pool sizeA hook-driven pool can look deep in total and be thin where the trade needs depth.
- 05Mirror exits with partial mirroringTrims are common in v4 pools with dynamic fees, so copy a trim as a trim.
- 06Read the rejection log for revert patternsRepeated reverts on one token usually mean a hook you do not want to trade against.
Questions people actually ask
Why can a bot not identify the trader from a Uniswap v4 swap event?
Because the account that calls the PoolManager is normally a router, so the event records the router as the sender. On Robinhood Chain that is often the Universal Router or the v3 SwapRouter. Account abstraction compounds it: with ERC-4337 in common use, the transaction sender can be a shared bundler rather than the trader.
What is the v4 PoolManager address on Robinhood Chain?
We observed 0x8366a39cc670b4001a1121b8f6a443a643e40951, with Swap logs under topic 0x40e9cecb... and liquidity changes under ModifyLiquidity topic 0xf208f491.... It was the busiest venue in our log sample on 14 September 2026.
How many RPC calls does it take to watch many wallets?
Two per poll, regardless of how many wallets you follow, because a topic OR list packs every followed address into one filter for incoming transfers and one for outgoing. Trade size needs one extra read per candidate, since in our measurements buys were paid in native ETH rather than a wrapped token.
Do hooks make v4 pools unsafe to copy into?
They make pools non-uniform. A hook can change fees dynamically, alter the curve, gate trades or route part of every trade elsewhere, so two v4 pools are not interchangeable. Rather than modelling hooks, keep a slippage ceiling, use a pool depth floor and treat repeated reverts on a token as a reason to skip it.
Is it better to copy v4, v3 or v2 pools?
v2 style pairs are the most predictable, v3 depends on the active liquidity band, and v4 is the busiest and the most variable because of hooks. A copy engine should not choose: detection that reads the wallet works across all three, and the differences are handled with slippage and depth settings rather than with separate integrations.
Does flash accounting help or hurt a copier?
Mildly helps. Because balances settle at the end of the transaction, a route that cannot fill within your limits reverts as a unit instead of filling badly, so a firm slippage ceiling is genuinely protective. The mistake is loosening that ceiling until every copy fills.
Figures that move are quoted with the date they were measured. Pons Copy Trading does not publish numbers it cannot point at a source for.