The Sandbox's 329-Trillion SAND Mint: How an approveAndCall Exploit Hijacked LayerZero Delegate Permissions and Drained the Bridge Reserve

At 23:42:05 UTC on August 21, 2026, an attacker began exploiting a vulnerability in The Sandbox's cross-chain SAND token infrastructure on Base and BNB Smart Chain. Over the next five hours, across 703 separate minting events distributed to 173 wallets through more than 400 transactions, the attacker manufactured approximately 329.24 trillion unbacked SAND tokens on Base — a nominal face value of roughly $49 billion at the prevailing SAND price of $0.045. The last minting event was recorded at 04:45:21 UTC on August 22.

The headline figure is misleading. Unbacked tokens created on Base could only be converted into real value by redeeming them against the Ethereum-side OFT Adapter — the contract holding the legitimate SAND reserve that backs cross-chain transfers. That reserve held approximately 14,769,723 SAND. The attacker drained it: the adapter balance fell from 14,769,723 SAND to 0.0056 SAND across 15 separate redemption events, with one externally owned account receiving 14,095,483 SAND across six transactions inside a 24-second window. The total real loss — legitimate SAND drained from backed reserves plus approximately 79.74 ETH converted — was approximately $665,000–$675,000, not $49 billion.

At 05:09:19 UTC, 24 minutes after minting activity had organically ceased, The Sandbox's multisig executed a response: it zeroed out the trusted peers for LayerZero endpoint IDs 30101 and 30102, severing cross-chain messaging between the Ethereum and Base deployments. Bridging on Base and BNB Smart Chain was permanently suspended. The Ethereum mainnet supply remained exactly 3,000,000,000 SAND; Ethereum and Polygon deployments were confirmed unaffected. Exchanges including Upbit and Bithumb suspended SAND trading activity during the incident. The Sandbox stated the direct impact was less than 0.01% of the legitimate SAND supply.

The Sandbox deployed its cross-chain SAND token using LayerZero's Omnichain Fungible Token (OFT) framework — a widely adopted standard that allows a single token to exist and transfer across multiple chains without wrapping. The OFT pattern works by burning tokens on the source chain and minting an equivalent amount on the destination, or by locking tokens in an adapter on Ethereum and minting representatives on other chains. The framework relies on LayerZero's messaging infrastructure to relay verified cross-chain burn and mint instructions.

The exploit had two stages: first, hijacking delegate authority over the OFT contract on Base; second, using that authority to mint SAND without corresponding burns on Ethereum. Both stages were enabled by a single function call.

Stage 1: Hijacking LayerZero delegate permissions via approveAndCall

The SAND token contract on Base included an approveAndCall function — an ERC-20 extension that combines a token approval with an immediate call to the approved contract in a single transaction. The pattern is designed for usability: rather than requiring a user to first approve a contract and then call it in two separate transactions, approveAndCall does both atomically.

The vulnerability was in how the SAND implementation of approveAndCall handled the destination contract call. The function allowed the caller to pass an arbitrary data payload to the approved contract. The attacker crafted a payload that, when delivered to the LayerZero endpoint contract via the SAND token's approval context, was interpreted as a legitimate instruction to set the attacker's helper contract as a delegate over the SAND OFT on Base. LayerZero's OFT delegate system is a feature that allows a designated address to send cross-chain messages on behalf of the OFT contract. With delegate authority granted, the attacker could originate cross-chain mint instructions as though they were the OFT contract itself.

// approveAndCall: approve spender and call it with arbitrary data
function approveAndCall(
    address spender,
    uint256 amount,
    bytes calldata data   // ← caller-controlled payload
) external returns (bool) {
    _approve(msg.sender, spender, amount);

    // The spender (LayerZero endpoint) is called with attacker-supplied data.
    // The endpoint interprets the payload as an instruction to set a delegate.
    // No validation is applied to restrict what operations data may trigger.
    (bool success,) = spender.call(data);
    require(success, "call failed");
    return true;
}

// The crafted data payload encodes a call to:
// layerZeroEndpoint.setDelegate(attackerHelperContract)
// After this executes, attackerHelperContract is the trusted delegate
// for the SAND OFT on Base — able to originate cross-chain messages
// as though it were the SAND contract itself.

Stage 2: Minting unbacked SAND via delegated cross-chain messages

With delegate authority over the SAND OFT on Base, the attacker could send cross-chain messages through LayerZero's infrastructure that instructed the Ethereum OFT Adapter to release SAND from its reserves. The Adapter, receiving a message that appeared to originate from a legitimate SAND OFT peer, processed the release without querying whether a corresponding burn had actually occurred on Base. Simultaneously, the attacker's helper contract minted SAND on Base without performing the required burn — the two-sided accounting that backs the cross-chain peg was broken.

// Legitimate OFT transfer: Base → Ethereum
// Source (Base): burn SAND from sender
sandOFT.burn(sender, amount);
// LayerZero sends verified message to Ethereum adapter
layerZero.send(ethereumAdapterId, encodeRelease(recipient, amount));
// Destination (Ethereum adapter): release SAND to recipient
sandAdapter.release(recipient, amount); // amount == burned amount — peg intact

// --- Exploit path with hijacked delegate ---

// Attacker's helper contract (now a delegate) sends a fabricated message:
// No burn is performed on Base.
attackerHelper.sendMessage(
    layerZero,
    ethereumAdapterId,
    encodeRelease(attackerEOA, 14_095_483e18)  // request release of ~14M SAND
);
// Ethereum adapter receives a message that appears valid (correct peer ID,
// correct format) — it cannot verify that no burn occurred on Base.
sandAdapter.release(attackerEOA, 14_095_483e18); // real SAND released, unbacked

// Simultaneously, attacker mints SAND on Base without burning:
sandOFT.mint(attackerWallets[], massiveAmounts[]);
// 329.24 trillion SAND created on Base across 703 events — none backed.

Why the loss was capped at $675,000

The total extractable value was bounded by the Ethereum OFT Adapter's reserve balance at the time of the attack: approximately 14.77 million SAND. Once the adapter reached zero, no further real SAND could be released regardless of how many more unbacked tokens the attacker minted on Base. The 329 trillion SAND on Base had no claim on any remaining backed reserve, making it unredeemable for real value. The size of the headline number and the size of the actual loss diverged because the attack broke the peg accounting but could not manufacture the underlying reserve it was trying to drain.

The multisig response — zeroing the trusted peer configuration for LayerZero endpoint IDs 30101 and 30102 — severed the messaging link between Ethereum and Base entirely, preventing any further cross-chain redemption attempts even if the adapter had held additional reserves.

• Restrict the operations that approveAndCall may trigger. The approveAndCall function passed an unrestricted payload to the approved contract. Any implementation of this pattern that calls an external contract with caller-supplied data must validate or restrict the target function selectors the payload may invoke. Specifically, calls that can modify trust configurations — delegate settings, peer registrations, admin roles — must be explicitly blocked from being reachable through this path. A function selector allowlist on the data parameter would have made this exploit impossible.
• Restrict delegate-setting to the OFT contract owner. LayerZero's delegate system allows an OFT to nominate a helper contract to send messages on its behalf. This is a privileged operation — a delegate can originate any cross-chain message the OFT could send. Delegate assignment must be callable only by the contract owner or through a time-locked governance action, never as a side effect reachable through a user-facing function like token approval. The delegate configuration is an administrative privilege and must be protected with the same controls as minting authority or bridge admin keys.
• Apply burn-before-send ordering on the source chain. In the OFT pattern, the source-chain burn must be atomically committed before the cross-chain message is sent. If the burn is not atomic with the send, or if the send can be triggered independently of the burn, the two-sided accounting can be broken. OFT implementations should enforce that the burn and the send occur in the same transaction, with the burn result checked before the message is dispatched, making it structurally impossible to originate a release message without a corresponding burn.
• Cap OFT Adapter reserves relative to expected bridge volume. The Ethereum OFT Adapter held approximately 14.77 million SAND — the full amount that users had bridged from Ethereum to other chains. If the adapter had been subject to a reserve cap and per-period release limit, the maximum extractable amount per exploit window would have been bounded further, and the automated 24-second drain of 14 million SAND across six transactions would have triggered a circuit breaker.
• Monitor LayerZero delegate configuration changes in real time. The delegate change was the pivotal event: everything that followed depended on it. An on-chain monitoring system watching for setDelegate calls on production OFT contracts, with an immediate alert to a security response team, would have flagged the attack at its first step — before a single token was minted. Delegate configuration is not an event that occurs in normal operation; any change to it during live production should be treated as a critical alert.
• Audit all external-call paths in token contracts for privilege escalation. approveAndCall and similar combined approval-and-call patterns create an execution path where the token contract calls an external target with caller-supplied data, using the token contract as the message sender. This context — a trusted contract calling an external target with attacker-controlled input — is a well-known privilege escalation surface. Any security audit of a token contract that includes such patterns must explicitly enumerate the operations reachable through the call path and verify that none of them can be triggered by an unprivileged user.