1Claw Now Supports Robinhood Chain

A technical walkthrough of key provisioning, signing, simulation, and guardrails for Robinhood Chain on the Intents API.

Robinhood opened the public mainnet of Robinhood Chain on July 1st, alongside stock tokens that trade 24/7 and can be pledged as collateral across DeFi. Robinhood also has Agentic Trading live for equities and options, with a crypto rollout on the way. Put those two things together and you get retail-accessible instruments, on a public chain, that an AI agent can trade directly, any hour of the day.

We covered the why in our launch post. This one is for the people who want to see the actual requests: how a key gets provisioned, what a signed transaction call looks like, how simulation and guardrails behave, and how the MCP tools map to all of it.

Robinhood Chain, technically

Robinhood Chain is an Arbitrum Orbit Layer 2 that settles to Ethereum and uses Ethereum blobs for data availability. For signing purposes it behaves exactly like the other EVM chains in the registry: same transaction shape, same EIP-1559 fee mechanics, same address format.

Because it is EVM-standard, nothing about how 1Claw talks to it is new. What is new is that it is now in the chain registry, so "chain": "robinhood-chain" is a valid value anywhere a chain parameter is accepted. Guardrails can target it specifically. Transactions broadcast to it. The shorthand robinhood also resolves.

Provisioning a signing key

Robinhood Chain uses the same secp256k1 curve as every other EVM chain. That means a single ethereum signing key works across Ethereum mainnet, Base, Arbitrum, and Robinhood Chain. If your agent already has an Ethereum signing key provisioned, you are done. The same address, the same key, just fund it on Robinhood Chain.

If you are starting fresh, a human provisions the key once. Agents cannot create or rotate their own keys; those endpoints return 403 on purpose.

curl -X POST "https://api.1claw.xyz/v1/agents/$AGENT_ID/signing-keys" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "chain": "ethereum" }'

{
  "id": "a7c3e8f0-1234-4567-89ab-cdef01234567",
  "agent_id": "550e8400-e29b-41d4-a716-446655440000",
  "chain": "ethereum",
  "curve": "secp256k1",
  "public_key": "04a1b2c3d4e5f6...",
  "address": "0x8f3E2a1B9c4D5e6F7a8B9c0D1e2F3a4B5c6D7e8F",
  "key_version": 1,
  "is_active": true,
  "created_at": "2026-07-13T14:02:11Z"
}

The private key goes into the org's __agent-keys vault, encrypted under Cloud KMS. There is no field in this response, or any response, that contains the private key. What you get back is an address. Fund it on Robinhood Chain and the agent can transact.

When the agent submits a transaction with "chain": "robinhood-chain", the system resolves the secp256k1 key automatically. No extra config.

Signing and broadcasting a transaction

The Intents API builds, signs, and broadcasts in a single call. You send an intent, not a raw transaction, so the policy engine has something to evaluate before anything gets signed.

For a native ETH transfer on Robinhood Chain:

curl -X POST "https://api.1claw.xyz/v1/agents/$AGENT_ID/transactions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "robinhood-chain",
    "to": "0x4b2Cd9e8F1a2B3c4D5e6F7a8B9c0D1e2F3a4B5c6",
    "value": "0.05",
    "simulate_first": true
  }'

For an ERC-20 stock token transfer, pass the token contract as token_mint. The server builds the transfer(to, amount) calldata so your agent never constructs raw ABI encoding:

curl -X POST "https://api.1claw.xyz/v1/agents/$AGENT_ID/transactions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "robinhood-chain",
    "to": "0xRecipientAddress...",
    "value": "25.0",
    "token_mint": "0xStockTokenContract...",
    "token_decimals": 18,
    "simulate_first": true
  }'

A successful call returns once the transaction is broadcast, not once it is mined:

{
  "id": "d4e5f6a7-b8c9-0123-4567-89abcdef0123",
  "agent_id": "550e8400-e29b-41d4-a716-446655440000",
  "chain": "robinhood-chain",
  "chain_id": 4663,
  "to": "0xRecipientAddress...",
  "value_wei": "25000000000000000000",
  "status": "broadcast",
  "tx_hash": "0x7e1c9f...4a2b",
  "simulation_status": "success",
  "created_at": "2026-07-13T14:03:44Z"
}

That is the entire surface the agent sees. No private key, no signature bytes. A hash it can use to poll status or hand back to the user.

What simulation catches

With simulate_first: true, the request runs against current chain state via Tenderly before anything is signed. If the call would revert, for example the agent tries to move more of a stock token than the wallet holds, you get a 422 and nothing is signed or broadcast:

HTTP 422 Unprocessable Entity

{
  "id": "d4e5f6a7-b8c9-0123-4567-89abcdef0123",
  "chain": "robinhood-chain",
  "chain_id": 4663,
  "status": "simulation_failed",
  "simulation_status": "reverted",
  "error_message": "Simulation reverted: transfer amount exceeds balance",
  "tx_hash": null,
  "created_at": "2026-07-13T14:03:44Z"
}

This is a cheap check and it is worth defaulting to true for anything a model is constructing dynamically. Reverts cost gas on most chains. Here they cost nothing, because they never reach the point of being signed.

Guardrails, per chain

Guardrails are policy, evaluated before the HSM signs anything. They live on the agent record and can be set globally or per chain, so a Robinhood Chain wallet does not inherit the limits you configured for a DeFi wallet on Ethereum mainnet.

Set per-chain guardrails via the agent update endpoint:

curl -X PATCH "https://api.1claw.xyz/v1/agents/$AGENT_ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "per_chain_guardrails": {
      "robinhood-chain": {
        "max_value": "0.5",
        "daily_limit": "5.0",
        "to_allowlist": [
          "0xStockTokenContract...",
          "0xSettlementContract..."
        ]
      }
    }
  }'

Values are in native chain units (ETH on Robinhood Chain). You can also set global guardrails that apply to all chains: tx_to_allowlist, tx_max_value_eth, tx_daily_limit_eth, tx_allowed_chains. Per-chain rules override global rules; the strictest of both wins.

If a request violates any of these, for example the destination is not on the allowlist, or the daily cap has been spent, the policy engine rejects it before the vault is involved:

HTTP 403 Forbidden

{
  "detail": "Destination address is not in this agent's tx_to_allowlist"
}

Note what is consistent across both failure modes: the transaction is never signed. A bad simulation and a denied guardrail both stop the request at the same point, before signing. The agent can misjudge a trade all it wants; it cannot get a signature for something outside policy.

Using it from an MCP agent

If your agent runs through the 1Claw MCP server rather than calling the REST API directly, the same operations map to tools:

{
  "tool": "submit_transaction",
  "arguments": {
    "chain": "robinhood-chain",
    "to": "0xStockTokenContract...",
    "value": "25.0",
    "token_mint": "0xStockTokenContract...",
    "token_decimals": 18,
    "simulate_first": true
  }
}

provision_signing_key, submit_transaction, simulate_transaction, and sign_transaction (for bring-your-own-RPC flows where you broadcast yourself) all accept "chain": "robinhood-chain" the same way they accept base or ethereum. If your agent already trades on another EVM chain through 1Claw, pointing it at Robinhood Chain is a one-field change, not a new integration.

The request path, end to end

For a signed transaction, the full path is:

1. Auth — the agent's ocv_ API key is exchanged for a short-lived JWT via token exchange. The SDK and MCP client handle this automatically and refresh before expiry.
2. Policy engine— the request is checked against guardrails for that chain: allowlist, spend cap, daily limit. Any failure stops here.
3. Simulation(when enabled) — the transaction runs against current state via Tenderly. A revert stops here.
4. HSM vault— the key is decrypted only inside the HSM boundary, signs the transaction, and the plaintext key never leaves.
5. Broadcast— the signed transaction is submitted to Robinhood Chain via the configured RPC endpoint.
6. Audit log— the call is recorded: agent ID, action, target, allow or deny, resulting tx hash.

Every step from 2 onward runs the same way regardless of what the calling model decided to do. That is the property that matters for agentic trading specifically: strategy mistakes are bounded by policy, and policy is enforced by something that is not the model.

Getting started

# Provision an ethereum signing key (works for all EVM chains)
curl -X POST "https://api.1claw.xyz/v1/agents/$AGENT_ID/signing-keys" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "chain": "ethereum" }'

# Set per-chain guardrails for Robinhood Chain before funding the wallet
curl -X PATCH "https://api.1claw.xyz/v1/agents/$AGENT_ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tx_allowed_chains": ["robinhood-chain"],
    "per_chain_guardrails": {
      "robinhood-chain": {
        "max_value": "0.5",
        "daily_limit": "5.0"
      }
    }
  }'

The testnet identifier robinhood-testnet (chain ID 46630) works the same way if you want to run this against Robinhood Chain's public testnet before moving to mainnet. Full endpoint reference, error codes, and the complete guardrails schema are in the Intents API docs. If you are setting up your first agent, the quickstart covers vault and agent creation from zero.

Stock tokens trading onchain, 24/7, through an agent your model is driving, is a genuinely new kind of account to secure. The API surface above is small on purpose: provision a key, sign through policy, simulate before you commit gas, log everything. The agent gets to trade. It does not get to hold the key.