Minting Out of Thin Air: The LayerZero Delegate Hijack, Explained

Security firm Blockaid flagged automated minting of The Sandbox's SAND token on Base this month — hundreds of transactions producing tokens with nothing behind them, after an attacker gained control of delegate permissions in the token's LayerZero cross-chain configuration.

The mechanism is worth understanding, because it will recur. Cross-chain tokens are an accounting trick: the "real" supply lives on one chain, and bridged versions elsewhere are IOUs minted and burned by messaging infrastructure. In LayerZero's model, a token's team designates a delegate — an address with authority over that messaging configuration. Control the delegate, and you can tell the destination chain that deposits happened which never did. The contract obeys; unbacked tokens appear.

The specific door, per Blockaid's live thread, was a function called approveAndCall on SAND's omnichain fungible token contract on Base. An OFT is the cross-chain edition of a token, and its delegate role governs who may mint units on a given chain. Hijack the delegate through that call and the mint authority is simply yours. More than 400 transactions ran before anyone stopped it.

Not a token bug

Nothing in SAND's own contract failed. That's the uncomfortable part: audits of the token tell you nothing about this class of risk, which lives in the permissions wrapped around the bridge. It echoes every major bridge failure since Wormhole and Ronin — the chain of custody is only as strong as its most powerful key, and the industry keeps rediscovering how many powerful keys exist off the audit reports.

What a delegate is actually allowed to do

It is worth being precise about the powers attached to that role, because "delegate" is a mild word for it and LayerZero's own documentation is not mild at all.

In LayerZero V2, an omnichain application has an owner and, separately, a delegate. The split is deliberate: the owner sets local storage on the application itself — peers, and which remote address is trusted on each chain — while the delegate is the account permitted to reach into the protocol's EndpointV2 contract and change how messages to and from that application are handled. LayerZero's configuration documentation lists what that means in practice: the delegate is the caller for setSendLibrary, setReceiveLibrary, setReceiveLibraryTimeout and setConfig, and it can also call setDelegate at the endpoint.

Read that list again with an attacker's eyes. Those functions govern the message libraries a token's cross-chain traffic runs through, the executors that deliver it, and — most consequentially — the set of Decentralised Verifier Networks that must attest to a message before the destination chain will act on it. The DVN set is the security stack. It is the answer to the question "who has to agree that this deposit really happened?" An account that can rewrite that answer does not need to forge a deposit against honest verifiers. It can change who counts as a verifier.

This desk has not seen a public breakdown of which specific lever was pulled against SAND's Base deployment, and Blockaid's thread describes the entry point — approveAndCall — rather than the post-compromise configuration changes. So we are not going to claim the DVN set was rewritten here. The point is narrower and still uncomfortable: the role that was hijacked is, by design, the role that can rewrite the trust assumptions of the bridge, and nothing about a token audit would tell a holder who holds it.

The checklist that already said this

The most deflating detail is that none of this is obscure. LayerZero publishes an integration checklist for teams shipping omnichain applications, and it is explicit on the point: the delegate should always be the application's owner, and teams are advised to review and explicitly set the delegate for every deployment. It further warns that because only the owner can appoint a delegate, the delegate must be set or moved to the intended address before ownership is transferred — a sequencing trap that leaves a stale account holding endpoint authority if anyone gets the order wrong.

That guidance exists because the failure mode was foreseeable. Documented, checklisted, foreseeable — and still the thing that produced hundreds of unbacked mints on a live token. The gap in this incident was not knowledge. It was whether anybody was watching the address that held the keys.

The automation footnote

Blockaid's telemetry showed the minting run as scripted — hundreds of transactions at machine tempo. Exploits are increasingly executed end-to-end by software the moment access lands, which shrinks the response window from days to minutes. The month's broader theme, again: the attacker tempo is now machine tempo.

The $49 billion that wasn't

Blockaid put the face value of the minted tokens at roughly $49 billion across those 400-plus transactions, and that number went around the internet on its own. It is close to meaningless, and it is worth being precise about why. Minted tokens are only worth their market price if a market will absorb them. Dumping tens of billions of dollars of unbacked SAND into pools that hold a rounding fraction of that would collapse the price long before the attacker cashed out. Face value is what the ledger says. Realized value is what somebody actually pays you.

The realized figure is far smaller and far more informative: the Ethereum OFT adapter lost about 14.75 million SAND, worth roughly $675,000 at the time, with around 79.74 ETH reportedly converted out of the proceeds, per Crypto Briefing. That is the real hole. Everything above it was phantom supply that existed only until the bridges shut.

Headline number vs. money that moved

Face value minted~$49B

Actually drained~$675K

Related Nothing was hacked. Moonwell still lost $8.7 million

How it got contained

The Sandbox switched off bridging to and from Base and BNB Smart Chain on Aug 22, which isolated the phantom supply on those chains — unable to be moved or redeemed — and said it had identified and fully contained the vulnerability. It told users not to buy, sell or trade SAND on Base or BSC, on the grounds that liquidity there was compromised. It also said no user wallets were touched, that SAND on Ethereum and Polygon was unaffected, and that the SAND locked on Ethereum backing every bridged unit remained fully intact, The Defiant reports.

One claim in that statement deserves a flag rather than a repetition: the project characterised the impact as less than 0.01% of total SAND supply. That framing sits awkwardly next to a reported 14.75 million SAND drained from the Ethereum adapter, and the two figures are measuring different things — one the residual dilution after containment, the other the assets actually removed. Neither outlet reconciled them, and The Sandbox has not published a breakdown that would. Read the percentage as a statement about dilution, not about loss.

Killing the bridge is the correct reflex and it is also an admission: the only reliable way to stop a compromised delegate is to stop the messaging layer entirely. There is no partial mode, no rate limit, no circuit breaker that lets honest bridging continue while the attacker's mints are filtered out. The switch is binary, and every team running an OFT should know today where their hand goes to reach it.