Can one person move the money in Robinhood Chain’s own L1 rollup authority on Robinhood Chain? The authority score is 57 / 100 (moderate): a multisig without a real delay, the band where Bybit, WazirX and Radiant sat when they were drained.
In short. A real, publicly-named 7-of-8 Security Council Safe, plus a Timelock that - corrected in batch 8 - turns out to genuinely gate changes now, just with no separation between who can propose and who can veto.
Exposure, not intent. The score counts what the keys could do, not what their holders will do, and says nothing about the odds of a loss. Re-read it yourself with a public RPC and curl: how.
Try a fix: drag the sliders Open the live dashboard re-read from the chain every 6 hours; this page is the snapshot of the build
| admin key | 78 |
|---|---|
| multisig | 75 |
| timelock | 10 |
| price feed | 100 |
| shared control | 100 |
Composite = 40% admin key + 30% multisig + 30% timelock, rounded. Price feed and shared control are read and shown, not folded in.
To move the money: keys and hours to react not read for this contract (never shown as zero).
A real, publicly-named 7-of-8 Security Council Safe, plus a Timelock that - corrected in batch 8 - turns out to genuinely gate changes now, just with no separation between who can propose and who can veto.
every dApp above inherits this
Six core L1 contracts on Ethereum mainnet (Rollup, SequencerInbox, CoreProxyAdmin, DelayedInbox, Bridge, Outbox - not the L2 itself) share one authority chain. EXECUTOR_ROLE is held directly by a 7-of-8 Gnosis Safe named by Robinhood’s own governance docs: Robinhood (2 seats), BitGo, Chainlink Labs, Fireblocks, Offchain Labs, Paxos and Talos - though no public source maps a specific address to a specific institution. A second EXECUTOR_ROLE holder is a real, correctly-configured 7-day TimelockController. Batch 8 found and fixed a real bug here: this scorer had a hardcoded note from batch 4 claiming zero PROPOSER_ROLE holders, silently asserted as current fact on every push since - a live replay now shows a real holder (a 6-of-8 Safe), so the timelock does gate something today. But that same Safe also holds CANCELLER_ROLE - whoever can propose a change can also cancel any attempt to veto it, so there’s still no real separation of powers. This group's 14 root signers (7 direct Safe seats + 7 owners of one nested 3-of-7 seat) share none with any other tracked group (crossExposureScore: 100).
Exit window: a delay with a bypass, or one not ruled out, the time a user has to leave after a harmful change is queued.
If a market used the example policy today (src/ExampleConsumer.sol: revert when stale, 0 under 60, 50% to 80% above): collateral factor 0 (score 57 is under MIN_SAFE_SCORE 60). Cheapest path to decent (60): admin key from 78 to 85, that is a stronger admin setup (admin power spread beyond one key, or checked by others), every other axis unchanged. This is the smallest step into the next band, not a fix for the weakness: the first requirement not met is A confirmed delay before changes apply, no bypass (changes can apply with no waiting time).
[](https://realspap.github.io/oracle/p/robinhood-0x23a19d23e89166adedbdcb432518ab01e4272d94.html)
A live badge: the score is read from the published watch files every time the page that shows it loads. Change nothing but your own repository.
Not assessed for this contract: how many keys it takes to move it; the time anyone has to react; the money behind one key (no money figure, or no key count).
Money behind it: $1.0B (DefiLlama, the whole chain), of which $446M sits exposed to this setup (TVL × (100 − score) / 100, a weight, not a prediction).
Contract: 0x23a19d23e89166adedbdcb432518ab01e4272d94 on the explorer ↗. Score pushed on-chain on 2026-10-13; stale on the oracle when older than 9 days (the watch re-reads it anyway). Read the score yourself: getScore(0x23a19d23e89166adedbdcb432518ab01e4272d94) on the Robinhood Chain oracle, listed in the repository.
Read at block 136039274, methodology 0x667dc486af9557a8…. The score reads the authority path (keys, multisigs, timelocks, roles, price feeds); it does not audit the code for bugs, and it measures exposure, not the chance of being hit (see the backtest in the repository). Dispute this score with evidence, or read this page as JSON.
Independent read of the admin: not possible here (no code at this address on the chain's mainnet: a derived identifier for a native (non-EVM) entity such as HyperCore, or a contract that lives on another chain (a rollup's own L1 contracts); nothing for this reader to compare here). (scripts/second_opinion.py: a reader that shares nothing with the scorer, re-run every 6 hours)
Score unchanged since its publication on 2026-10-13; every later move will be a line of the hash-chained log. Methodology changed on 2026-10-13: points before that date come from another method and are not comparable.
Follow this contract: Atom feed of its score moves, alerts and queued operations (nothing else).
curl -s -X POST https://rpc.testnet.chain.robinhood.com/rpc -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9BF45734D09bC7CA39238e767B2af9AAc62a7f52","data":"0xd47875d000000000000000000000000023a19d23e89166adedbdcb432518ab01e4272d94"},"latest"]}'The 6th 32-byte word of the answer is the composite score (57 = 0x39); the 7th is the push timestamp. This RPC cannot replay the block of the build (it ignores the block tag, or no longer serves old state), so the value is the current one: compare the composite and the push timestamp with this page.