Quantum Audit Logo
Launch App

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

Is Aavegotchi GHST Token Safe?

GHSTBase
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 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance1/10Upgrades3/10Checks passed4 of 7Findings1 High · 1 Low · 3 Info5
SummaryAI Copilot

The OptimismMintableERC20 contract provides a standard ERC-20 token with controlled minting and burning capabilities, intended for cross-chain bridging.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.1%
  • LP top3 unlocked holders = 97.3%
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (90.3% total → 39.5% effective; 5.5% in EOAs, 84.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.1% (independent LP — depth risk, pool = 77% of DEX liquidity)
  • LP top3 unlocked holders = 97.3% (independent LP — depth risk, pool = 77% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Low 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
84.8%Contracts5.5%Wallets9.7%Everyone else
84.8%Contracts5.5%9.7%
ContractsWalletsEveryone elseBubble area = share of supply
90.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking84.8%
  • Walletsanonymous holders, free to sell5.5%
  • Everyone elsethe rest of the supply9.7%
Effective concentrationwhat the score reads39.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$912.3K across 9 pairs
Show 3 more pairs

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$700.8KShare of depth76.8%
Top-1 Unlocked Holder50.1%
Top-3 Unlocked97.3%
Unlocked LP held by
0xfa2b…52bb0x745b…d37f0xc1b1…cbee0x6be0…37bb

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

Security Findings

1 High1 Low3 Info
High

Centralization Risk and External Dependency on Bridge

The OptimismMintableERC20 contract grants exclusive minting and burning privileges to the BRIDGE address. This design introduces a significant centralization risk, as the security and integrity of the token are entirely dependent on the security of the BRIDGE contract. A compromise of the BRIDGE contract would allow an attacker to arbitrarily mint or burn tokens, leading to a loss of trust and potential economic exploit. (7.3 Access Control, 7.4 Economic, 7.6 External)H-01

Issue

The OptimismMintableERC20 contract grants exclusive minting and burning privileges to the BRIDGE address. This design introduces a significant centralization risk, as the security and integrity of the token are entirely dependent on the security of the BRIDGE contract. A compromise of the BRIDGE contract would allow an attacker to arbitrarily mint or burn tokens, leading to a loss of trust and potential economic exploit. (7.3 Access Control, 7.4 Economic, 7.6 External)

Fix

Ensure the BRIDGE contract itself undergoes rigorous security audits and implements robust access controls (e.g., multi-signature wallets, time-locks) to mitigate the risk of a single point of failure. Implement comprehensive monitoring for unusual activity originating from the BRIDGE address.

Status

Unresolved

Low

Immutability of Bridge and Remote Token Addresses

The BRIDGE and REMOTE_TOKEN addresses are set as immutable in the constructor. While this enhances security by preventing unauthorized modification post-deployment, it also means these critical addresses cannot be updated if the underlying bridge contract or remote token contract needs to be changed (e.g., due to an upgrade or a critical vulnerability in the bridge). This requires a full redeployment of the OptimismMintableERC20 contract and an update to the bridge's configuration if such a change becomes necessary. (7.1 Architecture, 7.8 Operations)L-01

Issue

The BRIDGE and REMOTE_TOKEN addresses are set as immutable in the constructor. While this enhances security by preventing unauthorized modification post-deployment, it also means these critical addresses cannot be updated if the underlying bridge contract or remote token contract needs to be changed (e.g., due to an upgrade or a critical vulnerability in the bridge). This requires a full redeployment of the OptimismMintableERC20 contract and an update to the bridge's configuration if such a change becomes necessary. (7.1 Architecture, 7.8 Operations)

Fix

Acknowledge this design trade-off. For future versions, consider if a controlled mechanism for updating these addresses (e.g., via a governance-controlled proxy or a timelock) might be beneficial, weighing the added complexity against the operational flexibility gained. For the current version, ensure clear documentation and operational plans for redeployment scenarios.

Status

Unresolved

Info

Use of Well-Audited OpenZeppelin Libraries

The contract leverages standard and widely-audited OpenZeppelin contracts (ERC20, IERC165, Strings). This significantly reduces the risk of common vulnerabilities related to token standards and utility functions, contributing to the overall robustness of the codebase. (7.2 Code Security)I-01

Issue

The contract leverages standard and widely-audited OpenZeppelin contracts (ERC20, IERC165, Strings). This significantly reduces the risk of common vulnerabilities related to token standards and utility functions, contributing to the overall robustness of the codebase. (7.2 Code Security)

Fix

Continue to utilize well-established and audited libraries for core functionalities to maintain high security standards.

Status

Unresolved

Info

Clear and Effective Access Control

The onlyBridge modifier is correctly implemented and applied to the mint and burn functions, ensuring that only the designated BRIDGE contract can perform these critical operations. This clear access control mechanism prevents unauthorized token supply manipulation. (7.3 Access Control)I-02

Issue

The onlyBridge modifier is correctly implemented and applied to the mint and burn functions, ensuring that only the designated BRIDGE contract can perform these critical operations. This clear access control mechanism prevents unauthorized token supply manipulation. (7.3 Access Control)

Fix

Maintain clear and explicit access control mechanisms for all sensitive functions to prevent unauthorized actions.

Status

Unresolved

Info

Non-Upgradeability

The contract is not designed with an upgrade proxy pattern. This simplifies the contract's architecture and reduces the attack surface associated with upgrade mechanisms. However, any future feature enhancements or bug fixes would necessitate deploying a new contract and updating all integrations, including the BRIDGE contract, to point to the new address. (7.7 Upgrades)I-03

Issue

The contract is not designed with an upgrade proxy pattern. This simplifies the contract's architecture and reduces the attack surface associated with upgrade mechanisms. However, any future feature enhancements or bug fixes would necessitate deploying a new contract and updating all integrations, including the BRIDGE contract, to point to the new address. (7.7 Upgrades)

Fix

Document the non-upgradeable nature of the contract and establish a clear process for redeployment and migration if future changes are required. Ensure all dependent systems are aware of this design choice.

Status

Unresolved

Analysis

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

The OptimismMintableERC20 contract provides a standard ERC-20 token with controlled minting and burning capabilities, intended for cross-chain bridging. The contract leverages well-audited OpenZeppelin libraries and implements clear access control, restricting token supply manipulation to a designated bridge address. While the contract's internal code is robust, a significant centralization risk exists due to its reliance on the security of the external bridge contract, which has exclusive control over token minting and burning. The contract is non-upgradeable, simplifying its architecture but requiring redeployment for any future changes.

Technical7/10Low risk

The contract exhibits strong technical security, leveraging battle-tested OpenZeppelin libraries for its ERC20 implementation (7.2 Code Security). Access control for critical mint and burn functions is robustly enforced via the onlyBridge modifier, ensuring only the designated bridge can alter token supply (7.3 Access Control). The architecture is straightforward, with REMOTE_TOKEN and BRIDGE addresses set as immutable, preventing post-deployment changes (7.1 Architecture). While immutability enhances security, it introduces operational inflexibility if these addresses need updates (7.8 Operations).

Governance1/10High risk

The economic model of the OptimismMintableERC20 token is inherently tied to the security of its external BRIDGE contract (7.4 Economic, 7.6 External). The BRIDGE possesses exclusive rights to mint and burn tokens, creating a significant centralization risk; a compromise of the bridge would directly impact the token's integrity and value (7.5 Governance). Therefore, the overall economic security is largely dependent on the robustness and governance of the external bridge system.

Upgrades3/10High risk

This contract is designed without an upgradeability mechanism, which simplifies its architecture and reduces the attack surface associated with proxy patterns (7.7 Upgrades). The Semver implementation provides clear versioning information but does not enable in-place upgrades. Consequently, any future modifications or bug fixes would necessitate a complete redeployment of the contract and subsequent updates to all integrated systems, including the BRIDGE contract.

Final RecommendationWhat to do about this score

Prioritize a comprehensive security audit of the associated BRIDGE contract, as its security directly dictates the integrity of this token.

Ensure robust operational procedures are in place for managing the BRIDGE address, including multi-signature controls and emergency response plans. Given the non-upgradeable nature, plan for potential future redeployments and the associated migration efforts if critical addresses or logic require changes.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0xcd2f…9bcb
Deployer0xc3c2…9fe5
Badge for your website
Aavegotchi GHST Token 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. Sep 4, 202660Medium
  2. Aug 30, 202658Medium

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

Frequently Asked Questions

What is the GHST contract address?

The Aavegotchi GHST Token (GHST) contract on Base is 0xcd2f22236dd9dfe2356d7c543161d4d260fd9bcb. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Aavegotchi GHST Token a scam?

Quantum Audit's risk score for Aavegotchi GHST Token is 60/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is GHST liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $912.3K.

Who holds GHST?

As of Sep 4, 2026, the 10 largest holders own 90.3% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Morpho TokenMORPHO · Base60MediumTether USDUSDT · Base60MediumevoBase60MediumBIOBase60MediumHydrexHYDX · Base60MediumFree BotsBOTS · Base60Medium

Would You Like a More Detailed Audit of Aavegotchi GHST Token?

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