Quantum Audit Logo

Is Gravity Safe?

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

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

Gravity G
0x9c7b…0649
Ethereum
Not verifiedThis 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 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The Gravity Token (G) contract implements an ERC20 token with standard OpenZeppelin functionalities (burnable, pausable, permit) and a custom LimitedMinterManager for controlled token minting. The contract utilizes Ownable2Step for ownership management, with the owner being a 3/6 multisig. While the architecture leverages well-audited libraries, a critical integer overflow vulnerability exists in the custom minting limit calculation, which could severely disrupt the token's economic model. Additionally, the owner retains the ability to mint an unlimited supply of tokens, posing a significant centralization risk.

1 Critical1 High1 Low1 Informational
Volume 24h
$1.57M
Liquidity
$1.58M
Price
$0.008818
Token Age
2y
Top 10 Holders
90.0%

Security Findings

1 Crit1 High1 Low1 Info
Critical

Integer Overflow in `_getCurrentLimit` Calculation

C-01The `_getCurrentLimit` function in `LimitedMinterManager.sol` calculates the replenished minting limit using the formula `_calculatedLimit = _limit + ((_timePassed * _maxLimit) / _duration);`. The multiplication `_timePassed * _maxLimit` can lead to an integer overflow if both `_timePassed` (which can be very large, representing time elapsed since `_timestamp`) and `_maxLimit` (which can be up to `type(uint256).max / 2`) are sufficiently large. An overflow would cause `_calculatedLimit` to wrap around to a much smaller value, effectively denying minters their expected minting capacity and breaking the core economic logic of the limited minter system.
IssueThe `_getCurrentLimit` function in `LimitedMinterManager.sol` calculates the replenished minting limit using the formula `_calculatedLimit = _limit + ((_timePassed * _maxLimit) / _duration);`. The multiplication `_timePassed * _maxLimit` can lead to an integer overflow if both `_timePassed` (which can be very large, representing time elapsed since `_timestamp`) and `_maxLimit` (which can be up to `type(uint256).max / 2`) are sufficiently large. An overflow would cause `_calculatedLimit` to wrap around to a much smaller value, effectively denying minters their expected minting capacity and breaking the core economic logic of the limited minter system.
FixImplement robust overflow protection for the multiplication `_timePassed * _maxLimit`. Consider using OpenZeppelin's `SafeMath` library (if not already implicitly handled by Solidity 0.8.x checked arithmetic for additions/subtractions, which it is, but not for intermediate products in a division) or explicitly check for overflow before multiplication. For example, check `if (_timePassed != 0 && _maxLimit > type(uint256).max / _timePassed)` before performing the multiplication.
StatusUnresolved
High

Unlimited Owner Minting Capability

H-01The `ownerMint(address to, uint256 amount)` function in `GravityTokenG.sol` allows the contract owner to mint an arbitrary `amount` of tokens to any `to` address without any limits or restrictions. This capability bypasses the `LimitedMinterManager`'s controlled minting mechanism entirely. While protected by `onlyOwner`, this grants the owner absolute control over the token's total supply, posing a significant centralization risk and potential for arbitrary inflation, which could severely devalue the token.
IssueThe `ownerMint(address to, uint256 amount)` function in `GravityTokenG.sol` allows the contract owner to mint an arbitrary `amount` of tokens to any `to` address without any limits or restrictions. This capability bypasses the `LimitedMinterManager`'s controlled minting mechanism entirely. While protected by `onlyOwner`, this grants the owner absolute control over the token's total supply, posing a significant centralization risk and potential for arbitrary inflation, which could severely devalue the token.
FixEvaluate the necessity of unlimited owner minting. If not strictly required, remove the `ownerMint` function. If it is deemed necessary for specific operational reasons (e.g., emergency recovery), consider implementing a time-locked or multi-signature approval mechanism for such mints, or cap the maximum amount that can be minted by the owner within a certain period. Ensure robust operational security for the owner's keys.
StatusUnresolved
Low

Inefficient Minter Removal with Index Hint

L-01The `_removeMinterByIndexHint` function in `LimitedMinterManager.sol` requires an `_indexHint` parameter to locate the minter in the `_minters` array. If the array's state changes (e.g., another minter is added or removed) between the time an off-chain system fetches the index and the transaction is submitted, the provided `_indexHint` might become invalid. This would cause the transaction to revert with `ILimitedMinterManager_InvalidIndexHint()`, requiring the owner to re-fetch the correct index and resubmit.
IssueThe `_removeMinterByIndexHint` function in `LimitedMinterManager.sol` requires an `_indexHint` parameter to locate the minter in the `_minters` array. If the array's state changes (e.g., another minter is added or removed) between the time an off-chain system fetches the index and the transaction is submitted, the provided `_indexHint` might become invalid. This would cause the transaction to revert with `ILimitedMinterManager_InvalidIndexHint()`, requiring the owner to re-fetch the correct index and resubmit.
FixWhile not a security vulnerability, this can lead to a poor user experience for the owner. Consider iterating through the `_minters` array to find the minter's index if the array is expected to remain small. For larger arrays, ensure off-chain tooling is robust in handling potential index mismatches and retries, or provide a mechanism to update the index hint if the transaction reverts.
StatusUnresolved
Info

High Degree of Centralized Control

I-01The `GravityTokenG` contract design grants significant control to a single owner address (currently a 3/6 multisig). This owner has the power to pause/unpause transfers, change the token name, set minting limits for all minters, remove minters, and crucially, mint an unlimited supply of tokens via `ownerMint`. While a multisig mitigates some risks associated with a single point of failure, the protocol's operation remains highly dependent on the integrity and security of this central entity.
IssueThe `GravityTokenG` contract design grants significant control to a single owner address (currently a 3/6 multisig). This owner has the power to pause/unpause transfers, change the token name, set minting limits for all minters, remove minters, and crucially, mint an unlimited supply of tokens via `ownerMint`. While a multisig mitigates some risks associated with a single point of failure, the protocol's operation remains highly dependent on the integrity and security of this central entity.
FixAcknowledge and accept the inherent risks of centralized control. Ensure the multisig signers are diverse, trusted, and follow strict operational security procedures. For future iterations, consider gradually decentralizing control over critical functions, perhaps through a more robust on-chain governance mechanism or by introducing time-locks for sensitive operations.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The technical architecture (7.1 Architecture) benefits from extensive use of battle-tested OpenZeppelin libraries for ERC20, burning, pausing, and ownership, which enhances code security. However, the custom `LimitedMinterManager` introduces a critical integer overflow vulnerability in the `_getCurrentLimit` function (7.2 Code Security), which can lead to incorrect minting limit calculations and disrupt the token's core functionality. Access control (7.3 Access Control) is appropriately implemented for critical owner-only functions, but the `_removeMinterByIndexHint` function has a minor usability flaw (7.8 Operations) due to its reliance on an index hint.

GovernanceHigh1/10

The economic model (7.4 Economic) is significantly impacted by the `ownerMint` function, which allows the owner to mint an unlimited supply of tokens, creating a single point of failure and potential for arbitrary supply inflation. This centralization of power is a major concern. The governance model (7.5 Governance) relies solely on a single owner (a 3/6 multisig), which, while better than a single EOA, still represents a centralized control point for all critical operations, including pausing and setting minter limits. The critical integer overflow in minting limit calculation also directly undermines the intended economic controls.

UpgradesHigh3/10

The contract is deployed as a standard implementation and does not incorporate any upgradeability mechanisms (7.7 Upgrades). This means that any discovered bugs or desired feature enhancements would necessitate a complete redeployment of the contract and a migration of token holders, which can be a complex and disruptive process. While this approach avoids the complexities and potential risks associated with proxy patterns, it sacrifices future flexibility.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

90.0% in top 10
29.3% in wallets60.6% in contracts
Effective Concentration53.6%

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

$1.58M

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

Top-1 Unlocked Holder98.5%
Top-3 Unlocked100.0%

Key Addresses

7 addresses
Deployer
0x397b…ee13
Unlocked LP Held By
0xfdd2…ccf00xaf7c…80700xe171…daa50xf6bd…5dc20x1c86…77f40x826f…1e65

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

What Raised This Score

9 factors
  • Ownership NOT renounced — strong Multisig (3-of-6)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (90.0% total → 53.6% effective; 29.3% in EOAs, 60.6% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.5% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 1 High 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

Related Audits

6 more on the record
HarryPotterObamaSonic10Inu (BITCOIN)High RiskLego Pepe (LEPE)High RiskGraph Token (GRT)High RiskGnosis Token (GNO)High RiskInterfold (FOLD)High RiskTokenFi (TOKEN)High Risk

Would You Like a More Detailed Audit of Gravity?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit