Rolling your own.

A timelock is twenty lines, and we will not pretend otherwise. The contract was never the hard part — everything that has to exist around it is, and that is where an afternoon turns into ongoing maintenance nobody budgeted for.

Updated 2026-07-29 · HoodLock Team

The part that is easy#

A single-beneficiary timelock is short enough to read in one screen, and there is nothing clever in it.

solidity
contract Timelock {
    address public immutable owner;
    IERC20  public immutable token;
    uint256 public immutable unlockTime;

    constructor(address t, uint256 u) { owner = msg.sender; token = IERC20(t); unlockTime = u; }

    function withdraw() external {
        require(msg.sender == owner, "not owner");
        require(block.timestamp >= unlockTime, "locked");
        token.transfer(owner, token.balanceOf(address(this)));
    }
}

If your team writes Solidity, deploying this is an afternoon including tests. Anyone claiming the mechanism itself is hard is selling something.

The part that is not#

The contract is the smallest component of the job. What follows is the rest of it.

What you still needWhy it is not optional
Verified source on the explorerAn unverified lock contract proves nothing to anyone. If they cannot read it, they cannot check it.
A page a non-technical holder can readMost of the people you are reassuring cannot read a contract. A link to a raw address does not do the job.
Correct handling of odd tokensFee-on-transfer tokens deposit less than you sent. Tokens that return no boolean break naive transfers. Both are common.
An extend pathWithout one you have to withdraw and re-lock, which creates exactly the gap a lock exists to avoid.
Ongoing discoverabilityA bespoke contract appears in no explorer, no aggregator and no directory. Nobody finds it unless you tell them.
Credibility of a contract only you have seenA one-off address is precisely the shape a fake lock takes. Yours is real; it looks the same from outside.
Careful

That last row is the one teams underestimate. A custom lock contract asks holders to audit your code before they can trust your commitment, which is a larger ask than the commitment itself, and most of them will simply decline.

The narrow case for building it#

It is worth naming honestly, because it is narrower than it first looks.

Where the reasoning usually breaks down#

Note

That third point is the counterintuitive one. The value of using a shared, public, verified locker is precisely that you did not write it. Nobody has to consider whether you left yourself a door. The security model names the functions to check, and they are the same functions on every lock we hold.

What most teams land on#

Lock the ordinary balances — creator supply, treasury, LP — where they are discoverable and checkable without effort, and reserve bespoke contracts for the rare case that genuinely needs logic nothing offers. Teams that start by building their own almost always end up wanting a shared, public locker for the straightforward cases anyway, because that is where the credibility comes from rather than the mechanics.

What you would be comparing against#

Your own contractHoodLock
CostEngineering time, then gas0.005 ETH flat, plus gas
VerificationYours to doVerified on Blockscout
Public proof pageYours to buildGenerated per record
Extend without a gapYours to implementBuilt in, free
Fee-on-transfer safetyYours to handleRecords the balance gained; rebasing tokens unsupported
Discoverable by strangersNoIn the explorer
Custom release logicAnything you writeLinear vesting, or a single date

How to choose a token locker covers the criteria to apply to any option, including this one.

Skip the afternoon of engineering

Flat 0.005 ETH per lock, a verified contract you did not have to write, and a proof page generated for you.

Open HoodLock →