Robinhood Chain RPC Endpoints: How to Connect and Read the Chain Yourself
If you trade on Robinhood Chain, you eventually want your own pipe into it. A robinhood chain rpc endpoint is what turns a wallet, a script or a bot from a spectator into something that can read balances, pull logs and simulate calls before anything gets signed. This guide covers the chain id, the public endpoint and its limits, the node providers Robinhood's own documentation points to, and how to read token data straight from RPC instead of trusting a dashboard.
Everything below is mainnet, chain id 4663. The testnet id is 46630.
The essentials: chain id 4663 and the public RPC URL
Robinhood Chain is a permissionless Layer 2 built on Arbitrum technology (Arbitrum Orbit / Nitro). Gas is paid in ETH. Mainnet launched July 1, 2026. If you want the wider picture of what the chain is and how activity flows through it, start with Robinhood Chain explained.
Two public endpoints are documented:
https://rpc.mainnet.chain.robinhood.comrobinhood-rpc.publicnode.com
The first is the one Robinhood's docs list, and those same docs say it is rate-limited and not for production. That is not a criticism. It is a convenience endpoint meant for wallets and one-off calls. If you are polling block numbers, running a bot, or asking for eth_getLogs across a wide block range, you will hit the ceiling quickly and start seeing throttled or rejected responses.
For anything sustained, use a provider.
What the public endpoint will and will not do
Good for:
eth_chainId,eth_blockNumber,eth_gasPrice- Single
eth_callreads such asbalanceOf,totalSupply,owner,getThreshold - Small
eth_getLogsranges, a few thousand blocks at a time - Occasional
eth_getTransactionReceipt
Bad for:
- Wide
eth_getLogsscans. On this chain a day is roughly 860,000 blocks, so "give me every Transfer event for 24 hours" is an enormous request. - High request rates from a bot or an indexer
- Archive-style queries against old state
- Anything that has to stay reliable in production
The practical rule is simple. If a human is clicking, the public endpoint is fine. If code is looping, get a provider.
Robinhood Chain node providers
Robinhood's documentation recommends Alchemy and lists Chainstack, QuickNode, Blockdaemon, dRPC, Validation Cloud and GlobalStake as providers. As of September 2026, Infura and Ankr were not found to support Robinhood Chain.
When you pick a Robinhood Chain node provider, ask three questions before you commit:
- Does it serve archive data, or only recent state?
- What are the
eth_getLogslimits per request and per second? - Is there a websocket endpoint for subscriptions, or HTTP only?
Those three answers decide whether your setup works. A provider that looks cheap but caps getLogs at a tiny range will cost you more in engineering time than it saves in fees.
Add Robinhood Chain to your wallet
Adding the network takes about a minute. In most wallets:
- Open network settings and choose "Add network" or "Add a network manually".
- Name it Robinhood Chain.
- Paste the Robinhood Chain RPC URL. Use a provider URL if you have one, the public one if you do not.
- Set the chain id to 4663.
- Set the currency symbol to ETH, since gas is paid in ETH.
- Save, switch to the network, and confirm the block number is moving.
If the wallet refuses to save, the usual cause is a chain id typo. 4663 is mainnet, 46630 is testnet, and mixing them up leaves you staring at an empty balance on the wrong chain.
Reading token data straight from Robinhood Chain RPC
This is where an endpoint earns its keep. Four calls cover most of what a trader wants to know about a token before touching it.
balanceOf: who holds what
balanceOf(address) has the selector 0x70a08231. You pass the address left-padded to 32 bytes. A curl call looks like this:
curl -s https://rpc.mainnet.chain.robinhood.com \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0xTOKEN","data":"0x70a08231000000000000000000000000WALLET"},"latest"]}'
The result is hex. Decode it and you have the balance. Run it for the pool address, the staking contract and the top wallets, and the shape of the holder base starts to appear.
totalSupply: what is actually minted
totalSupply() is 0x18160ddd. This matters because the max supply shown on data sites is not the same thing as the minted supply returned by the contract. A token can advertise a large max supply and have a very different number actually in existence. Read the contract, not the aggregator.
getLogs: every transfer, in order
Transfer(address,address,uint256) has the topic hash 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef. Filter by that topic and the token address and you get every movement of the token.
Two things to remember:
- Chunk the range. Ask for 5,000 to 10,000 blocks at a time and paginate.
- Direction matters. Tokens moving into a DEX pool are a sell. Tokens moving out of a pool are a buy. A route that hops through two pools in one transaction nets to roughly zero, which is why net flow per transaction beats counting transfers.
Block time maths: turning blocks into hours
Blocks on Robinhood Chain arrive roughly every 0.1 seconds, measured. That gives clean arithmetic:
- 1 minute is about 600 blocks
- 1 hour is about 36,000 blocks
- 24 hours is about 860,000 blocks
So if the current block is N, the block from 24 hours ago is roughly N minus 860,000. That one subtraction is what turns "recent activity" into a defined window you can query, chart or compare.
The manual check, step by step
Say you want to vet a token called $EXAMPLE without trusting anyone.
- Call
totalSupply()and note the number. - Call
owner()(0x8da5cb5b) and see what answers. A plain wallet, a contract, or a reverting call each tells you something different. - Check whether the contract is a proxy. Read the EIP-1967 implementation slot,
0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc. If it holds an address, the logic can be replaced. If the owner is a Safe, readgetOwners()andgetThreshold()to find out whether "multisig" means five keys or one. That pattern is covered in Safe multisig 1 of 1. - Pull Transfer logs for the last 860,000 blocks and sort the counterparties into pools, staking contracts, burn addresses and wallets.
- Simulate a sell. Take a real holder address and
eth_calla transfer to the pool. A revert is a strong signal that selling is blocked or taxed into oblivion. A passing simulation is not proof it will pass tomorrow, because code can be upgraded and fees changed. The full method is in honeypot token check.
That is an afternoon of work for one token, and it still leaves the hardest question open: of everyone selling, who is actually selling?
What raw RPC cannot tell you
Here is the honest limit. RPC gives you transfers. It does not give you intent.
A wallet that bought in one pool and sold in another in the same transaction is an arbitrage bot moving price between venues. It is not dumping on holders, and counting it as sell pressure is wrong. Telling that apart from a real seller means looking at transaction counts, holdings and routing, which is a different job from reading logs. There is more on that in arbitrage bots are not dumping.
The same gap applies to:
- Protocol mint-and-sell: a contract receiving newly minted tokens from the zero address and selling them into a pool. That is dilution, even when it is by design.
- Unstakers: tokens leaving a staking or vault contract that holds a large share of supply, sold in the same flow. Unlock schedules often land on a calendar you can plan around, as covered in token unlocks and unstaking.
- Real float: supply sitting in pools, staking vaults, burn addresses and treasury Safes is not freely trading, so a quoted market cap can badly overstate what can actually be sold. See real float and liquidity pools.
None of that is visible from balanceOf alone.
Manual RPC versus one SellTape message
| Question | Raw RPC | SellTape |
|---|---|---|
| What is the total supply? | totalSupply() |
Shown in the contract scan |
| Can the owner change fees? | Manual simulation | Simulated and reported |
| Can I sell? | eth_call sell simulation |
Sell simulation from a real holder |
| Who are the top holders? | Transfer log sorting | Labelled: pool, vault, burn, Safe, wallet |
| Who is selling in the last 24h? | Not answerable from logs alone | Split by source: protocol, treasury, unstakers, holders, bots |
| Is the owner a real multisig? | getOwners() and getThreshold() |
Threshold and owner type reported |
The point of the table is not that RPC is bad. It is that RPC answers mechanical questions well and intent questions badly.
SellTape is read-only on-chain analysis delivered in Telegram. No wallet connection, no signing, no deposits, and it never asks for keys. A report has three parts: a contract scan (proxies, privileged roles, dangerous functions, fee-change simulation, sell simulation), a holder map (top holders labelled, share held by staking and pools versus the real float, concentration of the top 10 real holders), and the sell breakdown over the last 24 hours across all pools of the token, V2, V3 and V4 style. Every report shows the block number, UTC time, caveats and the line "heuristic, not financial advice". Missing data gives a grade of INCOMPLETE, never a low grade.
Chains today are Robinhood Chain and Ethereum, with Base, Arbitrum, BSC and Berachain coming. You can look at a sample tape before paying anything. Pricing is in USDC, 30 days, no auto-renew and no refunds: Free at 3 scans a day, Trader at 29, Pro at 99, and Group at 149 for a bot that sits in a Telegram group and answers only when asked. Details are on the pricing page.
Which one should you use
Use RPC when you are building. If you are writing an indexer, a bot or a dashboard, you need a provider and you need to understand getLogs limits, archive depth and block time maths. That work is real and it is yours.
Use RPC when you want to verify a single fact. Reading totalSupply() yourself takes seconds and removes all doubt.
Use an analysis layer when the question is about behaviour. "Who is selling" is not a log query. It is a classification problem, and it is the one that decides whether the red candle in front of you is dilution, an unlock, a bot doing its job, or holders heading for the exit.
For a fair look at how the other tools divide the work, including what they do and do not cover, see the comparison of Token Sniffer, Bubblemaps and DexScreener. As of September 2026, none of them split sell flow into protocol, arbitrage bots, unstakers and ordinary holders.
Key takeaways
- Robinhood Chain mainnet is chain id 4663, testnet is 46630, gas is ETH, and blocks land roughly every 0.1 seconds.
- The public RPC at https://rpc.mainnet.chain.robinhood.com is rate-limited and not for production. Use it for wallets and one-off calls.
- Robinhood's docs recommend Alchemy and list Chainstack, QuickNode, Blockdaemon, dRPC, Validation Cloud and GlobalStake.
- One day is about 860,000 blocks. Chunk your
getLogscalls or you will be throttled. - RPC tells you what moved. It does not tell you who is selling or why.
Scan a token free in Telegram at t.me/SellTapeBot.
SellTape is an information service, not financial advice.