Honeypot, rug-pull and ownership checks

Is FLOKI a Scam?

BNB Chain

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

84/ 100

High RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

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

SummaryAI Copilot

The FLOKI token contract implements ERC-20 functionality with a Compound-style delegation system for governance.

Read the full analysis

What raised the score

Ownership not renounced — owner is an EOA
Top-10 concentration > 70%
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 > 70% (85.8% total → 79.9% effective; 75.9% in EOAs, 9.9% in contracts — extreme)
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 BNB Chain. 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

85.8%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking9.9%
Walletsanonymous holders, free to sell75.9%
Everyone elsethe rest of the supply14.2%

Effective concentrationwhat the score reads79.9%

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$9.88M across 19 pairs

Show 4 more pairs

The 9 remaining pairs hold $90 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$9.15MShare of depth92.5%

LP Locked90.7% · OnlyMoons Lock, UNCX

Top-1 Unlocked Holder9.2%

Unlocked LP held by

0x17e9…4b940x6605…16c00x0ed9…97060xf558…75200x2a90…5e5a0xf610…84b30xa3c4…04a80xd634…cc73

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

Security Findings

1 Critical2 High1 Medium1 Low1 Info

Critical

Missing Core `_transfer` Function Implementation

The provided contract snippet for FLOKI is missing the implementation of the internal _transfer function, which is essential for all token transfers (transfer, transferFrom). Without this function, the token is non-functional, as no actual balance updates or Transfer events can occur.C-01

Issue

Fix

Implement the _transfer function, ensuring it correctly updates _balances for sender and recipient, and emits Transfer events, adhering to ERC-20 standards. This function is fundamental for the token's operation.

Status

Unresolved

High

Incorrect `transferFrom` Allowance Logic

The transferFrom function first calls _transfer(sender, recipient, amount) and *then* checks and updates the allowance. This order is incorrect. If _transfer succeeds but the allowance check subsequently fails, the transaction will revert, but the logical flow is flawed. The allowance should be checked and updated *before* the actual token transfer to ensure atomicity and prevent potential unexpected behavior.H-01

Issue

Fix

Reorder the operations in transferFrom. First, check currentAllowance >= amount, then update _approve(sender, _msgSender(), currentAllowance - amount), and finally call _transfer(sender, recipient, amount).

Status

Unresolved

High

Potential Truncation of Voting Power in `_moveDelegates`

In the _moveDelegates function, delegatorBalance (a uint256) is cast to uint224 before being used to update delegate votes. If a delegator's balance exceeds type(uint224).max (approximately 2^224 - 1), the amount will be truncated. This leads to an incorrect representation of voting power for the delegatee, significantly impacting the integrity and accuracy of governance decisions.H-02

Issue

Fix

Ensure that delegatorBalance is handled as uint256 throughout the delegation logic to prevent truncation, or implement explicit checks to revert if delegatorBalance exceeds type(uint224).max if uint224 is strictly necessary for gas optimization. Using uint256 for vote amounts is generally safer if the total supply can exceed type(uint224).max.

Status

Unresolved

Medium

Centralized Control of Tax and Treasury Handlers

The setTaxHandler and setTreasuryHandler functions are protected by onlyOwner, allowing the contract owner to unilaterally change the addresses of the ITaxHandler and ITreasuryHandler contracts. This grants significant power to the owner, as these handlers could potentially control critical tokenomics such as transaction taxes, fees, and treasury distributions, without any community governance or time-lock mechanisms.M-01

Issue

Fix

Consider implementing a multi-signature wallet for ownership or introducing a time-lock mechanism for sensitive administrative actions like changing handler addresses. This would provide a delay, allowing the community to react to potentially malicious changes. Alternatively, integrate these changes into the governance system.

Status

Unresolved

Low

Theoretical `numCheckpoints` Overflow

The numCheckpoints variable, which tracks the number of checkpoints for a delegatee, is a uint32. While highly unlikely in practice (requiring over 4 billion delegation changes for a single address), it is theoretically possible for this variable to overflow, leading to unexpected behavior in vote counting.L-01

Issue

Fix

While the practical impact is minimal, consider using uint256 for numCheckpoints if future scaling or extreme usage patterns are anticipated, or add a check to prevent exceeding type(uint32).max.

Status

Unresolved

Info

Highly Centralized Initial Token Distribution

In the constructor, the entire totalSupply() of FLOKI tokens is minted and assigned to the deployer (_balances[_msgSender()] = totalSupply();). This results in a highly centralized initial token distribution, where the deployer holds 100% of the tokens. While common for new projects, it implies significant control over the token's supply and potential governance power if not subsequently distributed.I-01

Issue

Fix

Ensure a clear and transparent plan for token distribution is communicated to the community. Consider mechanisms for gradual decentralization of token holdings and governance power over time.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The FLOKI token contract implements ERC-20 functionality with a Compound-style delegation system for governance. The audit identified a critical vulnerability where the core _transfer function is entirely missing from the provided code, rendering the token non-functional. Additionally, a high-severity flaw in transferFrom's allowance logic and a high-severity truncation issue in the governance delegation mechanism were found, which could lead to incorrect voting power calculations. The contract also exhibits centralized control over key handler addresses.

Technical6/10Medium risk

The contract implements ERC-20 token standards and a Compound-style delegation system for governance. Strengths include the use of Solidity 0.8.11 for automatic overflow/underflow checks and a robust delegateBySig mechanism with nonce and expiry protection (7.2 Code Security). However, a critical issue is the complete absence of the _transfer function, making the token non-functional (7.2 Code Security). Furthermore, the transferFrom function has incorrect allowance update logic, and the _moveDelegates function may truncate large token balances when calculating voting power, impacting governance integrity (7.2 Code Security).

Governance1/10High risk

The FLOKI token incorporates a standard delegation-based governance system, allowing token holders to delegate their voting power. The fixed totalSupply and initial distribution to the deployer provide clarity on tokenomics (7.4 Economic). However, the contract owner retains significant centralized control, specifically the ability to unilaterally change taxHandler and treasuryHandler addresses, which could influence tokenomics without community oversight (7.3 Access Control, 7.5 Governance). The truncation of voting power in _moveDelegates also poses a direct risk to the fairness and accuracy of the governance mechanism (7.5 Governance).

Upgrades6/10Medium risk

The FLOKI contract is implemented as a standard, non-upgradeable token contract. This design choice eliminates the complexities and potential risks associated with proxy upgrade patterns, such as storage collisions or improper initialization (7.7 Upgrades). However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a complete redeployment and migration of token holders, which can be a complex and disruptive process (7.7 Operations).

Final RecommendationWhat to do about this score

Prioritize the immediate implementation of the _transfer function to make the token functional.

Rectify the transferFrom allowance logic to ensure correct and secure token transfers. Address the _moveDelegates truncation issue to guarantee accurate voting power calculations, which is crucial for the integrity of the governance system. For long-term security and decentralization, consider implementing a multi-signature wallet or a time-lock for administrative functions like changing handler addresses. Ensure a clear plan for initial token distribution is communicated.

Contract & Record

1 audit on record

TypeVault, Token

NetworkBNB Chain

Token age4y

Contract0xfb5b…d37e

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

Aug 30, 202684High

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 BNB Chain is 0xfb5b838b6cfeedc2873ab27866079ac55363d37e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.