Is Aavegotchi GHST Token (GHST) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Low3 Info

High

Centralization Risk and External Dependency on Bridge

H-01The `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)

IssueThe `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)

FixEnsure 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.

StatusUnresolved

Low

Immutability of Bridge and Remote Token Addresses

L-01The `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)

IssueThe `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)

FixAcknowledge 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.

StatusUnresolved

Info

Use of Well-Audited OpenZeppelin Libraries

I-01The 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)

IssueThe 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)

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

StatusUnresolved

Info

Clear and Effective Access Control

I-02The `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)

IssueThe `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)

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

StatusUnresolved

Info

Non-Upgradeability

I-03The 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)

IssueThe 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)

FixDocument 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.

StatusUnresolved

Category Ratings

TechnicalLow7/10

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).

GovernanceHigh1/10

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.

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

90.3% in top 10

5.5% in wallets84.8% in contracts

Effective Concentration39.5%

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.

Liquidity Depth

$912.3K across 9 pairs

AerodromeUSDCanalysed$700.8K AerodromeWETH$210.9K AerodromeUSDC$588 Uniswap v3WETH$36 Uniswap v4wstETH$2 SushiswapWETH$1

Show 3 more pairsShow less

AerodromeUSDC$1 AerodromeAERO$1 AerodromeWETH$0

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder50.1%

Top-3 Unlocked97.3%

Key Addresses

5 addresses

Deployer

0xc3c2…9fe5

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.

What Raised This Score

8 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

Is Aavegotchi GHST Token Safe?

Security Findings

Centralization Risk and External Dependency on Bridge

Immutability of Bridge and Remote Token Addresses

Use of Well-Audited OpenZeppelin Libraries

Clear and Effective Access Control

Non-Upgradeability

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

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