DEV Community

Den
Den

Posted on

Building Multi-Chain Support for Ironclaw

#ai #web3 #blockchain

"I'd like to send 0.005 ETH to my friend 0x1234... on Sepolia. My NEAR address is xxxx.testnet and the derivation path is the string ethereum-0."

That was the prompt I typed into Ironclaw last week. The agent derived a Sepolia address it had never seen before, looked up gas prices and a nonce, built the transaction, asked a contract on NEAR to sign it, and broadcasted the result. Just 10 seconds later it handed me an Etherscan link.

That single transfer was the end of a project to get Ironclaw signing transactions on any chain. Here's how we built it, in two parts.

What's Ironclaw?

For readers who haven't met it - IronClaw is OpenClaw inspired implementation in Rust focused on privacy and security. It runs on your own machine, talks to whichever language model you point it at, and remembers what you tell it across sessions.

Teaching the agent to use a NEAR account

The plan was multi-chain support from day one: we wanted Ironclaw to send a transaction on any chain its user cared about. But the route to "any chain" ran through NEAR specifically, because of a contract on NEAR called the chain-signatures MPC contract — more on that in a moment. To use that contract, the agent would first need to be able to send transactions from the user's NEAR account.

So the first milestone was narrower - full NEAR-account control. Get that working, and we'd have everything we needed to start on the rest.

The first attempt was the obvious one - build a NEAR-signing tool. Compile it to WebAssembly, plug it into Ironclaw, let the agent call it. We got partway through before hitting the wall. Ironclaw's tool sandbox is intentionally restrictive about secrets, a tool can ask whether a credential exists, but never read it. Private keys included. A signer-as-a-tool was a non-starter.

The second attempt sat at a different layer. Instead of building a signer ourselves, we wrote a skill that taught the agent how to drive near-cli-rs, the user's existing command-line tool for NEAR, from the shell. Shell access in Ironclaw is opt-in and off by default; you launch the agent with ALLOW_LOCAL_TOOLS=true ironclaw to enable it. The skill then describes the surface of near-cli-rs to the agent, which subcommand maps to which intent, what arguments to compose, how to read the output back.

That worked. The agent could now turn a sentence like "send 0.5 NEAR to bob.testnet" into the right near-cli-rs invocation and run it. Milestone reached — and although NEAR-account control was useful in its own right, its real importance was as the foundation for what came next.

Going multi-chain via NEAR MPC

What is MPC?

NEAR runs an MPC chain-signatures contract at v1.signer-prod.testnet, hand it a payload and a (account, path) pair, and it returns a signature, produced by a key that's derived deterministically from those two inputs. Same NEAR account, infinite addresses on every chain you know how to derive for Ethereum, Bitcoin, Solana, all from the one NEAR identity.

The architecture

A small Rust WASM tool (near-tool) with a set of deterministic actions, plus a skill (MPC_SKILL.md) that teaches the agent how to use them, plus the near-cli-rs shell command plumbing from Step One. The tool handles the chain-specific encoding. The skill orchestrates the sequence. near-cli-rs makes the actual MPC contract call.

When I sent the prompt from the beginning, the agent walked through roughly this sequence:

NEAR account + path
        │
        ▼
1.  get_derived_pubkey                ──►  Sepolia address
        │                                  (and BTC/Solana too)
        ▼
2.  evm_parse_value                   ──►  amount in wei (hex)
        │
        ▼
3.  evm_get_nonce                     ──►  pending nonce
        │
        ▼
4.  evm_get_gas_price                 ──►  base gas price
        │
        ▼
5.  evm_get_priority_fee_wei_per_gas  ──►  priority fee
        │                                  + max fee per gas
        ▼
6.  evm_estimate_gas                  ──►  gas limit (20% buffer)
        │
        ▼
7.  evm_build_transfer_mpc_payload    ──►  unsigned tx
        │                                  + sighash payload
        ▼
8.  near-cli-rs sign payload via MPC  ──►  (big_r, s, recovery_id)
        │
        ▼
9.  evm_attach_mpc_signature_to_tx    ──►  signed tx + tx_hash
        │
        ▼
10. evm_send_signed_tx                ──►  Etherscan link
Enter fullscreen mode Exit fullscreen mode

A few build choices worth pointing at.

The agent narrates every step. The nonce, the gas estimate, the unsigned transaction, the raw signature — they all show up in the chat. It was tempting to bundle the prelude into one big "build me a transaction" call, but legible failure modes were worth more than the cleaner-looking flow.

That's also why steps 2 through 6 are separate actions instead of one. When something breaks, a flaky RPC endpoint, an underestimated gas limit, the agent knows exactly which piece broke, can show the user a sensible cost before committing, and can retry just the part that needs retrying.

What's next

Bitcoin and Solana already work end-to-end through the same arc, but their flows are coarser than EVM's — fewer intermediate steps, fewer natural seams to surface errors. The next push is to bring them up to the same level of granularity: small actions for fee estimation, UTXO selection, blockhash fetching, and so on.

Additional resources

Top comments (0)