Until the owner calls enableTrading, nobody other than the owner and the sale contract can move tokens. There is no deadline, no automatic release and no external trigger, so the decision to make the token tradable rested entirely and indefinitely with one private key. This is the structural pattern behind a presale honeypot - buyers can acquire tokens through the sale contract but cannot resell them until the owner permits it. Two design choices limit the damage and deserve credit. The switch is one-way, guarded so it can only ever be flipped once, meaning the market can never be closed again after opening. And the exemption only grants permission to transfer, never authority to spend somebody else's balance. On the live contract the switch has been flipped and the capability is permanently spent. On the deployed contract the switch has already been used in the permissive direction and cannot be reversed, so transferability no longer rests on anyone's discretion. Recorded as informational on that basis. It would rate as medium for anyone redeploying this source.

setSaleContract writes a permanent and security-relevant storage slot, namely the one address that receives a lifetime exemption from the trading restriction, and emits nothing at all. Off-chain monitoring, indexers and explorers have no event to subscribe to, so detecting the change requires either polling the getter or decoding raw transaction input. There is no direct risk to funds, but it weakens the audit trail for a privileged action that can never be undone. The write has already happened and can never happen again, so the missing event is a historical gap in observability rather than a live one, and it is recorded as informational. It would rate as low for anyone redeploying this source.

The contract inherits the single-step Ownable rather than Ownable2Step, so transferOwnership hands over control immediately with no acceptance step from the recipient. A mistyped address, or an address whose key the recipient does not actually control, results in permanent loss of administrative control with no way back. The practical impact here is small because both privileged functions have already been used up and cannot be called again, so losing ownership today would cost nothing of substance. It remains a deviation from current best practice. On the deployed contract the owner role no longer carries any power over token mechanics, because both privileged functions are spent, so even a botched handover would cost nothing. Recorded as informational. It would rate as low for anyone redeploying this source, where the same role still decides whether the token can trade at all.

setSaleContract only checks that the argument is not the zero address and that the slot has not already been written. It does not check that the target actually has code, so a plain wallet can be given a permanent exemption from the trading restriction, which is not what the variable name suggests. The write-once guard is a deliberate and genuinely useful design choice because it stops an owner redirecting the exemption later, but the trade-off is that a wrong value can never be fixed. On the live contract the value is correct and points at the verified presale contract, and trading is open anyway, so there is no practical exposure today. The slot has already been written, and checking the stored address on-chain confirms it holds a genuine contract rather than a plain wallet, so the risk did not materialise. The exemption is in any case meaningless now that trading is open to everyone. Recorded as informational. It would rate as low for anyone redeploying this source.

Ownership was assigned to the deployer at construction, and checking that address on-chain confirms it has no contract code, so it is an ordinary wallet rather than a multi-signature setup. There is no timelock on any privileged function either. What keeps the impact low is that both privileged functions are single-use and both have already been used - enabling trading now reverts, and setting the sale contract now reverts. The only remaining owner capabilities are transferring or renouncing ownership, neither of which affects any balance. Both privileged functions are spent, so the role is effectively empty on the deployed contract and a compromise of the key would not let anyone freeze, mint, seize, blacklist or tax a single token. Recorded as informational on that basis. It would rate as low for anyone redeploying this source, where the same key would control launch.

The exemption is written so that only the sale contract as sender is allowed through. Tokens can leave the sale contract while trading is disabled, but they can never be sent into it. Any workflow that needs a buyer to hand tokens back - a refund, a buyback, a cancelled allocation, a swap into a different tranche - is impossible before trading opens unless the recipient happens to be the owner. This is a functional limitation rather than a security hole, and it is not currently relevant because trading is open. Now that trading is open to everyone, the direction of the exemption no longer makes any difference, so this is recorded as informational. It would rate as low for anyone redeploying this source, where the restriction is live right up until launch.

The restriction is enforced by overriding the public transfer and transferFrom functions, rather than by using the single internal hook that the underlying library routes every balance change through. For the contract exactly as deployed the coverage happens to be complete, and extensive fuzzing and symbolic analysis confirm there is no way around it today. The concern is that this completeness is incidental rather than structural. We demonstrated this by adding a perfectly ordinary batch-transfer helper to a subclass: the documented transfer path stayed correctly blocked while the new helper moved the same tokens freely, with no compiler warning and no failing test. The same helper added on top of the internal-hook design remained fully protected. The deployed contract is immutable and cannot be extended, so no new function can ever be added that would slip past the check, and the gap stays theoretical. Recorded as informational. It would rate as low for anyone redeploying this source, where the next feature someone adds is exactly what would bypass it.

The owner exemption applies when either side of a transfer is the owner. The outbound leg is what pre-launch distribution needs. The inbound leg grants something different - while the market is frozen, any holder, and any third party holding an allowance, can push tokens to the owner. This does not let anyone bypass the lock for their own benefit since the tokens end up with the owner, but it does mean the freeze is not uniform, and it creates a path where a holder could be talked into a transfer that looks like the only permitted action available. Not currently relevant because trading is open. With trading open the exemption no longer grants anything that is not already available to everyone, so this is recorded as informational. It would rate as low for anyone redeploying this source.

The constant is read exactly once, in the constructor, to size the initial mint, and is never compared against the actual supply afterwards. Because there is no mint function the supply can never exceed it, so the missing check is not a vulnerability. The name nonetheless promises a ceiling the code does not enforce, and burning drives the real supply permanently below it, so the two values diverge as soon as anyone burns.

Not a single function, parameter, return value, event or state variable carries documentation comments. The trading restriction in particular encodes business rules that are not self-evident - why the owner is exempt on both sides, why the sale contract is exempt only when sending, why burning is deliberately left unrestricted - and none of it is recorded. Explorers and wallets that display developer and user documentation have nothing to show.

The constructor explicitly sets the trading flag to false, but a boolean already starts as false, so the assignment is a no-op that only costs deployment gas. It is harmless and arguably self-documenting, but unnecessary.

The trading status event marks its boolean argument as indexed, which puts the value into a log topic rather than into the event data. The result is an event with an empty body, so any consumer that decodes non-indexed arguments receives nothing at all. We confirmed this by recording the log and observing two topics and zero data bytes. The event is also only ever emitted with the value true, since trading can only be switched on.

The source declares a floating compiler range starting at 0.8.20 while the deployment actually used 0.8.34. A floating range means the same source can compile to different bytecode depending on which compiler picks it up, which weakens reproducibility. It also nominally admits compiler versions carrying a few known issues, though none of those affect the version actually used or the constructs present in this contract.

The sale contract setter takes a parameter with a leading underscore, a prefix the style guide reserves for private and internal members. That same function is indented inconsistently, with its declaration offset by three spaces, its body at the wrong level and its closing brace at column zero. There are also stray blank lines in two places.

The burn functions reach the internal burn logic without passing through the trading rule check, so any holder can destroy their own tokens even while the market is frozen. Burning with an allowance behaves the same way and correctly consumes the allowance first. This is an undocumented asymmetry rather than a defect.

Approving overwrites the previous allowance without a compare-and-set, so a spender watching pending transactions can front-run a reduction, spend the old allowance and then spend the new one as well. We reproduced this and showed a spender extracting 150 tokens across a sequence that only ever authorised 100 and then 50. This is inherent to the token standard rather than a flaw in this contract, and the newer library version no longer ships the incremental allowance helpers that used to mitigate it.

Anyone who sees a signed approval in the pending transaction pool can submit it first. The nonce is consumed, the allowance is set correctly, and the signer's own transaction then reverts. No funds are at risk and the intended allowance is granted either way, but the signer pays for a failed transaction, and any contract bundling the approval with a follow-up call in the same transaction fails as a whole. This is inherent to the signature-approval standard.

The entire supply was minted to the deployer at construction and distributed manually from there. Reconstructing every balance from the complete transfer history shows the owner still holds just under twenty-eight percent, the top five addresses hold roughly fifty-seven percent and the top ten hold roughly eighty-one percent, spread across about three thousand six hundred holders. There is no vesting contract, no lock contract and no distribution schedule anywhere in the token, so every one of those balances is immediately transferable. At the time of review no automated market maker pool existed for this token against wrapped Ether at any standard fee tier, so there is currently no on-chain venue where those balances could be sold. This is a market and governance consideration rather than a contract defect.

The file header describes the contract as a token sale at a version number that does not correspond to anything else in the codebase, and it embeds a personal email address. Because the source is verified on the block explorer and the contract is immutable, that address is published permanently and cannot be removed.

The token standard is explicit that a transfer of zero must be treated like any other transfer and must still emit a transfer event. This contract evaluates the trading restriction before it ever looks at the amount, so while trading is disabled a zero-value transfer between two ordinary addresses is rejected outright rather than succeeding quietly. The library the token is built on handles zero amounts correctly, so the deviation is introduced entirely by the added restriction. It is a compatibility problem rather than a safety one, since no funds can move or be lost either way. On the deployed contract trading is already open and both transfer paths now handle zero amounts exactly as the standard requires, so this is recorded as informational. It would rate as low for anyone redeploying this source.