Smart Contract Analysis Statement

Contract Analysis

The VestingVault contract manages vesting and claims for PLXR presale buyers, advisors and team members. Buyer allocations are read directly from PresaleCore rather than duplicated, so there is one source of truth for who is owed what. Buyers receive five percent at the token generation event and the remainder linearly over three hundred and sixty-five days following a ninety-day cliff. Advisors use fixed constants and team members use per-member configurable cliff, duration and start offset, both funded from a pool separate from the buyer pool and pulled from the owner on registration. This is the second remediation round on this contract, and it is in good shape: no High or Medium severity issue remains open, and the two most serious items from the first engagement, the absent funding check and the unbounded deferral of the generation event, remain properly closed and were re-verified here. The claim deadlock that had been open since the first engagement is now genuinely resolved, because the presale state this vault gates on has become permissionlessly reachable. The areas that need attention are these:

• The pause bound added this round is the right response to the finding and the reasoning behind it is correct: unlike the presale, which never custodies buyer funds, this vault holds tokens buyers have already paid for, so a published policy alone would not have been adequate and a code bound was needed. Claims now resume automatically fourteen days after a pause begins, whether or not the owner ever unpauses, and that was verified to work with no owner action at all. The gap is in how the window is anchored. The timestamp is rewritten on every pause and no minimum interval between pauses is enforced, so unpausing and re-pausing starts a fresh fourteen-day window. Those are two separate calls, but an owner able to batch them into one transaction, which is the normal case for a multisig or timelock executor, leaves no block in which a claim is possible. Demonstrated over twenty consecutive windows, roughly ten months, with every claim attempt reverting throughout and nothing claimed. The bound therefore binds an unresponsive owner, which is a real improvement, but not a hostile one, and the code comment claims both. Accumulating paused time in a lifetime budget, or requiring a cooldown at least as long as the pause window between pauses, closes this while preserving the emergency-stop use case.
• The vesting math library was not part of the sources received, so the schedule could not be read from code in this round. Every schedule constant the vault exposes publicly, and both vesting curves, are re-exported from that library. The documentation half of the previous ambiguity is fixed and is now internally consistent everywhere it appears, with no remaining trace of the seven-hundred-and-thirty-day figure that previously conflicted with the implementation, and that matches what the remediation summary states was confirmed and set. The behavioural checks in this review were run against the library as it appeared in the last revision that contained one, which implements exactly the documented schedule and was verified to pay a buyer their entire allocation with zero residual at the end of the curve. That is evidence about an older file plus the current documentation rather than about the library that will ship, so the schedule should be confirmed against the team's repository.
• Two small asymmetries are worth tidying. Funding the vault is permissionless while the only route back out is the owner-only surplus rescue, so a third party topping the vault up beyond outstanding obligations is in effect donating to the owner; both halves of that are documented, but as separate facts rather than as the conclusion they add up to. Separately, registering a beneficiary or raising an allocation pulls tokens from the caller while lowering or removing one refunds to whatever address is the owner at that moment. Those are the same address in normal operation, and diverge only if ownership changes between the two operations, which is exactly the kind of step a handover to a multisig would land between.

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:

• Committing the token generation event timestamp, which requires the presale to have reached its terminal state and the vault to already hold enough PLXR to cover every outstanding obligation. It may be corrected at most three times before it is reached, each correction landing within thirty days of the stored value, and it locks permanently once reached.
• Pausing and unpausing claims. A pause expires automatically after fourteen days, subject to the re-pause behaviour noted above.
• Adding, updating and removing advisors and team beneficiaries, all of which are rejected once the generation event has been committed. Additions and increases pull PLXR from the caller; reductions and removals refund it.
• Setting each team member's cliff, vesting duration and start offset within bounded ranges, so no beneficiary's allocation can be locked for an unrealistic period or have its vesting math pushed into an overflow.
• Rescuing arbitrary ERC-20 tokens other than PLXR, and rescuing PLXR only above total outstanding obligations, which itself requires both the presale to have ended and the generation event to have been committed.
• No ability to reduce or revoke a buyer's allocation, which is read from the presale and never written here.
• No ability to claim on a beneficiary's behalf or redirect a claim.
• No ability to withdraw PLXR that is owed to anyone, and no ability to withdraw ether, of which the vault can now hold none.
• No ability to defer the generation event indefinitely, and no ability to block claims indefinitely through an unresponsive posture.
• Renunciation is deliberately disabled, so admin cannot be lost accidentally during the claim phase.

Security Features

The contract implements a substantial set of positive security features:

• A funding gate on the generation event: the vault must already hold at least total outstanding obligations before the timestamp can be committed. Verified that a one-wei shortfall reverts with the exact required and actual figures and that supplying that one wei lets it through. The single check is sufficient because both obligation sources freeze at that moment, buyer totals by the presale's terminal state and beneficiary changes by the gate itself, which was confirmed as an invariant across one hundred and twenty-eight thousand fuzzed calls.
• A bounded correction window on the generation event: at most three re-sets, each within thirty days of the stored value, capping post-publication deferral at ninety days, with the counter emitted so it can be audited from events. Verified at each step and at the cap.
• A code bound on the pause, which releases claims automatically rather than depending on the owner acting, subject to the re-pause caveat above.
• Buyer allocations read live from the presale rather than duplicated, removing any possibility of the two contracts disagreeing about what is owed.
• Advisor and team allocations funded from a separate pool pulled from the owner, so beneficiary obligations can never be serviced out of the buyer pool.
• The vesting token is excluded from the generic rescue path, and the surplus rescue is gated behind both the presale's terminal state and the committed generation event, so nothing owed to anyone can be withdrawn.
• No ether exit path and no way in: the constructor is no longer payable and the contract has neither a receive function nor a fallback, so the previously reported ether trap is now unreachable by construction rather than mitigated after the fact. Verified that a plain value transfer to the vault fails.
• Reentrancy guards on all three claim paths, with the claim accounting written before the token transfer.
• Beneficiary counts capped per list so the removal scan and the list readers stay bounded in gas, and every configurable duration, cliff and offset bounded so the vesting math cannot be pushed into an overflow that would permanently brick a beneficiary's claims.
• Two-step ownership transfer with renunciation disabled, re-exercised in this review by transferring the vault to a contract owner and accepting from it.
• Claim accounting verified conservative across the fuzz campaign: no beneficiary ever claims more than their allocation, the aggregate claimed figure always equals the sum of the parts, the outstanding calculation never underflows, and a vault that passed its funding gate stays solvent for every remaining obligation.
• No declared error or event in either interface is unused, confirmed by a programmatic sweep, and the previous token ticker no longer appears anywhere in the contract or its interface.
• No High or Medium static-analysis finding. The locked-ether findings raised against this contract in 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 VestingVault smart contract following the second round of remediation of the previous engagement's findings. This analysis did not include economic analysis of the project's tokenomics or vesting policy. Moreover, we only audited this contract for the Plexrum team. The presale was audited in parallel and reported separately, and the two were also exercised together, since this contract's correctness depends on presale state. The PLXR token was not part of this submission, so the findings previously raised against it remain open and unverified. The sources were supplied as archives without the dependency tree or the vesting math library, so a build was reconstructed for analysis using the pinned compiler version, OpenZeppelin 5.6.1, and the vesting math library as it appeared in the previous revision; the shipping schedule implementation should be confirmed against the team's own repository. We recommend investors do their own research before investing.