“Lock” and “vest” are used interchangeably in DeFi project documentation. They appear in tokenomics tables, investor presentations, and launch announcements as though they describe the same mechanism. They do not. They solve different problems, operate on different release schedules, and are appropriate for different token allocation categories.
Applying the wrong instrument to a token allocation does not produce a security failure in the traditional sense — the tokens are still constrained. But it produces a commitment structure that is mismatched to the underlying economic relationship it is supposed to represent. That mismatch has consequences for investor confidence, contributor incentives, and the clarity of the on-chain record.
This article defines each instrument mechanically, at the contract level, and specifies precisely when each is appropriate.
The Lock: Mechanical Definition
A lock is a binary constraint. Tokens deposited into a lock contract are inaccessible until a defined timestamp is reached. Before that timestamp: zero tokens are claimable. After that timestamp: the full deposited amount is claimable by the designated beneficiary address.
The state machine has two states: locked and unlocked. There is no intermediate state. There is no partial release. There is no streaming. The transition from locked to unlocked occurs at a single point in time, defined at the moment of deployment.
The contract logic reduces to a single conditional:
if block.timestamp >= unlock_timestamp:
release all tokens to beneficiary
else:
revertThis simplicity is the lock’s defining property and its primary limitation. It is the correct instrument when the desired behavior is exactly this: hold assets completely inaccessible until a specified date, then release them entirely.
What a Lock Secures Against
The lock is designed for a specific threat: premature access to pooled assets by the party who deposited them.
For LP tokens, the threat is the liquidity removal event — the deployer calling removeLiquidity() on the pool, draining the ETH reserve and collapsing the token price. A lock prevents this by taking the LP tokens out of the deployer’s control for the lock duration. The deployer cannot call removeLiquidity() because they no longer hold the LP tokens. The lock contract holds them.
For treasury tokens, the threat is discretionary spending from the project’s reserve before the project has demonstrated the value creation that reserve is meant to fund. A lock on treasury tokens creates a forced patience mechanism — the treasury cannot be accessed until the team has had sufficient time to build and the market has had sufficient time to evaluate.
In both cases, the lock’s binary nature is appropriate. Either the LP tokens are secured or they are not. Either the treasury is accessible or it is not. A graduated release schedule would undermine the instrument’s purpose — partial access to LP tokens does not meaningfully constrain the liquidity drain vector.
What a Lock Does Not Do
A lock is not a vesting schedule. It does not distribute tokens over time. It does not create proportional alignment between token receipt and ongoing contribution. It does not stream.
A team member whose allocation is placed in a lock receives nothing until the lock expires, then receives everything simultaneously. This is not compensation alignment — it is a delayed lump sum. The team member has no incremental incentive during the lock period beyond what they brought to the project at launch. Their full allocation arrives as a single event, creating a concentrated release that may generate significant sell pressure and that does not reflect the ongoing nature of their contribution.
Applying a lock to contributor allocations is a common mistake. It addresses the question “when can this person access their tokens?” without addressing the more important question: “do this person’s incentives remain aligned throughout the contribution period?”
The Vest: Mechanical Definition
A vest is a continuous release mechanism. Tokens deposited into a vesting contract accrue to the beneficiary over time according to a defined schedule. The beneficiary can claim the accrued balance at any point, but the total claimable amount increases gradually rather than becoming available all at once.
In a fully on-chain implementation, tokens accrue second-by-second. The claimable balance at any moment is a function of elapsed time since the vesting start — or since the cliff expiry, if a cliff is configured — divided by the total vesting duration, multiplied by the total allocation.
The contract logic for a linear vest without a cliff:
elapsed = block.timestamp - start_timestamp
vested = (total_allocation * elapsed) / vesting_duration
claimable = vested - already_claimedWith a cliff:
if block.timestamp < cliff_timestamp:
claimable = 0
else:
elapsed = block.timestamp - cliff_timestamp
post_cliff_duration = vesting_duration - cliff_duration
vested = (total_allocation * elapsed) / post_cliff_duration
claimable = vested - already_claimedThe vesting contract’s state is not binary. It exists on a continuum between fully locked and fully vested, with the beneficiary’s claimable proportion increasing continuously as time passes.
What a Vest Secures Against
The vest is designed for a different threat: misaligned incentives between token receipt and ongoing contribution.
A contributor who receives their full allocation at a single point — whether at launch or at a lock’s expiry — has no structural incentive to continue contributing after that point. Their economic relationship with the protocol is complete. They hold the tokens. What they do next is a personal decision unconstrained by any token-based incentive.
Linear vesting changes this relationship. At any given moment, the contributor’s claimable balance reflects only what they have “earned” up to that point. The remainder is still in the vesting contract, accessible only if they remain through the vesting period. A contributor who exits midway through a 24-month vest and stops claiming leaves the unvested portion in the contract — realizable only by the beneficiary address, which they still control, but accruing at a rate that creates a meaningful incentive to remain engaged rather than pivot to other opportunities.
The cliff extends this further by creating a minimum engagement threshold. A contributor who exits before the cliff date receives nothing at all. The cliff is a binary gate that filters for the initial commitment, and the subsequent linear schedule is the ongoing alignment mechanism.
What a Vest Does Not Do
A vesting contract is not a liquidity lock. Its purpose is not to prevent a pool drain or secure a treasury against premature access. It is a compensation distribution mechanism.
Using a vesting schedule on LP tokens would create a series of partial LP token releases over time — a drip of liquidity removal capability delivered to the deployer incrementally. This does not secure the pool against a drain; it schedules the drain in installments. The appropriate instrument for LP tokens is the lock: full binary constraint until the commitment period is satisfied.
The Structural Distinction
The difference between a lock and a vest is the difference between binary constraint and continuous distribution.
A lock answers the question: when can this entire allocation be accessed? A vest answers the question: how much of this allocation has been earned at any given moment?
These are different questions, appropriate to different economic relationships.
The LP token relationship is binary: either the deployer has committed to keeping the pool intact for a period, or they have not. There is no “partially committed to the pool.” The lock’s binary nature maps correctly to the binary nature of the commitment.
The contributor relationship is continuous: a developer contributing to a protocol over 24 months earns their allocation incrementally. They have delivered more value in month 18 than in month 2, and their token receipt should reflect accumulated contribution rather than a single future event. The vest’s continuous nature maps correctly to the continuous nature of the contribution.
The Four Allocation Categories
Every token allocation in a project’s distribution falls into one of four categories, each with a distinct appropriate instrument.
Category 1: Liquidity Pool (LP Tokens)
Appropriate instrument: Lock.
LP tokens represent pool ownership. The security question is binary: can the deployer drain the pool? A lock removes that capability for the defined duration. A vest on LP tokens would incrementally restore that capability, which is the opposite of the desired outcome.
Lock duration of 365 days minimum. Extension always preferable to expiration without renewal when the project is ongoing.
Category 2: Project Treasury
Appropriate instrument: Lock, or lock with staggered tranches.
Treasury tokens are a reserve for future operational needs — development costs, security audits, marketing, grants. The security question is about preventing premature or unauthorized access to a fund that is supposed to be deployed gradually against a roadmap.
A single lock constrains the entire treasury until a defined date, at which point it is accessible entirely. For large treasuries, this creates a concentrated release event. A staggered approach — multiple lock contracts with different expiry dates, each holding a tranche of the total treasury — distributes the release events over time and avoids a single large unlock event that could create market pressure if liquidated.
A vesting schedule on the treasury is occasionally used but is mechanically awkward for a fund that is meant to be deployed against operational needs rather than earned by an individual. The lock better represents the nature of the commitment.
Category 3: Team and Founder Allocations
Appropriate instrument: Vest with cliff.
Founder and team allocations are compensation for ongoing contribution. The cliff establishes a minimum commitment threshold — typically 6 to 12 months for founders, 3 to 6 months for senior contributors. The linear schedule distributes the remainder over the contribution period.
A lock applied to team allocations creates a deferred lump sum rather than a proportional compensation structure. It does not align ongoing incentives. It simply delays access. The vest with cliff is the mechanically correct instrument.
Category 4: Investor Allocations
Appropriate instrument: Vest with cliff.
Investor allocations, like team allocations, should be distributed over time to prevent concentrated selling events and to maintain alignment between investor token receipt and protocol development milestones. A 6 to 12-month cliff followed by 18 to 24 months of linear vesting is standard practice.
A lock applied to investor allocations creates the same problem as a lock on team allocations: a delayed lump sum that generates a predictable, concentrated sell event at the unlock date. Large unlock dates are visible on-chain and are frequently targeted by traders positioning ahead of anticipated selling pressure. A linear vest distributes this pressure across an extended period, reducing its magnitude at any single point.
What Happens When the Instruments Are Misapplied
Lock Applied to Contributor Allocation
A founding team that places their allocation in a 12-month lock and communicates this to investors as their commitment mechanism has created a surface-level commitment signal with no underlying alignment structure.
At month 1, the team has $0 in liquid tokens — identical to a properly vested team. At month 12, the team has 100% of their allocation unlocked simultaneously — unlike a properly vested team, which would have received only 50% of their post-cliff allocation at month 12 of a 24-month vest.
The lock provides the same initial restraint as a vesting schedule with worse long-term alignment properties. The team’s incentive to continue contributing beyond month 12 is entirely dependent on their personal commitment to the project, not on any remaining vested allocation. An investor reviewing “12-month lock on team tokens” and inferring “12-month commitment with ongoing alignment” is reading more into the instrument than its mechanics support.
Vest Applied to LP Tokens
A project that places LP tokens into a 24-month linear vesting schedule has given itself the ability to remove a growing portion of the pool liquidity every month. Month 1: 1/24 of LP tokens claimable. Month 6: 6/24 claimable. Month 24: full pool accessible.
This is not a liquidity commitment. It is a scheduled liquidity reduction capability. The pool is not secured against a drain — the drain is structured into the vesting schedule.
Investors reviewing the lock status of this project and finding a “24-month vest” on LP tokens may interpret this as a 24-month commitment. The mechanics produce the opposite: liquidity removal capability incrementally restored over 24 months.
Reading the On-Chain Record
Distinguishing a lock from a vest on-chain requires reading the contract rather than the announcement.
For a lock contract: the relevant state variables are the beneficiary address, the token contract address, the deposited amount, and the unlock timestamp. The absence of any streaming or accrual logic confirms the binary release mechanism. A contract that has only a single time-gated release function with no arithmetic on elapsed time is a lock.
For a vest contract: the relevant state variables are the beneficiary address, the token contract address, the total allocation, the start timestamp, the cliff timestamp (if any), the vesting duration, and the amount already claimed. The presence of elapsed-time arithmetic in the claimable balance calculation confirms the continuous release mechanism.
Verify which instrument has been applied to each allocation category. Verify that the instrument matches the category’s economic relationship. A team allocation in a lock and an LP position in a vest are red flags — not because the tokens are inaccessible, but because the instruments are misapplied to the relationships they are supposed to govern.
The commitment structure of a project is readable entirely from its on-chain contracts. No announcement, no documentation, and no team statement is required. The contracts describe the actual economic relationships with precision. Read them.
Summary
| Property | Lock | Vest |
|---|---|---|
| Release mechanism | Binary — all at expiry | Continuous — accrues over time |
| Intermediate access | None | Proportional to elapsed time |
| Cliff support | N/A (lock is the cliff) | Optional — gates linear start |
| Appropriate for | LP tokens, treasury | Team, advisors, investors |
| Misapplication risk | Deferred lump sum on contributors | Incremental drain capability on LP |
| Primary alignment function | Pool security, treasury constraint | Contribution incentive, sell pressure distribution |
Conclusion
A lock and a vest are not interchangeable instruments. They are designed for different economic relationships, operate on different release mechanics, and produce different incentive structures when applied correctly — and different failure modes when misapplied.
The appropriate due diligence question is not “are the tokens locked?” It is “which instrument has been applied to which allocation, and does the instrument match the economic relationship it is supposed to represent?”
A pool secured by a lock and a team incentivized by a vest with cliff is a complete commitment structure. A team whose tokens are locked and a pool whose LP tokens are vested is a misapplication of both instruments, producing weaker pool security and weaker contributor alignment simultaneously.
Read the contracts. Identify the instrument. Verify the match.
0xKeep operates on an immutable, zero-admin-key architecture. No wallet — including those controlled by the 0xKeep team — can pause, modify, or interact with deployed contracts. Time is the only admin.
Deploy on Base, Arbitrum, or Optimism at 0x-keep.xyz Follow protocol updates: @0xKeep_official