Quantum Audit Logo

Is Intuition Safe?

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

Intuition TRUST
0x6cd9…d8a3
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the Intuition Trust contract (implementation of the token) identified critical vulnerabilities related to its upgradeable design and tokenomics. Specifically, the ERC20 initialization is missing, and the intended minting logic with supply caps from the inherited `TrustToken` contract is completely bypassed. This allows an authorized controller to mint an unlimited supply of tokens, severely impacting the token's economic model. While the proxy setup is robust, these implementation flaws pose significant risks.

2 Critical1 High
Volume 24h
$135.7K
Liquidity
$273.3K
Price
$0.05355
Token Age
1y
Top 10 Holders
77.2%

Security Findings

2 Crit1 High
Critical

ERC20 Initialization Missing in `Trust` Contract

C-01The `Trust` contract inherits `ERC20Upgradeable` via `TrustToken`, but its `reinitialize` function only calls `__AccessControl_init()`. The `TrustToken` contract has an `init()` function that calls `__ERC20_init("TRUST", "TRUST")`, but this `init()` function is never called by the `Trust` contract. Consequently, the ERC20 token's name, symbol, and decimals are not properly initialized, which can lead to display issues in wallets/explorers and potential integration problems with DeFi protocols.
IssueThe `Trust` contract inherits `ERC20Upgradeable` via `TrustToken`, but its `reinitialize` function only calls `__AccessControl_init()`. The `TrustToken` contract has an `init()` function that calls `__ERC20_init("TRUST", "TRUST")`, but this `init()` function is never called by the `Trust` contract. Consequently, the ERC20 token's name, symbol, and decimals are not properly initialized, which can lead to display issues in wallets/explorers and potential integration problems with DeFi protocols.
FixEnsure that the `reinitialize` function in `Trust` calls the `init()` function of `TrustToken` or directly calls `__ERC20_init` with the desired token name and symbol. For example, `super.init()` or `__ERC20_init("Intuition", "INTU")` should be added to `reinitialize`.
StatusUnresolved
Critical

Minting Logic and Supply Caps Bypassed

C-02The `Trust` contract's `mint(address to, uint256 amount)` function overrides the `mint` function from `TrustToken`. However, the `Trust` contract's implementation only calls `_mint(to, amount)` (the internal ERC20 mint) and does not call `super.mint()` or otherwise incorporate the logic from `TrustToken`'s `mint` function. This means the `MINTER_A`/`MINTER_B` restrictions, `MAX_SUPPLY` check, `totalMinted` updates, and `minterAmountMinted` tracking from `TrustToken` are completely bypassed. As a result, the `baseEmissionsController` can mint an unlimited amount of tokens, ignoring all intended supply caps and minter-specific limits.
IssueThe `Trust` contract's `mint(address to, uint256 amount)` function overrides the `mint` function from `TrustToken`. However, the `Trust` contract's implementation only calls `_mint(to, amount)` (the internal ERC20 mint) and does not call `super.mint()` or otherwise incorporate the logic from `TrustToken`'s `mint` function. This means the `MINTER_A`/`MINTER_B` restrictions, `MAX_SUPPLY` check, `totalMinted` updates, and `minterAmountMinted` tracking from `TrustToken` are completely bypassed. As a result, the `baseEmissionsController` can mint an unlimited amount of tokens, ignoring all intended supply caps and minter-specific limits.
FixThe `Trust` contract's `mint` function must be refactored to correctly enforce the intended minting logic. If the `TrustToken`'s minting logic (minter caps, max supply) is still desired, the `Trust` contract's `mint` function should call `super.mint(to, amount)` or replicate the necessary checks and state updates. If the `TrustToken` logic is deprecated, it should be explicitly removed or clearly documented, and new supply caps should be implemented in `Trust` if desired.
StatusUnresolved
High

Unused `TrustToken` Minting Logic and State Variables

H-01Due to the `Trust` contract's `mint` function overriding and bypassing the `TrustToken`'s `mint` function (C-02), the `MAX_SUPPLY`, `MINTER_A`, `MINTER_B` constants, and the `totalMinted`, `minterAmountMinted` state variables within `TrustToken` are effectively dead code. They are defined but never utilized or updated by the live `Trust` contract logic. This creates a false sense of security, makes the code harder to understand, and could lead to confusion regarding the actual tokenomics.
IssueDue to the `Trust` contract's `mint` function overriding and bypassing the `TrustToken`'s `mint` function (C-02), the `MAX_SUPPLY`, `MINTER_A`, `MINTER_B` constants, and the `totalMinted`, `minterAmountMinted` state variables within `TrustToken` are effectively dead code. They are defined but never utilized or updated by the live `Trust` contract logic. This creates a false sense of security, makes the code harder to understand, and could lead to confusion regarding the actual tokenomics.
FixAlign the code with the intended functionality. If the `TrustToken` minting logic is to be used, ensure it is correctly integrated (as per C-02 recommendation). If it is no longer relevant, consider removing these unused constants and state variables from `TrustToken` or refactoring the inheritance to avoid inheriting deprecated logic, to improve clarity and prevent misleading information.
StatusUnresolved

Category Ratings

TechnicalHigh2/10

The contract utilizes OpenZeppelin's upgradeable patterns and access control, which generally provide a solid foundation (7.1 Architecture, 7.2 Code Security). However, critical implementation errors were found. The `Trust` contract fails to initialize its ERC20 component, leading to an improperly configured token. Furthermore, its `mint` function overrides and completely bypasses the intended supply cap and minter-specific logic defined in the `TrustToken` parent, allowing the `baseEmissionsController` to mint an arbitrary amount of tokens without any limits (7.3 Access Control).

GovernanceHigh1/10

The economic model of the token is critically compromised due to the bypassed minting logic (7.4 Economic). The `MAX_SUPPLY` and minter-specific caps defined in `TrustToken` are not enforced by the `Trust` contract, enabling the `baseEmissionsController` to mint an unlimited supply. While `DEFAULT_ADMIN_ROLE` controls the `baseEmissionsController`, this role itself does not enforce the intended supply limits. The governance structure for the proxy admin is robust, utilizing a Timelock (7.5 Governance), but this does not mitigate the fundamental economic flaw in the token's implementation.

UpgradesHigh1/10

The contract employs the Transparent Upgradeable Proxy pattern with a ProxyAdmin owned by a Timelock, which is a strong setup for upgrade safety (7.7 Upgrades). The `reinitialize` function is correctly guarded, and `_disableInitializers()` is used. However, the critical issue of missing ERC20 initialization means that even after an upgrade, the token's core properties might remain uninitialized unless explicitly addressed in a future upgrade or reinitialization, which is not the standard way to handle ERC20 initialization.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

77.2% in top 10
37.5% in wallets39.7% in contracts
Effective Concentration53.4%

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

$298.5K across 6 pairs
AerodromeUSDCanalysed$273.3K91.6%Uniswap v3USDC$23.2K7.8%AerodromeUSDC$1.8K0.6%Uniswap v3WETH$850.0%PancakeswapUSDC$630.0%PancakeswapUSDC$00.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 Holder92.6%
Top-3 Unlocked100.0%

Key Addresses

11 addresses
Deployer
0xc288…fcb6
Unlocked LP Held By
0x6ccc…75fb0x983b…d23b0x72ff…caee0x8eb8…04190x5a01…a6920xe2ef…d6be0xa69c…c7150x586f…516b0x3ea7…c5bc0xb28b…891e

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (77.2% total → 53.4% effective; 37.5% in EOAs, 39.7% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.6% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • 2 Critical finding(s) from audit
  • 1 High 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
Tevaera (TEVA)Critical RiskValtherix AI (VLTX)Critical RiskMineBean (BEAN)Critical RiskStrike Robot (SR)Critical RiskFLock.io (FLOCK)Critical RiskCoinbase Wrapped MEGA (CBMEGA)Critical Risk

Would You Like a More Detailed Audit of Intuition?

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

Get Detailed Audit