If I don't understand code at all and can't judge myself whether two protocols' logic is genuinely similar, what should I do?
You don't need to read code details yourself — the technical capability genuinely needed in these five steps is just searching and reading, not understanding program logic. Steps one and two can both be completed through a search engine; for step three, if you can't understand the audit report's technical terminology yourself, you can directly copy the passage related to this known weakness and ask support or a community member to explain it in plain language; step four is just checking whether this team has spoken publicly before, no code reading involved either.
If you find you genuinely can't complete a step at all (the audit report itself isn't public, or the protocol team declines to respond to related questions, say), that can't find it result itself is also meaningful information — it means transparency at this layer is insufficient, worth treating this information gap itself as an independent risk factor.
If the similarity I find is only superficial (both using the same programming language, say), does that count as a genuine cross-protocol exploit signature?
No, and this is an important distinction. A cross-protocol exploit signature refers to a specific logical structure similarity (an identical function call sequence, an identical permission-verification flow design, for example), not a general technology-choice similarity (both written in Solidity, both deployed on the same chain, say). Most protocols use the same mainstream programming language — this level of similarity doesn't constitute a meaningful risk signal at all.
The similarity genuinely worth attention is, after verifying the specific attack technical detail found in step two (exactly which piece of program logic the attacker exploited, what preconditions were needed to trigger the vulnerability), confirming whether the protocol you're using genuinely has an identical or highly similar logical structure — not concluding the two share a comparable exploit signature just from surface-level traits like the same programming language or both being lending protocols.
If the protocol team declines to answer my question about whether they've patched a known vulnerability, what does that mean?
This requires distinguishing between two possible refusal scenarios. One is the team, for reasonable security considerations, not wanting to publicly disclose detailed patching technical information (avoiding revealing details that could actually help a potential attacker) — in this case, a more reasonable approach is asking the team whether they can provide indirect evidence, whether a third-party audit report covers this issue, or whether they can offer a high-level confirmation that doesn't involve technical detail (yes, we're aware of this issue and have addressed it, for example).
The other scenario is the team not responding at all, or evading this specific question with vague language — this scenario warrants more heightened caution, since the transparency principle discussed earlier in this series applies here too: a responsible team, even if it's inconvenient to disclose technical detail publicly, is usually still willing to offer some level of confirmation or a high-level explanation. Complete silence or evasion is itself a signal worth adding to your risk assessment checklist.
How should I prioritize this five-step checklist against other due diligence checklists discussed earlier in this series (a cross-chain bridge finality check, say)?
In practice, different due diligence checklists target different risk dimensions, and ideally all of them should be run, but if time is limited and prioritization is needed, a simple judgment principle can help: prioritize whichever checklist relates directly to the concrete technical characteristics of the product you're using — if this product involves cross-chain operations, prioritize the cross-chain bridge finality check; if this product adopts a well-known open-source template, or a peer with a similar architecture has had a recent incident, prioritize this cross-protocol exploit signature comparison.
If the product you're evaluating spans multiple technical dimensions simultaneously, you could also consider running the lower-time-cost checks first (checking public information, reading the audit report), leaving the steps requiring you to actively contact the team for later — that way, even if you don't have time to complete every checklist, you've already ruled out some obvious risk through low-cost channels first.
This series earlier discussed the concept of cross-protocol exploit signature — after breaching one protocol, an attacker often carries the exact same technique over to another architecturally similar protocol unchanged. This article demonstrates a practical comparison checklist to help you judge whether the DeFAI product you're using shares a similar vulnerable structure with a protocol breached recently.
Most DeFi and DeFAI protocols don't write code entirely from scratch — they reference or even directly fork a widely circulated open-source template and modify it. First confirm whether the protocol you're using has technical documentation or a code repository explicitly noting built on [a well-known open-source project] — the most direct clue to similarity.
Once you've found the template's name, search a keyword like [template name] exploit or [template name] vulnerability to see whether any other protocol built on the same template has ever had an attack incident. If you find a related incident, it's worth further reading that incident's technical analysis to understand exactly which piece of logic in the template the attacker exploited.
Once you've found the known vulnerable logic segment, go back and check your protocol's audit report or update history to confirm whether this logic has been patched, or still retains the original template's implementation. If the protocol team has publicly stated we've hardened against this known category of vulnerability, that's a concrete, trustworthy positive signal.
Beyond comparing whether a single code segment is similar, it's also worth checking whether this protocol team has previously publicly discussed a peer incident, and whether they've proactively explained whether their own architecture is affected. A team that proactively pays attention to peers' lessons generally means they treat security as ongoing work, not a one-time task revisited only at launch.
If, after the first four steps, you find your protocol genuinely shares similar logic with a known breached protocol and you can't find any patching record, that doesn't mean you need to exit immediately, but it's worth honestly treating this finding as an additional risk factor in your position planning, addressing this currently unresolvable uncertainty with a more conservative committed amount.
These five steps turn the cross-protocol exploit signature concept discussed earlier in this series into a comparison checklist you can actually operate yourself. Most users, when evaluating a protocol, only look at whether that protocol itself has ever had an incident. This checklist reminds you that peers' lessons are equally worth checking against the product you're using, since an attacker rarely stops after just one attack.