Security model.

The useful question is not whether we would take your tokens. It is whether the code lets us. Everything below points at a function you can read rather than a promise you have to accept.

Updated 2026-07-29 · HoodLock Team

Non-custodial, precisely#

The locker and the vesting contract hold tokens. That is custody in the literal sense, so the claim worth making is narrower and checkable: no function exists that lets anyone other than the rightful party withdraw them.

ContractWho can move tokens outUnder what condition
LockerThe lock's owner, and nobody elseAt or after the unlock time
VestingThe beneficiary, and nobody elseAs the schedule releases
BurnerNobody — everTokens go straight to the dead address and never rest in the contract
Note

Note the absence rather than the presence. There is no rescue, no sweep, no emergencyWithdraw and no pause that redirects funds. A backdoor you cannot find is usually a backdoor that is not there, and you can check, because all three contracts are verified on Blockscout.

What admin can actually do#

Each contract has an admin key. Its reach is deliberately narrow.

Admin canAdmin cannot
Change the fee for new recordsTouch any existing lock, schedule or balance
Change the fee collector addressWithdraw, redirect or freeze user tokens
Transfer the admin roleAlter an unlock date or a vesting schedule
Careful

Two asymmetries worth knowing rather than discovering:

  • Vesting has a hard fee cap of 0.05 ETH, written as a contract constant. No admin action can exceed it.
  • The locker and burner have no such cap. The admin can set any fee for new records. Existing locks are never re-priced and withdrawal is always free, but the ceiling is not enforced in code.

The vesting contract uses a two-step admin transfertransferAdmin then acceptAdmin, so a mistyped address cannot strand the role.

Verify it yourself#

This takes about five minutes and does not require trusting anything on this page.

How to read a contract on Blockscout covers the mechanics if you have not done it before.

Token quirks the contracts handle#

QuirkHow it is handled
Fee-on-transfer tokensThe amount recorded is the balance the contract actually gained. Simple fee-on-transfer is recorded correctly; rebasing and reflection tokens are not supported and can leave the shared per-token pool short of what it owes.
Tokens that return no booleanTransfers use a safe wrapper in the vesting contract rather than a raw require.
Overpaid feesRefunded by the locker and burner. Not by vesting, which requires the exact fee.
Non-contract token addressesVesting rejects an address with no code, so a typo cannot create an empty schedule.

What this does not protect you from#

Being clear about the boundary matters more than the reassurance.

Reporting an issue#

If you believe you have found a vulnerability in any of the three contracts or in the site, report it privately before disclosing it publicly. A responsible report gives us a chance to protect the people currently using the contracts, which a public one does not.