How Presale Smart Contracts Lock and Vest Tokens

# title: How Presale Smart Contracts Lock and Vest Tokens

I was on the phone with a friend last week who had just bought into a presale. He sent me the contract address and asked me to check if the team could dump their tokens at launch. I looked at the contract, found the vesting schedule, and walked him through what it meant. He said something I have heard before. "I have been buying these for two years and I never actually understood how the locking works."

That conversation is why I am writing this. The smart contract mechanics behind presale token locks and vesting schedules are not complicated once you know what to look for. But most people never look. They see a marketing page that says "team tokens locked for 12 months" and they move on. The marketing claim and the smart contract reality do not always match.

Here is how presale smart contracts actually handle token locks, cliffs, and vesting.

The basic building blocks

Every presale token distribution follows a few standard patterns. The simplest is a direct release. You buy tokens during the presale, the contract holds them, and at the TGE the contract releases them to your wallet. That is what happens to buyer allocations in almost every presale.

The lockup and vesting mechanics apply to the team, the advisors, the investors, and the treasury allocations. These groups get their tokens on a delayed schedule, not all at once. The delay is enforced by the smart contract, not by a promise. That is the key distinction. A promise can be broken. A smart contract lock can only be broken if the contract has a backdoor, which is exactly what you are checking for when you audit a presale.

The three patterns you will see are cliffs, linear vesting, and time locked vaults.

Cliffs

A cliff is a period during which nobody in the locked group can claim any tokens. If the team has a six month cliff, they cannot access their allocation at all for the first six months after TGE. After the cliff expires, the tokens become available according to the vesting schedule.

Cliffs exist to prevent an immediate dump. If the team could sell their tokens on day one, the market would price that risk into the token from the start. The cliff gives the project runway to build value before the team's incentives shift from building to selling.

I have seen cliffs as short as one month and as long as two years. The standard in well structured projects is six to twelve months. Anything shorter than three months is effectively no cliff. Anything longer than eighteen months is unusually restrictive and might indicate that the team does not plan to be around when their tokens unlock.

Linear vesting

After the cliff expires, the tokens release gradually through linear vesting. The contract releases a fixed amount of tokens per block or per second until the full allocation is distributed.

The math is straightforward. If the team has 10 million tokens with a six month cliff and an eighteen month linear vesting period, then after the cliff, about 555,000 tokens become claimable each month for the next eighteen months. The contract handles this automatically. The team does not get to choose when to release. The contract does.

Linear vesting is better than milestone based vesting because it removes discretion. Milestone based vesting requires someone to decide whether a milestone was met. That decision creates a point of failure and a potential dispute. Linear vesting just runs on a clock. It is mechanical and predictable.

Time locked vaults

Some projects use a more complex pattern called a time locked vault. Instead of the token contract itself handling the vesting, a separate vault contract holds the locked tokens and releases them on schedule. The vault pattern is useful because it separates the logic of the token from the logic of the lock. If the token contract needs to be upgraded or migrated, the vault remains unaffected.

The vault pattern also makes it easier to verify the lock independently. You can look at the vault contract on the block explorer and see exactly how many tokens are held, when they unlock, and who can claim them. No interpretation needed. The contract code is the truth.

What to check in a presale contract

When you are evaluating a presale, there are four things to verify in the smart contract.

First, the team allocation address. The contract should have a specific address or set of addresses that are subject to the vesting schedule. If the team allocation goes to a multisig wallet without a vesting contract attached, the team can move those tokens at any time. That is a risk.

Second, the cliff duration. Check the exact number of blocks or seconds. Some contracts advertise a "12 month cliff" but the actual cliff in the code is calculated in blocks and the block time varies. A 12 month cliff on Ethereum is roughly 2.6 million blocks, but the actual time depends on network conditions.

Third, the vesting period after the cliff. A project that says "tokens are locked" without specifying a vesting period is being misleading. A lock with no vesting means the full allocation unlocks at the cliff date, which is almost as bad as no lock at all. You want to see a linear vesting period of at least 12 months after the cliff.

Fourth, the control functions. Does the contract have functions that let the team modify the vesting schedule, or override the lock, or transfer locked tokens to a different address? If it does, the lock is not real. The team can change it whenever they want.

Why Blazpay's approach matters

I use Blazpay as an example because I have analyzed their contracts recently and they represent a well structured case.

The team allocation has a cliff with a linear vesting period after it. The contract does not have functions that allow the team to modify the schedule. The lock is enforced at the contract level, not the promise level. The advisor and investor allocations follow similar patterns with different parameters depending on their agreements.

The key detail is that the liquidity allocation is treated differently. It goes into the pool at launch to provide trading depth, not into a vesting contract. That is standard and correct. The liquidity needs to be available on day one for the market to function. It is the team and early backer allocations that need the lock.

I also checked whether the contract has a mint function that would let the team create new tokens after the total supply is fixed. It does not. The supply cap is hard coded and the mint function is disabled. That is another green flag. A presale contract with an active mint function is a contract that can be diluted at any time.

Common red flags

I have seen some creative attempts to circumvent token locks over the years. Here are the ones to watch for.

Locked tokens in a staking contract. Some projects claim tokens are locked, but the "lock" is actually a staking contract that lets the team claim rewards on the locked tokens. That technically preserves the lock while still generating value. It is a gray area.

Transferable locks. A contract that lets the team move their locked allocation to a different address undermines the entire purpose of the lock. If the team can move the tokens to any address, they can effectively sell them through a third party even if the original address cannot trade.

Unlocked treasury. The treasury allocation is often excluded from vesting on the theory that the project needs operating funds. That is reasonable, but a large unlocked treasury is effectively a sell pressure risk. Check the size of the treasury allocation and factor it into your risk assessment.

Proxy contracts with upgradeable locks. Some projects use proxy contracts that let the team upgrade the vesting logic after deployment. A proxy is not automatically a red flag, but if the team can replace the vesting contract with one that removes the lock, the lock is not real.

The takeaway

Token locks are one of the few mechanisms in crypto that actually work as advertised, provided they are properly implemented in the contract. They are not marketing. They are code. The contract either enforces the lock or it does not. There is no gray area.

The problem is that most buyers never look at the contract. They trust the marketing page and move on. A few minutes spent reading the vesting schedule on a block explorer can tell you more about the project's long term alignment than hours of reading the whitepaper.