Quantum Audit Logo
Launch App

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

Is Zest Safe?

ZESTBase
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance3/10Upgrades4/10Checks passed2 of 5Findings1 Low · 2 Info3
SummaryAI Copilot

The FactoryBurnMintERC20 contract implements a standard ERC20 token with controlled minting and burning capabilities, leveraging well-audited OpenZeppelin and Chainlink libraries.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
78.4%Contracts19.5%Wallets2.0%
78.4%Contracts19.5%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
98.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking78.4%
  • Walletsanonymous holders, free to sell19.5%
  • Everyone elsethe rest of the supply2.0%
Effective concentrationwhat the score reads50.9%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$173.2K

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$173.2KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x7c83…fc36

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

Security Findings

1 Low2 Info
Low

Use of Deprecated ERC20 increaseApproval/decreaseApproval Functions

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

Issue

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

Fix

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

Status

Unresolved

Info

Significant Centralized Control by Owner

The 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).I-01

Issue

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

Fix

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

Status

Unresolved

Info

Potential Gas Limit Exceedance for Role Enumeration

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

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance3/10High risk

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.

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to maintain strict security practices for the multisig controlling the owner role, including regular audits of its participants and operational procedures.

While the deprecated ERC20 functions are minor, consider removing them for clarity and adherence to modern standards. For any future administrative roles, evaluate the potential for gas limit issues if the number of participants is expected to be very large.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0x7297…7fc2
Deployer0x75f0…4b4c
Badge for your website
Zest security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202657Medium
  2. Aug 11, 202649Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the ZEST contract address?

The Zest contract on Base is 0x7297968ffb753dd12e4f6b1f18d9865c76707fc2. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Zest a scam?

Quantum Audit's risk score for Zest is 57/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ZEST liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $173.2K.

Who holds ZEST?

As of Sep 4, 2026, the 10 largest holders own 98.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Coinbase Wrapped XRPCBXRP · Base57MediumBankr KatBANKAT · Base57MediumOMI TokenOMI · Base58MediumSilencioSLC · Base58MediumRibbita by VirtualsTIBBIR · Base56MediumPromptBase56Medium

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 Is this your token? Publish your own audit on this page