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.
Non-custodial, precisely#
The locker, the vesting contract and the airdrop 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.
| Contract | Who can move tokens out | Under what condition |
|---|---|---|
| Locker | The lock's owner, and nobody else | At or after the unlock time |
| Vesting | The beneficiary, and nobody else | As the schedule releases |
| Airdrop | Each recipient, with a valid proof, for their own share. The creator, for what is left | Recipients until the deadline. The creator only after it, and never if no deadline was set |
| Burner | Nobody, ever | Tokens go straight to the dead address and never rest in the contract |
Note the absence rather than the presence. The locker, burner and vesting contracts have no
rescue, no sweep, no emergencyWithdraw and no pause that redirects
funds. The airdrop contract has one sweep, and only the airdrop's own creator can call it,
after the deadline. A backdoor you cannot find is usually a backdoor that is not there, and you can check
by reading the source yourself.
What admin can actually do#
Each contract has an admin key. Its reach is deliberately narrow.
| Admin can | Admin cannot |
|---|---|
| Change the fee for new records | Touch any existing lock, schedule, airdrop or balance |
| Change the fee collector address | Withdraw, redirect or freeze user tokens |
| Transfer the admin role | Alter an unlock date, a vesting schedule or an airdrop |
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.
- Airdrops have a hard fee cap of 0.25 ETH per airdrop, also a contract constant.
- 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 and airdrop contracts use a two-step admin transfer. After
transferAdmin, the new admin has to call acceptAdmin, so a mistyped address
cannot strand the role. The locker and burner hand over admin in a single step with
setAdmin.
Verify it yourself#
This takes about five minutes and does not require trusting anything on this page.
- Open a contract address from the contract reference on Blockscout.
- Confirm the source is verified. If it is not, nothing else here can be checked.
- Search the source for
withdraw. Every match that moves tokens should be limited to the owner or beneficiary.withdrawFeesonly moves the ETH fees, to the fee collector. - Search for
onlyAdmin. Read what those functions touch. You should find fees, the collector and the admin key, and nothing else. - Read the contract's
feevalue and check it matches what the app asks you to pay.
How to read a contract on Blockscout covers the mechanics if you have not done it before.
SBSecurity reviewed the token locker and the vesting contract in September 2026 and reported no findings. That report, every page of it, is at the security review, together with the original PDF. The Liquidity Locker, which holds Uniswap V3 and V4 positions, was audited by SBSecurity in October 2026: six findings, none high, all fixed and verified before launch. That report is on the same page, under Liquidity Locker. The burner, the airdrop contract and everything off chain were not part of either review.
Token quirks the contracts handle#
| Quirk | How it is handled |
|---|---|
| Ordinary ERC-20 tokens | Supported, and that is almost every token. Locking, burning and vesting behave exactly as described above. The rows below are the exceptions, not the rule. |
| Fee-on-transfer tokens | The locker, burner and vesting contracts record the balance they actually gained, so simple fee-on-transfer is recorded correctly. The airdrop contract rejects fee-on-transfer tokens outright. |
| Rebasing and reflection tokens | Not supported, and it goes wrong in both directions. A negative rebase leaves the shared per-token pool short of what it owes, and the last owner to withdraw is the one who finds out. A positive rebase or a reflection is the opposite problem: the extra tokens land in the contract and nobody can ever withdraw them, because each lock pays back the amount it recorded. Nothing blocks either kind, so read the token first. |
| Tokens that return no boolean | The vesting and airdrop contracts accept tokens that return no value on transfer. The locker and burner do not, so the transfer fails and nothing is created. |
| Overpaid fees | Refunded by the locker and burner. Not by vesting or airdrops, which require the exact fee. |
| Non-contract token addresses | Vesting and airdrops reject an address with no code, so a typo cannot create an empty record. |
What this does not protect you from#
Being clear about the boundary matters more than the reassurance.
- A malicious token contract. Locking a token that can be minted at will does not constrain the minting. Read the token, not just the lock.
- A compromised wallet. If someone controls the lock owner's key, they control the lock when it expires.
- Bad distribution. A locked balance says nothing about the other 95% of supply, so check the holder list.
- Phishing. We will never DM you first, never ask for a seed phrase, and never ask you to “verify” a wallet. Reach the app by typing the domain.
Reporting an issue#
If you believe you have found a vulnerability in any of the contracts or in the site, message us privately at admin@hoodlock.tech or x.com/HoodLockRH 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.