Quantum Audit Logo

Is VERA Safe?

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

Is this your token? Publish your own audit on this page →

VERA VRA
0xf411…7255
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

4 Informational
Volume 24h
$24.5K
Liquidity
$62.6K
Price
$0.0000161
Token Age
5y
Top 10 Holders
38.3%

Security Findings

4 Info
Info

ERC777 Hooks Design Considerations

I-01The 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`.
IssueThe 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`.
FixProtocols 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.
StatusUnresolved
Info

ERC777/ERC20 Compatibility Challenges

I-02Although 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.
IssueAlthough 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.
FixDevelopers 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.
StatusUnresolved
Info

Centralized Operator Mechanism

I-03The 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.
IssueThe 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.
FixUsers 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.
StatusUnresolved
Info

Lack of Administrative Functions (Mint/Pause)

I-04The 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.
IssueThe 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.
FixConfirm 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium5/10

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.

UpgradesMedium4/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedPass
Not a ProxyPass

Holder Composition

38.3% in top 10
38.3% in wallets0.0% in contracts
Effective Concentration38.3%

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

$82.8K across 5 pairs
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 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

LP Locked99.1% · Null Address, UNCX
Top-1 Unlocked Holder0.7%
Lock ExpiryExpired 1831d ago

Key Addresses

6 addresses
Deployer
0xdeca…1b74
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.

What Raised This Score

3 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

Related Audits

6 more on the record
PrometheusMedium RiskStarmanMedium RiskI love puppies (PUPPIES)Medium RiskAliensMedium RiskwojakMedium RiskBalancer (BAL)Medium Risk

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