On August 22, 2026, a wrapped SAND token on Base saw an externally-owned account (EOA) obtain minting rights and issue a large supply. The Sandbox subsequently confirmed a cross-chain bridge vulnerability affecting Base and BSC and halted cross-chain functions. Whatever the final mechanism, it is a clean, real-world reminder of one rule: for a token contract, "who can mint" is the most expensive access-control question there is.
Rather than repeat the report, I queried the Base chain directly (public RPC):
0xac531Eb26Ca1d21b85126De8FB87E80E09002DcF is a token with name = SAND, symbol = SAND, 18 decimals — the wrapped SAND on Base.totalSupply() reads roughly 327.6M SAND at query time.0x67624bfadee937c9281b4f98ce18af1bee01257e, is an EOA (no deployed code) with 371 on-chain transactions — a wallet, not a contract, consistent with "an address obtained minting rights."Reports put the issued amount at 500M+ SAND and note the cause was awaiting official confirmation at first report; the bridge-vulnerability confirmation came later from The Sandbox. I'm distinguishing here between what I could verify with an eth_call and what comes from reporting — that distinction is the whole point of this post.
Most static-audit checklists lead with reentrancy. Reentrancy is real, but it's a bounded problem: an attacker can drain what a function lets them drain, usually the funds in one path. A compromised mint key is unbounded. The attacker doesn't take existing value — they create new value, arbitrarily, at the contract's own authority. Every holder is diluted instantly, and no single transaction can undo it.
That's why, when I look at a token contract, the first question is not "is there a reentrancy guard" but "enumerate every address that can call a mint function, and what protects each one."
Being honest about scope matters here, because the SAND incident sits at the boundary between two distinct risks:
Layer 1 — code-level access control. A mint function behind a weak or missing guard, an owner() modifier on every privileged path with no timelock, an onlyOwner that can be reassigned without event or delay. This is exactly what a deterministic static pre-check flags: the patterns are knowable, and the same code produces the same result every run.
Layer 2 — infrastructure trust. A bridge contract whose mint authority is held by an EOA key, or a multisig whose threshold is wrong, or an upgrade path controlled off-chain. No Solidity pattern scanner catches this, because the bug is not in the bytecode — it's in who holds the key and where the trust boundary sits. The SAND event, as described, is a Layer 2 failure: mint authority on a bridge path was effectively compromised.
The honest split: a $2 static pre-check tells you whether your code has a weak mint path. It does not tell you whether your bridge or your key custody is sound. Anyone selling you a code scanner as a complete answer to this class of event is overselling. Know which layer you're actually auditing.
We run the code-level half as a pay-per-call endpoint: a $2 static pre-check (deterministic rules across reentrancy, access control, integer overflow, unchecked external calls, tx.origin auth, delegatecall, selfdestruct, timestamp, assert, and owner change) and a $20 AI deep pass that reads for uninitialized owners, account confusion, and missing signer auth. Both settle in USDC over x402 — no API key, no signup, the 402 challenge carries the price. A worked example of the pre-check catching a reentrancy before deploy is at the reentrancy case study.
But the most valuable thing in this post is the split itself: know which layer your audit covers, and don't let anyone blur it. The SAND incident is a Layer 2 story. It's still the clearest recent argument for taking Layer 1 seriously — because "who can mint" is the question that costs the most when you get it wrong.