Quantum Audit Logo

Is Definitive Safe?

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

Definitive EDGE
0xed6e…f110
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DefinitiveToken contract is an upgradeable ERC-20 token utilizing OpenZeppelin's battle-tested libraries for core functionality, ownership, and UUPS upgradeability. While the technical implementation is robust and follows best practices, the contract exhibits a high degree of centralization due to the owner's ability to mint an unlimited supply of tokens. Additionally, a discrepancy in hardcoded constants was identified, and an unused constant exists. The owner is a multisig, which mitigates some centralization risks.

1 High1 Medium1 Informational
Volume 24h
$371.8K
Liquidity
$649.3K
Price
$0.09609
Token Age
1y
Top 10 Holders
83.8%

Security Findings

1 High1 Med1 Info
High

Centralized Token Minting

H-01The `mint(address to, uint256 amount)` function is callable by the contract owner (`DefinitiveConstants.MULTISIG_OWNER`) and allows for the creation of an arbitrary amount of new tokens at any time. This centralized control over the token supply introduces a significant economic risk, as it can lead to uncontrolled inflation, devaluing existing tokens and impacting the project's economic stability (7.4 Economic, 7.3 Access Control).
IssueThe `mint(address to, uint256 amount)` function is callable by the contract owner (`DefinitiveConstants.MULTISIG_OWNER`) and allows for the creation of an arbitrary amount of new tokens at any time. This centralized control over the token supply introduces a significant economic risk, as it can lead to uncontrolled inflation, devaluing existing tokens and impacting the project's economic stability (7.4 Economic, 7.3 Access Control).
FixConsider implementing a more decentralized or constrained minting mechanism. Options include: 1) Capping the total supply, 2) Implementing a time-locked minting schedule, 3) Requiring a broader governance vote for minting operations, or 4) Renouncing the minting capability entirely if a fixed supply is desired. If centralized minting is an intentional design choice, clearly communicate this economic model to all users and stakeholders.
StatusUnresolved
Medium

Discrepancy in Hardcoded Implementation Address

M-01The `DefinitiveConstants` library defines `DEFINITIVE_TOKEN_IMPLEMENTATION` as 0x0000…e325. However, the provided context states the live implementation address for the proxy 0xed6e…f110 is 0xc335…05f7. This mismatch between the hardcoded constant and the actual deployed address can lead to confusion, misconfiguration in deployment scripts, or incorrect assumptions about the contract's identity, potentially impacting future operations or integrations (7.6 External, 7.8 Operations).
IssueThe `DefinitiveConstants` library defines `DEFINITIVE_TOKEN_IMPLEMENTATION` as . However, the provided context states the live implementation address for the proxy is . This mismatch between the hardcoded constant and the actual deployed address can lead to confusion, misconfiguration in deployment scripts, or incorrect assumptions about the contract's identity, potentially impacting future operations or integrations (7.6 External, 7.8 Operations).
FixUpdate the `DEFINITIVE_TOKEN_IMPLEMENTATION` constant in `DefinitiveConstants.sol` to accurately reflect the deployed implementation address (). Ensure all hardcoded addresses in constant libraries are verified against live deployments and updated as necessary.
StatusUnresolved
Info

Unused Constant `INITIAL_OWNER`

I-01The `DefinitiveConstants` library defines an `INITIAL_OWNER` address (0xc9EC…32b8), but this constant is not utilized anywhere within the `DefinitiveToken` contract. The `initialize` function directly sets the owner to `MULTISIG_OWNER` (7.2 Code Security).
IssueThe `DefinitiveConstants` library defines an `INITIAL_OWNER` address (), but this constant is not utilized anywhere within the `DefinitiveToken` contract. The `initialize` function directly sets the owner to `MULTISIG_OWNER` (7.2 Code Security).
FixRemove unused constants to reduce contract bytecode size and improve code clarity, or ensure that all defined constants serve a clear purpose within the contract logic. This helps maintain a clean and efficient codebase.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The DefinitiveToken contract demonstrates strong technical foundations by inheriting from OpenZeppelin's `ERC20Upgradeable`, `OwnableUpgradeable`, `ERC20PermitUpgradeable`, and `UUPSUpgradeable` contracts (7.1 Architecture, 7.2 Code Security). The `_disableInitializers()` in the constructor and `initializer` modifier on `initialize()` correctly prevent re-initialization. Access control for upgrades is appropriately restricted to `onlyOwner` via `_authorizeUpgrade` (7.3 Access Control). The primary technical concern is a mismatch between a hardcoded constant and the live implementation address.

GovernanceHigh3/10

The economic model of DefinitiveToken presents a high centralization risk due to the `mint` function, which allows the owner to create an arbitrary amount of new tokens at any time (7.4 Economic). This capability can lead to significant inflation and devalue existing token holdings. While the owner is a multisig (`DefinitiveConstants.MULTISIG_OWNER`), which is a good governance practice for critical roles, it still represents a single point of control for token supply (7.5 Governance).

UpgradesHigh1/10

The contract implements the UUPS upgradeability pattern using OpenZeppelin's `UUPSUpgradeable` (7.7 Upgrades). The `_authorizeUpgrade` function is correctly overridden and restricted to the `onlyOwner` role, ensuring that only the designated multisig can initiate upgrades. This standard approach, combined with multisig ownership, provides a secure and well-understood upgrade mechanism. No immediate upgrade safety issues were identified within the contract's logic itself.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

83.8% in top 10
15.1% in wallets68.7% in contracts
Effective Concentration42.6%

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

$745.5K across 7 pairs
AerodromecbBTCanalysed$649.3K87.1%AerodromeMAMO$43.3K5.8%Uniswap v3USDC$27.0K3.6%AerodromecbBTC$20.1K2.7%Uniswap v3WETH$5.8K0.8%AerodromeAERO$20.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 Holder97.5%
Top-3 Unlocked98.6%

Key Addresses

11 addresses
Deployer
0x11ed…392d
Unlocked LP Held By
0xfc0f…8e110x2d8c…70b90xd83c…2f600x25fd…e6e70x5234…3f790x1c58…83f10x818a…15210x2742…6e5b0xdc25…e18f0xab70…b3ae

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 NOT renounced — Multisig (2-of-3)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (83.8% total → 42.6% effective; 15.1% in EOAs, 68.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 97.5% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • LP top3 unlocked holders = 98.6% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
Morpho Token (MORPHO)High RiskTether USD (USDT)High RiskevoHigh RiskBIOHigh RiskHydrex (HYDX)High RiskAavegotchi GHST Token (GHST)High Risk

Would You Like a More Detailed Audit of Definitive?

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

Get Detailed Audit