Is Dog Food Token (OISHII) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Low1 Info

High

Highly Restrictive `approve` Functionality with Hardcoded Dependency

H-01The `approve` function, when the `vistaOnly` flag is set to `true`, restricts approvals exclusively to the router address obtained from a hardcoded `IEtherVistaFactory` instance (0x9a27…57B4). This design choice severely limits the token's utility, preventing it from interacting with other DeFi protocols that require `approve` calls to different spenders (e.g., lending platforms, other AMMs, staking contracts). Furthermore, the hardcoded `factory` address means the token's functionality is permanently tied to a single external contract. If that factory contract is compromised, upgraded, or ceases to exist, or if the router address it returns becomes invalid,…

IssueThe `approve` function, when the `vistaOnly` flag is set to `true`, restricts approvals exclusively to the router address obtained from a hardcoded `IEtherVistaFactory` instance (). This design choice severely limits the token's utility, preventing it from interacting with other DeFi protocols that require `approve` calls to different spenders (e.g., lending platforms, other AMMs, staking contracts). Furthermore, the hardcoded `factory` address means the token's functionality is permanently tied to a single external contract. If that factory contract is compromised, upgraded, or ceases to exist, or if the router address it returns becomes invalid,…

FixReconsider the necessity and implications of the `vistaOnly` flag. If broader DeFi interoperability is desired, this restriction should be removed. If the restriction is critical, implement a mechanism (e.g., an owner-controlled function) to update the `factory` address or the allowed `router` address, rather than hardcoding it, to mitigate risks associated with external dependency failures.

StatusUnresolved

Low

Use of `tx.origin` for Initial Minting

L-01The constructor uses `tx.origin` to mint the initial token supply to the deployer. While this is not a critical access control vulnerability in this specific context (as it's for initial supply and not for ongoing permissions), `tx.origin` is generally discouraged in Solidity. It can be susceptible to phishing attacks where a malicious contract could trick a user into signing a transaction that appears legitimate but actually grants permissions or transfers assets to the attacker, if `tx.origin` were used for critical access control. For initial minting, the risk is lower but it deviates from best practices. (7.2 Code Security)

IssueThe constructor uses `tx.origin` to mint the initial token supply to the deployer. While this is not a critical access control vulnerability in this specific context (as it's for initial supply and not for ongoing permissions), `tx.origin` is generally discouraged in Solidity. It can be susceptible to phishing attacks where a malicious contract could trick a user into signing a transaction that appears legitimate but actually grants permissions or transfers assets to the attacker, if `tx.origin` were used for critical access control. For initial minting, the risk is lower but it deviates from best practices. (7.2 Code Security)

FixFor future contracts, it is best practice to use `_msgSender()` (which resolves to `msg.sender`) instead of `tx.origin` for any address-related operations, including initial minting, to align with secure coding standards and prevent potential `tx.origin` related attack vectors in more complex scenarios.

StatusUnresolved

Info

Lack of Standard Extensibility Hooks

I-01The `ERC20` implementation does not include common extensibility hooks like `_beforeTokenTransfer` or `_afterTokenTransfer`, which are typically found in widely used ERC-20 libraries (e.g., OpenZeppelin). While not a direct vulnerability, this design choice limits the ability to add custom logic (e.g., fee mechanisms, blacklisting, compliance checks, or tax functions) in the future without modifying the core `_transfer` logic. This could necessitate a new token deployment if such features become necessary, increasing operational overhead. (7.1 Architecture)

IssueThe `ERC20` implementation does not include common extensibility hooks like `_beforeTokenTransfer` or `_afterTokenTransfer`, which are typically found in widely used ERC-20 libraries (e.g., OpenZeppelin). While not a direct vulnerability, this design choice limits the ability to add custom logic (e.g., fee mechanisms, blacklisting, compliance checks, or tax functions) in the future without modifying the core `_transfer` logic. This could necessitate a new token deployment if such features become necessary, increasing operational overhead. (7.1 Architecture)

FixConsider incorporating standard extensibility hooks in future ERC-20 implementations to allow for easier integration of custom logic and future-proofing without requiring a full redeployment.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract implements a standard ERC-20 token with custom error handling, which is a positive security practice. It utilizes `unchecked` blocks for gas efficiency where appropriate. However, a major technical risk is the `vistaOnly` flag, which, when true, severely restricts the `approve` function to only allow approvals for a single, hardcoded router address. This design choice significantly limits the token's interoperability and introduces a single point of failure if the external factory or router address becomes invalid or compromised. Additionally, the constructor uses `tx.origin` for initial minting, which is generally discouraged.

GovernanceHigh1/10

The token's economic model is a standard fixed-supply ERC-20, minted entirely at deployment. There are no complex economic mechanisms or governance features within this contract. The primary economic risk stems from the `vistaOnly` restriction on the `approve` function. If enabled, this limits the token's ability to participate in broader DeFi ecosystems, potentially hindering its liquidity and adoption. The hardcoded factory address also ties the token's functionality to an external dependency, which could have economic consequences if that dependency fails or changes.

UpgradesLow7/10

This contract is not designed to be upgradeable, meaning its logic is immutable once deployed. This eliminates risks associated with upgrade mechanisms, such as proxy pattern vulnerabilities or improper upgrade paths. Any future changes to the token's core functionality would require a new contract deployment and migration of assets.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

99.6% in top 10

62.6% in wallets37.0% in contracts

Effective Concentration77.4%

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

$46.2K across 2 pairs

Uniswap v3WETHanalysed$38.2K EthervistaWETH$8.1K

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 Locked100.0% · UNCX Locker

Key Addresses

3 addresses

Deployer

0x6298…0c59

Unlocked LP Held By

0x6bfe…bf960x07c7…8cad

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 status UNKNOWN (owner could not be resolved)
Top-10 concentration > 70% (99.6% total → 77.4% effective; 62.6% in EOAs, 37.0% in contracts — extreme)
Liquidity < $50k ($46,245 across 2 pairs — thin market)
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 Dog Food Token Safe?

Security Findings

Highly Restrictive `approve` Functionality with Hardcoded Dependency

Use of `tx.origin` for Initial Minting

Lack of Standard Extensibility Hooks

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 Dog Food Token?