Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Avantis Safe?

AVNTBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance2/10Upgrades7/10Checks passed3 of 5Findings2 High · 1 Medium · 2 Info5
SummaryAI Copilot

The audit focused on the Token contract, an ERC20 token with blacklisting and cross-chain bridging capabilities.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 74.3%
  • LP top3 unlocked holders = 96.2%
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-6)
  • Top-10 concentration > 30% (86.7% total → 46.5% effective; 19.6% in EOAs, 67.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 74.3% (independent LP — depth risk, pool = 82% of DEX liquidity)
  • LP top3 unlocked holders = 96.2% (independent LP — depth risk, pool = 82% of DEX liquidity)
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
67.0%Contracts19.6%Wallets13.3%Everyone else
67.0%Contracts19.6%Wallets13.3%
ContractsWalletsEveryone elseBubble area = share of supply
86.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking67.0%
  • Walletsanonymous holders, free to sell19.6%
  • Everyone elsethe rest of the supply13.3%
Effective concentrationwhat the score reads46.5%
How holder types affect the score

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$775.8K across 21 pairs
Show 4 more pairs

The 11 remaining pairs hold $282 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$635.7KShare of depth81.9%
Top-1 Unlocked Holder74.3%
Top-3 Unlocked96.2%
Unlocked LP held by
0x3624…147c0x4150…97c50xb713…11d10x33ab…21fa0x9a88…bd090x13e0…63f70x83d9…452a0x808c…997f0xa3fb…50d90x1f61…b2b6

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

2 High1 Medium2 Info
High

Centralized Blacklisting Power

The blacklistUpdate function, protected by onlyOwner, allows the contract owner to blacklist any address. This grants significant centralized control, enabling the owner to prevent transfers to or from specific users, effectively freezing their tokens or preventing participation. While the owner is a multisig (3/6), a compromise of the multisig could lead to severe disruption and loss of user access to funds.H-01

Issue

The blacklistUpdate function, protected by onlyOwner, allows the contract owner to blacklist any address. This grants significant centralized control, enabling the owner to prevent transfers to or from specific users, effectively freezing their tokens or preventing participation. While the owner is a multisig (3/6), a compromise of the multisig could lead to severe disruption and loss of user access to funds.

Fix

Ensure the multisig controlling the owner address is secured with the highest operational and key management standards. Implement robust internal procedures and controls for the use of the blacklisting function. Consider adding a timelock for critical owner actions like blacklisting to provide a window for detection and reaction.

Status

Unresolved

High

Critical Dependency on SuperchainTokenBridge

The crosschainMint and crosschainBurn functions are exclusively callable by the SUPERCHAIN_TOKEN_BRIDGE address. This makes the token's supply and cross-chain functionality critically dependent on the security and integrity of this external bridge contract. A vulnerability or compromise in the SUPERCHAIN_TOKEN_BRIDGE could lead to unauthorized minting of tokens (inflation) or burning of user funds (deflation), severely impacting the token's economic stability.H-02

Issue

The crosschainMint and crosschainBurn functions are exclusively callable by the SUPERCHAIN_TOKEN_BRIDGE address. This makes the token's supply and cross-chain functionality critically dependent on the security and integrity of this external bridge contract. A vulnerability or compromise in the SUPERCHAIN_TOKEN_BRIDGE could lead to unauthorized minting of tokens (inflation) or burning of user funds (deflation), severely impacting the token's economic stability.

Fix

Thoroughly audit and continuously monitor the security of the SUPERCHAIN_TOKEN_BRIDGE contract. Implement robust monitoring systems to detect unusual activity related to cross-chain minting/burning. Consider a mechanism to pause cross-chain operations in an emergency, if feasible within the bridge's design.

Status

Unresolved

Medium

Potential for User Fund Freezing via Blacklist

The blacklisting mechanism, while an intended feature, inherently carries the risk of freezing user funds. If an address holding tokens is blacklisted, those tokens become untransferable. This could occur due to an error, a malicious act by a compromised owner, or a policy decision, leading to a loss of access for affected users.M-01

Issue

The blacklisting mechanism, while an intended feature, inherently carries the risk of freezing user funds. If an address holding tokens is blacklisted, those tokens become untransferable. This could occur due to an error, a malicious act by a compromised owner, or a policy decision, leading to a loss of access for affected users.

Fix

Clearly communicate the blacklisting policy and its implications to all users. Establish a transparent process for blacklisting decisions and potential appeals. Consider implementing a 'grace period' or notification system before an address is fully blacklisted, if appropriate for the project's risk model.

Status

Unresolved

Info

No Upgradeability Mechanism

The contract is implemented without an upgradeability pattern (e.g., proxies). This means that once deployed, the contract's logic cannot be modified. Any future bug fixes, security patches, or feature enhancements would require deploying a new contract and migrating all users and associated liquidity, which can be a complex and costly process.I-01

Issue

The contract is implemented without an upgradeability pattern (e.g., proxies). This means that once deployed, the contract's logic cannot be modified. Any future bug fixes, security patches, or feature enhancements would require deploying a new contract and migrating all users and associated liquidity, which can be a complex and costly process.

Fix

Acknowledge the implications of non-upgradeability. For critical infrastructure, consider if an upgradeable design would be beneficial for long-term maintenance and adaptability. If not, ensure the current design is extremely robust and future-proof.

Status

Unresolved

Info

Hardcoded SuperchainTokenBridge Address

The SUPERCHAIN_TOKEN_BRIDGE address is hardcoded as a constant. While this ensures immutability and prevents accidental changes, it also means that if the bridge contract ever needs to be replaced (e.g., due to a major upgrade, vulnerability, or change in infrastructure), the Token contract itself would need to be redeployed. This lack of flexibility could be a long-term operational constraint.I-02

Issue

The SUPERCHAIN_TOKEN_BRIDGE address is hardcoded as a constant. While this ensures immutability and prevents accidental changes, it also means that if the bridge contract ever needs to be replaced (e.g., due to a major upgrade, vulnerability, or change in infrastructure), the Token contract itself would need to be redeployed. This lack of flexibility could be a long-term operational constraint.

Fix

Evaluate the long-term stability and upgrade path of the SUPERCHAIN_TOKEN_BRIDGE. If there's a foreseeable need for the bridge address to change, consider making it a configurable state variable, managed by the owner (preferably with a timelock), rather than a constant. If the bridge is truly immutable and part of the core chain infrastructure, then the constant is appropriate.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit focused on the Token contract, an ERC20 token with blacklisting and cross-chain bridging capabilities. The contract utilizes OpenZeppelin's battle-tested libraries for ERC20 and Ownable2Step functionalities. Key features include an owner-controlled blacklist and functions for cross-chain minting/burning restricted to a predefined SuperchainTokenBridge address. The primary risks identified relate to the centralized control points (owner for blacklisting, and the critical dependency on the external bridge) and the inherent implications of a blacklisting mechanism. The owner is a multisig, which mitigates some centralization risks.

Technical8/10Low risk

The contract (7.1 Architecture) is a standard ERC20 implementation enhanced with blacklisting and cross-chain functionality. It leverages OpenZeppelin's well-audited contracts (ERC20, Ownable2Step), contributing to robust code security (7.2 Code Security). The _update function is correctly overridden to enforce blacklist checks on transfers. However, the critical dependency on the SUPERCHAIN_TOKEN_BRIDGE for cross-chain operations introduces an external technical risk (7.6 External).

Governance2/10High risk

The contract exhibits significant centralization (7.3 Access Control) through the onlyOwner modifier for the blacklistUpdate function, granting the owner the power to freeze funds or prevent transfers for any address. While the owner is a 3/6 multisig, mitigating single-point-of-failure risk, this remains a powerful control. Economically (7.4 Economic), the token's integrity heavily relies on the security of the SUPERCHAIN_TOKEN_BRIDGE, as its compromise would allow arbitrary minting/burning. The blacklisting feature, while intended, carries an inherent risk of user fund freezing if misused.

Upgrades7/10Low risk

The contract is not designed with an upgrade mechanism (7.7 Upgrades). This means that any future bug fixes, feature enhancements, or changes to critical dependencies (like the SUPERCHAIN_TOKEN_BRIDGE address) would necessitate a complete redeployment of the token contract, which can be a complex and disruptive process for users and integrated protocols.

Final RecommendationWhat to do about this score

It is crucial to ensure the highest security standards for the owner's multisig wallet, as it holds significant power over the token's functionality, particularly the blacklisting feature.

Continuous monitoring and auditing of the SUPERCHAIN_TOKEN_BRIDGE are paramount, given its critical role in the token's supply and cross-chain operations. Consider clear communication to users regarding the implications of the blacklisting mechanism.

Contract & Record

2 audits on record
TypeToken
NetworkBase
Token age1y
Contract0x696f…f4f1
Deployer0xe4cc…797d
Badge for your website
Avantis security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Jul 27, 202649Medium
  2. Jul 27, 202665High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

Is Avantis a scam?

Based on automated analysis, Avantis scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Avantis safe to buy?

Our scanner flagged a risk score of 65/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Avantis been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
Supergemma4-26b-multimodalSUPERGEMMA · Base49MediumStonxBase49MediumWhuffieWHUF · Base49MediumCoinbase Wrapped Staked ETHCBETH · Base48MediumThe Innovation GameTIG · Base48MediumMetronome Synth ETHMSETH · Base50Medium

Would You Like a More Detailed Audit of Avantis?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page