Pinksale liquidity lock sets an unlock date for deposited LP tokens

Existing LP tokens and automatic listing

Existing LP tokens use PinkLock’s direct lock flow, while a launchpad’s Auto Listing option creates and locks liquidity through sale finalization. For a direct deposit, the relevant asset is the supported LP token that the wallet already holds. If an EVM presale’s project token has transfer fees, rewards or transaction limits, the presale contract needs the relevant exclusions before finalization. A presale configured for Auto Listing uses its selected exchange router and liquidity settings when the owner successfully finalizes the sale. Its liquidity-lock duration is separate from the sale’s start and end times.

Manual Listing makes the project responsible for adding liquidity. Fair-launch pools also distinguish these listing options. A configured duration describes a planned restriction; the resulting lock entry establishes the deposited amount and its actual release schedule. A sale announcement alone doesn’t establish a completed liquidity lock.

LP-token identity and the locked share

An LP-token contract identifies the pool share entering the lock; the project’s trading-token contract identifies a different asset. In a V2-style pool, LP tokens represent a proportional claim on the pool’s reserves. Depositing only part of an LP balance therefore restricts only that part. LP tokens elsewhere remain under their holders’ separate control.

Open full-size image

Lock amounts use LP-token units. They aren’t the quantity of either underlying asset, and an LP-token count isn’t a dollar balance. Any displayed locked percentage needs a denominator: a share of one wallet’s LP balance differs from a share of the pool’s total LP-token supply.

UTC expiry and release timing

A simple lock’s UTC timestamp specifies when its deposited LP tokens become eligible for an owner-authorized withdrawal. The date and hour both matter. Converting an intended local time to UTC can move the calendar date, so copying the local date alone can select the wrong expiry. The lock follows its recorded timestamp, regardless of the timezone on a phone or computer.

Service charges and native transaction fees

PinkLock’s service charge depends on the network, and a zero service charge doesn’t remove network transaction costs.

The listed PinkLock service charge is zero on BNB Smart Chain and 1 SOL on Solana. These entries apply to their named networks; they don’t establish one price for every liquidity-lock route. The service amount shown during creation can change, so the transaction’s actual charge belongs in the budget.

Approval, deposit and withdrawal each require gas in the direct EVM flow. Native currency pays those network costs separately from the LP-token deposit. The service quote and the wallet’s transaction quote describe different expenses, and holding enough LP tokens doesn’t fund a native-currency fee.

Token transfer rules before deposit

Transfer fees, rewards and transaction limits on the asset entering PinkLock can cause the lock transaction to fail. When those features apply, the deployed locker for the selected network needs the required exclusions before deposit. A taxed transfer can leave custody short of the intended amount and disrupt withdrawal accounting. The token contract must support the necessary exclusion. The LP token and the underlying project token are separate contracts, so a restriction on one doesn’t automatically describe the other.

Approval and lock confirmation

Token approval permits PinkLock to spend an LP balance; the Lock transaction creates the deposit and its recorded restrictions. In the direct EVM creation flow, approval precedes the Lock transaction. A successful approval alone doesn’t demonstrate that LP tokens have entered custody. The selected owner can also differ from the wallet that grants the spending permission.

A wallet prompt, pending transaction or transaction hash alone doesn’t establish a completed deposit. A successful lock transaction and its matching entry identify what entered custody. A failed creation transaction doesn’t become a lock merely because an earlier approval succeeded.

Choosing an earlier or later expiry

For the same eligible LP-token deposit, an earlier and a later future expiry impose different periods without withdrawal access. If access by the earlier date is necessary, the later expiry conflicts with that requirement. The earlier option fits only if its shorter restriction also meets the intended lock commitment.

• Confirm that the selected network and LP-token contract identify the intended pool.
• Check that the depositing wallet holds the LP amount and native currency for transaction fees.
• Keep vesting disabled if the intention is one full release after a single expiry.
• Confirm the intended owner address; it can differ from the depositing wallet.
• Complete any required token approval before submitting the Lock transaction with the chosen UTC date, then match the confirmed entry’s owner, asset, amount and expiry.

The earlier date restores eligibility sooner only while that schedule remains in force and the owner retains control of the claim.

Open full-size image

Can trading change the value of locked liquidity?

Trading can change a pool’s reserves and market value while its LP tokens remain locked. The lock restricts redemption through the deposited tokens; it doesn’t hold each reserve at its initial quantity or price. An unchanged LP-token balance can therefore represent a different mix and value of underlying assets later. A long expiry establishes a withdrawal restriction for a period without establishing a price floor. When a lock display includes a value estimate, that estimate describes the position’s valuation, while the LP-token amount describes the share held in custody.

Ownership transfers during the term

The current lock owner can transfer control to another wallet without releasing the deposited LP tokens.

Open full-size image

Transferring ownership of a PinkLock entry leaves its deposited tokens subject to the existing release schedule. The new owner gains the relevant claim rights, and the former owner loses control of that entry. A transfer changes the claimant, so the creator address alone doesn’t identify who currently controls withdrawal.

Transferring one entry doesn’t transfer every lock associated with that wallet. Each remaining entry retains its own designated owner.

Expiry, withdrawal and permanent loss of access

After a simple lock expires, its owner can withdraw the LP tokens through PinkLock, provided ownership hasn’t been renounced. Expiry doesn’t send assets automatically. Withdrawal returns the LP tokens; redeeming them for underlying assets remains a separate operation at the liquidity pool. An LP withdrawal therefore doesn’t itself complete removal of pool liquidity.

Renouncing lock ownership permanently removes the ability to withdraw the entry’s remaining deposit. Nobody controls the address that must authorize the claim. Even when the recorded expiry arrives, the LP tokens remain inaccessible.