Is FLOKI a Scam? Security Analysis

Security Findings

1 Crit2 High1 Med1 Low2 Info

Critical

`transferFrom` Logic Flaw Allows Unauthorized Transfers

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

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

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

StatusUnresolved

High

Vote Tracking Inconsistency and Potential Reverts in `_moveDelegates`

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

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

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

StatusUnresolved

High

Centralized Control Over Critical External Handlers

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

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

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

StatusUnresolved

Medium

Missing `_transfer` Function Implementation

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

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

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

StatusUnresolved

Low

Owner as Externally Owned Account (EOA)

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

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

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

StatusUnresolved

Info

Fixed Total Supply Minted to Deployer

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

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

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

StatusUnresolved

Info

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

I-02The `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.

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh2/10

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

UpgradesMedium6/10

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.

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

69.6% in top 10

57.1% in wallets12.5% in contracts

Effective Concentration62.1%

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

$7.69M across 3 pairs

Uniswap v2WETHanalysed$7.69M Uniswap v3WETH$454 Uniswap v3USDT$1

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 Locked78.9% · UNCX

Top-1 Unlocked Holder12.5%

Top-3 Unlocked21.1%

Lock Expiry2286 (verified ≥ 1 year) · UNCX V2

Key Addresses

10 addresses

Deployer

0xa99c…5b9b

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.

What Raised This Score

6 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

Is FLOKI a Scam?

Security Findings

`transferFrom` Logic Flaw Allows Unauthorized Transfers

Vote Tracking Inconsistency and Potential Reverts in `_moveDelegates`

Centralized Control Over Critical External Handlers

Missing `_transfer` Function Implementation

Owner as Externally Owned Account (EOA)

Fixed Total Supply Minted to Deployer

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

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?