Disabling a payment asset only clears its enabled flag and leaves it in the list. Because registration appends whenever the asset is not currently enabled, re-enabling a previously disabled asset appends a second entry, and each further disable and re-enable cycle adds another. Five cycles were reproduced leaving five extra copies. The list is returned in full by a public helper, so it grows without bound and becomes progressively more expensive to read, and the reported event on removal states a decimal count of zero while the stored record keeps the real value.

The helper that returns the active phase indexes the phase array directly, so between deployment and the creation of the first phase it fails with an out of bounds panic. The neighbouring helper that reports whether the sale is active handles the same state correctly by checking the array length first, so the inconsistency is clearly unintended.

Every native currency purchase forwards the payment to the funds wallet with a raw call and reverts the whole purchase if that call fails. The destination is set by an administrator with no check that it can accept native currency, so pointing it at a contract that rejects transfers stops the entire native purchase path for every buyer, which was reproduced. Because the call forwards all remaining gas and is not capped, a destination that consumes gas deliberately can also make purchases fail or become arbitrarily expensive.

Phase creation rejects a window whose end is not after its start, but the update function writes both timestamps with no such check. An administrator can therefore update a phase into an inverted window, which the creation function refuses, and the phase then becomes permanently unbuyable because the purchase validation can never be satisfied. This was reproduced by confirming that the creation call reverts and the equivalent update call succeeds.

Whether a purchase is locked at all is decided solely by the vesting duration, so a phase configured with a long cliff and a zero duration pays out in full immediately and the cliff is silently discarded. This was reproduced with a one year cliff that had no effect whatsoever. In the opposite configuration, where the cliff is longer than the duration, the elapsed time has already passed the duration by the moment the cliff expires, so the entire position unlocks in a single step and no linear release ever occurs. Neither combination is rejected at configuration time.

The setters for the oracle staleness window, the referral bonus rate and the global hard cap all write storage and return without emitting anything. Every other configuration change in the contract does emit an event, so these three are gaps rather than a consistent choice, and two of them alter parameters that directly affect pricing and cap enforcement.

Four externally reachable functions index the phase array without checking it first. Both purchase paths reach it through the shared validation helper, which reads the active phase before anything else, so while no phase has been created yet a buyer gets a raw out of bounds panic instead of a descriptive error. That window is narrow, because it closes permanently once the first phase exists and the active index can never be pushed past the array bound afterwards, but it is open from the moment the contract is deployed. The two claim functions take a phase index straight from the caller and index the array with it, so any out of range value fails the same opaque way. The neighbouring helper that reports whether the sale is active does guard the empty case, which shows the omission is not deliberate.

The price read keeps only the answer and its timestamp and discards the round identifier and the round in which the answer was computed, and it has no sequencer uptime check. It also subtracts the reported timestamp from the current block time without checking the order of the two, so a feed reporting a timestamp in the future makes the subtraction underflow and the whole purchase fails with a raw arithmetic panic. A conforming feed cannot trigger that, because it stamps each round with the block that recorded it and so can never be ahead of the consuming block, and the stablecoin path does not read the oracle at all, so the sale does not stop entirely. Reaching it requires a non conforming feed, and since the feed reference is immutable that can only originate at deployment.

The contract uses the plain access control base with no protection against the final administrator revoking or renouncing its own role. If that happens, every function gated on the administrator role becomes permanently unreachable, which means phases can no longer be created or updated, payment assets can no longer be managed, the funds destination is frozen and emergency recovery is gone, while buyers may still hold unclaimed vesting positions. The non-enumerable base also means the number of holders cannot be read on chain, so the condition cannot be checked before it is too late. The companion token contract implements exactly this guard, so the omission is inconsistent within the same project.

The mapping named as if it held rewards owed to a referrer is in fact a running total of bonuses that have already been transferred, because the bonus is sent immediately in the same call that records it. Anyone reading the contract or its public getters would reasonably conclude there is a pending balance to be claimed, and there is no claim function, so the naming is actively misleading to integrators and to anyone auditing the token flows.