Quantum Audit Logo
Launch App

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

Is toby Safe?

TOBYBase
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance4/10Upgrades6/10Checks passed4 of 5Findings1 Critical · 1 High · 1 Low · 1 Info4
SummaryAI Copilot

The toby token contract is a custom ERC20 implementation with owner-controlled functionalities.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 20%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 20% (23.0% total → 21.5% effective; 20.4% in EOAs, 2.6% in contracts — mild)
  • 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
2.6%20.4%Wallets77.0%Everyone else
20.4%Wallets77.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
23.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking2.6%
  • Walletsanonymous holders, free to sell20.4%
  • Everyone elsethe rest of the supply77.0%
Effective concentrationwhat the score reads21.5%
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$234.9K across 21 pairs
Show 4 more pairs

The 11 remaining pairs hold $172 between them and are not listed. The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$209.2KShare of depth89.1%
LP Burned99.7% · ≈ permanent lock
LP Locked99.7%
Unlocked LP held by
0xe7aa…bf760xa266…40cf0x2515…fbc00x538c…4d970x0444…e33a0x12c9…da4a0x5ffc…85b10xc027…64870x34b2…93e6

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

Security Findings

1 Critical1 High1 Low1 Info
Critical

tx.origin for Access Control

The onlyOwner modifier in the Ownable contract uses tx.origin instead of msg.sender for access control. This is a critical vulnerability as it makes all owner-restricted functions susceptible to phishing attacks. If the legitimate owner interacts with a malicious contract, that contract can then call owner-restricted functions (e.g., transferOwnership, renounceOwnership, recoverERC20) on the toby token contract, as tx.origin would still resolve to the legitimate owner's address.C-01

Issue

The onlyOwner modifier in the Ownable contract uses tx.origin instead of msg.sender for access control. This is a critical vulnerability as it makes all owner-restricted functions susceptible to phishing attacks. If the legitimate owner interacts with a malicious contract, that contract can then call owner-restricted functions (e.g., transferOwnership, renounceOwnership, recoverERC20) on the toby token contract, as tx.origin would still resolve to the legitimate owner's address.

Fix

Replace tx.origin with msg.sender in the onlyOwner modifier. The msg.sender variable always refers to the immediate caller of the function, providing a secure and standard way to implement access control.

Status

Unresolved

High

Incorrect transferFrom Logic

The transferFrom function executes the token transfer (_transfer) before checking if the allowance is sufficient and updating it. Specifically, _transfer(sender, recipient, amount) is called first, followed by `require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance"). If the allowance is insufficient, the _transfer` operation will still occur (if the sender has enough balance), but the transaction will then revert due to the subsequent require statement. This leads to wasted gas and non-standard ERC20 behavior, potentially causing issues for integrations expecting the allowance check to precede the transfer.H-01

Issue

The transferFrom function executes the token transfer (_transfer) before checking if the allowance is sufficient and updating it. Specifically, _transfer(sender, recipient, amount) is called first, followed by `require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance"). If the allowance is insufficient, the _transfer` operation will still occur (if the sender has enough balance), but the transaction will then revert due to the subsequent require statement. This leads to wasted gas and non-standard ERC20 behavior, potentially causing issues for integrations expecting the allowance check to precede the transfer.

Fix

Reorder the operations within transferFrom. The allowance check (require(currentAllowance >= amount)) should occur before _transfer(sender, recipient, amount). The correct sequence is: check allowance, perform transfer, then update allowance.

Status

Unresolved

Low

Unused State Variable Optimization

The public state variable Optimization is declared and initialized with a large uint256 value but is never read or used within any of the contract's functions. This adds unnecessary storage cost to the contract and can be misleading to developers or auditors regarding its purpose.L-01

Issue

The public state variable Optimization is declared and initialized with a large uint256 value but is never read or used within any of the contract's functions. This adds unnecessary storage cost to the contract and can be misleading to developers or auditors regarding its purpose.

Fix

Remove the Optimization variable if it serves no functional purpose. If it is intended for future use, consider adding comments to explain its role or making it internal if it's not meant for external interaction.

Status

Unresolved

Info

Custom ERC20 Implementation

The contract utilizes a custom implementation of the ERC20 standard rather than leveraging battle-tested and widely audited libraries such as OpenZeppelin Contracts. While the current implementation largely adheres to the standard, custom code carries a higher inherent risk of introducing subtle bugs, edge cases, or non-compliance issues that might have been addressed in more mature libraries.I-01

Issue

The contract utilizes a custom implementation of the ERC20 standard rather than leveraging battle-tested and widely audited libraries such as OpenZeppelin Contracts. While the current implementation largely adheres to the standard, custom code carries a higher inherent risk of introducing subtle bugs, edge cases, or non-compliance issues that might have been addressed in more mature libraries.

Fix

Consider migrating to OpenZeppelin's ERC20 implementation for enhanced security, reliability, and maintainability. If a custom implementation is deemed necessary, ensure comprehensive unit testing, formal verification, and thorough security audits are conducted to mitigate potential risks.

Status

Unresolved

Analysis

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

The toby token contract is a custom ERC20 implementation with owner-controlled functionalities. A critical vulnerability was identified in the access control mechanism, utilizing tx.origin instead of msg.sender, which exposes owner-restricted functions to phishing attacks. Additionally, the transferFrom function exhibits incorrect logic, and an unused state variable was found. The contract includes a token recovery mechanism for ERC20 tokens.

Technical7/10Low risk

The contract implements a custom ERC20 token with standard functionalities like transfer, approve, mint, and burn (7.2 Code Security). It includes a useful TokenRecover mechanism allowing the owner to retrieve accidentally sent ERC20 tokens (7.8 Operations). However, a critical tx.origin vulnerability in the onlyOwner modifier compromises all owner-restricted functions (7.3 Access Control). The transferFrom function has incorrect logic, performing the transfer before checking allowance, leading to gas waste and non-standard behavior (7.2 Code Security). An unused state variable also adds minor technical debt.

Governance4/10Medium risk

The contract represents a simple ERC20 token with no complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). The initial supply is minted to a specified token owner during deployment. The owner has control over token recovery and ownership transfer, which is standard for a basic token contract. No fees are imposed on token transfers.

Upgrades6/10Medium risk

The contract is not designed to be upgradeable (7.7 Upgrades). It does not implement any proxy patterns, meaning its logic is immutable once deployed. This simplifies the architecture but requires careful initial deployment.

Final RecommendationWhat to do about this score

It is critical to address the tx.origin vulnerability by replacing it with msg.sender in the onlyOwner modifier to prevent phishing attacks and unauthorized access to owner-controlled functions.

The transferFrom function's logic should be corrected to ensure the allowance check precedes the token transfer, aligning with ERC20 standards and preventing gas waste. Consider using battle-tested OpenZeppelin contracts for ERC20 and Ownable implementations to leverage audited and secure code, reducing the risk of subtle bugs inherent in custom implementations.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2y
Contract0xb8d9…e56e
Deployer0xbcad…4c0c
Badge for your website
toby 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. Aug 13, 202630Low

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

Frequently Asked Questions

What is the TOBY contract address?

The toby contract on Base is 0xb8d98a102b0079b69ffbc760c8d857a31653e56e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is toby a scam?

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

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $234.9K.

Who holds TOBY?

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

Related Audits

6 more on the recordAll audits
Coinbase ManBRIAN · Base30LowO1 DollO1DOLL · Base30LowMoonbaseBase30LowJerry the goatJERRY · Base31LowPORTALBase29LowBaselineBase29Low

Would You Like a More Detailed Audit of toby?

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