On-chain security analysis — is it a scam or legit?
EthereumThe audit of the EtherVista Token contract identified a significant design limitation in the approve function, which, when enabled, restricts token approvals to a single hardcoded router address.
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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x6bfe…bf960x07c7…8cadNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approve Functionality with Hardcoded Dependencyapprove 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,…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 (). 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,…
Reconsider 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.
Unresolved
tx.origin for Initial Mintingtx.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)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)
For 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.
Unresolved
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)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)
Consider 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.
Unresolved
The audit of the EtherVista Token contract identified a significant design limitation in the approve function, which, when enabled, restricts token approvals to a single hardcoded router address. This severely impacts the token's interoperability with other DeFi protocols. Minor issues include the use of tx.origin for initial minting and a lack of standard extensibility hooks.
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.
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.
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.
It is strongly recommended to reconsider the vistaOnly functionality within the approve function.
If the intention is to allow broader DeFi integration, this restriction should be removed or made configurable by a trusted entity. If the restriction is essential, ensure robust mechanisms are in place to update the router address if the factory changes or is compromised. Additionally, for future contracts, avoid using tx.origin and instead use _msgSender() for any address-related operations, even for initial minting, to adhere to best practices.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Dog Food Token (OISHII) contract on Ethereum is 0xa1b014878d47c0836ed79163ddec55985adb7023. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Dog Food Token is 47/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $46.2K.
As of Sep 4, 2026, the 10 largest holders own 99.6% of the supply. The Holders section on this page shows who they are by holder type.
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
