Smart Contract Analysis Statement

Contract Analysis

The ZEON contract implements an ERC20 token with a fixed supply of 1,000,000,000 units minted once at deployment, a fee-on-transfer mechanism that applies only to trades against registered market maker pairs, and a set of anti-whale controls comprising a maximum wallet balance, a maximum transaction size and a per-sender cooldown. Fees are split across three destination wallets for rewards, treasury and liquidity support, and are raised to a flat 7 percent for the first 72 hours after trading first opens. Rate changes are governed by a 24-hour delay and are limited to two changes for the lifetime of the contract. The token is not upgradeable, uses no proxy, contains no mint or burn function beyond the initial supply creation, and makes no external calls at all, which removes reentrancy as a category of risk. Transfers between ordinary holders are not charged a fee.

This statement covers the second re-review of the contract, carried out against the revision submitted as final. The fee arithmetic was sound before and remains so: across extensive automated testing the total supply never changed, the sum of all balances always matched the total supply, the sender was always debited exactly the amount requested, and the effective fee reached but never exceeded the advertised 7 percent ceiling. Every property established in the previous review still holds on this revision, and none of the changes made since disturbed them.

Three of the four items carried into this round are now closed. The two anti-whale figures became compile-time constants with no setter anywhere in the contract, so the 2 percent per wallet and 0.5 percent per transaction the documentation presents can no longer be moved by anyone in either direction. The three setters that previously changed protective state silently now announce every change. Marking a fee wallet or the contract's own address as a trading pair is refused. Most substantially, the shared-privilege side effect that two of the previous revision's own fixes had introduced is fully closed: both writes to the exemption flag now check whether the address being cleared still holds another role before clearing it, and the deployment shortcut that made the problem easy to reach is rejected outright by the constructor. We re-ran both configurations that previously misbehaved and both now behave correctly.

The one item deliberately not changed is the breadth of the exemption itself, and the project has accepted that in writing, in a comment on the mapping. That is a legitimate position and the reasoning given for it is sound. It does, however, interact with the decision to remove the limit setters, in a way worth stating plainly to holders rather than leaving implicit, and that is the substance of our remaining recommendations.

Ownership Privileges

The ownership of the contract has been assigned at deployment to a single externally owned account, with no multi-signature wallet and no delay on any privileged function other than the fee rate change. The owner retains full privileges including:

• Granting any address a complete exemption from the trading lock, the transaction size limit, the wallet balance cap, the cooldown and all fees in a single call. The exemption is all-or-nothing and cannot be granted in part. This was raised in the previous two reviews and has now been accepted explicitly as a design decision rather than changed. It is announced on chain, which it previously was not, so the privileged set is at least auditable by a holder who watches for it.
• Waiving either anti-whale limit for a chosen address. The two figures are now immutable, but their enforcement is not: the transaction limit is skipped whenever either party to a transfer is exempt, and the wallet cap is skipped whenever the recipient is exempt, the recipient is a registered pair, or the sender is flagged as a payout source. A holder should read the guarantee as the figures being fixed forever, and exemption from them remaining an owner privilege.
• Redirecting all future fee revenue by changing any of the three destination wallets, and designating or removing market maker pairs, which determines which transfers are charged a fee at all. De-registering the live pair silently reduces all fees to zero, and so does pointing a fee wallet at the live pair, which the contract still permits.
• The owner can no longer re-freeze trading. The release is irreversible once taken, cannot be taken twice, and is always announced. The owner can still hold the launch indefinitely before releasing, which is the intended purpose of the control.
• The owner can no longer raise or lower the wallet cap or the transaction limit. Both are compile-time constants and no function exists to change either. This is the most significant reduction in owner power in this revision.
• The owner can no longer disable the cooldown. It is bounded between 15 and 120 seconds, where it previously accepted zero. This narrows owner power but also removes an option the design's own reasoning depends on, which is covered in our recommendations.
• The owner can no longer render the contract unusable. Renouncing while the lock is engaged is refused, and a handover requires the incoming address to accept, so neither an accidental renouncement nor a mistyped destination can remove the ability to open trading.
• The owner cannot mint new tokens. The supply is created once in the constructor and no mint function exists anywhere in the contract, which we confirmed both by review and by automated testing across several hundred thousand operations.
• The owner cannot raise fees above 7 percent. The ceiling is a fixed constant that cannot be changed, applies to both the buy and the sell rate, and is enforced when a change is proposed. Only two rate changes are permitted for the lifetime of the contract, after which rates are frozen permanently.
• The owner cannot bypass the 24-hour delay on a fee change. We verified that an early execution attempt is refused and that the change applies only once the full period has elapsed.
• The owner cannot burn or seize any holder's balance, cannot blacklist an address, and cannot pause an individual account. There is no blacklist and no burn path in the contract.

Security Features

The contract implements several positive security features:

• A genuinely hard fee ceiling. Unlike most fee-bearing tokens, where a maximum rate is itself an owner-settable value, the 7 percent limit here is a compile-time constant. Combined with the two-change lifetime budget and the 24-hour delay, this is a real and well-implemented restraint on the parameter most commonly abused in this class of contract.
• Immutable anti-whale figures. The wallet cap and transaction limit are now constants rather than settable parameters, so the advertised percentages hold in both directions. This closes the half of the previous finding that concerned the values themselves, and it is verified as a standing property across every reachable sequence of privileged calls rather than only by reading the code.
• An irreversible trading release. The launch can be held back but not undone, which removes the single most common honeypot construction in this class of contract.
• Role-aware privilege management. Rotating a fee wallet or handing over ownership now moves the exemption with the role and, new in this revision, declines to revoke it from an address that still holds another role. This is the correct shape for the problem and it closes a side effect the previous round's fixes had introduced.
• Ownership that cannot strand the contract. Renouncement is refused while transfers are frozen, and a handover requires the incoming address to accept, so the two routes to an unrecoverable state are both closed.
• A fixed, verifiable supply with no inflation surface. The absence of any mint function, rebase mechanism, reflection accounting or hidden allocator was confirmed by review and held as a property throughout automated testing.
• No external calls and no upgrade path. The contract cannot be altered after deployment and cannot be re-entered, which eliminates two of the most common sources of loss in token contracts. There is no proxy, no delegated code execution and no assembly.
• Careful handling of the supply creation path. The zero address is excluded from all fee and limit logic in the constructor, the exemption function permanently refuses to change that entry, and the ownership override is written so that renouncing cannot clear it either. We verified that last point specifically, because it is the kind of interaction a fix of this shape can easily break.

Recommendations

Nothing outstanding is blocking, and nothing raised in this round is rated above informational. Four items remain, all small, and three of them are consequences of changes made in this revision rather than survivals from the previous one. None is reachable by anyone other than the owner, none puts a holder's funds at risk, and none grants an owner a capability the exemption flag does not already grant, which is why each is recorded as an observation rather than as a defect to fix before launch.

The comment introducing the newly immutable limits states that locking them makes the interface's claim of no admin override and no fine print literally true. The figures are indeed fixed forever, and that is a real improvement worth publicising. Enforcement of them is not fixed: three separate owner-controlled flags each waive one or both limits for a chosen address, and we confirmed each of them on this revision. Since the exemption flag is being kept as a single dimension by choice, the honest statement to holders is that the figures are immutable and exemption from them is an owner privilege that is announced on chain. Publishing the exempt set and the payout-source set alongside the percentages would let a holder check who is currently outside them, which is the part of our original recommendation that still carries.

Removing the limit setters also removed the only fine-grained lever the operator had. An exchange, a market maker or a large presale buyer legitimately holding more than 2 percent of supply can now only be accommodated by granting the full exemption bundle, which waives their fees as well. That is a tokenomics decision rather than a defect, but it should be a decision taken knowingly before launch rather than discovered afterwards, because after renouncement no accommodation is possible at all.

Registering a trading pair now refuses an address that is one of the fee wallets. The three fee-wallet setters did not get the matching check, so the same state is still reachable from the other direction: pointing a fee role at the live pair is accepted, the setter exempts it, and every trade through that venue then pays nothing. We confirmed this on the resubmitted source, where a sale into the registered pair delivered in full and none of the three sinks received anything. It is an owner mistake rather than an attack and one call undoes it, but the guard should point both ways. Separately, the constructor should pick up the check the three setters already carry and refuse the contract's own address as a fee sink; that configuration is still accepted at deployment and sends fees somewhere they can never be recovered from.

The cooldown gained a lower bound of 15 seconds in this revision, which conflicts with the reasoning the same revision gives for keeping the rest of the cooldown design as it is. That reasoning rests on the cooldown being a soft launch-window measure intended to be relaxed once the launch has settled, and the floor makes relaxing it impossible. Two costs become permanent as a result: any address holding an allowance can keep the granting wallet throttled indefinitely for the price of one dust transfer per window, and every ordinary wallet carries a per-transfer throttle for the life of the token while a wallet that installs a delegation does not. We recommend letting the floor be zero and treating standing the cooldown down after launch as the planned end state, which is what the surrounding comment already says the intention is. If a non-zero floor is wanted as a guarantee to holders, then close the delegated-transfer path at the same time, so the residual it makes permanent is removed rather than locked in.

Finally, ownership of the contract should be moved to a multi-signature wallet, with a delay on the broadest privileged functions. This is now the single largest remaining risk in the contract, and it is the item we would want settled before any funds are raised.

Note - This Audit report consists of a security analysis of the ZEON smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the ZEON team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.