Recently, I’ve looked at a few projects and, while I was at it, skimmed their GitHub and audit reports. To be honest, I used to be lazy too—I thought, “If the code is open-sourced, that should be enough.” But later I realized that simply checking whether there’s an audit report is not enough.



The key is two things: first, whether the audit report states “known risks” or “recommended fixes” that haven’t been addressed—if so, you need to stay on guard; second, when upgrading or adjusting the multisig configuration—who manages it, how many people need to sign, and how long the lock-up period is—this is more important than whether the coin price goes up or down.

About that recent cross-chain bridge hack—actually, looking back at the on-chain transaction records, you can see that the multisig address had already been changed to a suspicious one, but nobody noticed. The oracle abnormal pricing incident was similar too: if you wait a bit longer for confirmations, you can avoid a lot of pitfalls.

Anyway, I’ve developed a habit now. Before a new pool or new strategy goes live, I first check the GitHub commit history to see whether there have been recent changes to permission-related code. Take it slow—it’s better than getting rugged and regretting it later.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Repost
  • Share
Comment
Add a comment
Add a comment
No comments
  • Pinned