Skip to content

Add CAIP: CLI Wallet Protocol (CWP)#397

Merged
bumblefudge merged 2 commits intoChainAgnostic:mainfrom
arein:caip-cli-wallet-protocol
Mar 3, 2026
Merged

Add CAIP: CLI Wallet Protocol (CWP)#397
bumblefudge merged 2 commits intoChainAgnostic:mainfrom
arein:caip-cli-wallet-protocol

Conversation

@arein
Copy link
Contributor

@arein arein commented Feb 23, 2026

Summary

This CAIP proposes a standard protocol for CLI applications to discover and interact with wallet providers through executable plugins on PATH.

Key concepts:

  • Binary naming: wallet-<name> executables (e.g., wallet-walletconnect, wallet-ledger, wallet-cast)
  • Communication: JSON on stdin/stdout, status on stderr, semantic exit codes
  • Operations: info, accounts, sign-message, sign-typed-data, sign-transaction, send-transaction
  • Discovery: PATH scanning + optional ~/.config/wallet/config.json for preferences
  • Orchestrator: wallet CLI discovers providers and delegates

Inspired by:

Motivation

CLI blockchain tools (API clients, deployment scripts, AI agents) hardcode specific wallet providers. There's no CLI equivalent of EIP-6963 for pluggable wallet discovery. This creates tight coupling and limits user choice.

Reference Implementations

  • Orchestrator: @anthropic-ai/wallet-cli — discovers wallet-* on PATH, delegates operations
  • Provider: wallet-walletconnect — CWP adapter for the walletconnect CLI
  • Consumer: nansen-cli — uses wallet CLI for x402 auto-payment signing

Discussion

#396

arein and others added 2 commits February 23, 2026 12:52
Proposes a standard for CLI wallet discovery and interaction via
executable plugins on PATH, inspired by EIP-6963 and git credential
helpers.

Discussion: ChainAgnostic#396

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Introduces grant-session, revoke-session, and get-session operations
that let a human pre-approve scoped permissions (spending limits,
rate limits, contract allowlists) for AI agents to operate without
per-operation approval. Adds permission/policy type system, session
error codes, security considerations, and rationale. References
EIP-7715, EIP-7710, and CAIP-171.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

#### `grant-session`

Creates a scoped permission session for autonomous operation. MUST complete within 120 seconds (requires human approval to authorize the session).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is human approval assumed to be interactive? Would it be more precise/explicit to say "MUST timeout if interactive user approval has not authorized the session within 120 seconds"?


#### `info`

Returns provider metadata and capabilities. MUST complete within 3 seconds.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Returns provider metadata and capabilities. MUST complete within 3 seconds.
Returns provider metadata and capabilities, and doubles as [discovery mechanism](#Discovery). MUST complete within 3 seconds.

@bumblefudge
Copy link
Collaborator

bumblefudge commented Mar 2, 2026

Hey this great and well-thought out, appreciate all the Considerations. Minor things:

  1. Is there already a reference implementation, or known implementations in the wild? Linking to them in the spec would be great if so; it looks like the "Reference Implementations" section of the PR summary is more of a "prior art" or "potential users" list.
  2. Attenuation-only makes perfect sense but I wonder if being more precise or normref-ing to something more precise because people don't always interpret that constraint predictably1. I also notice that EIP-7715 doesn't actually include this constraint (it uses the word attenuate to mean either escalating or de-escalating permissions!), so anchoring this constraint in another specification or policy semantic seems even more important to do to prevent weird divergences in policy creeping in.
  3. Is a wallet-cli conformant if it doesn't do one of the operations? Should the supported functions be returned by the discovery function, if so?

Footnotes

  1. For instance, if I grant a total of up to 3 payments, totalling 10Eth or less, be made within the next 3 days, everyone would agree that lowering the number of payments to 1 is an attenuation of scope/privilege, but I suspect changing only the maximum total would not universally be seen as an attenuation, just an update to a value. (OK bad example because in payments that value is pretty obviously correlated to privilege, but you get what I mean, semantics slips in sometimes).

Copy link
Member

@pedrouid pedrouid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@bumblefudge bumblefudge merged commit ebacdb9 into ChainAgnostic:main Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants