Set up Ethereum, Base, and Arbitrum RPC with an AI agent

Fetch the public capabilities and onboarding documents before provisioning. These requests need no SolidRPC credential and authorize no payment:

curl --fail-with-body --silent --show-error \
  https://api.solidrpc.io/agent/v1/capabilities
curl --fail-with-body --silent --show-error \
  https://api.solidrpc.io/agent/v1/onboarding

Inspect the response body as well as HTTP status. Confirm the credential model, current terms, payment network, asset, and minimum funding amount. If the API returns feature_disabled, an error, or HTML instead of the documented JSON, stop and report that access could not be established. Do not proceed from a cached guide.

For discovery across the product, llms.txt links the public documentation and catalogs. Use the live API for current setup terms. A public guide is evidence of a documented flow, not proof that an account has been created or funded.

For a new account, an agent can follow the public onboarding guide to provision a prepaid account using the owner's permanent email. The owner must approve account creation and the applicable terms. Provisioning alone does not activate operational account control. A new account begins with a restricted management credential and becomes eligible for RPC keys only after funding settles and the credential is rotated.

If you already have an eligible paid account, create a management credential in the dashboard's Agent access settings and choose only the permissions the agent needs. Free accounts cannot delegate control. An owner can claim a newly agent-created account later to get dashboard login, but that claim is not a prerequisite for funding, key creation, or RPC requests. The public onboarding guide describes this optional owner login path.

The agent should fetch the current prepaid terms and general Terms of Service linked from the onboarding response, then present the exact terms and intended account email for owner approval. The public flow uses a wallet-signed budget with two independent ceilings: the amount that may be transferred for funding and the amount of RPC credit that may be consumed. The owner must approve both values before signing. A management token alone cannot authorize or raise the budget.

The current production path funds prepaid access with USDC on Base through an x402 payment challenge. The onboarding response specifies the current minimum, payment network, asset, and tax behavior. Check those fields immediately before funding. The signer should verify the displayed service, chain, amounts, and terms hash against the owner's approval. Keep wallet keys outside the agent's chat and outside the repository. This step authorizes a payment for RPC credit, not arbitrary onchain transactions by the agent.

As checked on October 29, 2026, capabilities advertise a minimum funding amount of 100 cents and live USDC payments on Base. That amount is a funding minimum, not a monthly subscription price. Read the actual quote for payment, tax, and resulting RPC credit. Do not assume payment on Base restricts RPC reads to Base.

Create a funding intent with an idempotency key that is saved before the request. The response quotes the payment and any tax treatment. Review the quote against the approved payment ceiling. When the API returns an x402 payment requirement, sign the exact advertised requirement with the authorized wallet and save the payment proof before sending it. Use the same funding intent and proof if a response is lost.

Payment submission and settlement are separate states. Read the original funding intent until it reports SETTLED. A pending or missing HTTP response is not permission to create another payment. The public onboarding recovery instructions specify how to resume quoted, submitted, and settled intents. If an earlier submission expires without a clear outcome, stop and reconcile it before asking the owner to authorize another payment.

After the original payment reports SETTLED, rotate the restricted provisioning credential. Save the replacement privately and confirm that it has operational access before retiring the old credential. Funding by itself does not expand the old token's permissions. A lost rotation response deserves review before another rotation, since a new call can issue another credential.

The replacement sa_ token belongs only on the agent management API as a Bearer token. Use it to create a separate ak_ RPC key with a stable idempotency key. Save that key privately, then get the desired chain's URL from the management API's network list. Do not put either secret into a prompt, source file, or public issue. The management token cannot make RPC calls, and the RPC key does not manage the account. The credential safety guide explains why this separation matters.

With the returned RPC URL and the ak_ key, make a read-only eth_chainId request over HTTPS. Confirm that the result matches the intended network before running other methods. Then test a method your application actually needs and check that the public network catalog advertises its family on that chain. An archive label alone does not establish that every trace method is available.

Restart the agent in a fresh session and verify it can read its billing and usage state with the saved operational credential without opening the payment wallet again. Keep the wallet and management credential available only to the workflow that needs them. Prepaid agent access currently uses HTTPS JSON-RPC, not WebSocket. If the application needs WebSocket or a different commercial plan, check the current eligibility and transport documentation before designing around it.

Use the RPC URL template returned by the authenticated network list and insert the RPC key privately. Verify these identities before starting application work:

• Ethereum mainnet: chain ID 1, expected eth_chainId result 0x1.
• Base mainnet: chain ID 8453, expected result 0x2105.
• Arbitrum One: chain ID 42161, expected result 0xa4b1.

Send eth_chainId and eth_blockNumber to each requested network. That gives six small read-only checks, not a throughput or history benchmark. Record each result, timestamp, and JSON-RPC error if present. Then test the actual balance, log, or historical call the application needs.

A useful completion record says whether provisioning, funding settlement, credential rotation, key creation, and all requested chain checks succeeded. If only discovery succeeded, report discovery. If payment is pending, report pending. Never label an unsigned quote or a testnet payment as purchased production access.

1. Read current capabilities, onboarding instructions, and both linked terms documents.
2. Get owner approval for the account email, terms, payment ceiling, and RPC usage ceiling.
3. Store the restricted management credential privately before provisioning.
4. Sign the exact budget challenge with an authorized wallet, without revealing its private key.
5. Save funding and payment retry identities, then pay the quoted intent once.
6. Wait for SETTLED, rotate the credential, and retire the old one only after saving the replacement.
7. Create a separate RPC key, select the network from the current catalog, and verify eth_chainId.
8. Test a fresh session, usage visibility, revocation, and the specific RPC methods the product needs.

The resumable public example illustrates this path. Review any example code and its live-payment settings before running it. The agent can carry out the mechanics, while the owner retains approval of terms, budget, wallet use, and the application's transaction policy.