Smart Contract Analysis Statement

Contract Analysis

The Zyphron (ZYN) V2 contract is a revision of the previously audited ERC20 token. It keeps the same external behaviour - 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 - but reworks the internals to address the items raised in the prior audit. The re-audit confirmed that the majority of the prior findings have been addressed correctly, with a single regression introduced by one of the fixes:

• The supply-floor concern from the prior audit was addressed by adding a floor check inside the core ledger update. That change closes the original breach (totalSupply can no longer drop below the floor) but introduces a separate accounting regression on the user-callable burn paths. The sender's balance is debited by the full requested value before the burn amount is silently capped against the available headroom, so any voluntary burn larger than the headroom reduces the sender's balance by more than the supply decrease. The difference is destroyed without supply accounting, which violates the ERC20 invariant that the sum of all balances equals the total supply. This finding is tracked as the headline high-severity item for the re-audit.
• The timelock for the per-transfer cap was previously a 48-second delay with no binding between the announced and executed amounts. V2 raises the delay to 48 hours and stores the requested amount in the timelock-request struct so the execute path rejects any divergent amount. Both halves of the original concern are fully addressed.
• The combined burn-fee plus extra sell-tax math is now capped once after summing the components, so a near-floor sell can no longer over-burn. Because the floor cap inside the core ledger update applies belt-and-suspenders, the in-transfer cap is now the primary gate and the ledger cap is a safety net for the fee-burn path.
• The setDexPair admin function now mirrors the burn-fee exclusion to the active argument, only updates the canonical pointer on registration, and clears the previous canonical pair's flag when switching. The de-registration semantics are no longer surprising and operators no longer need a second call to fully revoke a pair.
• Zero-value transfers now succeed and emit the standard Transfer event, in line with the EIP20 specification. The token-recovery helper now rejects non-contract addresses and uses abi.encodeCall with a SafeERC20-style return-data check, closing the event-spoofing concern from the prior audit.
• The token-holder counter is now guarded so it only changes on real balance transitions, the burn(0) griefing path is closed, the per-fee-setter event mismatch is fixed, the constructor zero-address checks are present, the renamed and missing-NatSpec items are all in. A two-step renounce ceremony was introduced, but both calls can be made in the same block by the same key, so the protection is closer to a UI confirmation than a real ceremony - this is captured as a residual low-severity item.

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 full privileges including:

• 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 now 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 now rejects non-contract addresses and uses a SafeERC20-style return-data check.
• Registering or de-registering DEX pairs; the burn-fee exclusion flag now mirrors the active argument and the previous canonical pair is cleared on registration of a new one.
• Renouncing ownership through a two-call ceremony. Both calls can be made in the same block by the same key, so the protection is weaker than a transferOwnership-style two-party flow. This is tracked as an open low-severity item with a recommended timelock-based fix.

Security Features

The contract implements several positive security features that have been preserved and in some cases strengthened in V2:

• Two-step ownership transfer (Ownable2Step) which protects against accidental ownership handover to an address that cannot accept it.
• 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, replacing the previous 48-second cosmetic delay.
• Custom errors throughout the contract in place of string-based require messages, with consistent ZYN__ naming.
• NatSpec on the constructor, on every ZYN-specific external function, and on the internal _update and _transfer hooks, documenting both intent and the team-accepted governance choices.
• Compliance with the ERC20 selectors and events as required by the standard; slither-check-erc confirms that every required function and event is present with the correct signatures. Note that the new sum-of-balances accounting regression is not visible to slither-check-erc because it is a relational invariant between two state variables rather than an ABI defect.

Re-audit Outcome

The re-audit confirmed that all open prior findings have been addressed with the following dispositions: every high and medium item from the prior audit is either fixed or has its remediation in place, with one exception. The previous high item on the burn floor has been partially addressed; the attempted fix closes the original breach but introduces a new high-severity accounting regression that is captured as a new finding. Two governance choices (drainable admin paths, on-chain holder counter, native-value receive fallback) have been formally acknowledged by the team rather than fixed. Three new informational items were surfaced during the re-audit: the burn event is only emitted on the fee-burn path, the constructor-time exclusion grants do not emit their event, and one interface member (getReserves) remains unused. A residual low-severity item tracks the weak two-step renounce. Static-analyzer hits dropped sharply from the prior baseline; the remaining detector hits are false positives or mitigated patterns.

Note - This re-audit report consists of a security analysis of the Zyphron (ZYN) V2 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 the team address the new high-severity accounting regression before deployment, and we recommend investors do their own research before investing.