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.

On-chain security analysis — is it a scam or legit?
Is VERA Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Walletsanonymous holders, free to sell38.3%
- Everyone elsethe rest of the supply61.7%
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- Uniswap v2WETHAnalysed$62.6K75.6%
- Uniswap v4ETH$13.7K16.5%
- Uniswap v3WETH$6.0K7.3%
- VerseUSDT$4200.5%
- Uniswap v4USDC$340.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xcf9d…21450xc31d…d40d0x2f0e…64fb0x70d3…dbe90x1f2f…f387No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
InfoERC777 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
InfoERC777/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
InfoCentralized 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
InfoLack 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 4The 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.
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.
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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