KoinlyticsBetween July 21 and July 24, 2026, four separate incidents hit four separate layers of the crypto stack. Each drained real money. Each attacked a completely different primitive. Put them side by side and the picture is one that no single incident can show on its own.
AFX Trade lost $24.15M through an Arbitrum bridge exploit that manipulated cross-chain message validation. Zilliqa disclosed that its official Ledger app had been generating Schnorr signatures with the top 64 bits of every nonce fixed at zero since 2019. SecondFi disclosed that its Cardano wallet had been computing Ed25519 nonces without the RFC 8032 secret prefix input, exposing the signing key on every signature and losing $2.4M across 374 ADA wallets. Lien Finance lost $542K in USDC because a bond group registration function that documentation described as governance-gated was actually permissionless in production.
Four incidents. Four totally different categories of failure. And a standard smart-contract audit would find one of them, on a good day.
That is the point of this analysis. The industry defaults to reading Solidity in a repo and calling the protocol secure. The past week is a reminder that the attack surface of any modern DeFi protocol extends into cross-chain messaging, into signature nonce derivation inside the wallet build, into the discipline of hooking client-side cryptography to a specification, and into the boring bookkeeping of confirming which functions on a deployed contract actually require the roles they were supposed to require.
AFX Trade Arbitrum bridge, $24.15M drained via cross-chain messaging abuse
On July 22, AFX Trade's Arbitrum bridge was drained of $24.15M in USDC. Within hours the attacker had routed the funds through decentralized exchanges into 12,467 ETH, a standard laundering pattern to move value out of a stablecoin that can be frozen into a native asset that cannot. AFX Trade is a mid-tier perpetuals venue with a cross-chain component that lets users deposit on one chain and trade on Arbitrum.
The root cause sat in the messaging validation between the source chain and the Arbitrum deployment. Cross-chain bridges rely on some off-chain or oracle-based proof that a deposit occurred on the origin. The bridge trusted a message payload that the attacker was able to craft or replay without a matching on-chain deposit. In plain terms, the bridge minted representative USDC on Arbitrum against a deposit that did not exist.
The attack mechanics were direct. The attacker submitted a manufactured proof that the bridge's validator layer accepted. The validators did not verify the underlying source-chain state directly. They verified a signed attestation that a relayer produced. Once the mint on Arbitrum was live, the attacker withdrew the $24.15M into a fresh address and routed it through decentralized liquidity into 12,467 ETH before the AFX Trade team could pause the bridge contract.
Prevention requires that the destination-chain verifier check a proof of source-chain state, not a signed word from a relayer. Light-client bridges, zk-proof bridges, and multi-party attestation with meaningful slashing all raise the bar. A bridge that trusts a small validator set behind a shared signing quorum is, by construction, a target sized to whatever value sits above it. Every incident of this shape in the last three years has reinforced that lesson, and the industry keeps rediscovering it.
Zilliqa Ledger app, Schnorr nonces with 64 fixed bits since 2019
On July 21, Zilliqa published a disclosure that its official Ledger app had generated every Schnorr signature with the top 64 bits of the nonce fixed at zero, going back to the app's original release in 2019. Native ZIL Ledger signing was halted immediately. Users were advised to move funds to a wallet whose signatures did not carry the bias.
The root cause is a classic cryptographic mistake. A Schnorr signature involves a random nonce that must be uniformly distributed across the full range of the curve's group order. If any bits of the nonce are biased or predictable, the signature scheme leaks information about the signing key. The Zilliqa Ledger app derived nonces in a way that placed 64 leading zero bits on every signature. That is 64 bits of a 256-bit scalar known to the attacker before they look at any signature at all.
The attack mechanics have a name. This failure mode is called the Hidden Number Problem, and it is one of the oldest applied cryptography attacks against ECDSA and Schnorr. Given a handful of biased signatures, an attacker constructs a lattice whose shortest vector encodes the signing key. In this specific case, five signatures are sufficient for recovery. Any ZIL address that produced five Ledger signatures at any time since 2019 is at risk. No exploit has been publicly attributed as of disclosure, but the vulnerability window is seven years wide.
Prevention is well understood. The RFC 6979 approach to nonce derivation makes the nonce a deterministic function of the message and the signing key, hashed through HMAC in a way that cannot be shortened without breaking the hash. Every serious signature library uses it or an equivalent construction. Manual nonce assembly inside a hardware wallet app is exactly the kind of code that must be reviewed by cryptographers specifically, and the review must produce a written argument that every bit of the nonce is unpredictable to any observer.
SecondFi Cardano wallet, Ed25519 nonces missing the RFC 8032 secret prefix, $2.4M drained
On July 22, SecondFi disclosed that its Cardano wallet build had computed Ed25519 signature nonces without hashing in the RFC 8032 secret prefix input. Every signature produced by an affected wallet leaked the signing key directly. $2.4M was drained from 374 ADA wallets before the disclosure and the pause.
The root cause is more subtle than the Zilliqa case but even more damaging. Ed25519 is deterministic by design. The nonce is derived by hashing a secret prefix, a portion of the expanded key that is never exposed to the signer's message-handling code, together with the message being signed. The secret prefix binds the nonce to the specific key. If the secret prefix input is omitted from the hash, the nonce becomes a function only of the message. Two signatures on different messages under the same key then produce nonces whose relationship is trivially computable, and the signing key falls out in one algebraic step.
The attack mechanics are as short as the algebra. An attacker collected two signatures from any affected wallet, ran the standard Ed25519 nonce-reuse recovery, and produced the signing key. From the signing key, the attacker built new signatures and swept funds. Because the flaw lived inside the wallet build and not in the on-chain protocol, no on-chain analytics surfaced anything unusual until the sweeps hit the ledger.
Prevention here is embarrassingly cheap. This class of bug is caught immediately by a signing self-test that any wallet build should ship. The test vectors published inside RFC 8032 exercise the exact nonce derivation path. If the build under review does not produce the RFC test-vector outputs bit-for-bit, the signing implementation is wrong, full stop. Wallet vendors that build against a well-known signature standard must run a reproducible build with the standard's test vectors as a release gate, and no wallet without that gate should be trusted with user funds.
Lien Finance bond group registration, permissionless where governance was documented, $542K drained
On July 24, Lien Finance lost $542K in USDC to an attacker who registered a malicious bond group. The documentation described bond group registration as a governance-gated action. In the deployed contract, the function had no access control at all. Anyone could register a group.
The root cause is a mismatch between documented role and enforced role. The attacker registered a bond group whose payoff function returned a distorted rate. Inside Lien, the internal function _calcRateBondToErc20 consumes the payoff to price bond redemption. A crafted payoff pushed the rate calculation into a state that overvalued the attacker's bond, and redemption produced $542K in USDC.
The attack mechanics were straightforward given the missing modifier. The malicious contract implemented the payoff interface with a return value that Lien's math treated as a valid rate. The bond group passed all sanity checks the protocol did run. The one check the protocol did not run was whether the group had been registered by an authorized address. That check was missing because a modifier that appeared to exist in an earlier revision was not present on the deployed selector.
Prevention is a paper exercise. A permissioning matrix, generated from the deployed bytecode and reconciled with the documented role model, is the auditable artifact that would have caught this incident on deploy day. Every function whose documentation lists a role gets a row in the matrix. Every row that shows a divergence between documented role and enforced role is a bug. The exercise costs a few hours per protocol. No traditional smart-contract audit produces it as a deliverable, and the industry keeps paying for that omission.
What a standard smart-contract audit reads and what it does not
A standard smart-contract audit reads Solidity in a repository. It looks for reentrancy, integer arithmetic, access control on the functions the auditor sees in the code, oracle usage, upgrade patterns, and known DeFi composition risks like flash loan interaction. If the repository compiles and the auditor sees a modifier on the function, the modifier is assumed to be applied in production.
Of the four incidents this week, only the Lien Finance failure lives inside that scope, and even Lien is caught only if the audit compares the deployed function selectors against the source that was reviewed. Most audits do not run that comparison.
The AFX Trade bridge failure lives in the validator layer between two chains, inside a signed attestation flow that the on-chain contract only verifies at a surface level. To find it, an auditor has to read the off-chain relayer code, understand the trust assumptions, and stress the case where the relayer set is compromised or bypassed. That is a separate engagement, and it is rarely commissioned alongside the on-chain review.
The Zilliqa and SecondFi failures live inside client-side signature code. The on-chain contract is fine. The wallet or hardware wallet application produces bad signatures. Smart-contract auditors do not review this code and are not trained to. A cryptographer must review the nonce derivation and prove it is unpredictable and secret-bound. Then the vendor must produce a reproducible build so the code the user runs is the code the cryptographer reviewed.
The lesson is not that smart-contract audits are useless. They are useful for what they cover. The lesson is that a smart-contract audit is one narrow slice of the actual attack surface, and treating it as a sufficient security posture leaves every other slice open. The last week's $27.1M in aggregate losses is a bill for that misconception.
The four-layer defense any DeFi protocol should verify
The first layer is cross-chain messaging. Every bridge or cross-chain composability layer a protocol depends on must document its trust assumptions and match them to a verifier that cannot be bypassed by a compromised relayer. If the answer to how the destination chain validates a source-chain event is a small validator set with a shared signing quorum, the number in the treasury above the bridge tells the attacker what they are competing for. Light-client verification, zk-proof verification, or a validator set large enough and slashed hard enough to make attack uneconomic are the acceptable answers.
The second layer is signature scheme and nonce derivation. Every signing path used by any user-facing product must be traced to a specification. If the scheme is ECDSA, the nonce must be RFC 6979 or better. If the scheme is Ed25519, the nonce derivation must include the secret prefix input per RFC 8032. If the scheme is Schnorr, the nonce must be produced by a construction whose distribution over the group is provably uniform. Any deviation from these baselines is a candidate for lattice recovery of the signing key, and the code responsible must be reviewed by a cryptographer, not by an application engineer.
The third layer is wallet client build reproducibility. If a user is trusting a wallet binary, the vendor must publish a build that anyone can reproduce byte-for-byte from the source code that was reviewed. Signing self-tests against the specification's test vectors must run on every release. A wallet that ships without reproducible builds is a wallet whose signing code no one has actually verified in the exact form the user runs. The SecondFi case is what that looks like at scale.
The fourth layer is application-layer governance-gated permissions actually being gated. For every function whose documentation describes an access-controlled role, the deployed bytecode must be inspected to confirm the modifier is present on that selector. A permissioning matrix that lists selector, documented role, and enforced role is the deliverable. Any row where documented and enforced diverge is a Lien Finance waiting to happen. This is the cheapest of the four artifacts to produce and the most consistently absent from audit reports.
The pattern the week draws
Four incidents in four days across four different layers is not a coincidence. It is a distribution of failures across a stack that most protocols only defend at one layer. The attacker's job is to find the least-defended layer. The defender's job is to raise the floor across all of them.
Every dollar of the $27.1M lost this week traces to a category of failure that a competent team could have surfaced ahead of time with a specific artifact. A bridge trust matrix would have flagged AFX. A cryptographer's review of nonce derivation would have flagged Zilliqa in 2019 and SecondFi at build time. A permissioning matrix reconciling documented roles against deployed selectors would have flagged Lien on the day it deployed. None of these artifacts are exotic. They are work that most protocols do not commission because a smart-contract audit report is treated as the complete answer to the question of whether the protocol is safe to use.
The industry will see more of these until that changes. The next week's losses are already being paid for by protocols that read only one layer of their own stack.
What Koinlytics tracks: bridge validator sets and trust assumptions, wallet build reproducibility and signing self-tests, signature scheme and nonce derivation audits, and deployed-selector permissioning matrices for every DeFi protocol in our coverage universe.