Smart Contract Analysis Statement

Contract Analysis

The Zyphron (ZYN) V3 contract is the second revision of the previously audited ERC20 token. External behaviour is unchanged from V2 - a hard-coded initial mint of 50,000,000 tokens, an automatic burn fee on every transfer, an additional sell tax when transferring to a registered DEX pair, a per-transfer cap, an emergency BNB withdrawal, and a stuck-token recovery helper. V3 closes every open finding from the V2 re-audit, including the high-severity sum-of-balances accounting regression introduced by the V2 burn-floor fix:

• The supply-floor remediation has been reworked using the audit's preferred option. The silent cap inside the core ledger update has been removed and replaced by a pre-flight floor check at the entry of the burn primitive. If a voluntary burn would push totalSupply below the declared floor the function reverts atomically with a dedicated custom error, leaving no state changes behind. The balance debit and the supply debit therefore always operate on the same value, preserving the ERC20 invariant that the sum of all balances equals the total supply. The fee-burn path inside the transfer hook is unaffected because the combined burn-fee plus sell-tax math continues to pre-cap to the available headroom.
• The two-step renounceOwnership ceremony introduced in V2 has been hardened with a mandatory 48-hour delay between the two calls. The first call records a future timestamp and emits the ownership-transfer-started event, the second call reverts until the delay has elapsed, and any intervening transferOwnership call cancels a pending renounce. The renounce timelock reuses the same constant as the per-transfer cap timelock, so the irreversible admin surface is now symmetric.
• The Burn event has been moved into the burn primitive itself, so voluntary burn, burnFrom, and the in-transfer fee-burn all emit it exactly once per burn. The previous duplicate-emit risk on the fee-burn path is gone, and indexers that subscribe to Burn no longer miss user-callable burns.
• The constructor now emits the burn-fee-exclusion event for every initial grant - the initial owner, the supply recipient, the contract itself, and the registered DEX pair - so off-chain indexers can reconstruct the full exclusion set from the deployment transaction without reading storage.
• The DEX pair interface is now honest about its surface area: the unused getReserves declaration has been removed alongside the unused factory declaration removed in V2.
• The increaseAllowance and decreaseAllowance helpers are retained for backward compatibility, but they now carry explicit NatSpec warning that they do not eliminate the underlying ERC20 approve race condition. Integrators are pointed at the OpenZeppelin v5 removal rationale.
• Every other V2 fix carries over without regression: zero-value transfers succeed per EIP20, the token-recovery helper rejects non-contract addresses and uses SafeERC20-style return decoding, the setDexPair function mirrors its active argument across the canonical pointer, sell-flag, and exclusion writes, the per-transfer-cap timelock binds the executed amount to the requested amount over a 48-hour delay, and the token-holder counter only changes on real balance transitions.

Ownership Privileges

The ownership of the contract is held by the deployer-supplied initialOwner address using OpenZeppelin's two-step Ownable2Step pattern. The owner retains the same privileges as in V2:

• Setting the burn fee percentage up to a 5% cap.
• Setting an additional sell-tax percentage up to a 5% cap.
• Excluding or re-including arbitrary addresses from the burn fee, which in practice also bypasses the per-transfer cap for that address.
• Scheduling and executing a per-transfer cap through a 48-hour timelock; the execute path requires the executed amount to match the requested amount stored on chain.
• Withdrawing the contract's entire native (BNB) balance in a single call without delay. The team has explicitly accepted this as a governance choice and documented the intent in the source.
• Recovering any non-ZYN ERC20 token sent to the contract in a single call without delay. The function rejects non-contract addresses and uses a SafeERC20-style return-data check.
• Registering or de-registering DEX pairs; the burn-fee exclusion flag mirrors the active argument and the previous canonical pair is cleared on registration of a new one.
• Renouncing ownership through a two-call ceremony with a mandatory 48-hour separation between the two calls. A pending renounce is cancelled by any transferOwnership call. This brings the renounce path in line with the rest of the irreversible admin surface and replaces the V2 same-block-completion weakness.

Security Features

The contract preserves and slightly strengthens the security mechanisms introduced in V2:

• Two-step ownership transfer (Ownable2Step) which protects against accidental ownership handover to an address that cannot accept it, with renouncement now subject to the same 48-hour timelock as the per-transfer cap.
• A ReentrancyGuard modifier on the admin paths that move value (emergencyWithdraw, recoverBEP20) and on both halves of the per-transfer cap timelock.
• Hard caps on both the burn fee (5%) and the sell tax (5%), well below typical fee-on-transfer protocol limits.
• A 48-hour timelock on the per-transfer cap with the executed amount bound to the requested amount stored on chain.
• A 48-hour timelock on the renounceOwnership ceremony, using the same constant as the per-transfer cap timelock.
• A pre-flight floor check inside the burn primitive that atomically reverts any burn that would push totalSupply below the declared 21,000,000 floor, preserving the sum-of-balances == totalSupply invariant on every path.
• The Burn event is now emitted from a single canonical location inside the burn primitive, so every burn path - voluntary, allowance-driven, and fee-burn - is observable by indexers with exactly one event per burn.
• Custom errors throughout the contract in place of string-based require messages, with consistent ZYN__ naming and two new errors (ZYN__BurnFloorBreached, ZYN__RenounceTimelockNotExpired) for the new revert paths.
• NatSpec on the constructor, on every ZYN-specific external function, on the internal _update, _burn, and _transfer hooks, and on the receive fallback, documenting both intent and the team-accepted governance choices.
• Compliance with the ERC20 selectors and events as required by the standard. The accounting-regression risk that slither-check-erc could not surface in V2 is closed; every Foundry-PoC scenario that previously demonstrated a sum-of-balances breach now demonstrates a clean revert, with the invariant intact across all branches.

Note - This re-audit report consists of a security analysis of the Zyphron (ZYN) V3 smart contract. The analysis did not include economic analysis of the contract's tokenomics. Only the main contract was audited; other contracts associated with the project were not in scope. We recommend investors do their own research before investing.