Docs

The chain

Robinhood Chain is an Arbitrum-stack layer two that settles to Ethereum. Gas is paid in ETH. It has been live since 1 July 2026. Blocks arrive fast enough that the desk measures age in seconds and flow in blocks rather than minutes, and the figure below is measured rather than quoted: /api/status reads two real block timestamps a thousand blocks apart and reports the difference. No page on this site states a block time it did not measure.

Chain id

4663, hex 0x1237

Block time

measuring

Gas token

ETH

RPC

https://rpc.mainnet.chain.robinhood.com

Public RPC

https://robinhood-rpc.publicnode.com

Explorer

robinhoodchain.blockscout.com

The official node wants a browser user agent on some networks. The publicnode endpoint does not, and it caps a single eth_getLogs response at around ten thousand logs, so every range read in this codebase is windowed rather than asked for in one shot.

Contracts and topics

Curve calls the desk uses

• getReserves() selector 0x0902f1ac, returning the quote reserve and the token reserve.
• graduated(), readyToGraduate(), isNativeQuote() and currentSnipeTaxBps(address).
• buy(uint256 quoteIn, uint256 minTokensOut, address recipient), payable, selector 0x59a87bc1, with msg.value equal to quoteIn.
• sell(uint256 tokensIn, uint256 minQuoteOut, address recipient).

Pons coins carry a supply of 1,000,000,000 with 18 decimals. Once a coin graduates, the desk routes its quotes and fills to Uniswap V3 instead of the curve.

Data sources

• Launches come from factory logs, not from a list somebody maintains.
• Prices and liquidity come from curve reserves or from a QuoterV2 call against the live pool.
• Holder concentration is rebuilt from Transfer logs, so it reflects the chain rather than a snapshot service.
• Flow is counted from CurveBuy and CurveSell logs over a recent block window.
• ETH in USD comes from the Chainlink feed listed in the Robinhood mainnet feed directory, read with latestRoundData, selector 0xfeaf968c.
• Jev is reached keyless through Vercel AI Gateway with the deployment's own OIDC token, model typesafe-ai/jev. A TypeSafe API key or an OpenJEV compatible server can stand in.

WARDEN checks

WARDEN runs before Jev and can end a trade on its own. Every rule below is measured on chain, and every flag comes back with its id, its level and the sentence you see on the scan page. These are the ids the running code emits, in the order the rules run.

How the flags become a status

• kill if any flag is a kill. The published verdict is killed no matter what Jev answered.
• unread if a read a rule needed was refused by every node. An unread scan is never a clear scan: it fails closed, it carries a warn flag per missing read naming the node that refused, and neither buy nor copy stands on it.
• watch if any flag is a warn and nothing was refused.
• clear only when every rule ran and none of them fired.

A rule with no data to fire on is not a rule that passed. That is why the fourth status exists, and why an unread scan shows a grey dashed chip rather than a green one. Open any token on the scan page to see the ids the running code assigned to it.

Jev questions and policy

Jev is TypeSafe's System One model: typed questions in, typed answers out, with calibrated probabilities and no prose. The desk sends one compact state object and four questions in a single call.

• action is a choice over buy, copy, skip and pass.
• rug is a score over Clean, Some flags and Likely rug, returned as an expectation plus the distribution.
• momentum is a boolean: buy flow over the last blocks is accelerating.
• crowd is a boolean: at least one tracked wallet already bought.

Nothing comes back called confidence. The desk computes it as the highest probability in the returned distribution. The model reads literally and is not a calculator, so every number in the state is computed in code and sent as a value and a named bucket, names taken from the chain are truncated to 32 characters and marked untrusted, and the whole state stays under sixty fields.

Policy applied in code, after the answer

• A WARDEN kill sets the verdict to killed.
• buy needs confidence of at least 0.55 and a rug score below 1.0.
• copy needs at least one tracked wallet already in.
• Anything that misses its condition becomes skip, with the reason written in plain words on the receipt.

The desk's book

The desk runs this exact loop on every launch in public and keeps a book of its own. It holds no key, no wallet and no signer, and it sends nothing. A verdict that clears its gate opens a position marked at the real quote /api/quote returns for the desk's size, which is the curve's own buy() simulated over eth_call at that amount, so the buy fee and the snipe tax are already inside the entry price. From there the position is marked every cycle against the curve's getReserves(), and a coin that has graduated is marked from QuoterV2 instead.

Positions are marked against the curve; no fill has been made. Fills begin when the desk wallet is funded. The published book says as much on every cycle: its mode is marked and its wallet is null.

What has to agree before a position opens

• The verdict gate is clear and the action is buy or copy.
• The action confidence is at least 0.6 and the rug score is under 0.6.
• Curve liquidity is at least 1 ETH and the launch is at least 20 seconds old.
• The book is under its open limit and the deployer is not blocked.
• Size is the smaller of the fixed size and equity times the risk fraction, then whatever the day cap still allows. The day's spend is counted from the ledger, open and closed, not from a counter.

The exit rules

• Take profit at the take profit level.
• Trailing stop once the peak passes its arming level, exiting when the position gives back a quarter of that peak.
• Hard stop at the hard stop level.
• Time stop once the position has been open for its time limit.
• WARDEN re-scan, run every fifth cycle a position is open, exits now on a kill.
• Graduation is recorded at the next cycle at the Uniswap quote, and the exit venue becomes Uniswap V3.

A stale mark blocks every decision that depends on it. A mark older than sixty seconds, a mark with no price, or a curve with a zero token reserve is refused with a stated reason, the position is carried at cost, and no exit is recorded from a price the desk does not have. The book is on the home page and at the top of the desk, read from GET /api/desk.

The veil and the rail

The veil is a one time snipe wallet that the browser makes and the browser keeps. Its key is generated on your machine, encrypted there, and used to sign one thing: the fill. Nothing on Robinhood Chain links that fill to the wallet you normally trade from, because the veil address has never touched it. The road in and out of the veil is NEAR Intents, which is why the rail is NEAR rather than a bridge of ours. Jevmaxxing is not affiliated with, endorsed by or speaking for Bitwise, NEAR or TypeSafe.

What the veil hides today is the link, not the order. The route the desk quotes right now is the public NEAR Intents route, so the amounts and the timing on both sides of it are readable. What the veil removes is the connection between the wallet you normally trade from and the fill: the veil is funded from another chain and signs with a key that has no history. Confidential Intents would hide the order's size, pair, direction and timing as well, and it needs a NEAR Intents partner key the desk does not hold yet. Until it does, a confidential quote is refused upstream and the page says so and offers the public route instead.

The flow, endpoint by endpoint

• Open the veil. The browser draws 32 bytes from crypto.getRandomValues, derives the address, and encrypts the key under a passphrase you type. No endpoint is involved. Nothing is sent.
• Pick what you are funding it with. GET /api/veil/assets lists the origin assets the rail accepts, the one destination funding has (native ETH on Robinhood Chain) and the assets you can exit into. ZEC, BTC, SOL, wNEAR, ETH on Arbitrum, ETH on Base and USDC on Solana lead the origin list.
• Quote the deposit. POST /api/veil/quote with the origin asset, the amount, a refund address on the origin chain and the veil address as recipient. A quote is dry unless you ask for a live one, and a live one is always preceded by a dry one, so a refusal or a floor arrives before a deposit address exists. The live quote returns the address to send to, its memo when the chain needs one, and its deadline. The page re-reads the recipient and the amounts out of the relay's own echo and refuses the flow when either one does not match the veil it is holding.
• Send the origin asset to the deposit address, then watch it land. GET /api/veil/status?deposit= reports pending, processing, done, refunded or failed, with the raw upstream state, the amounts and the transactions next to it. A state this build has not met reads as processing, never as done and never as failed.
• Snipe. The veil key signs the same unsigned ticket GET /api/quote builds for everybody else. WARDEN and Jev run exactly as they do on the scan page.
• Leave. POST /api/veil/exit quotes the road back: ETH on Robinhood Chain out to ZEC or any other listed asset, to an address you type. The quote echoes that address back before the sell is offered.

The security model

• The key is yours and only yours. It is generated with WebCrypto randomness in the browser, encrypted at rest with AES-GCM under a key stretched from your passphrase with a per key salt, and kept in that browser's local storage in encrypted form only. It is exportable as a JSON keystore. It is shown as a plain private key once, behind an explicit reveal click with a warning on it.
• The site cannot recover it. There is no account, no email and no reset. Lose the passphrase and the veil is gone with whatever is in it.
• What the server sees: a quote request (the asset pair, the amount, the refund address and the veil address, because the rail needs them) and nothing else. The API side is a proxy with validation only. It holds no key, stores no quote, rate limits by hashed IP and does not log addresses.
• What the veil page carries: no analytics, no error reporter, no third party script, and a content security policy that allows this origin, the fonts and nothing else. Every outside call goes through /api/veil.
• Before any send: the amount goes through the strict decimal regex, the chain id is checked against 0x1237, and a receipt with status 0 renders as reverted, in red, rather than as a fill.

NEAR Intents and Confidential Intents

NEAR Intents settles a cross chain order by auction: you state what you want, solvers compete to deliver it, and the winner sends the destination asset to your recipient address. The desk talks to the 1Click API at https://1click.chaindefuser.com and Robinhood Chain is the chain key hood, where native ETH is nep141:hood.omft.near. Confidential Intents, generally available since 8 July 2026, runs the execution on a private NEAR shard with no public RPC, mempool or explorer, operated by a permissioned validator set and bridged to mainnet through trusted execution environments. NEAR states that this hides an order's size, token pair, direction and timing while solvers still compete on it. Those are NEAR's claims about NEAR's infrastructure, cited here and not verified by us.

The desk quotes the public route. A confidential quote needs a NEAR Intents partner key, and the desk does not hold one, so the relay refuses a keyless confidential request with User authentication is required for confidential intent quotes. The endpoint passes that back as a 409 with the public route still on offer, and the veil page says which route it is about to use before you send anything. Order detail privacy arrives on this site the day the desk holds that key, and this page will say so when it does.

• Sources: docs.near-intents.org, and the NEAR blog posts Confidential Intents and Announcing general availability of Confidential Intents at near.org/blog. Read 2026-09-26.
• Fees are inside the quote. What the quote says you receive is what you receive: the solver's price, the relay's withdraw fee and the platform fee are all already taken out of it. The quote states the withdraw fee and the refund fee as their own numbers so you can see them. The unauthenticated route the desk uses carries a platform fee of 25 bps, charged by the relay inside the solver quote, not by us. Jevmaxxing adds nothing on top of it, takes nothing out of it, and holds no key in the route.
• Deadlines. A quote carries a deadline. A deposit that arrives after it is not filled at that price.
• Refunds. When a route cannot be filled, the origin asset goes back to the refund address you gave, on the origin chain. That address must be a real address on that chain: a ZEC route is refused outright if the refund address is not a valid Zcash address. It does not come back to the veil, and we cannot redirect it.

The rail's regulated wrapper

The network the veil settles through is NEAR, and NEAR is held in a European brokerage account through the Bitwise NEAR Staking ETP: ticker NEAR on Deutsche Boerse Xetra, ISIN DE000A4A5GV2, WKN A4A5GV, physically backed, staking its NEAR and reinvesting the rewards daily, inception 1 July 2025. The product page figures on the read date were a NAV of $26.21, a net staking reward of 3.01 percent, a TER of 0.85 percent and assets under management of about $132M.

• Source: the Bitwise product page at bitwiseinvestments.eu, with the listing note at rankiapro.com. Read 2026-09-26.
• This is named because it is the regulated way to hold the rail, and for no other reason. There is no partnership, no endorsement and no tokenised Bitwise share anywhere in this product. Robinhood Chain's stock token registry holds no Bitwise product.

The honest limits

• The fill is public. Whatever the veil buys, it buys in a transaction anybody can read on Robinhood Chain. The veil breaks the link to your other wallet. It does not hide the trade.
• Timing analysis is possible. A deposit on one chain and a fill on another, minutes apart, are two public events. Someone watching both sides can line them up, and a route with one participant in that window lines up very well.
• A refund undoes the privacy of that attempt. It lands back on the refund address you gave on the origin chain, which is an address you already control.
• Reusing a veil weakens it. Every fill a veil signs is on the same address. A veil that snipes twenty coins is a wallet with a history.
• The rail is somebody else's. Solvers, their quotes, their fees, their deadlines and their refunds are theirs. Read the terms before you use it.

Public API

Every endpoint answers plain JSON, needs no key and carries an at timestamp. Errors come back as { "error": "a sentence" }. Addresses are lowercase, ETH amounts are numbers in ETH unless the field name ends in Wei.

GET /api/status

Chain head, RPC state, which Jev backend answered and how fast, whether the store is degraded, and the desk counters.

curl -s https://jevmaxxing.xyz/api/status

GET /api/scout

The launch window, newest first, each with its WARDEN status and a decision when one is cached.

curl -s "https://jevmaxxing.xyz/api/scout?limit=24"

GET /api/scan

The full scan of one token: metadata, bytecode selectors, owner, curve or pool, holders, deployer, PULSE and LEDGER.

curl -s "https://jevmaxxing.xyz/api/scan?token=0x0000000000000000000000000000000000000000"

POST /api/decide

Sends the compact state to Jev and publishes a receipt. One decision per token is cached for sixty seconds, and each address gets thirty decisions per ten minutes.

curl -s -X POST https://jevmaxxing.xyz/api/decide \
  -H 'content-type: application/json' \
  -d '{"token":"0x0000000000000000000000000000000000000000"}'

GET /api/receipts

The public log, newest first.

curl -s "https://jevmaxxing.xyz/api/receipts?limit=50"

GET /api/decision

The stored decision for one token: the compact state Jev read, its four typed answers and the verdict built on them. It answers 404 until somebody has asked about that token.

curl -s "https://jevmaxxing.xyz/api/decision?token=0x0000000000000000000000000000000000000000"

GET /api/desk

The desk's own book, read from the document the engine publishes: mode, equity, realized, open positions, the last decisions and the backtest line.

curl -s https://jevmaxxing.xyz/api/desk

GET /api/quote

Tokens out, price impact, snipe tax, a minimum out and an unsigned transaction. Pons is simulated against the live curve; a graduated coin routes to Uniswap V3 automatically. Maximum 5 ETH.

curl -s "https://jevmaxxing.xyz/api/quote?token=0x0000000000000000000000000000000000000000&eth=0.05"

GET /api/whales

Wallets that keep buying inside the first four hundred blocks of a launch, computed from the last forty thousand blocks and cached for ten minutes.

curl -s "https://jevmaxxing.xyz/api/whales?limit=25"

GET /api/veil/assets

What the rail takes on the way in, the one thing funding can land as, and what you can leave in. ZEC, BTC, SOL, wNEAR, ETH on Arbitrum, ETH on Base and USDC on Solana lead the origin list and the rest follows alphabetically by symbol, 191 rows today. Cached ten minutes in memory and in the store, and a stale copy answers when the relay is down, which is what source says. The relay states no minimum until it quotes one, so no row carries a minimum.

curl -s https://jevmaxxing.xyz/api/veil/assets

{ "at": "...", "source": "live | memory | store | store-stale",
  "origins":      [ { "assetId", "symbol", "blockchain", "decimals", "priceUsd" } ],
  "destinations": [ native ETH on hood ],
  "exits":        [ ZEC, BTC, SOL, wNEAR, ETH on Arbitrum, USDC on Solana ] }

POST /api/veil/quote

Prices one deposit route into a veil. A quote is dry unless dry is false, a dry quote returns no deposit address, and a live quote is always preceded by a dry one so a refusal or a floor lands before an address to send to exists. recipient is the veil address and refundTo is an address you control on the origin chain. Twenty quotes per hashed address every ten minutes.

curl -s -X POST https://jevmaxxing.xyz/api/veil/quote   -H 'content-type: application/json'   -d '{"originAsset":"nep141:arb.omft.near","amount":"0.01",
       "refundTo":"0x0000000000000000000000000000000000000000",
       "recipient":"0x0000000000000000000000000000000000000000",
       "confidential":false,"dry":true}'

{ "at": "...",
  "quote":   { "depositAddress", "depositMemo", "amountIn", "amountInBase", "amountInUsd",
               "minAmountIn", "minAmountInBase", "amountOut", "amountOutBase", "amountOutUsd",
               "minAmountOut", "minAmountOutBase", "timeEstimateSec", "deadline", "timeWhenInactive",
               "withdrawFee", "withdrawFeeFormatted", "withdrawFeeWei", "refundFee", "refundFeeFormatted" },
  "request": { "originAsset", "originSymbol", "originChain", "destinationAsset", "destinationSymbol",
               "destinationChain", "recipient", "refundTo", "confidentiality", "slippageBps", "dry" } }

The request block is the relay's own echo, which is what the page re-reads before it shows you an address to pay into. withdrawFeeWei is the same number as withdrawFee and is set only when the destination is native ETH on Robinhood Chain, so it is null on an exit.

400 with a sentence for a bad amount or a bad address. The upstream sentences refundTo is not valid and recipient is not valid pass through inside our own wording, and any other upstream 400 arrives as NEAR Intents refused the quote: <sentence>. 409 when the relay refuses a confidential route, which keyless it always does, and the sentence says the public route still quotes. 502 when the rail does not answer. 429 once the twenty are spent, with a retry after 600 seconds. 503 when the store cannot count them.

GET /api/veil/status

Where one deposit got to, with the raw upstream state kept next to the normalised one. PENDING_DEPOSIT and INCOMPLETE_DEPOSIT read as pending, KNOWN_DEPOSIT_TX and PROCESSING as processing, SUCCESS as done, REFUNDED as refunded, FAILED as failed, and a state this build has not met reads as processing, never as done and never as failed. Not rate limited: polling is how the page watches a settle. Pass memo as well on a chain that needs one.

curl -s "https://jevmaxxing.xyz/api/veil/status?deposit=..."

{ "at": "...", "status": "pending | processing | done | refunded | failed",
  "raw": "<the upstream state>", "updatedAt": "...", "refundReason": null,
  "amounts": { "in", "inUsd", "out", "outUsd", "deposited", "refunded" },
  "txs": { "origin": [ { "hash", "explorerUrl" } ], "destination": [ ... ], "near": [ ... ] } }

404 when NEAR Intents does not know that deposit address. 400 when it is not a deposit address.

POST /api/veil/exit

The same flow in the other direction: the origin is native ETH on Robinhood Chain, the destination comes from the published exit list with ZEC first, the payout address is checked against the shape of the destination chain and the refund address against Robinhood Chain. The payout address is echoed back in request before the sell is offered.

curl -s -X POST https://jevmaxxing.xyz/api/veil/exit   -H 'content-type: application/json'   -d '{"destinationAsset":"nep141:zec.omft.near","amount":"0.02",
       "refundTo":"0x0000000000000000000000000000000000000000",
       "recipient":"<a Zcash address>","confidential":false,"dry":true}'

Nothing about the veil is stored on our side: no quote, no deposit address, no recipient, no refund address, and nothing is logged. The twenty quotes are counted against their own budget, so the veil and the desk's thirty decisions never eat into each other. No endpoint here takes a private key, and none of them exists for one. The veil signs in your browser.

Live now, and what arrives with the token

Live today: SCOUT, WARDEN, PULSE, LEDGER and FLUX all read Robinhood Chain directly, Jev answers through the gateway, receipts are published, and the snipe ticket is signed in your own wallet.

Arriving with the token: no coin has been issued. When one is, it launches fair on Pons with no presale and no team allocation, the address appears on this site and on the official account, and the creator fees start paying the Jev and RPC bill and funding the desk wallet that runs this loop in public.

A clear WARDEN scan is not safety and a Jev buy is not advice. Both are measurements of a contract that a stranger deployed minutes ago. Most new coins go to zero, and the ones that pass every check here go to zero too. Size accordingly.

Verify it on chain

None of this asks for trust. Open the explorer next to the desk and read the same logs.

• Pons V2 factory, where every TokenLaunched log the desk reads is emitted.
• Uniswap V3 factory, for PoolCreated.
• SwapRouter02, the contract your wallet calls on a graduated coin.
• WETH, the token the router wraps into.

Take any token from the desk, open its address on the explorer, and compare its holders and transfers with what the scan page reported. If they disagree, the scan is wrong and the chain is right.