Smart Contract Analysis Statement

Contract Analysis

The ZEON Presale contract implements a stablecoin-denominated token sale with an optional whitelist, a per-wallet contribution cap, an owner-set price bounded by immutable minimum and maximum rails, an optional purchase bonus capped at 25 percent, and a two-part release schedule in which a configurable share of each purchase unlocks immediately and the remainder vests linearly. Each purchase is recorded as a lot that captures the release terms in force at the time it was made, so a later configuration change cannot retroactively alter an existing buyer's schedule. The contract is not upgradeable and uses no proxy. It is intended for deployment on BNB Smart Chain against the USDT contract at 0x55d398326f99059fF775485246999027B3197955, which uses 18 decimals and returns a success value from its transfer functions.

This statement covers the second re-review of the contract, carried out against the revision submitted as final. Everything established in the previous review still holds: the immediate and vesting portions of every purchase sum exactly to the total, no buyer can claim more than they purchased, no lot is ever over-drawn, claims release only what has matured, the price never leaves its immutable bounds, and the contract always holds at least what it owes buyers. The obligation reserve introduced in the previous revision, which was the substantive fix in this engagement, was re-verified rather than assumed and was never broken.

All three items carried into this round are closed, and one of them was closed by the preferred remedy rather than a workaround. The contribution cap no longer applies a hardcoded 18-decimal scaling factor and is stored in the payment token's own units, so it now binds correctly against any payment token rather than only the selected one. Re-run against the six-decimal asset that previously voided it entirely, the cap refuses a purchase above it, accepts one exactly at it, and refuses one unit more. The constructor now requires the sale token and the payment token to be different addresses, which closes the configuration where the proceeds sweep would have walked straight through the obligation reserve, and it also rejects a zero contribution cap, which previously made every purchase revert until the sale was taken offline and reconfigured.

The third change is new accounting on the payment path, so we verified it from first principles rather than by comparison. A purchase that arrives under the same timestamp and the same schedule as the buyer's most recent lot is now folded into that lot instead of opening a new one, which removes the accumulation pressure on the per-buyer lot limit at its source. Fifty purchases in one block now produce one lot rather than fifty. We checked that the fold keeps the split exact, keeps the lot totals equal to the buyer's ledger, leaves the vesting anchor unchanged and pays the whole folded position out in full; that a change of schedule correctly opens a new lot instead of folding; and that it still holds in the one configuration where the reasoning given in the source does not, namely a zero-length schedule, where a lot can be drawn down in the block it was opened in. It survives that case because the counter it leaves untouched is cumulative against the same lot, so growing the position without growing the counter credits exactly the new money and nothing more. The property was also proved symbolically over two unbounded payment amounts and exercised across sixteen thousand stateful calls.

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. The owner retains full privileges including:

• Withdrawing all sale proceeds at any time, with no vesting condition. This is the only unbounded withdrawal in the contract, and it means an operator can collect all revenue before delivering anything. It is a policy choice rather than a defect, but it should be understood as one.
• Changing the price, the bonus and the release schedule, adding or removing any address from the whitelist, opening the sale to the public and bypassing the whitelist entirely, halting new purchases, and changing the address that receives withdrawn funds.
• The owner cannot withdraw tokens that buyers have already paid for. The recovery function computes what is owed before it moves anything and can only take the remainder. This was the critical finding in the first review and it remains closed on this revision.
• The owner can no longer reach the obligation reserve through the proceeds withdrawal either. That route depended on both configured token addresses pointing at the same asset, which the constructor now refuses. Both addresses are written once at construction and have no setter, so the guarantee holds for the life of the contract rather than only at deployment.
• The owner cannot change the price, the bonus or the release schedule while the sale is live. All three require the sale to be paused first. This should not be relied on as protection against a deliberate front-run, because pausing, repricing and resuming is three transactions and an operator willing to send them can still land all three ahead of a pending purchase. The control that actually protects a buyer is the minimum-output argument on the purchase function.
• The owner cannot set a release schedule longer than two years, and cannot set one that disables a buyer's claims. Both the length and the arithmetic are bounded.
• The owner cannot set a per-wallet contribution cap of zero, in the constructor or afterwards, so the configuration that silently disabled every purchase is no longer reachable.
• The owner cannot strand the contract's assets. Ownership moves in two steps and requires the incoming address to accept, and renouncing is refused while the contract holds either asset.
• The owner cannot set a price outside the minimum and maximum bounds fixed at deployment. These rails are immutable and cannot be changed afterwards, and they meaningfully limit how far a price change can move against a buyer. We verified that no setter can escape them.
• The owner cannot set the purchase bonus above 25 percent. This ceiling is a fixed constant and is enforced whenever the bonus is changed.
• The owner cannot alter an existing purchase's release schedule. Each lot stores its own terms at the moment of purchase, so a later change affects only subsequent purchases. The owner also cannot claim on a buyer's behalf, redirect a buyer's claim to another address, or cause a buyer to be credited more than they purchased.
• The owner cannot halt claims. Pausing the sale stops new purchases only; buyers can always withdraw what has matured.
• The owner cannot change the token addresses after deployment. Both the sale token and the payment token are fixed in the constructor and no function exists to alter them.

Security Features

The contract implements several positive security features:

• An enforced obligation reserve. The contract cannot sell what it does not hold and cannot release what it owes. This is the change that turns a sale where buyers held an unbacked claim into one where their allocation is backed at every moment, and it is verified as a standing property rather than a code-reading exercise.
• Buyer-side execution bounds. A purchase carries both a minimum acceptable quantity and an expiry, so a buyer can bound what they are willing to accept rather than committing to whatever terms happen to be in force when their transaction lands.
• Immutable price rails. The minimum and maximum price are fixed at deployment and cannot be changed, placing a hard and verifiable bound on how far the owner can move the sale price in either direction.
• A decimal-agnostic contribution cap. The cap is now held in the payment token's own units with no assumption about how many decimals that token has, which makes the whole contract decimal-agnostic rather than only its pricing arithmetic.
• Per-lot capture of release terms. Because each purchase records its own immediate-unlock share and vesting length, a configuration change cannot retroactively worsen the terms of a purchase already made. This is a deliberate and well-chosen design decision.
• Correct ordering and a reentrancy guard on every value-moving path. State is fully updated before any token leaves the contract, and the guard covers the purchase and both claim paths together, so a callback cannot re-enter one from another. Re-running the first review's attack against a payment token that notifies the payer, the nested purchase is rejected and the ledger records exactly what was paid.
• Bounded, overflow-proof release arithmetic shared by the claim path and the read-only view, with a hard ceiling on the schedule length enforced at deployment as well as at configuration time.
• A bounded claim cost, now bounded from two directions. Purchase lots per buyer are capped and a paginated claim is available, and rapid accumulation no longer consumes the cap at all because same-block purchases are folded into one lot. Measured at the cap, draining a full position still costs well under a block on the target chain.
• A hard ceiling on the purchase bonus and an explicit cap on the immediate-unlock share, both enforced on every change, together with an exact per-lot ledger that never allowed a buyer to be credited or paid more than they had purchased across several hundred thousand automated operations.

Recommendations

Nothing outstanding is blocking, the contract is in good shape, and nothing raised in this round is rated above informational. Four items remain, two of which are deployment discipline rather than code.

The change to the contribution cap is correct but it reverses the meaning of an argument. The constructor and the setter now store exactly what they are handed, where they previously multiplied it. A script written against the previous revision would pass a whole-unit figure and silently produce a cap smaller than intended by a factor of one quintillion against the selected asset, which we confirmed on this revision. It is recoverable by pausing and reconfiguring, so the cost is a failed launch window rather than lost funds, but reading the stored cap back and comparing it against the intended human-readable figure should now be a required deployment step rather than a recommended one.

The minimum-output argument is the control that protects a buyer from a change of terms, and it is opt-in. A front end that submits zero leaves buyers exactly as exposed as they were before that fix. Deriving that value from the price the buyer was shown, and rejecting a zero value client-side, should be treated as a hard requirement of the interface rather than an optional refinement.

The new purchase fold is described in the source as applying within a single block, but what it actually tests is that the previous lot's timestamp equals the current one. On BNB Smart Chain those are different statements, because the chain has produced a block every 0.75 seconds since the Maxwell hardfork while the timestamp available to contracts still has second precision, so consecutive blocks routinely share a value. The chain's own specification for that change flags using the timestamp as an identity key as a pattern needing adjustment. The effect here is benign, because the accounting depends on elapsed time rather than on block identity and zero seconds have still passed, but the documentation should describe what the fold does rather than what it was intended to do. The one practical consequence is off-chain: a folded purchase reuses the lot index it folded into, so the index carried by the release event no longer identifies a purchase and an indexer keyed on it will collapse two payouts into one. Emitting a sequence number alongside the index would remove that ambiguity.

The per-buyer lot limit is still permanent once reached, which is now much harder to reach by accident and remains self-inflicted, and no minimum purchase size was added, so at a low price a purchase worth a fraction of a cent still opens a lot. Both are worth closing eventually but neither is urgent.

Finally, ownership of the contract should be moved to a multi-signature wallet, with a delay on the recovery function and the vesting configuration. This is the largest remaining risk. We also recommend verifying the deployment wiring on a fork before doing it for real: the sale depends on two separate flags being set on it in the token contract, and setting only one still produces a sale that cannot be funded or cannot pay out. That requirement has not gone away, and it matters more now that the token's transaction limit is immutable and can no longer be raised to work around a missing exemption.

Note - This Audit report consists of a security analysis of the ZEON Presale 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.