Run a provider

Connect a blockchain node you operate to Direct RPC and charge for the requests it serves. The Direct client forwards requests to your node, checks that each request is paid for, and claims your earnings on chain.

This guide takes you through the first offering. Once it is enabled, Checking your provider's status explains qualification and ongoing service checks, and Tracking earnings explains how you are paid.

Prepare your node

Run Direct on a machine that can reach your node's HTTP JSON-RPC endpoint. If both run on the same machine, the upstream might be http://127.0.0.1:8545. Subscriptions also require access to the node's WebSocket endpoint.

Before configuring Direct, check the node itself:

curl -s http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '[{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]},{"jsonrpc":"2.0","id":2,"method":"eth_syncing","params":[]}]'

Confirm that the chain ID matches the network you intend to offer and that the node has finished syncing. For Ethereum, eth_syncing returns false when the node is not syncing; also check that its latest block follows the network head. A reachable node is not necessarily an up-to-date one.

The node must meet the requirements below before it can serve consumer traffic. The client detects additional capabilities from the upstream; Direct verifies them before consumers can select the offering for that work. Keep the node and Direct running while providing access, and allow the client's required outbound network traffic; see Network requirements.

Meet the service requirements

Your node configuration must support the requirements below, either directly or through the adaptations performed by the provider's Direct client. Advertising a lower price does not relax these requirements.

Block-hash state reads

Enable EIP-1898 support for the state methods it covers, including canonical-chain checking through requireCanonical. The upstream must honor the selected block hash rather than substitute its latest state. This is required for participation; inspect the block-selector tests before enabling the offering.

Recent and archive state

Keep the node synchronized and able to serve the network head and its 128 preceding blocks. The client detects archive coverage only when state is available back to genesis; proof and tracing support are checked separately. Review failed tests before enabling the offering.

Qualifying providers explains baseline requirements and ongoing checks. Reference-block availability covers temporary exclusions when a node falls behind.

Full chain history

To qualify for full chain history, retain blocks, transactions, receipts, logs, fee history, and applicable uncle data back to genesis. Enable the indexes needed to find old transactions and receipts by hash. Direct checks this as one bundle; retaining only old block headers or passing a single old-block query does not qualify.

Archive state and full chain history are independent. You can qualify for either or both; lacking one does not prevent recent RPC participation. Run Test connection and review the history checks before advertising coverage. Verify the advertised service describes the checks and historical data defines the consumer contract.

Block receipts and access lists

Run Test connection to detect eth_getBlockReceipts and eth_createAccessList support separately. These are optional capabilities; failing either does not prevent qualification for ordinary RPC service.

For block receipts, check that all receipts for the target block can be returned within Direct's whole-request budgets. For access lists, enable the supported upstream API and verify block selection and simulation limits. Review failed tests before advertising either capability. Optional capability checks describes the verification; method limits define the consumer contract.

Network-specific methods are detected only where they apply. You do not need to enable Ethereum blob-fee functionality on a chain that does not define that API.

Debug and trace capabilities

Enable the relevant upstream APIs and run Test connection. The client tests the complete tracing groups, including required methods, tracers, and options. Enabling a namespace or passing one transaction trace is not sufficient to advertise the whole group.

Review failed methods and output checks before enabling tracing. A group qualifies only when every required combination works. If a check fails, correct API exposure, tracer support, retained state, or trace indexing as indicated, then repeat the tests. Direct-operated peers verify the advertised group before consumers can select it.

Recent tracing does not require a full archive node. Historical simulations require archive state and the relevant tracing group; historical transaction or block replay also requires full chain history. When you advertise both, checks exercise historical tracing as well as recent traces; no separate archive-tracing flag is needed. Recent versus historical tracing explains the dependency.

Trace and debug limits

Configure the upstream and Direct client to meet Direct's tracing limits. Capability checks cover the required methods and formats under the same deadlines, output ceilings, simulation budgets, and method-specific limits offered to consumers.

A shorter upstream timeout or smaller output limit must be accommodated without changing the result; otherwise the affected tracing group cannot qualify. Keep internal work inside the original request budget, preserve sequential simulation state, and return explicit errors rather than truncated traces.

Qualification uses representative workloads, not a promise that every possible trace will complete. A request correctly rejected at Direct's published limit is different from repeatedly failing supported workloads below it. Account for whole-block traces and multi-call simulations when setting the offering's price: their internal work is still part of one consumer request.

Upstream log-range limits

Configure the node to accept at least 10,000 blocks per eth_getLogs query where possible. This avoids extra upstream calls, but a smaller native range does not disqualify the node by itself.

Internal splitting remains one billable request, so account for the extra upstream work when setting your price. How upstream log limits are accommodated explains splitting, result assembly, and failure handling.

Add an offering

Start the RPC client with direct rpc, then open Marketplace › Provide and select Add offering.

Setting	What to enter
Network	The blockchain and network your node serves
HTTP upstream	The node's JSON-RPC URL, reachable from Direct
WebSocket upstream	The node's subscription URL, if offering subscriptions
Capabilities	Detected archive-state, full-chain-history, historical proof, block-receipt, access-list, tracing, and applicable network-specific support
Price	Your price per request, displayed in USDC

For example, an Ethereum node on the same machine can use http://127.0.0.1:8545 for ordinary requests and ws://127.0.0.1:8546 for subscriptions, if those are the ports configured on the node.

Review the detected capabilities before enabling the offering. Selecting a capability does not override failed detection or qualification checks.

Test the upstream

Select Test connection before enabling the offering. Confirm the detected chain and inspect any failed capability tests. If a test fails, check the upstream from the machine running Direct, including any credentials or network restrictions on the node.

Correct the advertised capabilities or the node configuration before continuing. Saving an offering does not make an unsupported capability available.

Enable the offering

Select Enable to submit the offering for verification. Its status changes to Checking while Direct repeatedly tests the advertised service. It is announced to consumers only after qualification completes.

You can leave Direct running during this period. Checking your provider's status explains how to follow progress and resolve failed checks.

Confirm it is serving

When the offering becomes Active, inspect its request count and connected consumers in Marketplace › Provide. Availability does not guarantee immediate traffic: consumers also consider price, capabilities, and observed performance.

Requests arrive at your upstream as ordinary JSON-RPC, so your node does not need Direct-specific protocol support. Keep its normal service monitoring in place alongside the provider view.

Where earnings go

Your earnings are claimed from consumers' payment channels on chain and paid to your provider's address on Base, with Direct's fee deducted by the contract. Tracking earnings explains the earnings view and claims.