Disclosure Timing Gap

What is a disclosure timing gap, and how does it differ from the post-mortem report discussed earlier in this series?

When this series broke down the post-mortem report earlier, the evaluation focus was on the report's content quality — whether the timeline was concrete, whether root cause analysis was honest, whether remediation measures were verifiable. A disclosure timing gap addresses a more upstream time variable: how much time genuinely elapsed between the team internally knowing about a problem and publicly disclosing it. Even if a post-mortem report's content is written in extreme detail and honesty, if the team only chose to disclose a month after the incident happened, during that month-long window, users were actually bearing risk under information asymmetry the entire time without knowing it at all.

This means evaluating a team's transparency can't just look at whether the final report is well-written — it needs to push one layer further back: is the gap between the problem being discovered and being disclosed itself reasonable?

Why does a disclosure timing gap exist — why doesn't a team publicly disclose a problem the instant they discover it?

A disclosure timing gap existing doesn't always mean the team deliberately concealed anything — some delay has relatively reasonable technical and legal considerations: after discovering a vulnerability, a team might need time to first complete a patch and confirm it works before disclosing publicly, avoiding a situation where publicizing vulnerability details before the fix is done gives other attackers a chance to exploit it; if an incident involves user asset loss, the team may also need time to clarify the scope of the loss and specifically who's affected before giving an accurate disclosure, rather than rushing out an incomplete preliminary statement that could cause unnecessary panic.

But a disclosure timing gap can also reflect less legitimate considerations — a team might assess that disclosing the problem would hurt its brand image or fundraising, and choose to delay as long as possible; or the team internally might have a genuine gap in judgment or decision-making delay about whether this problem is even serious enough to warrant public disclosure. This means a disclosure timing gap is itself a neutral time metric that needs to be assessed together with the specific reason for the delay, rather than simply judging a team good or bad purely by the length of time.

How is a disclosure timing gap actually assessed, and can an ordinary user verify this gap themselves?

Verifying a disclosure timing gap requires cross-referencing two timestamps: when the problem actually occurred (or was discovered), and when that problem was publicly disclosed. The former usually needs on-chain data (the actual timestamp of an abnormal transaction, for example) or independent analysis from a third-party security research community to confirm; the latter is relatively easier to verify, usually just the date the team published its announcement or post-mortem. Placing the two timestamps side by side gives you the concrete length of the disclosure timing gap.

A more granular assessment can also further check whether the team took any interim action to reduce user risk during that gap (whether it already paused the affected feature or privately notified some high-risk users before fully disclosing the details, for example). This kind of taking action to protect users even before public disclosure, compared to complete inaction and simply waiting in silence, reflects a completely different team attitude even if the final disclosure timing gap length turns out similar.

What's the practical impact of a disclosure timing gap for everyday users, and how should it apply to evaluating and ongoing monitoring of DeFAI products?

If a DeFAI product you're using has previously had a security incident, verifying the disclosure timing gap helps you more accurately judge how quickly this team actually responded to the problem, rather than just looking at how detailed the final report turned out to be. A team with an extremely short disclosure timing gap that can offer a reasonable explanation ("we spent two days completing an emergency patch first, then disclosed immediately once we confirmed it was safe," for example) is generally more trustworthy than a team with a gap stretching several weeks and no explanation offered at all.

In practice, this is also a layer worth continuously monitoring — if a product you're using has had a community or third-party monitoring service raise a signal like "suspected anomaly but no official explanation yet," the time you spend waiting for an official response is itself the disclosure timing gap you're currently experiencing, worth heightening your guard over, and considering whether to proactively take exposure-reducing action (pausing use, revoking authorization) before an official statement comes out, rather than passively waiting for an announcement and handing the initiative entirely to a time gap you can't control.