Quantum Audit Logo

Is Tevaera Safe?

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

Tevaera TEVA
0x0030…894c
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The TevaTokenV1 contract, deployed as an upgradeable proxy, implements a standard ERC20 token with burnable, capped, permit, and voting functionalities. It leverages battle-tested OpenZeppelin libraries, providing a solid technical foundation. However, the audit identified significant centralization risks, with a single EOA controlling all critical administrative roles and upgrade capabilities. Additionally, the high potential for token dilution presents a notable economic risk. While the code quality is high, these centralization and economic factors elevate the overall risk profile.

3 High2 Medium1 Low
Volume 24h
$1.0K
Liquidity
$31.1K
Price
$0.0004777
Token Age
1y
Top 10 Holders
68.2%

Security Findings

3 High2 Med1 Low
High

Centralized Control of Critical Roles

H-01The `DEFAULT_ADMIN_ROLE`, `MINTER_ADMIN_ROLE`, and `BURNER_ADMIN_ROLE` are all granted to `msg.sender` during initialization. In a TransparentUpgradeableProxy setup, this `msg.sender` is typically the `ProxyAdmin` owner, which is an EOA (0x936d…aabe). This single EOA has complete control over granting and revoking `MINTER_ROLE` and `BURNER_ROLE`, effectively centralizing control over token supply and destruction. A compromise of this EOA would allow an attacker to mint tokens up to the cap or burn tokens arbitrarily.
IssueThe `DEFAULT_ADMIN_ROLE`, `MINTER_ADMIN_ROLE`, and `BURNER_ADMIN_ROLE` are all granted to `msg.sender` during initialization. In a TransparentUpgradeableProxy setup, this `msg.sender` is typically the `ProxyAdmin` owner, which is an EOA (). This single EOA has complete control over granting and revoking `MINTER_ROLE` and `BURNER_ROLE`, effectively centralizing control over token supply and destruction. A compromise of this EOA would allow an attacker to mint tokens up to the cap or burn tokens arbitrarily.
FixTransfer the `DEFAULT_ADMIN_ROLE`, `MINTER_ADMIN_ROLE`, and `BURNER_ADMIN_ROLE` to a multi-signature wallet (e.g., Gnosis Safe) or a robust DAO governance contract. This distributes control and requires multiple approvals for critical operations, significantly reducing the risk of a single point of failure.
StatusUnresolved
High

Centralized Upgrade Authority

H-02The `TransparentUpgradeableProxy` is controlled by a `ProxyAdmin` contract, which is owned by a single EOA (0x936d…aabe). This EOA has sole authority to upgrade the contract's implementation logic. A compromise of this EOA would allow an attacker to deploy malicious contract logic, potentially leading to loss of funds, freezing of assets, or other severe consequences.
IssueThe `TransparentUpgradeableProxy` is controlled by a `ProxyAdmin` contract, which is owned by a single EOA (). This EOA has sole authority to upgrade the contract's implementation logic. A compromise of this EOA would allow an attacker to deploy malicious contract logic, potentially leading to loss of funds, freezing of assets, or other severe consequences.
FixTransfer ownership of the `ProxyAdmin` contract to a multi-signature wallet or a DAO. This ensures that any future upgrades require consensus from multiple trusted parties, enhancing the security and trustworthiness of the upgrade process.
StatusUnresolved
High

High Potential for Token Dilution

H-03The provided data indicates a `mint_annual_dilution_pct` of 258.14%. While the token has a `MAX_CAP` of 4 billion, this high dilution rate suggests a significant capacity for rapid token inflation. If the `MINTER_ROLE` is misused or compromised, or if the minting schedule is not transparently managed, this could lead to substantial dilution of existing token holders' value, impacting market stability and investor confidence.
IssueThe provided data indicates a `mint_annual_dilution_pct` of 258.14%. While the token has a `MAX_CAP` of 4 billion, this high dilution rate suggests a significant capacity for rapid token inflation. If the `MINTER_ROLE` is misused or compromised, or if the minting schedule is not transparently managed, this could lead to substantial dilution of existing token holders' value, impacting market stability and investor confidence.
FixClearly communicate the project's minting strategy, schedule, and rationale to the community. Consider implementing additional controls such as a timelock for large minting operations or a more granular, rate-limited minting mechanism to provide greater predictability and prevent sudden supply shocks. Regular transparency reports on token supply changes are also recommended.
StatusUnresolved
Medium

Lack of On-Chain Governance for Critical Parameters

M-01While the contract includes `ERC20VotesUpgradeable`, indicating a potential for off-chain voting, there is no integrated on-chain governance mechanism (e.g., OpenZeppelin Governor) that allows token holders to directly influence critical contract parameters, role assignments, or upgrade decisions. All such decisions currently rest with the centralized administrative EOA.
IssueWhile the contract includes `ERC20VotesUpgradeable`, indicating a potential for off-chain voting, there is no integrated on-chain governance mechanism (e.g., OpenZeppelin Governor) that allows token holders to directly influence critical contract parameters, role assignments, or upgrade decisions. All such decisions currently rest with the centralized administrative EOA.
FixExplore integrating a robust on-chain governance module, such as OpenZeppelin's Governor contracts, to gradually decentralize decision-making power. This would allow token holders to propose, vote on, and execute changes to the contract, including role management and upgrades, thereby enhancing community participation and long-term resilience.
StatusUnresolved
Medium

Reliance on EOA for Critical Operations

M-02The `DEFAULT_ADMIN_ROLE` for the `AccessControl` and the owner of the `ProxyAdmin` are both single External Owned Accounts (EOAs). This creates a single point of failure where the compromise of a single private key could lead to complete control over the token contract, including minting, burning, and upgrading its logic. This poses a significant operational security risk.
IssueThe `DEFAULT_ADMIN_ROLE` for the `AccessControl` and the owner of the `ProxyAdmin` are both single External Owned Accounts (EOAs). This creates a single point of failure where the compromise of a single private key could lead to complete control over the token contract, including minting, burning, and upgrading its logic. This poses a significant operational security risk.
FixTransition all critical EOA roles to multi-signature wallets (e.g., Gnosis Safe) with a sufficient number of signers. This enhances security by requiring multiple independent approvals for sensitive operations, significantly reducing the risk associated with a single private key compromise.
StatusUnresolved
Low

Block Timestamp Dependency for Delegation Expiry

L-01The `delegateOnBehalf` function uses `block.timestamp` to check the `_expiry` of a delegation signature. While generally acceptable for time-based checks, `block.timestamp` can be manipulated by miners within a small window (typically up to 15 seconds). This could potentially allow a miner to slightly extend or shorten the validity period of a delegation signature.
IssueThe `delegateOnBehalf` function uses `block.timestamp` to check the `_expiry` of a delegation signature. While generally acceptable for time-based checks, `block.timestamp` can be manipulated by miners within a small window (typically up to 15 seconds). This could potentially allow a miner to slightly extend or shorten the validity period of a delegation signature.
FixFor delegation expiry, this minor manipulation risk is generally considered acceptable and does not typically pose a critical security threat. No immediate code change is required, but it's important to be aware of this characteristic of `block.timestamp` when designing time-sensitive logic.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract (7.1 Architecture, 7.2 Code Security) utilizes battle-tested OpenZeppelin upgradeable libraries, ensuring a robust and secure foundation for ERC20 functionality, access control, and upgradeability. The `delegateOnBehalf` function correctly implements EIP-712 typed data hashing and `SignatureChecker` for secure off-chain delegation. Role-based access control is properly structured with admin roles for minters and burners (7.3 Access Control). However, the primary technical risk lies in the highly centralized access control, where a single EOA holds the `DEFAULT_ADMIN_ROLE` and can manage all other critical roles, posing a single point of failure (7.8 Operations).

GovernanceHigh1/10

The token has a hard cap (MAX_CAP) of 4 billion tokens, and minting/burning are role-gated, providing some economic control (7.4 Economic). ERC20Votes is included, suggesting potential future governance integration. However, all critical roles (DEFAULT_ADMIN_ROLE, MINTER_ADMIN_ROLE, BURNER_ADMIN_ROLE) are controlled by a single EOA, leading to high centralization (7.5 Governance). The reported annual dilution rate of 258% indicates a significant potential for supply inflation, which could negatively impact token value if not managed transparently (7.4 Economic). There is no on-chain governance mechanism for token holders to influence critical parameters.

UpgradesHigh1/10

The contract employs the Transparent Upgradeable Proxy pattern with OpenZeppelin's `Initializable` and `_disableInitializers` for safe and standard upgradeability (7.7 Upgrades). This allows for future enhancements and bug fixes without redeploying the token. However, the upgrade process is entirely controlled by a single `ProxyAdmin` owner (an EOA), introducing a significant centralization risk. A compromise of this EOA would allow unauthorized contract logic changes (7.7 Upgrades).

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

68.2% in top 10
62.7% in wallets5.5% in contracts
Effective Concentration64.9%

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

$59.9K across 2 pairs
AerodromeWETHanalysed$31.1K51.9%Uniswap v3WETH$28.8K48.1%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x936d…aabe
Unlocked LP Held By
0x024d…21460x4d7d…5d49

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

What Raised This Score

11 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, nominal cap 258%/year — effectively unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • OZ ProxyAdmin -> Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 50% (68.2% total → 64.9% effective; 62.7% in EOAs, 5.5% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 52% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 52% of DEX liquidity)
  • 3 High finding(s) from audit
  • 2 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
Intuition (TRUST)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 Tevaera?

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

Get Detailed Audit