Quantum Audit Logo

Is World Liberty Financial 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 WLFI
0xda5e…bef6
Ethereum
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 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The WorldLibertyFinancialV3 contract, serving as an upgradeable ERC20 token with integrated vesting and registry logic, has been audited. The contract leverages OpenZeppelin's upgradeable libraries and implements a system for users to 'elect' vesting updates, which can alter their category and, in some cases, burn a portion of their token allocation. The audit identified a high-severity centralization risk due to the owner's extensive control over vesting updates and token burning, as well as medium-severity concerns regarding potential signature replay in user-initiated elections and an economic incompatibility for certain claimed users. Overall, the contract demonstrates good adherence to OpenZeppelin standards but requires careful consideration of its centralized control mechanisms and specific vesting logic implications.

1 High2 Medium1 Low1 Informational
Volume 24h
$356.7K
Liquidity
$4.74M
Price
$0.05629
Token Age
1y
Top 10 Holders
74.9%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control Over Vesting Updates and Token Burning

H-01The `ownerElectVestingUpdatesFor` function allows the contract owner (a multisig) to unilaterally trigger vesting updates for any array of accounts. This process can lead to the burning of 10% of an account's allocation if the account is in a 'known non-retail category' and has not claimed any tokens. This grants significant power to the owner to alter user vesting terms and reduce token supply without direct user consent for specific updates. The `authorizedSigner` also holds substantial power via `electVestingUpdate`.
IssueThe `ownerElectVestingUpdatesFor` function allows the contract owner (a multisig) to unilaterally trigger vesting updates for any array of accounts. This process can lead to the burning of 10% of an account's allocation if the account is in a 'known non-retail category' and has not claimed any tokens. This grants significant power to the owner to alter user vesting terms and reduce token supply without direct user consent for specific updates. The `authorizedSigner` also holds substantial power via `electVestingUpdate`.
FixConsider implementing a more decentralized or time-locked mechanism for owner-initiated vesting updates, especially those involving token burning. For instance, a governance vote or a timelock could be introduced before such significant changes are applied. Clearly document the extent of the owner's and authorized signer's control and its implications for token holders.
StatusUnresolved
Medium

Signature Replay Vulnerability in `electVestingUpdate`

M-01The `electVestingUpdate` function relies on an ECDSA signature for authorization, using `account` and `deadline` as part of the signed message. However, it does not incorporate a unique `nonce` for each signature. While `_msgSender()` ensures the caller is the `account` in the signature, the absence of a nonce means that a valid signature for a future `deadline` could potentially be replayed if the transaction fails or if the user wishes to invalidate a previously signed message before the deadline. This could lead to unintended or duplicate vesting updates.
IssueThe `electVestingUpdate` function relies on an ECDSA signature for authorization, using `account` and `deadline` as part of the signed message. However, it does not incorporate a unique `nonce` for each signature. While `_msgSender()` ensures the caller is the `account` in the signature, the absence of a nonce means that a valid signature for a future `deadline` could potentially be replayed if the transaction fails or if the user wishes to invalidate a previously signed message before the deadline. This could lead to unintended or duplicate vesting updates.
FixIntegrate a nonce into the signed message for `electVestingUpdate`. This nonce should be managed on-chain (e.g., incremented after each successful use or tied to an EIP-712 `nonces` mapping) to ensure that each signature can only be used once, effectively preventing replay attacks.
StatusUnresolved
Medium

Incompatibility for Claimed Non-Retail Users

M-02The `_electVestingUpdate` function explicitly reverts if `alreadyClaimed > 0` when attempting to transition an account to `TERMINAL_NON_RETAIL_CATEGORY` (which occurs for `isKnownNonRetailCategory` users). This means users who were in categories 2-20 and have claimed any amount of their allocation are permanently blocked from electing this specific vesting update. This design choice might lead to an undesirable user experience or lock certain users into less favorable vesting terms, potentially preventing them from accessing intended benefits of the `TERMINAL_NON_RETAIL_CATEGORY`.
IssueThe `_electVestingUpdate` function explicitly reverts if `alreadyClaimed > 0` when attempting to transition an account to `TERMINAL_NON_RETAIL_CATEGORY` (which occurs for `isKnownNonRetailCategory` users). This means users who were in categories 2-20 and have claimed any amount of their allocation are permanently blocked from electing this specific vesting update. This design choice might lead to an undesirable user experience or lock certain users into less favorable vesting terms, potentially preventing them from accessing intended benefits of the `TERMINAL_NON_RETAIL_CATEGORY`.
FixReview the business logic behind preventing claimed non-retail users from updating their vesting category. If this is an intentional design, ensure it is clearly communicated to users. If not, consider adjusting the logic to allow such transitions, perhaps by requiring a full burn of claimed tokens or a different mechanism to handle prior claims.
StatusUnresolved
Low

Dependency on `WorldLibertyFinancialV2` Storage Layout

L-01The `WorldLibertyFinancialV3` contract inherits from `WorldLibertyFinancialV2`. In upgradeable contract systems, maintaining strict storage compatibility between inherited contracts and their upgrades is crucial to prevent storage collisions and data corruption. Without the source code for `WorldLibertyFinancialV2`, it is assumed that proper storage layout practices (e.g., using `__gap` arrays for future expansion) have been diligently followed in `V2` to ensure `V3`'s storage remains aligned.
IssueThe `WorldLibertyFinancialV3` contract inherits from `WorldLibertyFinancialV2`. In upgradeable contract systems, maintaining strict storage compatibility between inherited contracts and their upgrades is crucial to prevent storage collisions and data corruption. Without the source code for `WorldLibertyFinancialV2`, it is assumed that proper storage layout practices (e.g., using `__gap` arrays for future expansion) have been diligently followed in `V2` to ensure `V3`'s storage remains aligned.
FixEnsure that the `WorldLibertyFinancialV2` contract strictly adheres to OpenZeppelin's upgradeable storage layout guidelines, including the use of `__gap` arrays to reserve storage slots for future upgrades. A thorough review of `V2`'s storage layout in conjunction with `V3`'s is recommended to confirm compatibility.
StatusUnresolved
Info

Lack of Event for Batch Owner Vesting Updates

I-01The `ownerElectVestingUpdatesFor` function iterates through an array of accounts, calling `_electVestingUpdate` for each. While `_electVestingUpdate` emits a `VestingUpdated` event for individual accounts, there is no overarching event emitted by `ownerElectVestingUpdatesFor` itself. This makes it harder for off-chain monitoring systems to track when a batch of owner-initiated vesting updates has occurred, or to identify the specific transaction that triggered multiple updates.
IssueThe `ownerElectVestingUpdatesFor` function iterates through an array of accounts, calling `_electVestingUpdate` for each. While `_electVestingUpdate` emits a `VestingUpdated` event for individual accounts, there is no overarching event emitted by `ownerElectVestingUpdatesFor` itself. This makes it harder for off-chain monitoring systems to track when a batch of owner-initiated vesting updates has occurred, or to identify the specific transaction that triggered multiple updates.
FixConsider emitting an event from `ownerElectVestingUpdatesFor` that includes the `owner` address and the array of `_accounts` for which updates were initiated. This would improve transparency and ease of monitoring for batch operations.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes OpenZeppelin's upgradeable components, including `Ownable2StepUpgradeable`, `ERC20Upgradeable`, and `SafeERC20`, contributing to a robust technical foundation (7.2 Code Security). The use of custom errors and the `whenNotPaused` modifier enhances error handling and operational control. However, the `electVestingUpdate` function lacks a nonce in its signature scheme, which could expose it to replay attacks if not carefully managed (7.2 Code Security). No reentrancy or integer overflow/underflow vulnerabilities were identified.

GovernanceHigh3/10

The contract exhibits a high degree of centralized control, with the `owner` (a multisig) having the ability to unilaterally initiate vesting updates for any account, potentially leading to token burning (7.3 Access Control, 7.4 Economic). The `authorizedSigner` also holds significant power in approving user-initiated vesting updates. A specific economic constraint prevents users in 'known non-retail categories' from updating their vesting if they have already claimed any tokens, which could lead to unexpected user experience or fund lock-up for affected users (7.4 Economic).

UpgradesHigh3/10

The contract is deployed behind a TransparentUpgradeableProxy and uses OpenZeppelin's upgradeable base contracts, indicating a well-established upgrade pattern (7.1 Architecture, 7.7 Upgrades). The proxy's admin is a multisig, which is a strong security practice for upgrade control. A minor concern exists regarding storage compatibility with the inherited `WorldLibertyFinancialV2` contract, though OpenZeppelin's upgradeable patterns typically mitigate this through careful design (7.7 Upgrades).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
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
Upgrades (30d)0 · stable

Holder Composition

74.9% in top 10
27.5% in wallets47.4% in contracts
Effective Concentration46.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

$7.54M across 12 pairs
Uniswap v4ETHanalysed$4.74M62.9%Uniswap v3USDT$1.45M19.3%Uniswap v3USDC$1.14M15.1%Uniswap v4USDC$166.6K2.2%Uniswap v3WETH$15.9K0.2%Uniswap v4ETH$12.6K0.2%
Show 4 more pairsShow less
Uniswap v3WETH$4.7K0.1%Uniswap v4ETH$3.4K0.0%Uniswap v4USDC$1.4K0.0%Uniswap v3USD1$4360.0%

The 2 remaining pairs hold $3 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
0x97f1…21e3

What Raised This Score

7 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (74.9% total → 46.5% effective; 27.5% in EOAs, 47.4% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 1 High finding(s) from audit
  • 2 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
Satellite Doge-1 (DOGE-1)Medium RiskEuro Coin (EURC)Medium RiskBiconomy (BICO)Medium RiskLisk (LSK)Medium RisksendMedium RiskNeiroMedium Risk

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

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

Get Detailed Audit