Quantum Audit Logo

Is Zest Safe?

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

Zest ZEST
0x7297…7fc2
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FactoryBurnMintERC20 contract implements a standard ERC20 token with controlled minting and burning capabilities, leveraging well-audited OpenZeppelin and Chainlink libraries. The contract demonstrates robust technical security, including proper access control for sensitive operations and immutable supply limits. While a few minor informational and low-severity findings were identified, the overall risk posture is considered low, especially given the owner is a multisig.

1 Low2 Informational
Volume 24h
$1.47M
Liquidity
$173.2K
Price
$0.1545
Token Age
1y
Top 10 Holders
98.0%

Security Findings

1 Low2 Info
Low

Use of Deprecated ERC20 `increaseApproval`/`decreaseApproval` Functions

L-01The contract includes `increaseApproval` and `decreaseApproval` functions, which are deprecated in modern ERC20 standards. While these functions correctly delegate to `increaseAllowance` and `decreaseAllowance` respectively, their presence can lead to confusion or suggest outdated practices to users and integrators.
IssueThe contract includes `increaseApproval` and `decreaseApproval` functions, which are deprecated in modern ERC20 standards. While these functions correctly delegate to `increaseAllowance` and `decreaseAllowance` respectively, their presence can lead to confusion or suggest outdated practices to users and integrators.
FixConsider removing the `increaseApproval` and `decreaseApproval` functions. Users should be encouraged to interact directly with `increaseAllowance` and `decreaseAllowance` for clarity and adherence to current ERC20 best practices.
StatusUnresolved
Info

Significant Centralized Control by Owner

I-01The `owner` role possesses extensive control over critical functions, including granting/revoking minter and burner roles, and setting the `ccipAdmin` address. This centralization means that a compromise of the owner's private key could lead to unauthorized minting, burning, or manipulation of the `ccipAdmin` role. The pre-filled data indicates the owner is a multisig, which significantly mitigates this risk (7.3 Access Control, 7.8 Operations).
IssueThe `owner` role possesses extensive control over critical functions, including granting/revoking minter and burner roles, and setting the `ccipAdmin` address. This centralization means that a compromise of the owner's private key could lead to unauthorized minting, burning, or manipulation of the `ccipAdmin` role. The pre-filled data indicates the owner is a multisig, which significantly mitigates this risk (7.3 Access Control, 7.8 Operations).
FixWhile mitigated by a multisig, it is crucial to maintain robust security practices for the multisig signers. Regularly review and audit the multisig setup and its participants. Consider implementing time-locks for critical administrative actions if the protocol's risk profile increases.
StatusUnresolved
Info

Potential Gas Limit Exceedance for Role Enumeration

I-02The `getMinters()` and `getBurners()` functions return an array of all addresses with the respective roles using `EnumerableSet.values()`. If the number of minters or burners were to grow excessively large (e.g., hundreds or thousands), calling these functions could potentially exceed the block gas limit, rendering them unusable (7.2 Code Security).
IssueThe `getMinters()` and `getBurners()` functions return an array of all addresses with the respective roles using `EnumerableSet.values()`. If the number of minters or burners were to grow excessively large (e.g., hundreds or thousands), calling these functions could potentially exceed the block gas limit, rendering them unusable (7.2 Code Security).
FixFor roles that are expected to remain limited (e.g., administrative roles), this is a low concern. If the design ever anticipates a very large number of minters/burners, consider alternative methods for querying roles, such as individual `isMinter`/`isBurner` checks, or pagination if a UI needs to display all roles.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract exhibits strong technical security (7.2 Code Security) by utilizing battle-tested OpenZeppelin and Chainlink libraries, and compiling with Solidity 0.8.x, which includes built-in overflow/underflow checks. The `validAddress` modifier prevents self-transfers, enhancing robustness. Access control (7.3 Access Control) for minting and burning roles is properly enforced. A minor issue includes the use of deprecated ERC20 functions, though they correctly delegate to modern equivalents.

GovernanceHigh3/10

The economic model (7.4 Economic) is straightforward, with an immutable `maxSupply` set at deployment, preventing uncontrolled inflation unless `maxSupply` is explicitly set to zero. Governance (7.5 Governance) is centralized, with the `owner` having control over minting/burning roles and the `ccipAdmin` address. This centralization is significantly mitigated by the owner being a multisig, as indicated by the pre-filled data, which enhances security and reduces single points of failure.

UpgradesMedium4/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no upgrade-specific risks such as proxy storage collisions or improper initialization. Any changes to the contract's logic would require a new deployment.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

98.0% in top 10
19.5% in wallets78.4% in contracts
Effective Concentration50.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

$173.2K

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x75f0…4b4c
Unlocked LP Held By
0x7c83…fc36

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

7 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (98.0% total → 50.9% effective; 19.5% in EOAs, 78.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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
Coinbase Wrapped XRP (CBXRP)High RiskOMI Token (OMI)High RiskSilencio (SLC)High RiskRibbita by Virtuals (TIBBIR)High RiskPromptHigh RiskEURCHigh Risk

Would You Like a More Detailed Audit of Zest?

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

Get Detailed Audit