Contract reference.

Five contracts, all deployed on Robinhood Chain. Read them yourself before you send anyone to them. That is the point of publishing the addresses.

Addresses#

None of the five is upgradeable and none sits behind a proxy. We compiled the source of each one and checked that it matches the bytecode running at these addresses. You can open any address on the explorer and compare it yourself. The network parameters are on the network page.

Locker#

One vault, many locks. Each lock records an owner, a token, an amount and an unlock time.

Functions#

Events#

event Locked(uint256 indexed id, address indexed owner, address indexed token, uint256 amount, uint256 unlockTime);
event Withdrawn(uint256 indexed id, address indexed owner, uint256 amount);
event Extended(uint256 indexed id, uint256 newUnlockTime);
event LockOwnershipTransferred(uint256 indexed id, address indexed from, address indexed to);
event FeeChanged(uint256 fee);

What the code guarantees#

• Locked tokens can only be withdrawn by the lock's owner, and only at or after the unlock time.
• There is no admin function that can move locked tokens.
• unlockTime can only ever be extended.
• The amount recorded is measured as the balance the contract actually gained, so a fee-on-transfer token is not over-credited.

Burner#

A burn registry rather than a vault. Tokens are moved from your wallet to the dead address in a single transfer and never rest in the contract.

event Burned(uint256 indexed id, address indexed burner, address indexed token, uint256 amount);
event FeeChanged(uint256 fee);

Vesting#

Linear release with an optional cliff. There is no revoke, no sweep and no rescue function in this contract, so no HoodLock function can cancel or alter a schedule once it exists.

Constants#

event VestingCreated(uint256 indexed id, address indexed token, address indexed beneficiary,
                     address creator, uint256 total, uint64 start, uint64 cliff, uint64 end);
event Claimed(uint256 indexed id, address indexed beneficiary, uint256 amount);
event BeneficiaryTransferred(uint256 indexed id, address indexed from, address indexed to);
event FeeChanged(uint256 fee);
event FeeCollectorChanged(address collector);
event FeesWithdrawn(address indexed collector, uint256 amount);
event AdminTransferStarted(address indexed current, address indexed pending);
event AdminTransferred(address indexed previous, address indexed current);

Airdrop#

Pull-based Merkle airdrops. The creator deposits the tokens and publishes a Merkle root, and each recipient claims their own share. Nothing is pushed to a wallet. How to run one is covered in the airdrops guide.

Each leaf is keccak256(bytes.concat(keccak256(abi.encode(index, account, amount)))), and pairs are hashed in sorted order. That is the OpenZeppelin convention, so proofs from standard Merkle libraries verify here.

Constants#

event AirdropCreated(uint256 indexed id, address indexed token, address indexed creator,
                     bytes32 merkleRoot, uint256 total, uint32 maxClaims, uint64 endTime, string listURI);
event Claimed(uint256 indexed id, uint256 index, address indexed account, uint256 amount);
event Swept(uint256 indexed id, address indexed creator, uint256 amount);
event FeeChanged(uint256 feeBase, uint256 feePerWallet);
event FeeCollectorChanged(address collector);
event FeesWithdrawn(address indexed collector, uint256 amount);
event AdminTransferStarted(address indexed current, address indexed pending);
event AdminTransferred(address indexed previous, address indexed current);

Liquidity Locker#

Locks a Uniswap v3 or v4 position until a date. The locker holds the position NFT for the whole lock, and the owner keeps collecting the position's trading fees while it is locked. How to use it is covered in the liquidity locker guide. The position managers it accepts are the Uniswap v3 NonfungiblePositionManager 0x73991a25C818Bf1f1128dEAaB1492D45638DE0D3 and the Uniswap v4 PositionManager 0x58daec3116aae6D93017bAAea7749052E8a04fA7.

Functions#

Events#

event Locked(uint256 indexed id, address indexed owner, address indexed manager, uint256 tokenId,
    address token0, address token1, bytes32 pool, uint256 unlockTime, uint16 collectFeeBps,
    bool hookVerified, address feeRecipient, uint256 fixedFeePaid);
event Extended(uint256 indexed id, uint256 newUnlockTime);
event Withdrawn(uint256 indexed id, address indexed to);
event LockOwnershipTransferred(uint256 indexed id, address indexed from, address indexed to);
event FeeRecipientChanged(uint256 indexed id, address indexed recipient);
event Collected(uint256 indexed id, address indexed recipient, uint256 amount0, uint256 amount1,
    uint256 cut0, uint256 cut1, bool byAdmin);

In Collected, amount0 and amount1 are everything the position paid out, before HoodLock's cut. The fee recipient received amount0 - cut0 and amount1 - cut1.

pool in Locked is the v4 pool id, or the v3 pool address left-padded to 32 bytes.

What the code guarantees#

• A locked position can only be withdrawn by the lock's owner, and only at or after the unlock time.
• No admin function can move a locked position. The admin's stray-position return reverts for any position with an active lock.
• unlockTime can only ever be extended, and at most 100 years ahead.
• The collect fee is frozen per lock at creation and capped at 30% in the contract; the fixed fee is capped at 0.1 ETH.
• The admin, or the keeper role it appoints, can trigger a fee collection with adminCollect. It pays exactly what an owner's own collect pays, to the lock's own fee recipient, and has no recipient parameter.

Integrating#

Explorers, scanners and security tools can tell whether a pool's liquidity is locked with two reads:

• Find who owns the position NFT on the v3 or v4 position manager. If it is the Liquidity Locker, call lockIdOf(manager, tokenId).
• A non-zero id is an active lock. getLock(id) gives the owner and unlockTime.

Every lock has a public proof page at https://hoodlock.tech/proof/position/{lockId}, and the same data as JSON from GET /api/lp/lock/{lockId}; GET /api/lp/locks lists every liquidity lock with its pair, amounts and value. The REST API covers the rest.

Administration#

All five contracts share one admin address, 0x79c1230cAb12d53D040f5FE1F5279e1A481CCeA2. It is a single wallet, not a multisig. Fees go to the fee collector, which is a contract at 0xd59948E49B1B56784626bDe2d6D1712eD24a6BBc. No admin function reads or moves user tokens, and none can change an existing lock, burn record, schedule or funded airdrop.

• The locker and burner forward each fee to the collector in the same transaction. Vesting and airdrops keep fees in the contract until the collector pulls them with withdrawFees().
• With a two-step admin transfer the new admin has to accept the role, so a mistyped address cannot strand it. The locker and burner do not have this protection.

The $LOCK buyback and burn uses separate contracts, which are not covered on this page.

How to confirm any of this yourself is covered in the security model, and reading a contract on the explorer is covered in this walkthrough.