Network details.

HoodLock runs only on Robinhood Chain. Everything below is what a wallet, a script or an indexer needs to talk to it.

Updated 2026-09-15 · HoodLock Team

Parameters#

FieldValue
Network nameRobinhood Chain
Chain id4663 (0x1237)
Gas tokenETH
RPChttps://rpc.mainnet.chain.robinhood.com
Explorerrobinhoodchain.blockscout.com (Blockscout)
StackEthereum L2, Arbitrum stack

Adding the network by hand is rarely necessary. The app and the embed widget both ask the wallet to switch, and add the chain if it is missing. Connecting a wallet covers the cases where that fails.

javascript
await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x1237",
    chainName: "Robinhood Chain",
    nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
    rpcUrls: ["https://rpc.mainnet.chain.robinhood.com"],
    blockExplorerUrls: ["https://robinhoodchain.blockscout.com"],
  }],
});

Contract addresses#

The locker, burner and vesting addresses are on the contract reference, along with the functions and events each one exposes.

Reading history#

If you are indexing HoodLock events yourself, one limit on the public RPC matters more than anything else about it, and it is not the one you might expect.

LimitMeasured behaviour
eth_getLogs result sizeHard cap at 10,000 logs. Exceeding it returns logs matched by query exceeds limit of 10000 and no partial result.
eth_getLogs block spanNo fixed span limit. A single call spanning two million blocks succeeds provided the result stays under the cap.
Note

This means you should chunk by result volume, not by block count. A quiet contract can be backfilled in one or two calls across its whole history, while a busy one needs narrow windows even over a few hundred blocks. Fixed 2,000-block chunking wastes thousands of requests on the first case and still fails on the second.

A workable strategy is to start wide and halve the window whenever the cap error comes back.

Note

Blockscout's API can return a contract's log history in one request, but its results are not always complete. We have seen the same query return far fewer logs an hour later. Check the count against the contract's own total, such as totalLocks(), and keep a chunked RPC scan as the fallback. A scan that silently returns nothing looks identical to a contract with no activity, and every number downstream will be wrong without anything appearing to fail.

Deploy blocks#

Start a backfill here rather than at block zero.

ContractDeploy block
Locker4,591,195
Burner16,820,186
Vesting20,301,744

Multicall#

Multicall3 is deployed at the canonical address, so batched reads work with the usual tooling. Viem, ethers and wagmi find it without configuration.

address
0xcA11bde05977b3631167028862bE2a173976CA11

Reverts stay isolated per call, so one failing read in a batch does not take the others down with it.

Rate limits#

Careful

The public RPC is rate limited by design, and Robinhood's own documentation says the public endpoints are not recommended for production. A read-heavy page can drop a call under load. If you are building on top of HoodLock, put your own RPC behind a fallback transport rather than relying on the public one.

Note that transaction submission goes through the user's wallet and its RPC, not yours. A wallet configured with a broken endpoint for chain 4663 will fail to submit no matter what your app does.