Reading a Security Incident Disclosure
Projects publish accounts of exploits. The good ones follow a recognisable structure, and the omissions are informative.
ELENA VOSS · · 2 min read
After an exploit, the affected project publishes an account. Quality varies enormously and the structure of a good one is consistent.
What a good disclosure contains
A timeline with timestamps. When the exploit occurred, when it was detected, when contracts were paused, when the disclosure was published.
The mechanism. What the flaw was, specifically. Not “a vulnerability in the contract” but which function, which assumption, which condition.
The transaction hashes. So that anyone can verify the account independently.
The amounts. Separated into user funds and protocol funds, valued at a stated time.
Who is affected. Which users, which positions, which chains.
What happens next. Compensation, if any, with a mechanism and a timeline.
What changed. Code fixes, audits commissioned, process changes.
The omissions that matter
No transaction hashes means the account cannot be verified.
Aggregate figures without separating user funds overstates or understates depending on which way it helps.
Mechanism described vaguely frequently indicates the cause was a key compromise rather than a contract flaw, which has different implications for everyone else.
No timeline conceals how long the exploit ran before detection.
No statement about affected users leaves people unable to determine whether they need to act.
The revision pattern
Initial disclosures are frequently wrong in specifics. Amounts are revised, mechanisms are reclassified, and what looked like a contract bug turns out to be a stolen key.
Treating the first account as provisional for several days is the correct default, and reading the follow-up analysis from independent security firms is where the accurate picture usually appears.
What a reader should do
Determine whether you are affected. Did you hold funds there, or interact with the contract.
Revoke approvals granted to the affected protocol, regardless of whether you held funds.
Check whether the mechanism is shared. An oracle manipulation raises questions about other protocols using the same feed. A key compromise raises questions about similar multi-signature arrangements elsewhere.
That last check is the one that turns a single incident into useful information.
The venue dimension
Where an incident affects an asset a venue lists, the venue typically suspends deposits and withdrawals for it while assessing. Notices are published in advance where possible.
Platforms with a documented incident process, such as retail venues covering the pair, state what they suspend and when they resume, which is the information a holder actually needs during an event.
Spotted an error? Corrections are published with a note at the foot of the article.Send the details.