Ankr aBNBc Mint (2022)

Independent research — not a commissioned audit. TierZero was not involved in Ankr, Helio, or any related protocol; this analysis is built entirely from public incident reports, on-chain data, and post-mortems.

What the protocol did

Ankr runs liquid-staking infrastructure across several proof-of-stake chains. On BNB Smart Chain, users deposited BNB and received aBNBc — a rebasing/reward-bearing certificate token meant to track the value of the underlying staked BNB plus accrued rewards, redeemable later for the original stake. aBNBc was liquid: it traded on PancakeSwap and, critically, was accepted as collateral by Helio Protocol, a BSC stablecoin issuer, to mint HAY. That composability is exactly what turned an admin-key compromise into a cross-protocol solvency event rather than a contained incident.

In December 2022, Ankr's deployer/admin key — the key holding minting rights on the aBNBc token contract — was compromised. Ankr's own post-incident disclosure attributed the exposure to a supply-chain failure: a former employee's retained access to Ankr's internal tooling/CI let an attacker obtain the private key used for privileged contract calls, rather than any flaw in the EVM bytecode itself.

The vulnerability

The bug class here is privilege centralization on a mint entrypoint, not a Solidity logic error. aBNBc's mint function was gated by a role check, but that role was held by a single externally-owned account with no multisig, no timelock, and — the part that determined blast radius — no on-chain cap tying issuance to actual staked collateral.

// Illustrative reconstruction of the flawed pattern
contract aBNBc is ERC20Upgradeable, AccessControlUpgradeable {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    function mintApprovedTo(address to, uint256 amount)
        external
        onlyRole(MINTER_ROLE)
    {
        _mint(to, amount); // no cap, no check against staked BNB backing
    }
}

Whoever controls the key with MINTER_ROLE can mint an arbitrary amount with a single transaction. There is no invariant enforced on-chain that total aBNBc supply track total staked BNB, so a compromised key is equivalent to an unbounded money printer, not a bounded exploit. This is the same failure mode we flag when reviewing upgrade authorities on any chain — see our note on how a single privileged authority over program state creates the same blast radius in Solana's upgradeable-loader model in our piece on upgradeable Solana programs and BPF loader risk.

How the exploit worked

1. The attacker obtained Ankr's deployer/admin private key through the compromised-access supply-chain route Ankr later confirmed, not through any weakness in the deployed contract's logic.
2. Using that key, the attacker called the privileged mint function directly on the aBNBc contract, issuing an enormous, effectively unbacked supply of aBNBc to an attacker-controlled address — reported publicly as an amount many orders of magnitude larger than the legitimate circulating supply.
3. A portion of the freshly minted aBNBc was deposited as collateral into Helio Protocol, which priced it near its intended peg and let the attacker mint a large amount of HAY stablecoin against fabricated collateral.
4. The remainder was dumped directly into PancakeSwap liquidity pools, swapping aBNBc for BNB and other liquid assets, draining pool reserves and breaking the aBNBc peg in the process.
5. Total value extracted across the HAY over-mint and the pool drains was reported in the mid-single-digit millions of dollars; the nominal nominal-supply figure minted was vastly larger, since most of it was never realized as liquid value before response teams intervened.
6. Ankr and Helio responded by pausing what could be paused, migrating to a new token contract with rotated admin keys, and coordinating a reimbursement plan for affected holders and HAY depositors.

How an audit catches this

This class of incident is precisely why access-control review is a standalone workstream in every engagement we run under smart contract audit, separate from bytecode-level logic review. Concretely, we:

• Enumerate every privileged function (mint, burn, pause, upgrade, role-grant) and map which address or contract holds each role — a single EOA holding a mint role is an automatic finding, full stop.
• Require multisig + timelock on any role that can move supply or upgrade logic, and check that the timelock delay is actually long enough to react to an anomalous transaction in the mempool.
• Test for the presence (or absence) of an on-chain supply invariant — for a staking-derivative token, total supply should be provably bounded by, or reconcilable against, the underlying staked balance, ideally checked in the mint function itself, not just off-chain.
• Push for downstream protocols to add collateral-specific circuit breakers: if Helio had capped HAY mintable against any single collateral asset per block, or paused new HAY issuance on abnormal aBNBc mint volume, the cross-protocol contagion would have been contained.
• Extend the review past the repo: CI/CD secrets handling, npm publish access, and key-custody procedures are in scope whenever a contract has post-deployment privileged functions, because — as this incident shows — the strongest Solidity code in the world doesn't help if the key that controls it leaks. This is the same reasoning behind treating supply-chain and dependency hygiene as a first-class check in code review and audit engagements, alongside patterns we cover in our writeup on Solidity approval and signature risk on EVM chains.

Remediation

Move every privileged role off single EOAs onto a multisig with a meaningful timelock before mainnet launch, not after. Enforce a hard, on-chain supply cap or collateral-backed invariant on mint functions so a compromised signer can inflate supply only within a bounded, recoverable range. Separate deployment/CI credentials from production signing keys entirely — use hardware-backed or MPC custody for anything that can call a privileged function, and rotate keys immediately on any employee offboarding or third-party access change. Add real-time monitoring that flags mint events exceeding expected issuance velocity and can trigger an automatic pause. Protocols that accept a third-party token as collateral, like Helio did with aBNBc, need their own circuit breakers — oracle sanity checks and per-asset mint caps — so a supply-side failure in one protocol can't cascade into a stablecoin depeg in another; the same cross-program trust boundary problem shows up in our analysis of cross-program invocation risk in Solana DeFi, where one program's compromised state gets trusted blindly by another.

If your protocol has a privileged mint, upgrade, or admin path anywhere in its dependency graph, get it in front of a smart contract audit before that key becomes someone else's single point of failure.

Thinking about a review like this for your own contracts? Get a smart contract audit from an independent team.