Quantum Audit Logo

Is BONE SHIBASWAP a Scam?

Honeypot, rug-pull and ownership checks

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

BONE SHIBASWAP BONE
0x9813…18d9
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 today 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The BoneToken contract implements an ERC20 token with Compound-style delegation for governance. It leverages OpenZeppelin contracts for core ERC20 functionality and ownership. The primary risk identified is the centralized minting authority, which allows the owner to control the token supply. Other findings include a theoretical long-term limitation for block numbers and informational notes on checkpointing behavior and lack of a pause mechanism.

1 High1 Low2 Informational
i Our automated scanner reviewed BONE SHIBASWAP (BONE) on Ethereum. 4 of 5 security checks passed — see the full breakdown below.
Volume 24h
$44.6K
Liquidity
$1.39M
Price
$0.05238
Age
5y
Top 10 Holders
47.2%

Security Findings

High

Centralized Minting Authority

H-01The `mint` function, protected by `onlyOwner`, allows the contract owner to create an arbitrary amount of new tokens. This introduces a significant centralization risk (7.3 Access Control), as a compromised or malicious owner could inflate the token supply, devaluing existing tokens and impacting the protocol's economy (7.4 Economic). While the owner is an 'Other-Contract', its nature (e.g., multisig, DAO, timelock) is not specified, leaving potential for a single point of failure.
IssueThe `mint` function, protected by `onlyOwner`, allows the contract owner to create an arbitrary amount of new tokens. This introduces a significant centralization risk (7.3 Access Control), as a compromised or malicious owner could inflate the token supply, devaluing existing tokens and impacting the protocol's economy (7.4 Economic). While the owner is an 'Other-Contract', its nature (e.g., multisig, DAO, timelock) is not specified, leaving potential for a single point of failure.
FixImplement a robust governance mechanism (e.g., DAO with timelock) to control the minting function, or define a fixed supply/emission schedule. If the owner is already a robust governance contract, ensure its security and decentralization.
StatusUnresolved
Low

Theoretical `block.number` Overflow in `safe32`

L-01The `safe32` helper function, used to cast `block.number` to `uint32` for checkpoints, includes a `require(n < 2**32)` check (7.2 Code Security). While `block.number` on EVM chains is currently far below this limit, it is a theoretical long-term limitation. If the blockchain were to run for thousands of years, `block.number` could eventually exceed `2**32`, causing transactions involving checkpoints to revert.
IssueThe `safe32` helper function, used to cast `block.number` to `uint32` for checkpoints, includes a `require(n < 2**32)` check (7.2 Code Security). While `block.number` on EVM chains is currently far below this limit, it is a theoretical long-term limitation. If the blockchain were to run for thousands of years, `block.number` could eventually exceed `2**32`, causing transactions involving checkpoints to revert.
FixConsider using `uint64` or `uint256` for `fromBlock` in the `Checkpoint` struct if extreme long-term compatibility (thousands of years) is a critical requirement. For practical purposes on current EVM chains, this is a very low risk.
StatusUnresolved
Info

Single Checkpoint per Block for Vote Tracking

I-01The `_writeCheckpoint` function updates an existing checkpoint if `checkpoints[delegatee][nCheckpoints - 1].fromBlock == blockNumber` (7.2 Code Security). This design means that for any given delegatee, only one vote balance snapshot is recorded per block. If multiple token transfers or delegation changes affecting the same delegatee occur within the same block, intermediate vote balance changes will not be individually recorded, only the final state at the end of the block. This is a common design pattern for Compound-style voting systems and is generally acceptable, but it's important for users and integrators to understand this behavior.
IssueThe `_writeCheckpoint` function updates an existing checkpoint if `checkpoints[delegatee][nCheckpoints - 1].fromBlock == blockNumber` (7.2 Code Security). This design means that for any given delegatee, only one vote balance snapshot is recorded per block. If multiple token transfers or delegation changes affecting the same delegatee occur within the same block, intermediate vote balance changes will not be individually recorded, only the final state at the end of the block. This is a common design pattern for Compound-style voting systems and is generally acceptable, but it's important for users and integrators to understand this behavior.
FixDocument this behavior clearly for users and integrators, explaining that vote changes within the same block are coalesced into a single checkpoint.
StatusUnresolved
Info

Lack of Emergency Pause Mechanism

I-02The `BoneToken` contract does not include a mechanism to pause token transfers or delegation in emergency situations, such as a critical vulnerability discovery or a major external exploit affecting the ecosystem (7.8 Operations). While not strictly a vulnerability, a pause function can provide a crucial safety net for mitigating damage in unforeseen circumstances.
IssueThe `BoneToken` contract does not include a mechanism to pause token transfers or delegation in emergency situations, such as a critical vulnerability discovery or a major external exploit affecting the ecosystem (7.8 Operations). While not strictly a vulnerability, a pause function can provide a crucial safety net for mitigating damage in unforeseen circumstances.
FixConsider implementing a pausable mechanism (e.g., using OpenZeppelin's `Pausable` contract) controlled by a robust governance system. This would allow the community or a trusted entity to temporarily halt operations if necessary.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The BoneToken contract is built upon battle-tested OpenZeppelin ERC20 and Ownable implementations, providing a solid foundation for token functionality. The custom delegation logic, inspired by Compound's governance token, is well-structured and correctly implements EIP-712 signatures for off-chain delegation. A minor technical observation is the theoretical long-term limitation of `block.number` fitting into a `uint32` for checkpoints (L-01), though this is not an immediate concern. The contract correctly uses `SafeMath` principles for arithmetic operations.

GovernanceMedium4/10

The contract's economic model is significantly influenced by the `mint` function, which is controlled by a single owner (H-01). This centralized control over token supply poses a high economic risk, as it allows for arbitrary inflation and dilution of token value. While the owner is an 'Other-Contract', its specific nature and decentralization level are not detailed. The delegation mechanism for voting is a positive aspect, enabling decentralized governance participation once tokens are distributed.

UpgradesLow8/10

The BoneToken contract is not designed to be upgradeable, meaning its logic is immutable once deployed. This eliminates risks associated with proxy patterns or upgrade mechanisms, such as storage collisions or faulty upgrade implementations. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a new contract deployment and migration.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

32.4% in wallets14.8% 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

Show 4 more pairsShow less

One more pair holds $34 and is not listed.

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 Holder50.2%
Top-3 Unlocked98.2%

Key Addresses

Deployer
0xc7d0…2bf3
Unlocked LP Held By
0x5e38…d5f10xfd08…d4810x4be2…2e140x4f92…48dc0x7bb8…9a6b0xaa86…abf80x5ddc…16bb0x0720…4b740xb628…a8a3

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

What Raised This Score

  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 30% (47.2% total → 38.3% effective; 32.4% in EOAs, 14.8% in contracts — moderate)
  • LP top1 unlocked holder = 50.2% (independent LP — depth risk, pool = 79% of DEX liquidity)
  • LP top3 unlocked holders = 98.2% (independent LP — depth risk, pool = 79% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 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

Worldcoin (WLD)Medium RiskVANRYMedium RiskConvex Token (CVX)Medium RiskDUALMedium RiskAuroraMedium RiskArtificial Superintelligence Alliance (FET)Medium Risk

Would You Like a More Detailed Audit of BONE SHIBASWAP?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit