Quantum Audit Logo
Launch App

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

Is GRVT Safe?

BNB Chain
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Info3
SummaryAI Copilot

The BridgeToken contract, implemented as a BeaconProxy, provides standard ERC-20 functionalities including minting, burning, and EIP-712 permit.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 60.9%
  • LP top3 unlocked holders = 97.5%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (90.8% total → 43.2% effective; 11.5% in EOAs, 79.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($22,169 across 4 pairs — thin market)
  • LP top1 unlocked holder = 60.9% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 97.5% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 1 High 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
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
79.3%Contracts11.5%Wallets9.2%Everyone else
79.3%Contracts11.5%9.2%
ContractsWalletsEveryone elseBubble area = share of supply
90.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking79.3%
  • Walletsanonymous holders, free to sell11.5%
  • Everyone elsethe rest of the supply9.2%
Effective concentrationwhat the score reads43.2%
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$22.2K across 4 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$21.7KShare of depth97.8%
Top-1 Unlocked Holder60.9%
Top-3 Unlocked97.5%
Unlocked LP held by
0x575e…fe980xf949…02980xe6ac…ec1f0xf022…cdbe0x8d17…35cc0x98c5…6e290x66cb…cf59

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

Security Findings

1 Critical1 High1 Info
Critical

EIP-712 Permit verifyingContract Mismatch in Proxy

The _buildDomainSeparator function, used to construct the EIP-712 domain separator for the permit function, incorrectly uses address(this) to determine the verifyingContract. In a proxy setup (like the BeaconProxy used here), address(this) within the implementation contract refers to the implementation's address, not the proxy's address. This means that any permit signatures generated by users will be invalid when verified by the proxy contract, rendering the permit functionality completely unusable.C-01

Issue

The _buildDomainSeparator function, used to construct the EIP-712 domain separator for the permit function, incorrectly uses address(this) to determine the verifyingContract. In a proxy setup (like the BeaconProxy used here), address(this) within the implementation contract refers to the implementation's address, not the proxy's address. This means that any permit signatures generated by users will be invalid when verified by the proxy contract, rendering the permit functionality completely unusable.

Fix

To correctly implement EIP-712 permit in a proxy contract, the verifyingContract in the domain separator must be the address of the proxy. This can be achieved by: 1. Storing the proxy's address during initialization (e.g., _initialize(address(this))). 2. Using OpenZeppelin's ERC712 contract and calling _ERC712_init(name, version) in the initializer, which correctly handles the _domainSeparatorV4 for proxies. The _initializePermitStateIfNeeded logic also needs to be updated to ref…

Status

Unresolved

High

Centralized Control by Owner

The contract grants significant centralized control to the owner address. The owner can mint new tokens, burn existing tokens, and updateDetails (name, symbol, sequence). While this level of control might be necessary for a bridge token's operational model, it introduces a single point of failure and a high trust requirement in the owner. A compromised owner key or malicious owner could lead to arbitrary supply manipulation or token identity changes.H-01

Issue

The contract grants significant centralized control to the owner address. The owner can mint new tokens, burn existing tokens, and updateDetails (name, symbol, sequence). While this level of control might be necessary for a bridge token's operational model, it introduces a single point of failure and a high trust requirement in the owner. A compromised owner key or malicious owner could lead to arbitrary supply manipulation or token identity changes.

Fix

To mitigate the risks associated with centralized control, consider implementing a multi-signature wallet for the owner address, if not already in place. For critical functions like mint and burn, explore implementing a time-lock mechanism or a more decentralized governance process that requires multiple approvals or community consensus for execution.

Status

Unresolved

Info

increaseAllowance/decreaseAllowance Front-Running Risk

The increaseAllowance and decreaseAllowance functions, while standard ERC-20 implementations, are susceptible to a known front-running attack. An attacker can observe a pending transaction to increaseAllowance or decreaseAllowance, and then quickly execute a transferFrom transaction to spend the original allowance before the new allowance is set. This can lead to the spender being able to spend more or less than the owner intended.I-01

Issue

The increaseAllowance and decreaseAllowance functions, while standard ERC-20 implementations, are susceptible to a known front-running attack. An attacker can observe a pending transaction to increaseAllowance or decreaseAllowance, and then quickly execute a transferFrom transaction to spend the original allowance before the new allowance is set. This can lead to the spender being able to spend more or less than the owner intended.

Fix

This is an inherent design limitation of the ERC-20 standard and not a bug in this specific contract's implementation. Users should be aware of this risk when interacting with increaseAllowance and decreaseAllowance. For critical operations, it is often safer to first approve(spender, 0) to reset the allowance, and then approve(spender, newAmount) to set the desired allowance, though this requires two transactions.

Status

Unresolved

Analysis

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

The BridgeToken contract, implemented as a BeaconProxy, provides standard ERC-20 functionalities including minting, burning, and EIP-712 permit. The contract exhibits good adherence to Solidity 0.8+ safety features and standard ERC-20 patterns. However, a critical vulnerability was identified in the EIP-712 permit implementation, where the verifyingContract in the domain separator incorrectly resolves to the implementation address instead of the proxy address, rendering the permit functionality unusable. Additionally, the owner maintains significant centralized control over token supply and metadata.

Technical4/10Medium risk

The contract implements standard ERC-20 functionalities (7.2 Code Security) with appropriate checks for zero addresses and sufficient balances, leveraging Solidity 0.8+ for automatic integer overflow/underflow protection. No reentrancy vulnerabilities were identified due to the absence of external calls in critical state-changing functions. However, a critical flaw exists in the EIP-712 permit implementation, where the verifyingContract is incorrectly set to the implementation address instead of the proxy address, making the permit function unusable (7.2 Code Security, 7.7 Upgrades).

Governance1/10High risk

The contract's economic model (7.4 Economic) grants the owner significant centralized control, including the ability to mint and burn tokens, and updateDetails such as name and symbol. While this is typical for a bridge token managed by a bridge operator, it represents a high centralization risk. The owner address is noted as an 'Other-Contract' (7.8 Operations), which suggests a multi-sig or similar controlled entity, mitigating some of the single-point-of-failure risk.

Upgrades1/10High risk

The contract utilizes the BeaconProxy pattern (7.1 Architecture, 7.7 Upgrades), which provides a robust and efficient mechanism for upgradeability. The initializer modifier correctly prevents re-initialization of the logic contract. However, the EIP-712 permit functionality's reliance on address(this) within the implementation context creates a critical issue for proxy deployments, as it does not correctly identify the proxy contract as the verifyingContract (7.7 Upgrades).

Final RecommendationWhat to do about this score

Prioritize resolving the critical EIP-712 permit verifyingContract mismatch to ensure the permit functionality works as intended for the proxy contract.

This is a common issue in proxy implementations of EIP-712 and requires careful handling of address(this) context. Additionally, consider enhancing the security posture of the owner's centralized control by implementing a time-lock or further decentralizing governance mechanisms for critical functions like minting, burning, and metadata updates, if feasible within the project's operational model.

Contract & Record

1 audit on record
TypeBridgeToken
NetworkBNB Chain
Token age11d
Contract0x46f2…1be7
Deployer0x22b1…79bf
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
GRVT 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. Sep 4, 202678High
  2. Aug 11, 202668High

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

Frequently Asked Questions

What is the GRVT contract address?

The GRVT contract on BNB Chain is 0x46f2564e0fa8248d15125e7e54173cfbdef91be7. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is GRVT a scam?

Quantum Audit's risk score for GRVT is 78/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; 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 GRVT liquidity locked?

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

Who holds GRVT?

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

Related Audits

6 more on the recordAll audits
Based TokenBASED · BNB Chain78HighFalcon FinanceFF · BNB Chain78HighKGENBNB Chain78HighBinance BrokersBBROKERS · BNB Chain78HighBitcoin Cash TokenBCH · BNB Chain78HighAleoBNB Chain78High

Would You Like a More Detailed Audit of GRVT?

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