Quantum Audit Logo

Is Aligned Token Safe?

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

Aligned Token ALIGN
0x53f3…0a8d
Base
Not verifiedThis 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.
Last checked 8d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The OptimismMintableERC20 contract serves as a standard ERC-20 token with minting and burning capabilities restricted to a designated bridge address. The contract is well-structured, utilizes OpenZeppelin libraries, and employs immutable variables for critical addresses and decimals. Identified issues are minor, primarily related to interface consistency and code redundancy, with no critical or high-severity vulnerabilities found.

1 Medium1 Low1 Informational
Volume 24h
$41.4K
Liquidity
$131.4K
Price
$0.005905
Token Age
1y
Top 10 Holders
89.9%

Security Findings

1 Med1 Low1 Info
Medium

Interface Mismatch for `bridge()` Function

M-01The `IOptimismMintableERC20` interface declares the `bridge()` function as `external returns (address);`, implying it might be a state-changing or non-view function. However, the `OptimismMintableERC20` implementation correctly defines it as `public view returns (address)`. While the implementation is functionally correct for a getter, this mismatch in the interface definition could lead to confusion or unexpected behavior if external tools or contracts strictly adhere to the interface's non-view declaration.
IssueThe `IOptimismMintableERC20` interface declares the `bridge()` function as `external returns (address);`, implying it might be a state-changing or non-view function. However, the `OptimismMintableERC20` implementation correctly defines it as `public view returns (address)`. While the implementation is functionally correct for a getter, this mismatch in the interface definition could lead to confusion or unexpected behavior if external tools or contracts strictly adhere to the interface's non-view declaration.
FixUpdate the `IOptimismMintableERC20` interface to declare `function bridge() external view returns (address);` to accurately reflect the `view` nature of the function in the implementation.
StatusUnresolved
Low

Redundant Getter Functions

L-01The contract includes multiple functions that return the same immutable addresses: `l1Token()` and `remoteToken()` both return `REMOTE_TOKEN`; `l2Bridge()` and `bridge()` both return `BRIDGE`. While not a security vulnerability, this redundancy adds unnecessary code complexity and slightly increases deployment gas costs.
IssueThe contract includes multiple functions that return the same immutable addresses: `l1Token()` and `remoteToken()` both return `REMOTE_TOKEN`; `l2Bridge()` and `bridge()` both return `BRIDGE`. While not a security vulnerability, this redundancy adds unnecessary code complexity and slightly increases deployment gas costs.
FixConsolidate redundant getter functions. For example, remove `l1Token()` and `l2Bridge()`, relying solely on `remoteToken()` and `bridge()` respectively, or vice-versa, ensuring consistency with the primary interface names.
StatusUnresolved
Info

Centralized Control by Bridge Address

I-01The `mint` and `burn` functionalities are exclusively controlled by the `BRIDGE` address via the `onlyBridge` modifier. This design is fundamental to the cross-chain bridging mechanism, where the L2 token supply is managed by an L1 bridge. However, it means the security and integrity of the entire token supply on L2 heavily relies on the security of the `BRIDGE` contract. A compromise of the `BRIDGE` would allow arbitrary minting or burning, potentially devaluing the token.
IssueThe `mint` and `burn` functionalities are exclusively controlled by the `BRIDGE` address via the `onlyBridge` modifier. This design is fundamental to the cross-chain bridging mechanism, where the L2 token supply is managed by an L1 bridge. However, it means the security and integrity of the entire token supply on L2 heavily relies on the security of the `BRIDGE` contract. A compromise of the `BRIDGE` would allow arbitrary minting or burning, potentially devaluing the token.
FixThis is an inherent design choice for mintable bridge tokens. Ensure the `BRIDGE` contract itself is highly secured, thoroughly audited, and follows robust operational security practices to mitigate the risk of its compromise.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates strong technical security (7.2 Code Security) by leveraging OpenZeppelin's ERC20 implementation and Solidity 0.8.15's default checked arithmetic. Access control (7.3 Access Control) for minting and burning is correctly enforced via the `onlyBridge` modifier, ensuring only the designated `BRIDGE` address can modify token supply. Key parameters like `REMOTE_TOKEN`, `BRIDGE`, and `DECIMALS` are set as immutable in the constructor, enhancing predictability and security (7.1 Architecture). A minor technical issue involves an interface mismatch for the `bridge()` function, and some getter functions are redundant.

GovernanceHigh1/10

The economic model (7.4 Economic) of this token relies entirely on the `BRIDGE` address for supply control, as it is the sole entity capable of minting and burning tokens. This design is inherent to cross-chain mintable tokens but introduces a significant centralized dependency (7.6 External). The security of the entire L2 token supply is directly tied to the security and integrity of the `BRIDGE` contract. While this contract itself does not have governance (7.5 Governance), the external `BRIDGE` contract's governance and operational security (7.8 Operations) are paramount.

UpgradesHigh3/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). All critical parameters are set as immutable in the constructor, meaning its logic cannot be changed post-deployment. This eliminates upgrade-related risks such as proxy storage collisions or incorrect upgrade paths.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

89.9% in top 10
54.5% in wallets35.4% in contracts
Effective Concentration68.7%

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

$131.6K across 8 pairs
AerodromeUSDCanalysed$131.4K99.8%Uniswap v4USDC$980.1%Uniswap v4ETH$390.0%Uniswap v4AERO$300.0%Uniswap v4USDC$250.0%Uniswap v4USDT$200.0%
Show 2 more pairsShow less
Uniswap v4ETH$90.0%Uniswap v4ETH$30.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 Holder79.5%
Top-3 Unlocked95.9%

Key Addresses

11 addresses
Deployer
0xfd42…ef17
Unlocked LP Held By
0xde15…a7de0x5a01…a6920xd0f5…48170x6c94…80160xe1f6…806f0xdd3f…cd9b0x3810…cc660x8db2…2cbf0x1cea…59db0xbe04…8dec

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 status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (89.9% total → 68.7% effective; 54.5% in EOAs, 35.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 79.5% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 95.9% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 Medium 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

Related Audits

6 more on the record
VelvetHigh RiskDiemHigh RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High RiskUmiaHigh RiskLisk (LSK)High Risk

Would You Like a More Detailed Audit of Aligned Token?

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

Get Detailed Audit