Honeypot, rug-pull and ownership checks

Is FLOKI a Scam?

Ethereum

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

65/ 100

High RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance2/10 Upgrades6/10 Checks passed5 of 7 Findings1 Critical · 2 High · 1 Medium · 1 Low · 2 Info7

SummaryAI Copilot

The FLOKI contract is an ERC-20 token with added governance delegation features, integrating with external Tax and Treasury handlers.

Read the full analysis

What raised the score

Ownership not renounced — owner is an EOA
Top-10 concentration > 50%
1 Critical finding(s) from audit
2 High finding(s) from audit
1 Medium 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 > 50% (69.6% total → 62.1% effective; 57.1% in EOAs, 12.5% in contracts — heavy)
1 Critical finding(s) from audit
2 High finding(s) from audit
1 Medium 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

Our automated scanner reviewed FLOKI (FLOKI) on Ethereum. 5 of 7 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 7 checks passed

Contract verifiedVerified

OwnershipRetained

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

HoneypotNone found

Buy / sell tax0.3% / 0.3%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

69.6%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking12.5%
Walletsanonymous holders, free to sell57.1%
Everyone elsethe rest of the supply30.4%

Effective concentrationwhat the score reads62.1%

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$7.69M across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$7.69MShare of depth100.0%

LP Locked78.9% · UNCX

Top-1 Unlocked Holder12.5%

Top-3 Unlocked21.1%

Lock Expiry2286 (verified ≥ 1 year) · UNCX V2

Unlocked LP held by

0xc954…e3a80x2b9d…0ab00x5c9b…49400x8d8a…2d6b0x09be…96180xf385…5f850x0333…2ddf0xa119…b9510x78c4…8fd7

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

Security Findings

1 Critical2 High1 Medium1 Low2 Info

Critical

`transferFrom` Logic Flaw Allows Unauthorized Transfers

The transferFrom function calls _transfer(sender, recipient, amount) *before* checking if currentAllowance >= amount and updating the allowance. This means tokens are transferred even if the allowance is insufficient, and then the transaction will revert on the require statement, but the tokens have already been moved. This allows an attacker to bypass allowance restrictions and transfer tokens without proper authorization, potentially draining funds from approved accounts.C-01

Issue

Fix

Reorder the operations within transferFrom. The allowance check (require(currentAllowance >= amount)) and allowance update (_approve(sender, _msgSender(), currentAllowance - amount)) must occur *before* the _transfer(sender, recipient, amount) call.

Status

Unresolved

High

Vote Tracking Inconsistency and Potential Reverts in `_moveDelegates`

The _moveDelegates function subtracts amount (which is uint224(delegatorBalance)) from the from delegate's vote count (fromRepOld). If fromRepOld is less than amount, this operation will cause an underflow and revert the transaction. This can occur if a delegator's balance changes (e.g., they transfer tokens) without their delegate's vote count being immediately adjusted, or if the from delegate has other delegators whose votes are not correctly accounted for in this specific operation. This can lead to a denial of service for delegation changes, hindering the governance mechanism.H-01

Issue

Fix

Ensure that fromRepOld is always greater than or equal to amount before subtraction. This might require a more robust mechanism for tracking and updating delegate vote counts, possibly by adjusting votes based on actual token balance changes or by ensuring fromRepOld accurately reflects the delegator's contribution being moved. Consider adding a require statement to explicitly check fromRepOld >= amount before subtraction.

Status

Unresolved

High

Centralized Control Over Critical External Handlers

The owner address has the exclusive privilege to call setTaxHandler and setTreasuryHandler, allowing them to change the addresses of ITaxHandler and ITreasuryHandler to any arbitrary contract. If the owner's private key is compromised or acts maliciously, they could replace these handlers with contracts designed to drain funds, impose exorbitant taxes, or otherwise disrupt token functionality, leading to significant financial loss for users.H-02

Issue

Fix

Implement a more decentralized or time-locked mechanism for changing critical external handler addresses. This could involve a multi-signature wallet for ownership, a timelock contract, or a community governance vote to approve such changes. This reduces the risk associated with a single point of failure.

Status

Unresolved

Medium

Missing `_transfer` Function Implementation

The provided source code is truncated and does not include the implementation of the internal _transfer function. This function is fundamental to the core ERC-20 token logic, handling balance updates and event emissions. Without its full implementation, a comprehensive security assessment of token transfers, including potential reentrancy vectors, balance manipulation, or other vulnerabilities, cannot be performed.M-01

Issue

Fix

Provide the complete source code for the _transfer function to allow for a thorough security review of the token's core transfer mechanism. Ensure it adheres to ERC-20 standards and best security practices, including checks for zero addresses, sufficient balances, and proper event emission.

Status

Unresolved

Low

Owner as Externally Owned Account (EOA)

The contract owner is an Externally Owned Account (EOA). An EOA is controlled by a single private key, making it a single point of failure. If this private key is compromised, lost, or misused, an attacker could gain full control over the owner-privileged functions, including changing critical taxHandler and treasuryHandler addresses.L-01

Issue

Fix

Consider transferring ownership to a multi-signature wallet (e.g., Gnosis Safe) or a robust governance contract. This distributes control, requires multiple approvals for sensitive operations, and significantly reduces the risk associated with a single point of failure.

Status

Unresolved

Info

Fixed Total Supply Minted to Deployer

In the constructor, the entire fixed totalSupply (1e13 * 1e9) is minted directly to the contract deployer (_msgSender()). This design choice means that all tokens are initially held by a single address, which then controls the initial distribution.I-01

Issue

Fix

This is a design decision and not a vulnerability in itself. However, ensure that the distribution strategy from the deployer's address is transparent and aligns with the project's economic model and community expectations.

Status

Unresolved

Info

Potential `uint32` Overflow in `_writeCheckpoint` (Extreme Unlikelihood)

The numCheckpoints[delegatee] = nCheckpoints + 1; operation increments a uint32 counter. While highly improbable, if a single delegatee were to accumulate 2^32 - 1 (approximately 4.2 billion) checkpoints, the next increment would cause a uint32 overflow, leading to a transaction revert. This would effectively halt further vote delegation changes for that specific delegatee.I-02

Issue

Fix

Given the extreme unlikelihood of this scenario, no immediate action is strictly necessary. However, for absolute robustness, consider using a larger integer type (e.g., uint64) for numCheckpoints if the project anticipates an exceptionally high number of delegation changes per delegatee over a very long period.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The FLOKI contract is an ERC-20 token with added governance delegation features, integrating with external Tax and Treasury handlers. The audit identified a critical vulnerability in the transferFrom function, allowing transfers without sufficient allowance, and a high-severity issue in the vote delegation logic that could lead to transaction reverts. Centralized control over critical external handlers by an EOA owner also presents a significant risk. The core _transfer function was not provided for review, limiting the scope of the audit.

Technical6/10Medium risk

The contract implements ERC-20 and governance delegation, utilizing OpenZeppelin's Ownable for access control (7.2 Code Security, 7.3 Access Control). However, a critical flaw in transferFrom allows token transfers to occur before allowance checks, leading to unauthorized spending. The _moveDelegates function contains logic that can cause reverts due to vote count inconsistencies, impacting governance functionality. The absence of the _transfer function's source code prevents a complete security assessment of core token transfers (7.2 Code Security).

Governance2/10High risk

The token design includes a fixed total supply minted entirely to the deployer, which is a clear distribution strategy (7.4 Economic). The governance delegation mechanism is based on a standard pattern, but its functionality is compromised by a high-severity bug in vote tracking. The owner, currently an EOA, has centralized control over taxHandler and treasuryHandler contracts, allowing them to change these critical external dependencies at will. This introduces a significant single point of failure and potential for malicious manipulation of tokenomics (7.5 Governance).

Upgrades6/10Medium risk

The contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities during upgrades. However, it also means that any discovered bugs or desired feature enhancements would require a new contract deployment and token migration.

Final RecommendationWhat to do about this score

Address the critical transferFrom vulnerability immediately by reordering the allowance check and update before the actual token transfer.

Rectify the vote tracking logic in _moveDelegates to prevent reverts and ensure consistent vote accounting. Consider implementing a multi-signature wallet for ownership to mitigate the risks associated with centralized control over critical external handlers and enhance operational security.

Contract & Record

1 audit on record

TypeVault, Token

NetworkEthereum

Token age4y

Contract0xcf0c…6a2e

Deployer0xa99c…5b9b

Badge for your website

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

Sep 4, 202665High

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

Frequently Asked Questions

What is the FLOKI contract address?

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