Is toby Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Low1 Info

Critical

`tx.origin` for Access Control

C-01The `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.

IssueThe `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.

FixReplace `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.

StatusUnresolved

High

Incorrect `transferFrom` Logic

H-01The `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.

IssueThe `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.

FixReorder 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.

StatusUnresolved

Low

Unused State Variable `Optimization`

L-01The 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.

IssueThe 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.

FixRemove 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.

StatusUnresolved

Info

Custom ERC20 Implementation

I-01The 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.

IssueThe 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.

FixConsider 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.

StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceMedium4/10

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.

UpgradesMedium6/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

23.0% in top 10

20.4% in wallets2.6% in contracts

Effective Concentration21.5%

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

$234.9K across 21 pairs

SushiswapWETHanalysed$209.2K Uniswap v3WETH$22.7K AerodromeWETH$1.5K SushiswapWETH$790 AerodromeWETH$184 Uniswap v3WETH$148

Show 4 more pairsShow less

AerodromeDOG$77 AerodromeUSDC$60 Uniswap v4ETH$52 Uniswap v4ETH$46

The 11 remaining pairs hold $172 between them and are 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

LP Burned99.7% · ≈ permanent lock

LP Locked99.7%

Key Addresses

10 addresses

Deployer

0xbcad…4c0c

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.

What Raised This Score

5 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

Is toby Safe?

Security Findings

`tx.origin` for Access Control

Incorrect `transferFrom` Logic

Unused State Variable `Optimization`

Custom ERC20 Implementation

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of toby?