Executive Summary
Every control ProofGuard applies to a launch pool's holders — the beneficial-owner sell throttle, the locked-lot multi-restriction hold — governs the retail side of the trade. None of it reaches a distinct and well-documented failure mode: liquidity providers, who may or may not be affiliated with the project itself, seeding a pool to create the appearance of tradeable depth, attracting buy volume against that apparent depth, and then withdrawing their underlying capital. The result collapses the pool and leaves buyers holding an asset with no exit liquidity — a "bait-and-pull," distinct from a rug pull because the actor doing the draining is the liquidity provider, not necessarily the project team, and the instrument being withdrawn is a claim on pooled reserves, not a holder's token allocation.
ProofGuard closes this gap by locking LP capital itself, independent of any holder-facing control. Every LP position carries its own minimum lock duration, scaled to the launch's risk classification. A withdrawal request against that position is then evaluated against the pool's current lifecycle state and stress mode before a size-tiered rule decides whether it releases immediately or queues behind a mandatory notice-delay.
Problem Statement
Standard LP-token lockers (Unicrypt, Team Finance, and similar services) lock the LP token itself for a static, pre-announced duration with no awareness of what is happening in the pool around it: no distinction between a healthy pool and one already under stress, and no size-sensitivity — a $500 withdrawal and a $5 million withdrawal are treated identically the instant the timer expires. Meanwhile, per-holder token restrictions address an entirely different instrument and have no bearing on an LP's separate claim on pooled reserves.
Technical Architecture
Lock at Deposit
When an LP position is created, its lock-until timestamp is fixed at deposit time using a minimum-lock-days figure selected by the launch's risk classification — a longer default for high-risk launches than for standard ones — and the lock event is anchored to the evidentiary ledger.
Withdrawal Decision Tree
A withdrawal request against an LP position is evaluated through an ordered set of checks, each capable of blocking, queuing, or releasing the request:
| Condition | Outcome |
|---|---|
| Pool in a pre-graduation lifecycle state (auction scheduled, active, just closed, or in active quarantine) | Blocked outright |
| Pool stress mode is other than normal | Blocked outright |
| Position's minimum lock duration has not elapsed | Blocked outright |
| Withdrawal amount at or above the large-withdrawal threshold | Queued behind a mandatory notice-delay |
| Withdrawal amount below the threshold, all prior checks clear | Released immediately |
Under default policy, withdrawals at or above $50,000 are queued with a 24-hour eligibility delay before they can be released, giving the platform and other market participants a window to observe and react before large capital actually leaves the pool. Every blocked, queued, and released outcome — including the specific reason code — is cryptographically anchored into the same tamper-evident ledger used across ProofGuard's other controls.
Why This Is a Distinct Control Surface
The beneficial-owner sell throttle and the locked-lot multi-restriction hold both operate on the launch-allocation token balance held by buyers. This mechanism operates on an entirely separate financial position — the liquidity-provider's claim on pooled reserves — evaluated against pool-level lifecycle and stress signals that neither of the holder-side controls reads. A project could have flawless holder-side controls and still be vulnerable to a bait-and-pull if LP capital itself were left unlocked; this claim is the control that specifically closes that gap.
Prior Art Differentiation
| Approach | Locks LP Capital? | Lifecycle/Stress-Aware? | Size-Tiered Notice-Delay? |
|---|---|---|---|
| Unicrypt / Team Finance-style LP locker | Yes, LP token only | No | No |
| Holder-side token vesting lock | No (different instrument) | N/A | N/A |
| Static calendar-only lock | Yes | No | No |
| JIL ProofGuard | Yes | Yes | Yes |