Quantum Audit Logo
Launch App

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

Is Tevaera Safe?

TEVABase
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
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings3 High · 2 Medium · 1 Low6
SummaryAI Copilot

The TevaTokenV1 contract, deployed as an upgradeable proxy, implements a standard ERC20 token with burnable, capped, permit, and voting functionalities.

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

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
5.5%Contracts62.7%Wallets31.8%Everyone else
5.5%62.7%Wallets31.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
68.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.5%
  • Walletsanonymous holders, free to sell62.7%
  • Everyone elsethe rest of the supply31.8%
Effective concentrationwhat the score reads64.9%
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$59.9K across 2 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$31.1KShare of depth51.9%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

3 High2 Medium1 Low
High

Centralized Control of Critical Roles

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

Issue

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

Fix

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

Status

Unresolved

High

Centralized Upgrade Authority

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

Issue

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

Fix

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

Status

Unresolved

High

High Potential for Token Dilution

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

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of On-Chain Governance for Critical Parameters

While 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Reliance on EOA for Critical Operations

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

Issue

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

Fix

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

Status

Unresolved

Low

Block Timestamp Dependency for Delegation Expiry

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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

Governance1/10High risk

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.

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

To mitigate the identified risks, it is strongly recommended to transition all critical administrative roles, including the DEFAULT_ADMIN_ROLE, MINTER_ADMIN_ROLE, BURNER_ADMIN_ROLE, and the ProxyAdmin ownership, to a robust multi-signature wallet (e.g., Gnosis Safe) or a decentralized autonomous organization (DAO).

This will eliminate single points of failure and enhance the security posture against private key compromise or malicious intent. Furthermore, clear communication regarding the token's minting schedule and rationale is crucial, especially given the high potential for dilution. Consider implementing a timelock for significant minting operations or a more granular, transparent control mechanism for supply adjustments to build trust and predictability within the ecosystem.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0x0030…894c
Deployer0x936d…aabe
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → EOA
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Tevaera 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. Aug 13, 2026100Critical

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

Frequently Asked Questions

What is the TEVA contract address?

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

Is Tevaera a scam?

Quantum Audit's risk score for Tevaera is 100/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 TEVA liquidity locked?

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

Who holds TEVA?

As of Sep 4, 2026, the 10 largest holders own 68.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
IntuitionTRUST · Base98CriticalValtherix AIVLTX · Base94CriticalMineBeanBEAN · Base89CriticalStrike RobotSR · Base87CriticalCrynux TokenCNX · Base87CriticalFLock.ioFLOCK · Base85Critical

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