Quantum Audit Logo
Launch App

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

Is VERA Safe?

VRAEthereum
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
SummaryAI Copilot

The VraToken contract is an ERC777 token implementation, also conforming to IERC20. The provided code snippet appears to be a standard, well-structured implementation, likely based on OpenZeppelin's battle-tested libraries.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (38.3% total → 38.3% effective; 38.3% in EOAs, 0.0% in contracts — moderate)

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 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
38.3%Wallets61.7%Everyone else
38.3%Wallets61.7%Everyone else
WalletsEveryone elseBubble area = share of supply
38.3%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell38.3%
  • Everyone elsethe rest of the supply61.7%
Effective concentrationwhat the score reads38.3%
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$82.8K across 5 pairs
LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$62.6KShare of depth75.6%
LP Locked99.1% · Null Address, UNCX
Top-1 Unlocked Holder0.7%
Lock ExpiryExpired 1831d ago
Unlocked LP held by
0xcf9d…21450xc31d…d40d0x2f0e…64fb0x70d3…dbe90x1f2f…f387

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

Security Findings

4 Info
Info

ERC777 Hooks Design Considerations

The ERC777 standard includes tokensReceived and tokensToSend hooks, which trigger external calls to recipient or sender contracts during transfers. While the VraToken contract itself appears to follow best practices to prevent internal reentrancy (e.g., Checks-Effects-Interactions pattern), these hooks introduce a reentrancy risk for integrating contracts or malicious recipients/senders if not handled carefully. For example, a malicious recipient could re-enter the calling contract during tokensReceived.I-01

Issue

The ERC777 standard includes tokensReceived and tokensToSend hooks, which trigger external calls to recipient or sender contracts during transfers. While the VraToken contract itself appears to follow best practices to prevent internal reentrancy (e.g., Checks-Effects-Interactions pattern), these hooks introduce a reentrancy risk for integrating contracts or malicious recipients/senders if not handled carefully. For example, a malicious recipient could re-enter the calling contract during tokensReceived.

Fix

Protocols and applications integrating with VraToken must implement robust reentrancy guards and carefully manage state changes within their tokensReceived or tokensToSend implementations. Thorough testing of all interaction flows is crucial to ensure secure integration.

Status

Unresolved

Info

ERC777/ERC20 Compatibility Challenges

Although VraToken implements the IERC20 interface, ERC777 tokens can exhibit different behaviors compared to pure ERC20 tokens due to the presence of hooks and distinct transfer semantics. This can lead to compatibility issues with DeFi protocols, exchanges, or wallets that are designed exclusively for ERC20 and do not account for ERC777-specific features like tokensReceived or operatorSend. This may limit the token's interoperability with certain parts of the ecosystem.I-02

Issue

Although VraToken implements the IERC20 interface, ERC777 tokens can exhibit different behaviors compared to pure ERC20 tokens due to the presence of hooks and distinct transfer semantics. This can lead to compatibility issues with DeFi protocols, exchanges, or wallets that are designed exclusively for ERC20 and do not account for ERC777-specific features like tokensReceived or operatorSend. This may limit the token's interoperability with certain parts of the ecosystem.

Fix

Developers integrating VraToken into existing ERC20-centric systems should perform comprehensive compatibility testing. Consider providing clear documentation on ERC777-specific behaviors and potential integration nuances to avoid unexpected issues for users and developers.

Status

Unresolved

Info

Centralized Operator Mechanism

The ERC777 standard allows token holders to authorize 'operators' who can send and burn tokens on their behalf using operatorSend and operatorBurn. While this is a core feature designed for flexibility (e.g., for dApps), it introduces a point of centralization and trust. If an authorized operator's address is compromised, they could potentially move or burn a user's tokens without explicit consent for each transaction.I-03

Issue

The ERC777 standard allows token holders to authorize 'operators' who can send and burn tokens on their behalf using operatorSend and operatorBurn. While this is a core feature designed for flexibility (e.g., for dApps), it introduces a point of centralization and trust. If an authorized operator's address is compromised, they could potentially move or burn a user's tokens without explicit consent for each transaction.

Fix

Users should be educated on the implications of authorizing operators and advised to only authorize trusted addresses. Projects should provide clear interfaces for users to manage (authorize/revoke) their operators. Implementations should ensure that the default operators (if any) are highly secure and their roles are clearly defined.

Status

Unresolved

Info

Lack of Administrative Functions (Mint/Pause)

The provided VraToken contract snippet does not include functions for minting new tokens or pausing token transfers. If the intention is for VraToken to have a fixed supply and be unpausable, this design choice aligns with decentralization principles and reduces administrative risk. However, if future flexibility for supply management or emergency pausing is desired, these features are absent.I-04

Issue

The provided VraToken contract snippet does not include functions for minting new tokens or pausing token transfers. If the intention is for VraToken to have a fixed supply and be unpausable, this design choice aligns with decentralization principles and reduces administrative risk. However, if future flexibility for supply management or emergency pausing is desired, these features are absent.

Fix

Confirm that the absence of minting and pausing capabilities aligns with the long-term vision and requirements for VraToken. If administrative control over supply or transfer pausing is ever needed, a new contract deployment would be required, as the current contract is immutable and lacks these features.

Status

Unresolved

Analysis

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

The VraToken contract is an ERC777 token implementation, also conforming to IERC20. The provided code snippet appears to be a standard, well-structured implementation, likely based on OpenZeppelin's battle-tested libraries. It utilizes SafeMath for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities. The primary considerations for ERC777 tokens revolve around their compatibility with existing ERC20 infrastructure and the design implications of their hooks, rather than direct vulnerabilities within the token contract itself. The audit assumes the truncated portion of the contract adheres to standard, secure implementation practices.

Technical8/10Low risk

The technical architecture (7.1) is a standard ERC777 token, which also implements IERC20, leveraging well-regarded libraries like SafeMath and Address for robust operations. Code security (7.2) is enhanced by SafeMath, preventing integer overflows/underflows. The contract's design for access control (7.3) follows the ERC777 operator pattern, allowing authorized third parties to manage tokens on behalf of holders. While the ERC777 hooks introduce external integration considerations, the contract itself appears to handle internal state changes securely before external calls, mitigating direct reentrancy vulnerabilities within its core logic.

Governance5/10Medium risk

The contract represents a basic token with no complex economic models (7.4) such as staking, lending, or dynamic fees. Its economic risk is inherently low due to its simplicity. There are no explicit governance mechanisms (7.5) implemented within the contract, meaning control over the token's parameters or upgrades is not decentralized. The token's supply appears to be fixed or managed externally, as no minting functions are present in the provided snippet.

Upgrades4/10Medium risk

The contract is not designed as an upgradeable proxy (7.7). This means its logic is immutable once deployed, eliminating risks associated with upgrade mechanisms such as proxy admin vulnerabilities, storage collisions, or malicious upgrade proposals. While this ensures immutability, it also means that any discovered vulnerabilities or desired feature enhancements would require a new contract deployment and migration.

Final RecommendationWhat to do about this score

It is recommended that any protocols or applications integrating with VraToken thoroughly understand the ERC777 standard, particularly the tokensReceived and tokensToSend hooks.

Implement robust reentrancy guards and compatibility checks in integrating contracts to prevent unexpected behavior or exploits. Users should be educated on the implications of authorizing ERC777 operators.

Contract & Record

1 audit on record
TypeVraToken
NetworkEthereum
Token age5y
Contract0xf411…7255
Deployer0xdeca…1b74
Badge for your website
VERA 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 17, 202632Low

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

Frequently Asked Questions

What is the VRA contract address?

The VERA (VRA) contract on Ethereum is 0xf411903cbc70a74d22900a5de66a2dda66507255. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is VERA a scam?

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

Is VRA liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $82.8K.

Who holds VRA?

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

Would You Like a More Detailed Audit of VERA?

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