Quantum Audit Logo
Launch App

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

Is Intuition Safe?

TRUSTBase
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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical2/10Governance1/10Upgrades1/10Checks passed1 of 5Findings2 Critical · 1 High3
SummaryAI Copilot

The audit of the Intuition Trust contract (implementation of the token) identified critical vulnerabilities related to its upgradeable design and tokenomics.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.6%
  • LP top3 unlocked holders = 100.0%
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
39.7%Contracts37.5%Wallets22.8%Everyone else
39.7%Contracts37.5%Wallets22.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
77.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking39.7%
  • Walletsanonymous holders, free to sell37.5%
  • Everyone elsethe rest of the supply22.8%
Effective concentrationwhat the score reads53.4%
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$298.5K across 6 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$273.3KShare of depth91.6%
Top-1 Unlocked Holder92.6%
Top-3 Unlocked100.0%
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.

Security Findings

2 Critical1 High
Critical

ERC20 Initialization Missing in Trust Contract

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

Critical

Minting Logic and Supply Caps Bypassed

The 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.C-02

Issue

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

Fix

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

Status

Unresolved

High

Unused TrustToken Minting Logic and State Variables

Due 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.H-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical2/10High risk

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

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to immediately address the critical issues identified.

The Trust contract must be upgraded to correctly initialize the ERC20 component by calling __ERC20_init and to properly integrate or remove the TrustToken's minting logic and supply caps. A thorough review of the intended tokenomics and how they are implemented in the Trust contract is essential to ensure that supply limits and minter roles function as designed. Consider a full re-evaluation of the inheritance structure and function overrides to prevent similar logic bypasses.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0x6cd9…d8a3
Deployer0xc288…fcb6
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Timelock
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Intuition 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, 202698Critical
  2. Aug 13, 202697Critical

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

Frequently Asked Questions

What is the TRUST contract address?

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

Is Intuition a scam?

Quantum Audit's risk score for Intuition is 98/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is TRUST liquidity locked?

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

Who holds TRUST?

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

Related Audits

6 more on the recordAll audits
TevaeraTEVA · Base100CriticalValtherix AIVLTX · Base94CriticalMineBeanBEAN · Base89CriticalStrike RobotSR · Base87CriticalCrynux TokenCNX · Base87CriticalFLock.ioFLOCK · Base85Critical

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 Is this your token? Publish your own audit on this page