Robinhood Chain RPC Endpoints: How to Connect and Read the Chain Yourself

Published 2026-09-27 · SellTape research

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:

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:

Bad for:

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:

  1. Does it serve archive data, or only recent state?
  2. What are the eth_getLogs limits per request and per second?
  3. 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:

  1. Open network settings and choose "Add network" or "Add a network manually".
  2. Name it Robinhood Chain.
  3. Paste the Robinhood Chain RPC URL. Use a provider URL if you have one, the public one if you do not.
  4. Set the chain id to 4663.
  5. Set the currency symbol to ETH, since gas is paid in ETH.
  6. 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:

Block time maths: turning blocks into hours

Blocks on Robinhood Chain arrive roughly every 0.1 seconds, measured. That gives clean arithmetic:

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.

  1. Call totalSupply() and note the number.
  2. Call owner() (0x8da5cb5b) and see what answers. A plain wallet, a contract, or a reverting call each tells you something different.
  3. 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, read getOwners() and getThreshold() to find out whether "multisig" means five keys or one. That pattern is covered in Safe multisig 1 of 1.
  4. Pull Transfer logs for the last 860,000 blocks and sort the counterparties into pools, staking contracts, burn addresses and wallets.
  5. Simulate a sell. Take a real holder address and eth_call a 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:

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

Scan a token free in Telegram at t.me/SellTapeBot.

SellTape is an information service, not financial advice.

Who is selling your token?Paste any Robinhood Chain or Ethereum token into the bot and get the tape in one message. Free for 3 scans a day.Scan a token in Telegram