Can one person move the money in Radiant Capital LendingPool (V2 Core) on Arbitrum? The authority score is 55 / 100 (moderate): a multisig without a real delay, the band where Bybit, WazirX and Radiant sat when they were drained.
In short. The pool’s token-upgrade and reserve-configuration path is gated by getPoolAdmin(), a 4-of-11 Gnosis Safe with no delay in front of it, not by the 72-hour TimelockController that owns the PoolAddressesProvider. This is the protocol that lost ~$50M on 2024-10-16 to compromised multisig-signer devices, a failure mode a timelock does not defend against.
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 | 65 |
|---|---|
| multisig | 95 |
| timelock | 0 |
| price feed | 52 |
| 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 not read, 72 h to react.
The pool’s token-upgrade and reserve-configuration path is gated by getPoolAdmin(), a 4-of-11 Gnosis Safe with no delay in front of it, not by the 72-hour TimelockController that owns the PoolAddressesProvider. This is the protocol that lost ~$50M on 2024-10-16 to compromised multisig-signer devices, a failure mode a timelock does not defend against.
pool-admin Safe bypasses the 72h timelock
Pushed on-chain 2026-09-20 (Arbitrum Sepolia block 310697409; previously 55 / 100 / 55 with composite 69): PoolAddressesProvider.owner() is a real 72-hour TimelockController (getMinDelay 259,200s), but getPoolAdmin() is a different address, a 4-of-11 Safe, and that Safe alone gates the LendingPoolConfigurator’s onlyPoolAdmin functions: updateAToken and the two debt-token upgrades (which upgrade the token proxies), freezeReserve, setReserveFactor, caps, the interest-rate strategy and batchInitReserve. A 2026-09-20 eth_call simulation, not re-run by the scorer, passed from that Safe and reverted CALLER_NOT_POOL_ADMIN from the timelock. The Safe also holds PROPOSER and CANCELLER on the timelock and 6 of its 11 owners hold EXECUTOR, so the delay still covers the provider-level owner functions but not the token-upgrade path. It is therefore scored as a Safe with no timelock: admin key 65 (threshold of 3 or more), multisig 95 (4 × 15 + 7 × 5, capped at 100), timelock 0, composite 55; an unread pool admin or provider owner degrades to 20 / 0 / 0. getEmergencyAdmin() is a separate 1-of-5 Safe whose five owners are all owners of the 4-of-11; it can only pause, so it is disclosed and not scored. Cross-exposure stays 100 on a dated check of the pool-admin and emergency-admin Safes against the 70 root-signer groups tracked across 7 ecosystems, which found no overlap (found none, not proof that none exists). The 2024-10-16 exploit (corroborated by DefiLlama’s hacks dataset and Radiant’s own remediation docs) compromised the SIGNERS themselves via blind-signing, not the timelock mechanism, so the delay would not have stopped it. This project scores the current authority mechanism, not historical incidents against it, but discloses the context since it bears directly on how much trust to place in the admin-key dimension here.
Exit window: none: a change applies at once, 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 55 is under MIN_SAFE_SCORE 60). Cheapest path to decent (60): admin key from 65 to 78, 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/arbitrum-0xe23b4ae3624fb6f7cdef29bc8ead912f1ede6886.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 money behind one key (no money figure, or no key count).
Money behind it: $183k (DefiLlama), of which $82k sits exposed to this setup (TVL × (100 − score) / 100, a weight, not a prediction).
Contract: 0xe23b4ae3624fb6f7cdef29bc8ead912f1ede6886 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(0xe23b4ae3624fb6f7cdef29bc8ead912f1ede6886) on the Arbitrum oracle, listed in the repository.
Read at block 319507783, methodology 0x51163f3cce461201…. 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.
Read live: admin: a timelock behind a bare contract; delay: 72 h on the timelock.
Independent read of the admin: a contract 0x454a8daf…160a via admin fixed in the proxy's bytecode (transparent proxy) -> owner() of the holder (timelock 259200s), disagrees with the published score: the timelock score says no delay (0), the holder's owner is a timelock of 72 h. Unchanged since 2026-10-10. Behind the holder, its owner() is a timelock of 72 h: that is the hand. Implementation behind the proxy: 0x36fd2506dd9666a2a659c9061952e548cd8a8e75 (EIP-1967 implementation slot). Its source is verified on Sourcify (LendingPool, match, 0.8.12+commit.f00d7308). (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.
# the implementation slot of the proxy (EIP-1967): the code behind it, an upgrade changes this word
curl -s -X POST https://arb1.arbitrum.io/rpc -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_getStorageAt","params":["0xe23b4ae3624fb6f7cdef29bc8ead912f1ede6886","0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc","latest"]}'Each answer is a 32-byte word (an address sits in its last 20 bytes); the admin path is the one scripts/second_opinion.py reports for this contract. read between blocks 515148086 and 515148107 of the chain; this RPC cannot replay the block of the read (it ignores the block tag, or no longer serves old state): the answers are the current ones
Follow this contract: Atom feed of its score moves, alerts and queued operations (nothing else).
curl -s -X POST https://sepolia-rollup.arbitrum.io/rpc -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x50840a7667baEa9D05ad4ae3dCeb384724b58720","data":"0xd47875d0000000000000000000000000e23b4ae3624fb6f7cdef29bc8ead912f1ede6886"},"latest"]}'The 6th 32-byte word of the answer is the composite score (55 = 0x37); 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.