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

Every address in that table answered eth_getCode on chain 4663 before it was written down, on 2026-09-27: PoolManager 24,009 bytes, StateView 3,531, Quoter 6,118, PositionManager 23,877, Universal Router 24,546, the Pons hook 15,167, the Pons locker 1,969, Permit2 9,152.

What a Uniswap V4 pool is here

Every V4 pool lives inside the one PoolManager, so a pool is a 32 byte id and not an address. That changes three things the desk has to say out loud.

• Native ETH is a currency in V4, written as the zero address, so a coin can trade against ETH itself rather than against WETH. The coin is whichever side of the pair is not ETH, WETH or USDG; a pool of two coins is listed by its currency0 side and the row says the pair was unnamed.
• The pool's own state is read from StateView: getSlot0(bytes32) for the live sqrt price and getLiquidity(bytes32) for the liquidity. Price comes from the sqrt price and the two decimals, computed here. The pool holds no reserve to read a balance from, so the ETH figure is the amount at the current price, which is what the liquidity and the sqrt price say it is, and it is what the thin liquidity floor is measured against. A fee of 0x800000 is V4's dynamic fee flag, not a rate: the hook sets the fee per swap, so the desk prints "dynamic" instead of a percentage.
• A pool can name a hook contract that runs inside every swap. WARDEN warns on any hook other than the Pons hook, with the address in the text, because a hook can tax, block or reorder a swap and nothing on this page has read it. The Pons hook has been read: it takes 1% plus the coin's creator tax on each swap, and WARDEN marks it as information.

V3 pools are read too: PoolCreated on the V3 factory and Initialize on the V4 PoolManager are one eth_getLogs, one filter over both addresses with either topic, split back by log.address.

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 crosses, the desk quotes and fills it in its Pons pool on Uniswap V4 instead of the curve. After bonding has the whole crossing.

Data sources

• Launches come from factory logs, not from a list somebody maintains.
• Prices and liquidity come from curve reserves, from StateView for a Uniswap V4 pool (a crossed coin's Pons pool included), or from a QuoterV2 call against a Uniswap V3 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, and after the crossing from the Pons pool's own V4 Swap logs, by pool id.
• 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 after the crossing it is marked where it would exit: the Pons pool, quoted by the same /api/quote at the position's size, with the Pons hook fee and the creator tax charged on the exit.

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.
• The crossing is recorded at the next cycle, and from then the position is marked and exited in its Pons pool on Uniswap V4. A fresh crossing is a candidate of its own: a Pons pool younger than the freshness window, ten minutes by default, is decided like a launch and listed in the book's crossings.

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, and the veil page moves NEAR up to second, straight after ZEC.
• 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.

NEAR, the network under the rail

NEAR is a sharded layer one blockchain: the chain is split into shards, each shard produces a chunk of every block, and blocks land well under a second apart (about 0.6 s a block over 1,000 final blocks measured on 2026-09-27, against the one second usually quoted). It is the network whose Intents relay fills the veil: a veil's deposit and its exit both settle through the NEAR Intents contract on NEAR mainnet, whichever chains the assets start and end on. NEAR is the network the rail runs on and nothing more: there is no partnership and no endorsement.

• The RPC endpoints the site reads. https://rpc.mainnet.near.org first and https://free.rpc.fastnear.com when the first does not answer, both public JSON-RPC with no key. Three calls: block with finality final (height, block time, chunk count), gas_price (yoctoNEAR per unit of gas) and view_account on the Intents contract. Answers are cached 30 seconds. When neither endpoint answers, the strip on the home page and on /veil prints NEAR RPC unread and no number, and the age of a block is worked out on every read, so an old block never reads as a fresh one.
• The Intents contract, intents.near. The contract every NEAR Intents order settles through. The site reads its account with view_account, which confirms code is deployed there and gives its code hash. The contract also lists its tokens through mt_tokens, but that list pages past ten thousand token ids, so the asset count on this site is the 1Click list's instead. No volume figure is read, because the NEAR Intents docs publish no volume view.
• The relay. GET /v0/tokens for the asset count (198 on 2026-09-27, Robinhood Chain listed as hood) and four dry quotes into native ETH on Robinhood Chain, ZEC, NEAR, SOL and ETH on Arbitrum, refreshed at most once a minute for everyone through GET /api/rail.
• Funding assets. ZEC first and NEAR second on the veil page, then BTC, SOL, ETH on Arbitrum, ETH on Base, USDC on Solana and every other listed asset. NEAR is nep141:wrap.near, which the relay lists as wNEAR. Its refund address is a NEAR account in either form: a named account ending in .near, or an implicit account of 64 lowercase hex characters. A dry quote of 5 NEAR on 2026-09-27 priced 0.00962 ETH on Robinhood Chain in about 19 s.
• Exit assets. ZEC, NEAR, BTC, SOL, ETH on Arbitrum and USDC on Solana, in that order on the veil page.
• Confidential Intents status. Not live here. The confidential route needs a NEAR Intents partner key and the desk holds none, so /api/rail answers confidential: { available: false, reason: "needs a partner key" } and every quote on this site runs the public route.

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.

After bonding

A Pons coin starts on a bonding curve. When the curve fills, the coin crosses into a Uniswap V4 pool that the Pons factory opens, and from then the pool is where it trades. This site calls that moment the crossing. Every fact below was read on chain on 2026-09-27. The live figures are on the home page and on the desk, from GET /api/crossing.

The four steps

1. The curve fills at 4.2 ETH. A native ETH launch has a supply of 1,000,000,000 and a graduation threshold of 4.2 ETH of real quote. The quote side of getReserves() carries a phantom reserve of 0.4 times the threshold, 1.68 ETH, so the real quote is the reserve less 1.68 ETH and progress is that over 4.2. The threshold is read from graduationThreshold() on the curve, and from word 2 of the TokenLaunched data where that view is missing. The buy that crosses 4.2 ETH is capped and the excess refunded (CurveBuyRefunded).
2. The sweep. Inside that same buy the curve emits CurveCompleted and the factory emits LaunchSwept(token, quote, tokens): 4.2 ETH and 285,714,285.71 tokens, the 2/7 of supply held back since launch, move to the factory. After it the curve reverts buy() and sell() with CurveGraduated() and getReserves() answers 1.68 ETH and 0 tokens. When the sweep fails inside the buy, the curve emits AutoGraduationFailed and anyone can finish it later with graduate(token) on the factory.
3. The pool opens. createGraduatedPool(address token) on the factory, selector 0x2f53ef2f, is permissionless. It reverts WrongGraduationPhase before the sweep and after the pool exists. It initializes the Pons pool at the curve's final price, tick 176998, about 2.058e-8 ETH per token or about 20.58 ETH fully diluted, and emits GraduationTokensPermanentlyLocked and PoolGraduated(token, positionId, tokenAmount, quoteAmount). Bots often bundle it into the crossing transaction. Of 9,592 graduations read, 2,256 opened in the crossing transaction and the rest in a later one, median 9 blocks, longest 73,019 blocks.
4. Liquidity locked forever. One full-range position, ticks -887200 to 887200, holding 4.2 ETH and 204,081,632.65 tokens, is minted straight to the Pons locker, and 81,632,653.06 tokens are locked in the same locker. The locker has no function that moves, decreases or destroys a position. It is not a proxy, it makes no delegatecall, and no position has ever left it.

The Pons pool, and only the Pons pool

The desk finds a coin's Pons pool by computing its key, never by taking the newest pool on the coin:

PoolKey {
  currency0:   0x0000000000000000000000000000000000000000   native ETH, not WETH
  currency1:   the coin
  fee:         0
  tickSpacing: 200
  hooks:       0xe5e702641ea86f4ae6cc3cdaed2b886f976be044   the Pons hook
}
poolId = keccak256(abi.encode(currency0, currency1, fee, tickSpacing, hooks))

$JEVMAXX 0x08e60318b77e4d695f7619bc639ac56c6afe8882, not open yet
  0x4c2c6f0c630526996f589c7244e7161a5357e2fe217160ae76b817f333d483ff
KNOB 0xea7ebc4b6484cf5dd76c82ddb9f507618979fa30, opened at block 62606964, position 2678790
  0x950884392d83850059bc118eee0ffe7bcb9d41fd41502984a06eb5f41f63ed37

For a launch paired with an ERC-20 the coin is currency0 when its address sorts lower. The desk, the quotes and the veil fill native ETH pools only, and say so for the others.

Anyone can open another V4 pool on the same coin, with no hook or any hook and at any fee; fees up to 88% have been seen. The desk never trades one. DexScreener lists a V4 pool under its pool id, so a pair whose address is not the id above is not the Pons pool. The $JEVMAXX V4 pairs listed there on 2026-09-27 were third-party pools with $1 to $5 of liquidity.

The fee after the crossing

The pool's LP fee is 0. The Pons hook's afterSwap takes 1% (hookFeeBps 100, split 30% protocol and 70% creator) plus the launch's creatorTaxBps, on the output side of every swap. $JEVMAXX's creator tax is 200 bps, so a $JEVMAXX swap after the crossing pays 3%. The site reads the creator tax live and prints the rule when it cannot. The curve's snipe tax, 9900 bps at 0 s and 0 by 3 s, applies to curve buys only; the pool has none.

After the crossing, the creator share of every swap fee (2.7 of the 3 points) is distributed to $JEVMAXX holders. The rules, the schedule and every payout are published here before the pool opens. Holders leave out the pool, the Pons locker and the Pons hook.

What the desk does at the crossing

• A crossed coin is scanned, priced, quoted, gated and decided on its Pons pool, with venue uniswap-v4 and pons: { phase, poolId }. Holder concentration leaves out the PoolManager, the Pons hook and the Pons locker.
• WARDEN says where the coin stands: graduated once it has crossed, crossing-open while it is swept with no pool, pons-hook in place of the v4-hook warn, and other-pools when other V4 pools trade it.
• /api/quote answers 409 while the curve is swept and the pool is shut, with that sentence.
• The desk's own book marks a crossed position in the Pons pool and exits it there.

What the veil does at the crossing

• Buys in the pool. A V4 ticket is a Universal Router execute call carrying V4_SWAP for the Pons pool. TAKE_ALL pays whoever sends the transaction, so the veil that signs it is the recipient, and the minimum out is in the calldata.
• Sells in the pool. The coin is approved to Permit2, Permit2 approves the Universal Router with an expiry, and the swap back to ETH carries its own minimum out.
• Opens the pool. When a coin is swept with no pool, the veil can call createGraduatedPool itself and buy in the next transaction.
• Arms the crossing. On a coin still on its curve, arm one capped buy. While the tab stays open the veil reads the factory every 1.5 seconds, and when the crossing lands it opens the pool if nobody has, quotes again, and signs the buy with the minimum out from the fresh quote less your slippage. Arming needs a typed cap and a confirm, fires once, expires after 60 minutes and disarms with one click. Bots often open the pool inside the crossing transaction, so the first fill in the pool is usually theirs. The key never leaves the browser.

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.trade/api/status

GET /api/scout

The launch window, newest first, each with its WARDEN status and a decision when one is cached. A V4 row carries poolId, hooks, fee, tickSpacing, sqrtPriceX96 and liquidity beside the fields every row has; window names the range each of the three sources was read over.

curl -s "https://jevmaxxing.trade/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. A coin in a V4 pool carries a v4 object (pool id, both currencies, fee, tick spacing, hooks, sqrt price, liquidity, price and the ETH at that price) and reads.liquidity says whether StateView answered.

curl -s "https://jevmaxxing.trade/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.trade/api/decide \
  -H 'content-type: application/json' \
  -d '{"token":"0x0000000000000000000000000000000000000000"}'

GET /api/receipts

The public log, newest first.

curl -s "https://jevmaxxing.trade/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.trade/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.trade/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 until the crossing; after it the coin is quoted in its Pons pool, and while the curve is swept with the pool shut the answer is a 409 with that sentence. A V4 coin is quoted through the V4 Quoter and filled through the Universal Router's V4 swap command, at the same 200 bps floor, and the floor is carried by the router's own TAKE_ALL action rather than by this page. The desk fills a V4 pool only out of native ETH: a pool paired against WETH would have to pull WETH through Permit2, so it answers 409 with that sentence unless a V3 pool can fill the same coin, and no route is invented either way. Maximum 5 ETH.

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

GET /api/crossing

The crossing, live: one coin's meter ($JEVMAXX unless ?token= names another), up to twelve native Pons coins that crossed lately with the gap from the sweep to the pool, up to eight coins at half their threshold or more, and the figures over the window read. A read the chain refused is phase unread with its reason, never a zero, and notice says which read came back short. Cached 15 seconds at the edge and rate limited by hashed IP on its own budget.

curl -s https://jevmaxxing.trade/api/crossing

{ "at", "head", "ok",
  "token":  { "address", "symbol", "phase": "curve | swept | pool | unread", "threshold", "realQuote",
              "progress", "toGo", "priceEth", "poolId", "pool", "locked", "fees": { "hookBps", "creatorTaxBps" },
              "reads", "reason" },
  "recent": [ { "token", "symbol", "sweptBlock", "poolBlock", "gapBlocks", "gapSec", "sameTx", "poolId",
                "openPriceEth", "priceEth", "changePct", "positionId", "ageSec", "state": "pool | open-to-anyone" } ],
  "near":   [ { "token", "symbol", "curve", "realQuote", "threshold", "progress", "toGo" } ],
  "stats":  { "fromBlock", "toBlock", "graduations", "sameTxShare", "medianGapBlocks", "medianGapSec", "openNow" },
  "sources", "notice" }

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.trade/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.trade/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.trade/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.trade/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.trade/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.

GET /api/rail

The rail, live. { at, near: { height, finalizedAt, secondsBehind, chunks, gasPriceYocto, contract, ok }, intents: { assets, hoodListed, origins, exits, source, ok }, quotesAt, quotes: [ { origin, amountIn, amountOutEth, timeEstimateSec, route, ok } ], confidential: { available, reason } }. NEAR is read over public RPC and cached 30 seconds; a part that could not be read answers ok: false with a reason and no number. The four quotes are dry, public and priced at most once a minute for every caller together, four per refresh and never more. Rate limited by hashed IP on its own budget, cached 30 seconds at the edge.

curl -s https://jevmaxxing.trade/api/rail

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.

The token is issued. $JEVMAXX launched fair on Pons with no presale and no team allocation; the address on this site, in the contracts table above and on the official account is the only one, and the creator fees pay the Jev and RPC bill and fund 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 V4 PoolManager, where every Initialize and every V4 Swap log the desk reads is emitted.
• Uniswap V4 StateView, for the liquidity and the sqrt price behind every V4 price on this site.
• Universal Router, the contract your wallet calls on a V4 fill, a crossed coin's Pons pool included.
• Pons locker, which holds every crossed coin's liquidity position and has no withdraw function.
• Uniswap V3 factory, for PoolCreated.
• SwapRouter02, the contract your wallet calls on a Uniswap V3 pool.
• 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.

Changelog

• 2026-09-26 The desk: SCOUT, WARDEN, PULSE, LEDGER and FLUX on Robinhood Chain, Jev's typed answers and published receipts.
• 2026-09-26 The veil: a one time snipe wallet made and kept in the browser, funded and exited through NEAR Intents.
• 2026-09-27 Uniswap V4 in SCOUT: V4 pools read from the PoolManager and priced through StateView.
• 2026-09-27 The NEAR rail live on the site: NEAR's final block, the Intents asset list and dry quotes on the home page and on /veil, NEAR second in the veil's asset list.
• 2026-09-27 $JEVMAXX issued at the address in the site config.
• 2026-09-27 The crossing: the desk follows a coin into its Pons pool on Uniswap V4; the crossing board and meter; the veil opens pools and arms for the crossing.