Quantum Audit Logo

Is Fake World Assets Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Fake World Assets FWA
0xa0df…c845
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FWAToken contract implements a fixed-supply ERC20 token with custom transfer restrictions and a Uniswap v4 integrated buyback mechanism. While leveraging battle-tested libraries like Solady and incorporating reentrancy protection, a critical vulnerability was identified in the Uniswap v4 callback logic. This flaw, involving an integer underflow during an allowance grant, could lead to the unauthorized draining of the contract's FWAToken balance. Additionally, the contract exhibits centralized owner privileges and a minor denial-of-service vector for its buyback function.

1 Critical1 Medium1 Low
Volume 24h
$1.04M
Liquidity
$823.4K
Price
$0.01162
Token Age
11d
Top 10 Holders
24.0%

Security Findings

1 Crit1 Med1 Low
Critical

Uniswap V4 Callback Integer Underflow Leads to Infinite Allowance

C-01The `uniswapV4UnlockCallback` function, invoked by the Uniswap v4 PoolManager during a swap, attempts to set an allowance for the `poolManager` to pull FWAToken from the contract. Specifically, `_approve(address(this), address(poolManager), uint256(delta.amount0))` is called. In the `buyback()` scenario, the contract is buying FWAToken (currency0) and selling ETH (currency1). This implies `delta.amount0` (the net change in FWAToken balance for the pool) will be a negative `int256` value, as the pool sends FWAToken to the contract. Casting a negative `int256` value to `uint256` results in an integer underflow, yielding a very large (effectively infinite) `uint256` value. This grants the `poo…
IssueThe `uniswapV4UnlockCallback` function, invoked by the Uniswap v4 PoolManager during a swap, attempts to set an allowance for the `poolManager` to pull FWAToken from the contract. Specifically, `_approve(address(this), address(poolManager), uint256(delta.amount0))` is called. In the `buyback()` scenario, the contract is buying FWAToken (currency0) and selling ETH (currency1). This implies `delta.amount0` (the net change in FWAToken balance for the pool) will be a negative `int256` value, as the pool sends FWAToken to the contract. Casting a negative `int256` value to `uint256` results in an integer underflow, yielding a very large (effectively infinite) `uint256` value. This grants the `poo…
FixThe `uniswapV4UnlockCallback` function's logic for setting allowances must be critically reviewed and corrected. For a buyback where FWAToken is received by the contract, no allowance should be granted to the `poolManager` for FWAToken. If an allowance is needed for other swap directions, ensure `delta.amount0` is correctly handled (e.g., only if positive and representing an outgoing token transfer) and that appropriate access control (`onlyHook`) is maintained. Consider removing the `_approve`…
StatusUnresolved
Medium

Extensive Centralized Owner Privileges

M-01The `Ownable` contract grants significant control to the owner address. The owner can: set `isDistributor` for any address, bypassing transfer restrictions; set the `pool` (IBuybackRouter) address, which receives a portion of bought FWAToken; set the `routeSplit` for depositors, purchasers, and burn, potentially manipulating token distribution; set `buybackSqrtPriceLimitX96`, influencing the buyback price; and approve any `spender` to transfer tokens from the contract using `_approve(address spender, uint256 amount)`. While common in early-stage projects, this centralization introduces a single point of failure and trust, where a compromised owner key could lead to significant financial los…
IssueThe `Ownable` contract grants significant control to the owner address. The owner can: set `isDistributor` for any address, bypassing transfer restrictions; set the `pool` (IBuybackRouter) address, which receives a portion of bought FWAToken; set the `routeSplit` for depositors, purchasers, and burn, potentially manipulating token distribution; set `buybackSqrtPriceLimitX96`, influencing the buyback price; and approve any `spender` to transfer tokens from the contract using `_approve(address spender, uint256 amount)`. While common in early-stage projects, this centralization introduces a single point of failure and trust, where a compromised owner key could lead to significant financial los…
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner address to reduce the risk of a single point of compromise. As the protocol matures, explore decentralizing control through a time-locked governance mechanism for critical parameters like the `pool` address and `routeSplit` to enhance trust and resilience.
StatusUnresolved
Low

Buyback Function Susceptible to Minor Denial of Service

L-01The `buyback()` function includes a rate-limiting mechanism (`block.number >= lastBuybackBlock + BUYBACK_DELAY_BLOCKS`). A malicious actor could repeatedly call `buyback()` with the minimum required ETH (`BUYBACK_INCREMENT` is 1 ETH) just after the `BUYBACK_DELAY_BLOCKS` period. This action would effectively reset `lastBuybackBlock`, preventing other users from executing larger or more impactful buybacks for the duration of the delay. While the cost of 1 ETH per call acts as a deterrent, it could still be used to disrupt buyback operations or create an unfavorable user experience.
IssueThe `buyback()` function includes a rate-limiting mechanism (`block.number >= lastBuybackBlock + BUYBACK_DELAY_BLOCKS`). A malicious actor could repeatedly call `buyback()` with the minimum required ETH (`BUYBACK_INCREMENT` is 1 ETH) just after the `BUYBACK_DELAY_BLOCKS` period. This action would effectively reset `lastBuybackBlock`, preventing other users from executing larger or more impactful buybacks for the duration of the delay. While the cost of 1 ETH per call acts as a deterrent, it could still be used to disrupt buyback operations or create an unfavorable user experience.
FixEvaluate if the `BUYBACK_DELAY_BLOCKS` and `BUYBACK_INCREMENT` are appropriately balanced for the intended operational frequency and cost. Consider increasing the `BUYBACK_INCREMENT` or implementing a dynamic delay based on recent buyback activity or a minimum ETH amount for the caller to prevent trivial denial-of-service attempts.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good architectural practices (7.1) by using immutable variables for critical external dependencies and inheriting `ReentrancyGuard` for code security (7.2). Custom error types enhance readability and gas efficiency. However, a critical flaw exists in the Uniswap v4 callback's handling of `BalanceDelta` values, leading to an integer underflow and unauthorized allowance grant (7.2). The interaction between custom transfer restrictions and the Uniswap v4 callback also presents an access control (7.3) bypass for the PoolManager.

GovernanceHigh2/10

The tokenomics (7.4) feature a fixed supply and a buyback mechanism designed to accrue value and distribute tokens, with configurable routing splits and a price limit to protect against extreme market movements. However, the owner retains significant control over key economic parameters, including setting distributors, the buyback router, and routing splits, which introduces centralization risk (7.5). The permissionless buyback function also has a minor denial-of-service vector (7.8) due to its rate-limiting mechanism.

UpgradesMedium4/10

The FWAToken contract is not designed as an upgradeable proxy (7.7). Therefore, there are no direct upgrade safety concerns. Any changes to the contract logic would require a new deployment and migration of assets, which is a standard practice for non-upgradeable contracts.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

24.0% in top 10
11.4% in wallets12.6% in contracts
Effective Concentration16.5%

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

$832.3K across 3 pairs
Uniswap v4ETHanalysed$823.4K98.9%Uniswap v4ETH$8.9K1.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.

Key Addresses

1 addresses
Deployer
0x0198…e8cb

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Token age < 30 days (still settling)
  • 1 Critical 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

Related Audits

6 more on the record
Token Prometeus Network (PROM)High RiskPrismHigh RiskStaked USDe (SUSDE)High RiskGULDHigh RiskDeXeHigh RiskTether Gold (XAUT)High Risk

Would You Like a More Detailed Audit of Fake World Assets?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit