The Ronin bridge required five of nine validator signatures to move funds.
In late 2021, during a period of very high transaction volume, Sky Mavis obtained permission to sign on behalf of a validator operated by Axie DAO. A sensible operational decision, taken to keep the network running.
It was meant to be temporary. The permission lapsed in November 2021.
The allowlist entry implementing it was never removed.
In March 2022 an attacker compromised four validators controlled by Sky Mavis. That is four of the five required, and on its own it is not enough.
The fifth signature came from the allowlist entry that had been sitting there, still valid, for four months.
About $625M left on 23 March. It was discovered on 29 March, six days later.
The grant was reasonable when it was made, for a real reason, and it was intended to end. Nothing ended it, because revocation was a manual step that nobody owned and nothing prompted.
The security of the entire bridge came to rest on a configuration entry that had outlived its purpose, and no monitoring anywhere reported on it.
Every course so far has been about you holding keys and you signing things. This one is about everything you have allowed somebody else to do, and the central fact is that you almost certainly cannot list it.
Five channels
Third-party access reaches you through five distinct mechanisms. They look unrelated and they behave identically in the way that matters.
1. Token approvals, on-chain. You authorise a contract to spend a token on your behalf. F105-05 covered these. Unlimited by default in many interfaces, scoped to one token and one spender, and permanent until revoked.
2. API keys, at venues. A credential that acts on your exchange account without going through the login. F109-02 is the whole lesson and the course autopsy.
3. Sessions and connections. A wallet connected to a site, a browser logged into an exchange, an application holding a token that represents you. F109-03.
4. OAuth and account linking. Sign in with a provider, an application granted access to your email or your files, a bot in a server you administer.
5. Smart-account delegation. Code that acts as your account, per F103-04 and F103-05. F109-04.
The property they share
Access, once granted, persists.
Not for a session. Not for a task. Until something removes it, and in almost every case the only thing that will is you, deliberately, later, having remembered.
Almost nothing you authorise expires on its own. A token approval from a protocol that shut down in 2022 is live today. An API key created for a bot you stopped using is live. A connection to a site whose domain now belongs to somebody else is live, and F107-01's Curve autopsy is what happens when a domain changes hands.
Which produces the working assumption for this whole course: every grant you have ever made is presumed live until you go and look.
Two properties, usually absent
A well-formed grant has two things.
A scope narrower than everything. Not "spend this token", but "spend this much of this token". Not "act on my account", but "read my balances". Not "access my files", but "access this folder".
An expiry. A date after which it stops working whether or not anybody remembers.
Almost nothing offered to you has both, and most have neither. Interfaces default to unlimited because a narrower grant produces a second prompt later, and a second prompt is friction, and friction is what the designer was measured on removing.
This is the operational consequence of the autopsy and it is the whole reason F109-05 exists.
Since the mechanism will not expire the grant, the expiry has to live somewhere else, and the only place available is your own schedule. A calendar entry. A quarterly review. Something with a date on it that is not dependent on you noticing.
Ronin's permission lapsed in November and the entry remained in March. The gap was not technical. It was that the lapse existed in an agreement and the entry existed in a system, and nothing connected the two.
Build the map
This is F109-L, and it is an inventory before it is an audit. Do not try to judge anything on the first pass; just find it all.
On-chain, per wallet. Use a revocation tool, reached through a bookmark you saved yourself per F111-04, and list every active approval on every chain each wallet has touched. Note the spender and the amount. The lab's own note is that learners routinely find approvals to protocols that no longer exist.
At every venue. Find the API key section on each exchange and list every key, its permissions, and whether it has an IP restriction. Then list active sessions and logged-in devices, which is a different screen.
In your wallet. List connected sites. Most wallets keep this and most people have never opened it.
In your browser. List extensions with access to your pages, which is F109-03's autopsy in advance.
In your accounts. The third-party applications with access to your email, your files, your calendar, and your identity provider.
And your account. Whether it delegates to any code, per F103-05.
Now the part that finds the Ronin-shaped problems: for each entry, write down why it exists. Any entry where the answer is "I do not remember" or "for something I stopped doing" is the finding. That is not a judgment about the counterparty. It is access that has outlived its purpose, which is the only condition the autopsy required.
Three questions per grant
Once the inventory exists, run each entry through these.
What can this do at its maximum? Not what it normally does. What is the worst outcome available to whoever holds it, if they are hostile. The course autopsy is the answer to this question being wrong: everybody assessed their keys on "can it withdraw" and the answer to "what is the worst it can do" was different.
Who actually holds it now? Companies are acquired, domains change hands, employees leave, and repositories get new maintainers. F104-01's Connect Kit attack ran through a former employee's account that had never been revoked, which is Ronin's shape at a different company.
Would I grant this today? If the answer is no, revoke it. This one sentence resolves most of an inventory faster than any risk analysis.
I only ever grant access to reputable services, so my exposure is limited.
Reputable is a statement about a counterparty at a moment, and every grant in the autopsy was to a reputable counterparty.
Axie DAO was a legitimate partner and the permission was operationally correct when granted. The Connect Kit account belonged to a real employee of a real company. The 3Commas keys were given to a service tens of thousands of people used deliberately.
Three things change after the grant and none of them ask you.
The counterparty changes. Acquisition, insolvency, a change of maintainer, a departing employee whose access nobody removes.
The counterparty is compromised. Their reputation does not survive their infrastructure being taken over, and it is their infrastructure holding your grant.
The purpose ends and the grant does not. This is Ronin, and it requires no bad actor at all until one arrives.
Which is why the discipline is not about choosing better counterparties, though you should. It is about grants having a lifetime, so that a counterparty's future does not have unlimited time to intersect with your access.
Five channels grant third parties the ability to act for you: on-chain approvals, API keys, sessions and connections, OAuth links, and smart-account delegation. They share the property that matters, which is that access persists until something removes it, and almost nothing removes itself, so treat every grant you have ever made as live until you have looked. Well-formed grants have a narrow scope and an expiry, and almost nothing offered to you has either, which means you are the expiry and it has to live in a calendar. Ronin lost $625M because a permission granted for a good reason in late 2021 lapsed in November and its allowlist entry was still there in March, supplying the fifth of five signatures.