Intents API for DeFi automation

Autonomous trading agent
key management

Your trading bot needs to sign hundreds of transactions per day across multiple chains. It doesn't need to hold the private key. 1claw Intents API handles signing inside a TEE with Tenderly simulation, atomic nonce management, and configurable guardrails.

Talk to us about IntentsIntents API overview
The status quo

How trading bots manage keys today

Most DeFi trading bots — arbitrage, MEV, rebalancers, yield optimizers — use one of three patterns for private key management. All of them have serious drawbacks for production systems managing meaningful capital.

1. Environment variables

The most common pattern: PRIVATE_KEY=0x... in .env or container config. Simple, but the key is in plaintext on disk, in process memory, in Docker layer cache, and in CI/CD logs. A single compromised dependency can exfiltrate it. No guardrails — the bot can sign anything, to any address, for any amount.

2. Centralized signing services

Services like Fireblocks and institutional custody solutions keep keys in HSM but require manual approval workflows designed for humans, not high-frequency bots. Latency is measured in seconds, not milliseconds. Pricing is enterprise-only. And you're trusting a single vendor with all your keys — a centralization risk for decentralized protocols.

3. Hot wallets with multisig

Some teams split keys across a multisig (Gnosis Safe) and have the bot control one signer. This adds latency for every transaction (on-chain confirmation for each signature), doesn't prevent the bot's key from being compromised, and makes high-frequency strategies impractical.

Built for DeFi speed

How 1claw Intents API works for trading

Your bot submits a transaction intent. 1claw handles the rest — simulation, signing, nonce management, and broadcast — all inside the TEE.

trading-bot.ts — submit intentkey in TEE
// Submit a swap intent to Uniswap on Base
const tx = await client.agents.submitTransaction(
  agentId,
  {
    to: "0x2626664c2603...",
    data: swapCalldata,
    value: "0.1",
    chain: "base",
    max_fee_per_gas: "30000000000",
    max_priority_fee_per_gas: "1500000000",
    simulate_first: true
  }
);

// Response:
// { status: "broadcast",
//   tx_hash: "0xabc...",
//   simulation_status: "success",
//   gas_used: 152847 }

What happens under the hood

  • 1
    Guardrails validated. The handler checks tx_to_allowlist, tx_max_value_eth, tx_daily_limit_eth, and tx_allowed_chains. Violations return 403.
  • 2
    Tenderly simulation. If simulate_first is true, the transaction is simulated against Tenderly. Reverted simulations are recorded and never signed.
  • 3
    Nonce reserved atomically. Server-side nonce serialization via SELECT FOR UPDATE on the nonce_tracker table. No nonce conflicts, even with concurrent requests.
  • 4
    Signed in TEE. The private key is decrypted from Cloud KMS inside TEE memory, used for secp256k1 signing (EIP-1559 Type 2 or legacy), and immediately dropped.
  • 5
    Broadcast via RPC. The signed transaction is sent via eth_sendRawTransaction to the chain's configured RPC. Status, tx hash, and simulation results are returned.

Built for production trading

Every feature a DeFi bot needs, without the key management headache.

109+ EVM chains

Ethereum, Base, Arbitrum, Optimism, Polygon, and every major L2. Chain registry is admin-configurable. Any Tenderly-supported chain works.

EIP-1559 Type 2

Full support for max_fee_per_gas and max_priority_fee_per_gas. Legacy signing as fallback. Your bot controls gas strategy.

Atomic nonce management

Server-side nonce serialization per (agent, chain, address). SELECT FOR UPDATE prevents races between concurrent transactions.

Tenderly simulation

Single and bundle simulation. Gas estimation, balance changes, revert reasons, and dashboard URL in the response.

Idempotency keys

Optional Idempotency-Key header prevents double-signing on retries. Duplicate requests return cached responses for 24h.

Signing key path control

Override the default signing key path per request. Restricted to keys/*, wallets/*, or agents/{id}/keys/* to prevent path traversal.

Works with any language

The Intents API is a REST endpoint. Use the TypeScript SDK, the MCP server, the CLI, or raw HTTP. Your bot authenticates with an agent API key and submits transaction intents as JSON. The response includes the signed transaction hash, simulation results, and broadcast status.

  • TypeScript SDK: client.agents.submitTransaction()
  • MCP server: submit_transaction tool
  • CLI: 1claw agent tx submit
  • REST: POST /v1/agents/:id/transactions
curl — submit transaction
curl -X POST \
  https://api.1claw.xyz/v1/agents/$AGENT_ID/transactions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "0x2626664c2603...",
    "data": "0xa9059cbb...",
    "value": "0.1",
    "chain": "base",
    "simulate_first": true
  }'
Enterprise DeFi infrastructure

Ship your trading bot without the key risk

Whether you're building an arbitrage bot, a yield optimizer, or a rebalancing agent — 1claw Intents API gives you production-grade signing infrastructure. TEE isolation, Tenderly simulation, nonce management, and guardrails out of the box.

Talk to us about IntentsRead the Intents docs

New to 1claw? Start free — 3 vaults, 2 agents, 1,000 requests/mo →

Intents API available on Business and Enterprise plans.