QUICKTXN / DOCUMENTATION

Regional endpoints

Choose an available QuickTxn region based on measured round-trip behavior from your application.

Availability states

Existing means the legacy customer service. Planned means the location is in the expansion footprint; it is not a usable endpoint. Newly isolated QuickTxn endpoints will be published after deployment and validation. This table is release information, not a real-time health dashboard.

Connection reuse

Use an HTTP client with connection pooling and keepalive. Send HTTPS JSON-RPC POSTs to the endpoint root. eth_chainId is a small public request suitable for connection checks. Customer QUIC support is not published.

Failover without changing products

Keep an ordered list of QuickTxn URLs assigned to your account. Check chain ID before using each one. On transient failure, query the original transaction hash on the chain RPC and, if appropriate, retry the identical signed bytes with bounded backoff on another confirmed QuickTxn endpoint. Do not silently fall back to a Sherwood Express hostname.

Repeated signed bytes retain the same transaction hash. Upstreams may return the hash, an already-known error, or a nonce error. There is no promise of one network submission. Do not sign a new nonce or replacement transaction solely because the HTTP response was lost.

Executable Node failover example

Download failover.mjs. Use Node 22 or later and install its pinned parser with npm install --save-exact [email protected]. Import this module in your server application; it does not run on download or import and never signs or logs. The website never receives your key or signed bytes.

import { submitWithFailover } from "./failover.mjs";

// Values come from your existing secure application configuration and wallet.
// assignedQuickTxnUrls contains ONLY URLs confirmed available for your account.
const outcome = await submitWithFailover({
  endpoints: assignedQuickTxnUrls,
  receiptRpc: robinhoodChainRpcUrl,
  apiKey: quickTxnApiKey,
  signedTransaction: alreadySignedType2Transaction,
});
// Handle outcome.status explicitly. Do not log request inputs.

The example validates the actual signed type-2 transaction and chain 4663 with ethers, computes its original transaction hash, and checks chain discovery before sending credentials. All configured submission URLs must be exact regional *.rh.quicktxn.com HTTPS roots; no redirects, custom Host headers, Sherwood fallback, or discovery of planned regions. Only use endpoint lists support has assigned to your account.

It tries each of at most nine distinct endpoints once, with a 10-second per-request timeout, a 60-second total deadline, a 64 KiB response cap, and 1.2–1.4 seconds between regions. These are conservative example limits, not service guarantees or a throughput allowance. Transient transport errors, HTTP 429, and HTTP 5xx trigger a receipt lookup; only a null receipt allows the identical bytes to move to the next endpoint. Receipt lookup failure stops the attempt. A null receipt never proves the original submission failed.

HTTP 4xx other than 429, unexpected chain discovery, JSON-RPC errors (including already-known and nonce errors), malformed replies, and mismatched result hashes stop automatic submission. RPC errors are reconciled against the original hash; the example does not parse unstable error messages. A second edge may forward the same transaction again: deduplication is not a cross-region guarantee. The client never signs a replacement or changes a nonce.

Local fixture tests execute this downloadable module against simulated QuickTxn edges and chain RPC responses, including ambiguous acceptance, duplicates, wrong product/chain, refusal and secret echoes. They do not prove live regional failover, sequencer inclusion, or funded execution; those remain rollout gates.

Oregon cutover

Columbus customers will receive a verified Columbus endpoint before any legacy Oregon hostname change. Actual Oregon is being prepared under ore-1.rh.quicktxn.com; it remains a canary until announced as available. The existing alias stays in Columbus until a separate customer cutover is agreed. Do not preconfigure a planned hostname as a working fallback.