> For the complete documentation index, see [llms.txt](https://node1.gitbook.io/node1-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://node1.gitbook.io/node1-docs/robinhood/robinhood-landing.md). # Robinhood Landing Service ## Introduction Use Node1 Landing Service to submit signed transactions to Robinhood Chain through the Node1 endpoints, authenticated with your Account UUID. Use this service to submit transactions. To receive the sequencer data stream, use the separate Robinhood Feed service. [Read the Feed documentation →](/node1-docs/robinhood/robinhood-feed.md) ## Landing benchmark **66% win rate from Frankfurt; 61% from Ohio.** Each location completed 100 on-chain races comparing two Node1 endpoints with three direct sequencer endpoints. [View results and methodology →](/node1-docs/robinhood/robinhood-landing/robinhood-landing-benchmark.md) ## Endpoint & authentication ### Ohio 2B · Transaction endpoint ``` https://robinhood-ohio-2b.node1.me ``` ### Ohio 2C · Transaction endpoint ``` https://robinhood-ohio-2c.node1.me ``` ### SFO3 · Transaction endpoint ``` https://robinhood-sfo3.node1.me ``` This is the Node1 transaction submission API, not a payment address or an upstream Robinhood node address. 1. Sign in to the [Node1 Dashboard](https://node1.me/dashboard) and copy your Account UUID from the page header. 2. Ohio 2B, Ohio 2C, and SFO3 support JSON-RPC single transactions, plain-text single transactions, and batches. Use any of the addresses above with the same Account UUID. Each node counts your quota independently. 3. For JSON-RPC submissions, send HTTPS requests to the endpoint root path, with your Account UUID in the Authorization header: ``` Authorization: Bearer ``` Your UUID authorizes use of your account’s sending quota. Keep it private and use the UUID belonging to the account with your Landing subscription. ## Plans & rate limits These limits apply to the updated nodes, separately to each Account UUID on each node. Connections using the same UUID share quota. Opening more connections or changing request formats does not increase it. | Plan | Counting unit | Limit | | ----------------------- | ----------------------------------------------------- | --------------------------------------------------------------------------------------- | | Free single transaction | Requests shared by JSON-RPC raw and plain text | At most 1 in any 3 seconds | | Free batch | Separate batch request count | At most 1 in any 3 seconds; 1–10 transactions per batch | | Standard paid | Transactions shared across raw, plain text, and batch | At most 30 in any 1 second; credits refill at 10 transactions/second, up to 300 credits | A paid single-transaction request consumes 1 credit; a batch containing 10 transactions consumes 10, not 1. The entire batch must fit both the rolling one-second allowance and the available credits. Otherwise, the whole batch receives HTTP 429 and is not split for sending. For example, after 20 single transactions within the same rolling second, there is room for at most one more 10-transaction batch. The 300-credit capacity allows short bursts, not 300 simultaneous submissions: the 30 TPS ceiling always applies. Sustained sending is constrained by the 10-credit/second refill. There is no additional per-minute or five-minute hard quota. Sliding windows do not reset at clock-second boundaries. **Need higher TPS?** [**Contact support**](/node1-docs/support.md) **for a custom TPS allowance tailored to your requirements.** Accounts with a separately configured TPS allowance use their agreed limit. All three formats still share transaction-based counting, without the standard paid account's 10-credit/second refill and 300-credit capacity. Repeated valid submissions still consume quota, including repeated transactions within a batch. Deduplication does not refund credits; nodes count independently. IP-level request limits and service capacity also apply. On HTTP 429, follow `Retry-After` and wait for quota to recover instead of immediately retrying in a loop. Landing and Feed subscriptions are independent. A paid Feed subscription does not grant paid Landing quota. When a standard Landing subscription expires, the account returns to free quota. ## Submission acknowledgement Updated nodes return HTTP 202 as soon as local validation, authentication, rate checks, and queue admission complete. They do not wait for a sequencer response or a chain receipt. This acknowledges local acceptance, not completed forwarding, upstream acceptance, or block inclusion. Batch submissions also persist a local receive record before queue admission. See [Responses & Retries](/node1-docs/robinhood/robinhood-landing/robinhood-responses.md). During migration, DNS caches or existing connections may still reach older nodes. See [Legacy responses during migration](/node1-docs/robinhood/robinhood-landing/robinhood-responses.md) for how to recognize their responses. ## Keep-alive connections The server closes a connection after about 60 seconds of inactivity, not every 60 seconds regardless of traffic. A bot can send `GET /ping` every 20–30 seconds over the same HTTPS connection used for transactions. It requires no Account UUID, returns HTTP 200, and consumes no account transaction quota. IP-level request limits still apply. Reuse the same HTTP/1.1 connection for heartbeats and transactions. If your pool has multiple connections, each connection you want to keep alive needs traffic. Opening a separate connection for a heartbeat does not keep another connection alive. Fully read responses and reconnect when a connection closes; heartbeats cannot guarantee that a connection will never be interrupted. ## Integration guides * [Send Transaction](/node1-docs/robinhood/robinhood-landing/robinhood-send-transaction.md) * [Send Plaintext Transaction](/node1-docs/robinhood/robinhood-landing/robinhood-send-plaintext.md) * [Batch Transactions](/node1-docs/robinhood/robinhood-landing/robinhood-batch.md) * [Responses & Retries](/node1-docs/robinhood/robinhood-landing/robinhood-responses.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://node1.gitbook.io/node1-docs/robinhood/robinhood-landing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.