Smart Contract Analysis Statement

Contract Analysis

The PresaleCore contract implements a twenty-one-stage presale for the PLXR token on Ethereum, accepting the native currency and registered ERC-20 payment tokens priced through Chainlink feeds. It enforces a three-hundred-million token cap, a forty-nine-million dollar hard cap, a ten-dollar minimum purchase, and per-buyer loyalty tier tracking. Purchases are all-or-nothing against the remaining stage allocation, with no partial fills. This is the second remediation round on this contract and the work in it is of high quality. No High or Medium severity issue remains open. The blocking oracle finding from the previous engagement is properly closed and was re-verified against live mainnet round data on four aggregators. The permissionless end-of-sale path is now genuinely outside the owner's control, which also closes the vesting-side claim deadlock that had been open since the first engagement. The treasury acceptance probe was reordered correctly and the high-confidence reentrancy finding the static analyser previously raised against it is gone. A hand-check confirms the stage table still reconciles exactly to both headline caps: the per-stage allocations sum to three hundred million tokens and price out to exactly forty-nine million dollars. What remains are low-severity items, most of them residuals of the fixes themselves, and they share a pattern worth stating plainly: each fix is correct in the place it was applied and incomplete one step away from it. The areas that need attention are these:

• The constant that anchors the new finalization deadline no longer matches the stage schedule it was calibrated against. The constant is eight hundred and fifty-five days and its comment itemises that figure as three stages of twenty-one days plus eighteen of forty-four, which describes the previous revision's table. This revision changed the first three stages to forty-four days, making the real schedule nine hundred and twenty-four days, and the constant was not updated. The intended ninety-day grace window after the final stage is therefore twenty-one days in practice. More consequentially, because the schedule already overruns the constant, extending it by a further twenty-one days in total, well inside the three-hundred-and-sixty-five-day per-stage limit the contract itself permits, moves the deadline to before the sale's own end, at which point any caller can flip the terminal sale flag while stages are still live and selling. The flag is one-way, so the remaining allocation becomes permanently unsellable. Deriving the constant by summing the configured durations in the constructor, the same way the allocation table is already self-checked against the token cap, removes the possibility of the two drifting apart again.
• One of the three stage-timing setters was missed by the unchecked-cast remediation. The two duration setters are now properly bounded to a realistic maximum, and the running timestamp chain accumulates at full width with an explicit fit check and a monotonicity assertion, all of which was verified across all twenty-one stages at the maximum accepted duration. The start-timestamp setter received none of that treatment and still narrows an unbounded caller-supplied value into the sixty-four-bit storage field, with every guard above that write passing for a value at the type boundary. The cast truncates, the stored start can land on zero, and the recalculation then chains every later stage off that zero without reverting. The consequence goes beyond wrong dates: every expiry check in the contract is guarded on the start timestamp being greater than zero, so a stage dated zero never expires at all, while the stages after it become instantly unbuyable.
• The aggregator-reuse fix introduced an irreversible lockout. The new guard rejects a registration whose target aggregator already carries a price band, which correctly stops one token silently overwriting another's settings. Token removal, however, clears only the supported flag and leaves the feed pointer, decimals, band and staleness window behind, with no function able to clear them. Re-registering a removed token therefore hits the guard and reverts even when the token and the feed are both the originals, and every alternative route is closed: the rotation path requires the token to still be supported, and the immediate setters are tighten-only and reject a zero lower bound. The same applies to the native-currency feed, where an aggregator that has been rotated away from can never be rotated back to. Since there is normally one canonical aggregator per pair, a token removal is in practice irreversible and a feed rotation is one-way.
• The raised staleness ceiling is global, so the forty-eight-hour window the stablecoin feeds require is equally available to the native-currency feed, whose measured heartbeat is one hour. Widening does require the forty-eight-hour timelock, but re-pointing a feed at its own current address is an accepted rotation, so the window on the main purchase path can be stretched forty-eight-fold with no other change, after which a nearly two-day-old answer prices real purchases bounded only by the configured band. The same live sampling exposes the opposite error: a window set naively to the published one-hour heartbeat is tighter than the cadence actually observed, so purchases would revert intermittently. Each feed's window needs to be set from measured round data plus a buffer, and the native-currency feed would be better served by its own tighter ceiling.
• The stalled-stage finalization trigger added this round only covers the final stage. It works, and both the dust remainder and exact-sellout variants were verified finalizable by an arbitrary caller far short of the deadline. A dust-locked stage anywhere earlier is still unbuyable with no trigger available, and falls back on the anchored deadline roughly two and a half years out. The dust condition itself is stage-agnostic and already computed in the purchase path, so dropping the final-stage precondition closes this.
• Pause still has no maximum duration on this contract, and the resolution rests on the published operational policy the code cites three times by name. The remediation summary states that such a public document already exists. No copy of it was included with the sources and no published location was supplied, so this review could neither read it nor confirm that the code's citation resolves to something a buyer can find. The reasoning behind choosing a policy over a code bound here is sound and was re-confirmed: a pause blocks only future purchases, because every successful buy forwards payment to the treasury inside the same transaction, and an invariant held the contract's native balance at zero throughout. That is precisely why the vault was given a code bound and this contract was not, and the distinction is correctly drawn. What is needed is the link.
• Bytecode size is now the tightest constraint on this contract. It compiles to twenty-four thousand four hundred and ninety-three bytes against a limit of twenty-four thousand five hundred and seventy-six, so it fits with eighty-three bytes to spare, and only at one specific optimizer setting: at one thousand runs, an ordinary production value, the same source is over the limit. The build profile supplied with the sources pins neither the optimizer nor the run count nor the compiler version, so the configuration that produces a deployable artifact rests on convention. The automatic size check added this round is the right response to the finding and works correctly. It is worth pinning the build configuration and recovering some margin before the remaining items in this report are implemented, because eighty-three bytes does not accommodate them.

Ownership Privileges

The ownership of the contract has been retained by the deployer and is intended to be a multisig. Ownership transfer is two-step and renunciation is deliberately disabled. The owner retains full privileges including:

• Starting the sale once, which records the sale start timestamp permanently and sets every stage start by chaining the configured durations.
• Scheduling and then executing a stage advance or a sale closure, each subject to a one-hour public notice and each now lapsing if not executed within a four-hour window. Advancing may skip a stage that is neither sold out nor expired, in which case that stage's unsold allocation is permanently forfeited rather than rolled forward.
• Cancelling a scheduled advance or closure before it executes.
• Pausing and unpausing purchases, with no maximum duration.
• Scheduling, executing, and cancelling a treasury change, subject to a forty-eight-hour timelock and a value-bearing acceptance probe that now runs after state is committed.
• Scheduling, executing, and cancelling the registration of a new payment token or the rotation of any existing price feed, each subject to a forty-eight-hour timelock, with feed decimals re-validated at execution and the target aggregator checked against existing registrations.
• Removing a payment token immediately, which blocks new purchases with it but leaves existing buyer state untouched and, as noted above, cannot be undone.
• Tightening a registered feed's price band or staleness window immediately. Widening either requires the timelocked rotation path.
• Toggling auto-advance on sellout, with no timelock.
• Editing the duration or start timestamp of the current or any future stage, subject to a one-hour minimum remaining window, a three-hundred-and-sixty-five-day per-stage maximum on the duration setters, and rejection once the sale has ended. Strictly past stages are rejected, and the current stage's start can only be moved to the present, so this path cannot be used to shorten the window a buyer is relying on.
• Rescuing arbitrary ERC-20 tokens and stuck native currency to the owner. No normal code path leaves either in the contract.
• No ability to move the finalization deadline by any route, which is the substantive change in this round.
• No ability to mint PLXR, credit an allocation without payment, or alter a recorded purchase. The contract never holds or releases PLXR at all.
• No ability to redirect payment to anywhere other than the timelocked treasury address.
• Renunciation is deliberately disabled, so admin cannot be lost accidentally during the sale.

Security Features

The contract implements a substantial set of positive security features, several of which exceed what we would normally expect to recommend:

• Payment is never custodied. Every successful purchase forwards the full payment to the treasury within the same transaction, which an invariant confirmed by holding the contract's native balance at zero across one hundred and twenty-eight thousand fuzzed calls.
• A permissionless end-of-sale path anchored to a timestamp recorded once at launch plus two fixed constants, so no owner action of any kind can defer it and the sum cannot overflow. Verified against every stage-editing path individually and held as an invariant across the full fuzz campaign. This is what closes the claim deadlock on the vesting side.
• Per-feed staleness windows with both a floor and a ceiling, a fail-closed default for unregistered feeds, rejection of answers carried over from an earlier round, and rejection of uninitialised round metadata. The ceiling now clears the real cadence of every feed this deployment needs: across four aggregators and twenty-four intervals each, not one interval exceeded it, against eleven, thirteen, twenty-two and twenty-four of twenty-four that exceeded the previously shipped value.
• A forty-eight-hour timelock on every treasury change and on every path that introduces or repoints a Chainlink aggregator, including the registration of a brand-new payment token. A compromised owner key cannot atomically install a malicious feed and begin mispricing purchases.
• Per-feed minimum and maximum price bands that bound what any feed can quote, defending against a clamped feed, a depegged stablecoin, or a compromised aggregator. Bands can be tightened immediately but only widened through the timelock, and this subset-only property is enforced rather than documented. Registering an aggregator that another slot already uses is now rejected rather than silently overwriting it.
• Feed decimals validated to be exactly eight at registration and re-validated at execution time, so the hardcoded scaling in the USD math can never be silently violated. Payment token decimals are validated against the token's own on-chain value.
• Fee-on-transfer payment tokens are rejected by a post-transfer balance check on the recipient.
• Checks-effects-interactions ordering on both purchase paths and now on the treasury change as well, with state committed before any external call, plus reentrancy guards and pause gating on every value-moving entry point.
• Quote and purchase arithmetic agree exactly. Fuzzing across both payment paths confirms that a purchase with the slippage bound set strictly to the quoted value always succeeds and yields exactly the quoted token and dollar figures. A new maximum-payment view mirrors the purchase-path formula rather than inverting the quote, and was fuzzed across all twenty-one stages with partially filled allocations: the advertised maximum always executes and one unit above it never does.
• Owner-initiated stage advances and sale closures carry a one-hour public notice that now expires after four hours, so the notice is a real guarantee rather than an open-ended option.
• A defence-in-depth constructor check that the hand-typed stage allocations sum to the token cap, which catches a drifted stage table before the contract can be deployed.
• An automatic bytecode size gate in continuous integration, which is a useful addition on a contract this close to the limit.
• Twelve cross-contract conservation properties were fuzzed at one hundred and twenty-eight thousand calls each with no counter-example, covering both caps, per-stage reconciliation against the global counter, stage index bounds, immutability of the recorded sale start and of the finalization deadline, per-feed window bounds, and the bounds on every claim path.
• No High or Medium static-analysis finding beyond the previously triaged set. The High reentrancy finding on the treasury probe and both locked-ether findings from the previous revision are resolved, and the pattern scanner reports zero security-rule and zero best-practice-rule matches.

Note - This audit report consists of a security re-analysis of the PresaleCore smart contract following the second round of remediation of the previous engagement's findings. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Plexrum team. The vesting vault was audited in parallel and reported separately. The PLXR token was not part of this submission, so the findings previously raised against it remain open and unverified. The broader Plexrum ecosystem including the presale frontend and off-chain treasury operations was not part of this engagement. The sources were supplied as archives without the dependency tree, so a build was reconstructed for analysis using the pinned compiler version and OpenZeppelin 5.6.1; re-verification against the team's own repository and a pinned build configuration is recommended before deployment. We recommend investors do their own research before investing.