Quantum Audit Logo

Is World Liberty Financial USD Safe?

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

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

World Liberty Financial USD USD1
0x8d0d…8b0d
BNB Chain
Not verifiedThis 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 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The StablecoinV2 contract, an upgradeable ERC-20 token, implements EIP-3009 for transfer authorizations and includes features for managing frozen accounts. The contract leverages OpenZeppelin's upgradeable patterns and security libraries. While the core EIP-3009 implementation and general code quality are robust, significant centralization risk exists due to the owner's ability to drain or reallocate funds from frozen accounts. Additionally, considerations for batch operation error handling and EIP-712 domain separator stability are noted.

1 High1 Medium1 Low2 Informational
Volume 24h
$607.2K
Liquidity
$5.28M
Price
$1.0000
Token Age
1y
Top 10 Holders
85.6%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control Over Frozen Account Funds

H-01The `drain` and `reallocate` functions allow the contract owner to transfer all funds from a frozen account to any specified address. While intended for emergency situations, this grants the owner significant centralized control over user assets in frozen accounts. A compromise of the owner's private keys or the multisig could lead to the unauthorized draining or reallocation of funds from all frozen accounts.
IssueThe `drain` and `reallocate` functions allow the contract owner to transfer all funds from a frozen account to any specified address. While intended for emergency situations, this grants the owner significant centralized control over user assets in frozen accounts. A compromise of the owner's private keys or the multisig could lead to the unauthorized draining or reallocation of funds from all frozen accounts.
FixImplement additional safeguards for `drain` and `reallocate` functions. Consider requiring a multi-signature approval from a separate, highly secure committee, or introducing a timelock mechanism to allow users to react to pending fund movements. Clearly document the conditions under which these functions would be used.
StatusUnresolved
Medium

Batch Cancellation Silent Error Handling

M-01The `batchCancelAuthorization` function includes an `_ignoreErrors` parameter. If set to `true`, individual authorization cancellations that fail (e.g., due to invalid signatures or already used nonces) will be silently skipped, and the transaction will not revert. This behavior might be unexpected for users who assume all authorizations in a batch will be canceled or that the transaction will revert on any failure, potentially leading to confusion or incorrect off-chain state tracking.
IssueThe `batchCancelAuthorization` function includes an `_ignoreErrors` parameter. If set to `true`, individual authorization cancellations that fail (e.g., due to invalid signatures or already used nonces) will be silently skipped, and the transaction will not revert. This behavior might be unexpected for users who assume all authorizations in a batch will be canceled or that the transaction will revert on any failure, potentially leading to confusion or incorrect off-chain state tracking.
FixEvaluate if silent error ignoring is the desired behavior. If not, consider removing the `_ignoreErrors` parameter or making the default behavior to revert on any individual failure. If `_ignoreErrors` is kept, ensure clear documentation and user interface communication about its implications, and consider emitting more granular events for each successful/failed cancellation within the batch.
StatusUnresolved
Low

Undetermined Security of Parent Contract `Stablecoin`

L-01The `StablecoinV2` contract inherits from `Stablecoin`, but the source code for `Stablecoin` was not provided for this audit. The security and upgradeability of `StablecoinV2` are directly dependent on the correctness, security, and proper upgradeability patterns of its parent contract. Any vulnerabilities, improper storage layouts, or upgrade issues within `Stablecoin` could directly impact `StablecoinV2`.
IssueThe `StablecoinV2` contract inherits from `Stablecoin`, but the source code for `Stablecoin` was not provided for this audit. The security and upgradeability of `StablecoinV2` are directly dependent on the correctness, security, and proper upgradeability patterns of its parent contract. Any vulnerabilities, improper storage layouts, or upgrade issues within `Stablecoin` could directly impact `StablecoinV2`.
FixConduct a full security audit of the `Stablecoin` parent contract to ensure it adheres to best practices, especially regarding upgradeability and storage management. Verify that its design does not introduce any hidden vulnerabilities or storage collision risks for `StablecoinV2`.
StatusUnresolved
Info

EIP-712 Domain Separator Reliance on Mutable `name()`

I-01The EIP-712 domain separator is initialized using `__EIP712_init(name(), _EIP712_VERSION)`. The `name()` function, while typically static for ERC-20 tokens, could theoretically be changed in a future contract upgrade. If the token's `name()` were to change, it would invalidate all previously signed EIP-712 authorizations, as the domain separator would no longer match.
IssueThe EIP-712 domain separator is initialized using `__EIP712_init(name(), _EIP712_VERSION)`. The `name()` function, while typically static for ERC-20 tokens, could theoretically be changed in a future contract upgrade. If the token's `name()` were to change, it would invalidate all previously signed EIP-712 authorizations, as the domain separator would no longer match.
FixWhile `name()` is generally considered immutable for tokens, for maximum robustness and future-proofing, consider using a more stable identifier for the EIP-712 domain separator that is guaranteed not to change across upgrades, such as a hardcoded string or a constant that is not derived from a potentially mutable contract state.
StatusUnresolved
Info

Lack of Event for Authorization Usage

I-02The `_setAuthorizationAsUsed` function, which marks an EIP-3009 authorization nonce as used, does not emit an explicit event. While `AuthorizationCanceled` is emitted when an authorization is canceled, there is no corresponding event when an authorization is successfully used (e.g., via `transferWithAuthorization` or `receiveWithAuthorization`). This makes it harder for off-chain systems to track the exact moment an authorization becomes invalid due to usage.
IssueThe `_setAuthorizationAsUsed` function, which marks an EIP-3009 authorization nonce as used, does not emit an explicit event. While `AuthorizationCanceled` is emitted when an authorization is canceled, there is no corresponding event when an authorization is successfully used (e.g., via `transferWithAuthorization` or `receiveWithAuthorization`). This makes it harder for off-chain systems to track the exact moment an authorization becomes invalid due to usage.
FixConsider emitting an event (e.g., `AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce)`) within the `_setAuthorizationAsUsed` function. This would provide clearer visibility into the lifecycle of authorizations and facilitate more robust off-chain monitoring and indexing.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates strong technical foundations by utilizing OpenZeppelin's battle-tested upgradeable contracts and `SafeERC20` for secure token interactions (7.2 Code Security). The implementation of EIP-3009 for transfer authorizations, including nonce management and timestamp validity, is well-structured (7.1 Architecture). However, the `batchCancelAuthorization` function's `_ignoreErrors` parameter could lead to silent failures, potentially confusing users or off-chain systems (7.2 Code Security, 7.8 Operations). The EIP-712 domain separator's reliance on `name()` could introduce issues if the token name changes in future upgrades (7.2 Code Security).

GovernanceHigh1/10

The contract's owner, a 3/5 multisig, provides a good level of decentralization for administrative actions (7.5 Governance). However, the `drain` and `reallocate` functions grant the owner significant power to move funds from frozen accounts (7.3 Access Control). While intended for emergency scenarios, this centralized control over user funds represents a high economic risk if the owner's multisig were compromised or misused (7.4 Economic).

UpgradesHigh1/10

The contract is designed for upgradeability using OpenZeppelin's `TransparentUpgradeableProxy` pattern, correctly employing `_disableInitializers()` and `reinitializer` (7.7 Upgrades). The use of a custom storage slot (`_STABLECOIN_V2_STORAGE_LOCATION`) for `StablecoinV2Storage` effectively mitigates storage collision risks with inherited contracts (7.7 Upgrades). A potential concern is the implicit dependency on the `Stablecoin` parent contract's upgradeability and storage layout, which was not provided for audit (7.1 Architecture, 7.6 External). Additionally, the EIP-712 domain separator's reliance on the token's `name()` could cause issues if the name changes during an upgrade, invalidating existing signatures (7.7 Upgrades).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source

Holder Composition

85.6% in top 10
80.9% in wallets4.6% in contracts
Effective Concentration82.8%

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

$8.40M across 20 pairs
Pancakeswap v3USDTanalysed$5.28M62.9%Pancakeswap v3WBNB$2.45M29.2%Pancakeswap v3USDC$350.5K4.2%Pancakeswap v2WBNB$189.4K2.3%UniswapUSDT$52.3K0.6%TopazUSDT$40.8K0.5%
Show 4 more pairsShow less
Pancakeswap v2USDT$16.1K0.2%Pancakeswap v3WBNB$9.9K0.1%UniswapUSDC$5.2K0.1%Pancakeswap v3USDf$4.8K0.1%

The 10 remaining pairs hold $1.5K 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.

Key Addresses

1 addresses
Deployer
0x29e3…26bb

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (85.6% total → 82.8% effective; 80.9% in EOAs, 4.6% in contracts — extreme)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 1 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

Related Audits

6 more on the record
SpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical RiskVenusCoinCritical RiskBedrock (BR)Critical RiskCysic Token (CYS)Critical RiskBased Token (BASED)Critical Risk

Would You Like a More Detailed Audit of World Liberty Financial USD?

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

Get Detailed Audit