Agents can sign Bitcoin transactions. They cannot tell you their cost basis. That is half a stack.
The agent wallet space is moving fast. Nunchuk just shipped the tooling for bounded-authority agent wallets: a CLI plus an agent-skills package that lets any LLM-driven agent hold a key inside a multisig with hard policy limits. It is a clean answer to the question "how do you let an agent spend bitcoin within bounds you define." But execution is only one half of the problem. If your agent can spend, you need to know what it spent, what it cost, and what your books say about it. The answer is a descriptor.
The Pattern: Bounded Authority on One Side, Audit Trail on the Other
The setup is a 2-of-3 multisig wallet. The agent holds one key. You hold one key. Nunchuk's platform key holds the third, and acts as a policy co-signer.
A 2-of-3 means every spend needs two signatures. Set a daily spending limit in fiat on the platform key. Under that limit, the agent signs first and the platform key auto-signs second, and the transaction goes through without involving you.
Above the limit, the platform key refuses. The agent's signed transaction lands on your phone as a push notification, waiting for your signature as the second key. The agent never signs alone.
An under-limit transaction in the Nunchuk mobile app. The agent key and the platform key have already co-signed, and the transaction is ready to broadcast. The user gets a notification, but no signature is required.
This is a different shape than a hot wallet with rate limiting bolted on. The bounds are enforced at the signing layer, not at an application layer the agent could route around.
Clams does not enforce those bounds. Nunchuk does. Clams reads every transaction the wallet touches and produces accounting records: balance sheet, cost basis, capital gains, journal entries. The handoff is clean. Nunchuk decides what gets signed. Clams records everything the wallet sees: income, spends, and transfers between wallets you control.
The Descriptor Is the Integration
Most product integrations are an API contract.
The Nunchuk-to-Clams handoff is not that. It is a Bitcoin output descriptor: a single string that fully describes a wallet's signing policy and key derivation. Export it from Nunchuk. Import it into Clams. The two products never have to know about each other.
wsh(sortedmulti(2,
[d7bd2f9c/48'/1'/0'/2']tpubDEM5m…,
[8889d469/48'/1'/0'/2']tpubDE2yu…,
[ecfed4c1/48'/1'/169'/2']tpubDEZP3…
))#car2ltnw
Three xpubs, a 2-of-3 threshold, derivation paths, a checksum. That is the entire interface. Any wallet that speaks descriptors can read it.
One Agent, Two Skills
Both Nunchuk and Clams offer installable agent skills. To install both, paste these into your terminal:
npx skills add nunchuk-io/agent-skills
npx skills add clams-tech/skills
After installing, you do not have to type the CLI commands at all. You ask. The agent runs them for you.
A single agent session can hold both skills at once. Load Nunchuk and Clams into the same agent and it drives both CLIs from the same terminal. The descriptor is the seam between them, produced by Nunchuk and handed to Clams as the agent moves through the flow.
A typical conversation with your agent could look like this.
Starting with the Nunchuk side:
- "Generate a new signing key for me."
- "Create a 2-of-3 sandbox called Agent Treasury."
- "Enable the platform key and send an invitation to my email."
- "Finalize the wallet and set the spending policy to 100 USD per day."
- "Export the descriptor to a file."
Then Clams:
- "Create a Descriptor connection from this file: wallet.descriptor.json"
- "Sync it and process journals."
- "Show me the balance sheet."
One agent, one terminal, plain English. The agent exports a descriptor from Nunchuk and feeds it straight into Clams. Under the hood, it's running real CLI commands against both tools. The skills handle the translation from intent to invocation.
And the balance sheet that comes back:
Generated and delivered by the agent.
What Bitcoin Accounting for AI Agents Looks Like Now
The pieces are in place. Bounded-authority signing exists. A Bitcoin-native accounting engine exists — real double-entry, cost basis tracking, capital gains by lot, the same numbers an accountant would produce by hand, except the agent can pull them on demand. Two skills in one agent session, answering "what is my cost basis on the last ten transactions" or executing "send 50,000 sats to this address".
What you build on top of that is up to you. An agent that runs treasury operations within policy and reconciles the books at the end of every day.
Our infrastructure vision post has more on where this is going.
A note: screenshots and numbers in this post are from a testnet wallet used to demo the flow.
Clams Team