The rescue helper is intended to recover unrelated tokens that were sent to the contract by mistake. It does not exclude the contract's own token, so calling it with the token's own address transfers the entire accumulated tax balance directly to the operator wallet. The transfer runs while the internal swap latch is engaged, so it is not taxed on the way out. This bypasses the fee recipient entirely and changes the form of the payout from ETH proceeds to raw tokens, which the operator can then dispose of on their own terms. It is within the operator's existing trust boundary rather than an outside attack, but it is an undeclared route for value to leave the contract and it undermines the separation between the operator wallet and the fee recipient that the rest of the design sets up.

The rescue helper interprets the response of the outbound transfer by decoding it as a boolean whenever the response is not empty. Some tokens return a payload that is shorter than a full word. Decoding such a response does not fail gracefully - it triggers a low level panic that aborts the whole call. The consequence is that any token behaving this way can be received by the contract but never recovered from it, so the balance is stuck for good. The condition is easy to reach in practice because non standard return data is common among older and hand written tokens, and it was reproduced with a token returning a single byte.

When a sell is processed, the contract converts part of its accumulated tax to ETH in the middle of the transfer hook, before the sender's and recipient's balances have been written. The proceeds are pushed to the fee recipient with all remaining gas forwarded. If that recipient is a contract, it regains control at a point where the internal swap latch is still engaged, and while that latch is engaged the transfer hook skips taxation and every size limit. A fee recipient behaving this way can therefore move tokens free of tax and free of limits, which was reproduced in testing. Balance readings taken by outside integrators during this window also reflect an intermediate state rather than a settled one. On the live token the fee recipient is an ordinary externally owned account with no code, so there is nothing to call back and the issue is not currently exploitable, but the ordering is incorrect and the exposure would become real the moment that address were replaced by a contract in a future deployment.

The contract defines a ceiling on how many tokens may be converted to ETH in a single swap, and the automatic conversion respects it. The operator triggered conversion does not consult it at all and instead sells the entire balance the contract is holding. With a zero minimum output on the same call, a large accumulated balance is pushed through the pool in one transaction, producing a price impact well beyond what the configured ceiling was meant to allow and creating an obvious opportunity for others to trade around it. Testing showed a balance six times the configured ceiling being sold in a single swap.

The contract declares a dedicated error for the case that trading is not yet open, and it maintains a flag that is set when trading is opened. No code path anywhere reads that flag to restrict transfers, and the error is never raised. Transfers therefore work normally before trading is opened, which was confirmed by moving tokens between two wallets on a freshly deployed instance. The practical exposure at launch was small, since the deployer held the entire supply at that point, but the arrangement is misleading to anyone reviewing the source and it would allow trading to begin on an alternative venue ahead of the official opening if any tokens had been distributed beforehand.

The hook decides what kind of transfer it is looking at purely by checking whether the pair is the sender or the recipient, so it cannot tell a trade apart from a liquidity operation. Withdrawing liquidity produces a transfer out of the pair, which is read as a purchase: the exit is charged the buy tax, it advances the purchase counter, and while the size limits are still active a large exit is rejected outright, preventing a provider from leaving in a single transaction. Adding liquidity produces a transfer into the pair, which is read as a sale: it is charged the sell tax and it triggers the automatic tax conversion, so the pair receives less than the depositor sent, the deposit ratio is skewed against them and they are issued fewer liquidity tokens than expected. On this deployment the whole liquidity position was burned and the limits have been removed, so the withdrawal side is academic, but the provision side still applies to anyone who wants to deepen the pool from here.

Parameter validation accepts opening and closing tax rates of up to one hundred percent and a tax ceiling of up to one hundred percent. Separately, the helpers that decide the rate in force return the opening rate while the purchase counter is still at or below its threshold, and that opening rate is never compared against the declared ceiling. A deployment can therefore advertise a low ceiling and still charge far more than it during the opening phase, and because the parameter that controls when the opening phase ends is itself unvalidated it can be set high enough that the phase never ends. For the token actually deployed here the numbers are benign - the ceiling is three percent, the opening rates are three percent, and the ceiling is enforced on every later change - so the concern is confined to reuse of the template.

Opening trading adds the contract's whole token and ETH balance as liquidity while accepting zero as the minimum for both sides and discarding the three values the call returns. Because the amounts actually consumed are never compared against the amounts intended, the contract has no way of noticing when the pool ends up with less than was sent. That is not hypothetical here - it is precisely how the three percent liquidity shortfall went unnoticed. The missing minimums also mean that anyone who pushes tokens or wrapped ETH into the empty pair beforehand can shift the opening price, and the call will proceed regardless instead of rejecting the distorted result.

The contract uses the single step ownership pattern, so an ownership transfer takes effect immediately and a mistyped destination address would have permanently removed the ability to open trading or lift the limits. That risk did not materialise and no longer applies, because ownership has since been renounced deliberately. The token also inherits the well known allowance race condition of the standard, where changing a non zero allowance directly to another non zero value can be exploited by a spender who front runs the change and spends both amounts. Both are noted for completeness and for the benefit of future deployments from this template.

The transfer hook treats any transfer coming from the trading pair as a purchase and increments the internal buy counter, with no check that the amount is greater than zero. A standard Uniswap pair exposes a public skim function that anyone may call, and on a pair whose balances match its reserves that call performs a zero-value transfer out of the pair. The token counts it as a real buy. Nothing is spent apart from gas, roughly 77,000 per increment. The counter is not merely a statistic - it gates the first-block purchase cap, both tax-reduction thresholds, the point at which automatic tax conversion becomes possible, and the provisional tax that applies while the counter is still zero. Before trading is opened the first-block branch is never taken, so the counter can be driven arbitrarily high in advance. Once the team then opens trading, the cap is already exhausted and every genuine purchase in the opening block is rejected, which turns the anti-sniping control into a denial of service against the launch itself. The same weakness has a second face: because the launch self-taxing issue only occurs while the counter is still zero, a single free skim beforehand would have skipped it entirely and delivered the full liquidity allocation to the pool. On the deployed token this is spent - the counter stands at 2,386, trading is open and every affected threshold has been passed - but in the reusable template it defeats the launch protection outright.

When the accumulated tax reaches its threshold, the transfer hook converts part of it to the native currency by calling the router directly inside the user's transfer, and that call is not guarded. Any failure inside the router - a rejected payment to the fee recipient, insufficient liquidity in the pair, a zero conversion amount, or a minimum-output bound if one were later added - propagates outward and reverts the seller's transaction. A holder whose only involvement was being the one to push the accumulated tax over the threshold is unable to exit, and will remain unable to for as long as the underlying condition persists. This also constrains how the missing slippage protection can be fixed, since adding a minimum-output bound without first isolating the conversion would convert an ordinary price movement into a frozen market.

Constructor validation rejects a conversion cap above one hundred percent but accepts zero, and the accompanying cross-check between the conversion threshold and the conversion cap is satisfied when both are zero. The resulting per-swap cap is zero, so the amount handed to the router is zero and the router rejects it. Combined with the fact that a failed conversion also cancels the user's sale, the outcome is that every sale which reaches the conversion threshold reverts, permanently. The same situation arises for small supplies where the cap is expressed in basis points and rounds down to zero. This is not reachable on the deployed token, whose cap is configured at one percent, but any future deployment from the same template can fall into it through a plausible configuration choice.