Is FLOKI a Scam? Security Analysis

Security Findings

1 Crit2 High1 Med1 Low1 Info

Critical

Missing Core `_transfer` Function Implementation

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

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

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

StatusUnresolved

High

Incorrect `transferFrom` Allowance Logic

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

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

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

StatusUnresolved

High

Potential Truncation of Voting Power in `_moveDelegates`

H-02In 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.

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

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

StatusUnresolved

Medium

Centralized Control of Tax and Treasury Handlers

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

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

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

StatusUnresolved

Low

Theoretical `numCheckpoints` Overflow

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

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

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

StatusUnresolved

Info

Highly Centralized Initial Token Distribution

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh1/10

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

UpgradesMedium6/10

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

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

85.8% in top 10

75.9% in wallets9.9% in contracts

Effective Concentration79.9%

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

$9.88M across 19 pairs

Pancakeswap v2WBNBanalysed$9.15M ApeswapWBNB$410.2K BiswapWBNB$319.3K Pancakeswap v3USDT$5.2K Pancakeswap v3DOGE$836 Pancakeswap v3WBNB$508

Show 4 more pairsShow less

Pancakeswap v3PEPE$366 Thena v1USDT$227 Pancakeswap v2USDT$125 0x6fB6…cbE5USDT$32

The 9 remaining pairs hold $90 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 Locked90.7% · OnlyMoons Lock, UNCX

Top-1 Unlocked Holder9.2%

Key Addresses

9 addresses

Deployer

0xa99c…5b9b

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.

What Raised This Score

6 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeVault, Token

Audit History

1 audit on record

Aug 3084

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

Is FLOKI a Scam?

Security Findings

Missing Core `_transfer` Function Implementation

Incorrect `transferFrom` Allowance Logic

Potential Truncation of Voting Power in `_moveDelegates`

Centralized Control of Tax and Treasury Handlers

Theoretical `numCheckpoints` Overflow

Highly Centralized Initial Token Distribution

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 FLOKI?