Smart Contract Analysis Statement

Contract Analysis

The VestingVault contract implements a structured vesting and distribution layer for the PLOD presale. Buyers receive a five-percent unlock at TGE and then linear vesting of the remaining ninety-five percent over 365 days after a 90-day cliff. Advisors use a fixed default schedule of a 365-day cliff followed by a 1095-day linear vest. Team beneficiaries use a fully configurable cliff, vesting duration, and start offset. The overall design is clean and well-isolated: the buyer pool and the beneficiary pool are funded from separate flows, so administrative beneficiary additions can never encroach on the buyer allocation. The contract reads each buyer's allocation directly from PresaleCore via an immutable reference, which removes any data-duplication risk. The areas that need attention are mostly operational:

• The vault assumes the owner has deposited at least TOKEN_CAP plus the running total of beneficiary allocations before TGE is set. The deposit happens off-chain and the contract does not verify it. An under-funded vault leads to early claimers receiving their tokens and late claimers seeing their claims revert when the balance is exhausted. The internal accounting handles this gracefully (each individual late-claim transaction rolls back cleanly with no state corruption), but the underlying funding gap is invisible until it bites. A single guard in setTGETimestamp that requires the vault's PLOD balance to cover all known obligations would close this.
• Setting the TGE timestamp requires the presale to have ended on the PresaleCore side. The only ways the sale ends are the owner calling endSale, the owner advancing past the last stage manually, or the last stage selling out with auto-advance enabled. If demand falls short of the full cap and the owner is unresponsive, the sale can remain in the started-but-not-ended state indefinitely, which keeps the TGE gate closed and blocks every buyer, advisor, and team claim forever even though the buyers have already paid the treasury. Pairing the existing gate with an automatic or permissionless end-of-sale fallback (or relaxing the gate after a sufficient deadline) closes this deadlock.
• Once a TGE timestamp is set but not yet reached, the owner can re-set it to any other future timestamp within a 365-day window, as many times as they want. While the previously-set TGE has not been reached, every buyer, advisor, and team claim reverts. The TGE value locks forever once block.timestamp catches up to it, so the post-TGE behaviour is safe, but the pre-TGE window is fully at admin discretion. A cap on the number of resets or on the delta between successive resets would bound the cumulative delay.
• The vault uses single-step Ownable transfer like the rest of the project. Because renounceOwnership is deliberately disabled, a mistyped transferOwnership cannot be recovered from except by the unintended new owner cooperating. Switching to Ownable2Step removes this risk by requiring the receiver to call acceptOwnership.

Ownership Privileges

The ownership of the contract has been retained by the deployer and is intended to be a multisig. The owner retains full privileges including:

• Setting and resetting the TGE timestamp until it has been reached, within a 365-day forward window.
• Pausing and unpausing all claim functions (buyer, advisor, and team).
• Adding, updating, and removing advisors and team beneficiaries, but only while TGE has not been set. Once TGE is set, the beneficiary set is frozen.
• Rescuing arbitrary ERC-20 tokens accidentally sent to the contract, except for PLOD itself which is blocked on that path.
• Rescuing excess PLOD above outstanding obligations, gated by both saleEnded on PresaleCore and TGE being set.
• No ability to mint PLOD: the vault only releases what was deposited into it.
• No ability to touch the buyer pool to satisfy beneficiary obligations: the beneficiary path is funded from a separate on-add transferFrom from the owner.
• RenounceOwnership is deliberately disabled, so admin cannot be lost accidentally during vesting.

Security Features

The contract implements several positive security features:

• Buyer-pool and beneficiary-pool isolation. Beneficiary allocations are pulled from the owner via safeTransferFrom at add and at upward update, and refunded on downward update or pre-TGE removal. The buyer pool is never deducted to satisfy a beneficiary obligation.
• Strict pre-TGE-only window for adding, updating, and removing beneficiaries, which means the beneficiary set is frozen at the moment the TGE timer locks. Buyers know exactly what they are vesting against from that moment forward.
• The rescueExcessPLOD function refuses to drain below outstanding obligations, computed as buyer tokens sold plus active beneficiary allocations minus everything claimed so far. It is also gated behind both saleEnded and TGE being set, so it cannot fire while either side is still in motion.
• The PLOD token reference and the PresaleCore reference are both immutable, so they cannot be repointed mid-vesting at malicious targets. The TGE value, once reached, also locks forever.
• Checks-effects-interactions ordering on every claim path, with nonReentrant on every external entry point that moves tokens.
• A renounceOwnership override that reverts, preventing accidental loss of admin during the vesting period.

Note - This audit report consists of a security analysis of the VestingVault smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the PlotDex team. Other contracts associated with the project (the token and the presale) were audited in parallel but reported separately, and the broader PlotDex ecosystem was not part of this engagement. We recommend investors do their own research before investing.