The incident happened on January 16, but the post-mortem wasn’t published until March 10. What exactly was the official team doing during those 53 days? That was the biggest question I had before reading the Post-Mortem.
I copied the key timestamps from the post-mortem into my notes: the attack happened on January 16; the main chain suspended bridge services later that day; funds were consolidated and affected addresses verified in late January; the full post-mortem was published on March 10. $DUSK Before copying that part, I first checked the update timestamp on the release page to confirm that no intermediate version had been withdrawn. By the third one I stopped: in those 53 days, the official team only updated status twice—once on the day of the incident, and once on the day the post-mortem was published.
I spread out the calendar and counted again: January 16 to March 10, 53 days, 2 updates, an average of one change every 26.5 days. The funds consolidation and address verification in late January were all added later in the post-mortem; at the time, not a single word was shared externally. I divided those 53 days into four boxes: freezing at the hour level, verification at the day level, root cause analysis at the week level, and the post-mortem plus internal review taking more than a month. The first three boxes were completely empty; only the last one spoke up. That’s the time ledger I worked out, and it was the first thing that felt off to me.
But when you lay those four boxes out and think about them, silence does not necessarily mean negligence. @Dusk Freezing at the hour level means the risk spread was cut off on the same day; verification at the day level means the reconciliation of each transaction did not drag on; root cause analysis at the week level means the conclusion was evidence-based, not made on a whim. Each stage had a clear action, it just wasn’t updated publicly. I then pulled up a few recent bridge incidents to compare how they were handled: some projects deleted their Twitter the next day, some waited half a year to issue a vague statement, and others simply never responded. After comparing them, I became even more certain: the process is the raw material of trust, and this post-mortem is one of the few that lays out the timeline, root cause, and measures in full.
So now I’m watching for one thing: the next time this happens, will there be process updates between the incident and the post-mortem? Update frequency is the measure of transparency; no matter how open the words sound, timestamps are more honest than talk. #dusk
I copied the key timestamps from the post-mortem into my notes: the attack happened on January 16; the main chain suspended bridge services later that day; funds were consolidated and affected addresses verified in late January; the full post-mortem was published on March 10. $DUSK Before copying that part, I first checked the update timestamp on the release page to confirm that no intermediate version had been withdrawn. By the third one I stopped: in those 53 days, the official team only updated status twice—once on the day of the incident, and once on the day the post-mortem was published.
I spread out the calendar and counted again: January 16 to March 10, 53 days, 2 updates, an average of one change every 26.5 days. The funds consolidation and address verification in late January were all added later in the post-mortem; at the time, not a single word was shared externally. I divided those 53 days into four boxes: freezing at the hour level, verification at the day level, root cause analysis at the week level, and the post-mortem plus internal review taking more than a month. The first three boxes were completely empty; only the last one spoke up. That’s the time ledger I worked out, and it was the first thing that felt off to me.
But when you lay those four boxes out and think about them, silence does not necessarily mean negligence. @Dusk Freezing at the hour level means the risk spread was cut off on the same day; verification at the day level means the reconciliation of each transaction did not drag on; root cause analysis at the week level means the conclusion was evidence-based, not made on a whim. Each stage had a clear action, it just wasn’t updated publicly. I then pulled up a few recent bridge incidents to compare how they were handled: some projects deleted their Twitter the next day, some waited half a year to issue a vague statement, and others simply never responded. After comparing them, I became even more certain: the process is the raw material of trust, and this post-mortem is one of the few that lays out the timeline, root cause, and measures in full.
So now I’m watching for one thing: the next time this happens, will there be process updates between the incident and the post-mortem? Update frequency is the measure of transparency; no matter how open the words sound, timestamps are more honest than talk. #dusk