Avantis (AVNT) security report
Radar AI scanned the verified Avantis AVNT contract on Base. Material findings include owner-controlled transfer blocking and uncapped minting by the designated crosschain bridge.
The verified contract is a conventional ERC-20 with no transfer tax, proxy upgrade path, or owner-controlled fee mechanism, but it has significant privileged controls. The owner can block transfers for selected addresses, while the designated bridge can increase supply without an on-chain cap. These controls create meaningful asset-locking and dilution risks if misused or compromised.
Trust score: 55/100. Source verified: Yes. Chain: base. Contract: 0x696f9436b67233384889472cd7cd58a6fb5df4f1.
This report was last modified on 2026-10-14 and contains 2 material findings.
high finding: Owner can blacklist addresses and block all transfers involving them
The owner can set any address's blacklist status. The overridden _update function reverts whenever either the sender or receiver is blacklisted, so blacklist activation prevents transfers, minting to, and burning from affected addresses. This can materially restrict token movement and can affect protocol components such as trading or custody addresses if they are selected.
Evidence: In src/Token.sol, blacklistUpdate(address user, bool value) is external onlyOwner and writes _blacklist[user]. The _update override requires !isBlackListed(to) && !isBlackListed(from) before calling super._update. GoPlus also reports blacklist functionality with is_blacklisted=1. The owner role is provided by OpenZeppelin Ownable2Step.
Recommendation: Document and govern blacklist authority with transparent criteria, event monitoring, and a defined emergency process. Consider a timelock, multisignature ownership, narrowly scoped sanctions logic, and protections against accidentally blacklisting essential protocol addresses.
high finding: Bridge authority can mint an uncapped amount of AVNT
The designated SuperchainTokenBridge address can call crosschainMint with any amount and no per-transaction, cumulative, or total-supply cap in Token.sol. A compromise, misconfiguration, or incorrect authorization at that bridge address could create arbitrary additional supply and dilute existing balances.
Evidence: crosschainMint(address _to, uint256 _amount) only checks msg.sender == SUPERCHAIN_TOKEN_BRIDGE, where SUPERCHAIN_TOKEN_BRIDGE is the fixed address 0x4200000000000000000000000000000000000028, then calls _mint(_to, _amount). No amount limit or supply ceiling is enforced. GoPlus reports is_mintable=1.
Recommendation: Use explicit bridge accounting and enforce verifiable crosschain limits, replay protection, and monitoring at the bridge layer. Consider operational mint caps or rate limits where compatible with the bridge design, and document the trust assumptions for the fixed predeploy.