“The liquidity is locked” is every launch’s safety story, and no two lockers say it the same way, so scanners and launchpads keep allowlists of lockers they have integrated. This draft is one interface for any contract that locks pool liquidity (v2 pool tokens, v3 and v4 positions): which pool, how much, until when, for whom, who collects the locked position’s fees, with events, and per pool lockedLiquidity (permanent, timed, earliest unlock) at a cost that does not grow with the number of locks. Release is only at or after unlockAt, only to the beneficiary, and never more than the lock holds. It names the figures ERC-8376 detectors take as inputs (lockedLiquidity, lockSinks, lpLockRemaining) so a detector can derive them instead of trusting them.
Readers still check a locker before counting it (that it holds the position, and has no path to move it early): the interface makes that check uniform, it does not replace it. Questions for locker operators and scanners:
- Are extension (beneficiary only, later only), release (anyone, to the beneficiary) and fee collection (anyone, to the fee recipient) the right three calls to standardize?
- For v4 positions, is (PoolManager, poolId, positionId) enough to identify a lock?