Reading the depth before the trade

Abstract

Robinhood Chain (chain ID 4663) hosts tokenized equities — NVDA, AAPL, TSLA and others — trading as ERC-20s against WETH and USDG in Uniswap-style pools. Because anyone can create a pool, being listed and quotable says nothing about being tradable.

The failure mode is specific and expensive: a pool will sell you a token and then have nothing on the other side when you want out. You can buy. You cannot sell. Every router in the ecosystem will still quote you into it, because a router answers what do I get for this ETH — not can I get this ETH back.

SentryRWA answers the second question before it spends. Every catalog token is scanned for real pool depth in ETH, for the price impact of a realistic order, and — the part that matters — for whether a reverse quote clears a recovery floor. Tokens are graded deep, thin, or no exit, and the grade is refusable: a pool that cannot be exited is marked no-exit no matter how much depth it shows.

Alongside it sits an optional non-custodial reserve. It holds your ETH under spend limits you set yourself, enforced on-chain, and it has no function that can pay anyone but the wallet that signs the withdrawal.

Listed is not liquid

A buy quote is evidence of exactly one thing: somebody is willing to sell you the token at that price. It is not evidence that anybody will buy it back.

This is not a theoretical concern on 4663. In a routine census of the catalog we find pools with a working buy path and no viable return path at all — tokens that quote a purchase and then fail every attempt to price the reverse. They appear in wallets, in explorers and in aggregator interfaces exactly like a healthy asset does.

Why the usual tooling misses it

• Aggregators optimise the leg you asked for. Ask for a buy and you get the best buy. Nothing in that answer inspects the sell side, because you did not ask about it.
• Depth is reported per pair, not per route. A token routed through USDG can look adequately deep on its own hop while the hop behind it is nearly empty. The binding constraint is the thinnest leg, not the advertised one.
• Price-impact fields are inconsistent. Different sources report impact in different units and scales; a figure taken at face value can be off by two orders of magnitude. We derive impact ourselves from the pool rather than trusting a provider field.
• Nothing surfaces “you can enter but not leave”. There is no standard field for it, so no standard interface shows it.

The result is a market where the most dangerous positions look identical to the safest ones right up until you try to close them.

Depth scan

The useful question about a pool is not whether it has liquidity but how much, and how much of it survives the route you would actually trade through. SentryRWA measures that against every catalog pool at a fixed probe size, so results are comparable across tokens and over time.

Depth is measured along the whole resolved route, not just the headline pair, so a shallow second hop cannot hide behind a deep first one. Impact is computed by quoting a probe one hundredth of the size, extrapolating it linearly, and comparing that against the real quote — the gap is the impact the pool actually imposes.

Equities carry a lower depth floor than general tokens. Tokenized stock pools on this chain are genuinely thinner by nature, and holding them to the same absolute floor would mark the entire asset class untradable without saying anything useful.

Grading order

The verdict is decided in sequence and stops at the first failure. Order matters: sellability is checked before depth, so a pool cannot buy its way to a passing grade with depth alone.

Depth scans are recomputed on a schedule and stored, so the catalog loads without hammering the chain. Selecting a token re-scans it live, and the interface always shows how old a stored reading is. When a read fails we say so — a throttled provider is reported as rate limiting, never as an absent pool.

The exit check

This is the part that distinguishes SentryRWA from a price feed, and it is deliberately simple.

Quote the probe forward: 0.005 ETH → token. Take the exact token amount that returns, and quote it back: token → ETH. The ratio of what comes back to what went in is the round-trip recovery. It must be at least 70%.

The floor is not 100% because a legitimate thin pool cannot return 100%. Two sets of swap fees and impact in both directions genuinely cost something. Below roughly seventy percent, though, you are not paying a spread — the pool is not a market you can leave.

A failed exit check overrides everything else. Depth, volume and a tidy buy quote do not redeem it, because none of them are the property you need. This is also what catches fee-on-transfer traps and honeypots without needing to special-case them: a contract that taxes or blocks the sell path fails the reverse quote by construction.

The result is stated plainly wherever it is shown — the recovery floor it cleared, or the reason it did not — and choosing a no-exit token in the reserve requires an explicit acknowledgement before the swap button will do anything.

Architecture

The reserve is built on a single contract, PolicyExecutor, live on chain 4663:

Custody

The contract keeps a per-user ledger of ETH and ERC-20 balances. Deposits credit msg.sender. Both exit functions — withdraw(amount) and withdrawToken(token, amount) — debit msg.sender and transfer to msg.sender.

Neither takes a recipient argument. There is no administrative sweep, no rescue function, no owner path and no agent path to user funds. The absence is the guarantee: funds can only move to the wallet that signed for them because the contract has no code that could send them anywhere else.

Spend limits

Each reserve carries a per-trade ceiling and a daily ceiling, both set by the account holder through setMyLimits. No owner or agent function can change them. The first deposit writes defaults of 0.05 ETH per swap and 0.2 ETH per day; the daily counter rolls over at 00:00 UTC.

Every spending path runs the same gate before any external call: agent not halted, target on the allowlist, value within the per-transaction cap, value within the remaining daily budget, and balance sufficient. Any user can halt the agent on their own reserve instantly, without asking anyone.

Slippage enforced by the contract

executeSwap takes an explicit minAmountOut and measures the contract’s own balance before and after the router call. If the delta falls short it reverts.

This matters because a router’s internal amountOutMinimum lives inside calldata, and calldata is built by whoever submits the trade. If that party were compromised it could set the router’s minimum to a single wei and swap a reserve into worthless dust. The contract-level bound is measured from state the caller does not control. The sell paths and the reserve-deposit paths carry the same kind of floor.

Allowlist and timelock

Calls are only permitted to explicitly allowlisted targets: the Uniswap V3 and V2 routers, the Universal Router, Permit2 and WETH. Custodied ERC-20s are deliberately excluded — allowlisting a token the contract holds would let anyone call transfer through it and drain the pooled balance.

Changing the executor, the target allowlist or the reserve allowlist is a two-step operation with a one-day delay between queueing and execution, so users have notice and time to withdraw.

The agent

Swaps are submitted by a server-side key — both the ones you press a button for and the ones the agent fires on a mandate. What it can do is bounded by the contract: call allowlisted routers, within your caps, with a minimum output it cannot weaken. What it cannot do is withdraw anything, alter your caps, unpause your reserve, or reach any address outside the allowlist.

Trust model

A security claim is only worth what enforces it. Here is the split, stated without flattery.

Enforced on-chain

• Withdrawals reach only the signing wallet.
• A per-trade and per-day ceiling, set solely by you.
• The target allowlist.
• Minimum output on every swap, sell and reserve deposit.
• Your own pause switch.
• A one-day delay on agent and allowlist changes.

Not enforced on-chain

• The agent key is held on a server. If it were stolen, the holder could trade your reserve balance through allowlisted routers up to your daily cap. They could not withdraw, and the on-chain minimum output stops a swap into dust — but repeated churn would still cost you fees and spread. Your daily cap is the real ceiling on that loss, which is why the interface argues for keeping it small.
• Depth scans are computed off-chain from on-chain reads. A stored grade can be stale; the age is always displayed and the detail panel re-scans live.
• Route discovery may consult an external quote service. If it is wrong or unavailable, a trade fails or is graded unavailable — it does not silently degrade into a worse trade.
• Ownership is a single key today. The owner cannot touch user funds, but can change the agent and the allowlist. The delay that governs those changes can itself be reduced by the owner without notice — a deliberate escape hatch for rotating a compromised agent quickly, and a real concentration of authority you should price in.
• The contracts are unaudited. They carry tests and have been reasoned about carefully. That is not the same as review by an independent security firm, and we will not pretend otherwise.

The honest summary: the reserve protects you from us taking your money, and bounds what a compromised server can cost you. It does not make a bad trade good, and it is not a substitute for keeping exposure small while the system is young.

Roadmap

SentryRWA goes out in stages. Each is usable on its own, and nothing that works today is gated behind what comes next. There are no dates here because we do not have honest ones.

No token

SentryRWA has not issued a token. There is no ticker, no contract address, no sale, no allocation round, no airdrop and no presale. Nothing in this project is gated on holding anything.

This section exists because its absence would be read as an omission rather than an answer. If a token ever exists, it will be described here, at this address, with its contract address printed in full — and until that happens, any contract, ticker, sale or allocation presented as ours is not ours. We will never send you an address.

One address appears in this paper: the PolicyExecutor in §05. It is the only contract that ever holds your funds. Verify it against this page before you deposit.

Disclaimers

• Not financial advice. SentryRWA reports measurements of on-chain state. A grade of deep is not a recommendation, and nothing here is a solicitation to trade any asset.
• Independent project. SentryRWA is not affiliated with, endorsed by, or connected to Robinhood Markets, Inc. or any of its subsidiaries. “Robinhood Chain” is used only as the name of the network.
• Data is presented as found. Readings come from public chain state and can be stale, throttled or unavailable. Where a value cannot be read, the interface says so rather than substituting a placeholder.
• Unaudited software. The contracts have not been audited by an independent security firm. Deposit only what you can afford to lose entirely.
• Depth scans are heuristics. They are computed at a fixed probe size against pools that change block to block. A passing grade reduces a specific, well-defined risk; it does not eliminate market, smart-contract or counterparty risk.
• There is no token. SentryRWA has issued none, and nothing described in this paper depends on one. Any contract or sale presented as ours is not ours. See §08.