feat: DWN-based P2PK key discovery via published protocol record

[LiranCohen]

Summary

Replace manual P2PK public key paste in the Send-to-DID flow with automatic key discovery via a published DWN record. Senders resolve the recipient DID, query their DWN, and find the P2PK public key without any out-of-band exchange.

Background

Currently, Send-to-DID requires the sender to manually paste the recipient's secp256k1 P2PK public key. This is the primary UX friction in the P2P transfer flow.

Studied approaches:

• archetech/agent-skills archon-cashu: Resolves the recipient's DID document, extracts verificationMethod[0] secp256k1 key, locks NUT-11 tokens to it. Simple and elegant but couples the DID to a specific application.
• cashu.me / eNuts: No DID-based P2PK discovery. Manual key exchange or Nostr-based.

Proposed design

Phase 1: Protocol-scoped discovery (nutsd-only)

Add a published, anyone-readable p2pk-info record to the cashu-transfer protocol:

structure: {
  transfer: { $actions: [{ who: 'anyone', can: ['create'] }] },
  request: {},
  'p2pk-info': {
    $actions: [{ who: 'anyone', can: ['read'] }],
    $recordLimit: { max: 1, strategy: 'reject' },
  },
}

The p2pk-info record contains the wallet's secp256k1 compressed public key (unencrypted). Written during wallet setup, readable by any DID.

Sender flow:

1. Resolve recipient DID -> find #dwn service endpoint
2. Query recipient's DWN for cashu-transfer protocol p2pk-info record
3. Read the P2PK public key
4. Lock token with NUT-11 -> write transfer record to recipient's DWN

Delegate compatibility: The delegate can read the owner's p2pk-info (public) and use it for sending. Cannot redeem incoming transfers (no private key). Correct security boundary.

Phase 2 (future): Platform-level P2PK info

Explore adding a similar published record at the Enbox platform protocol level, so any application can discover a DID's P2PK public key. This would require:

• A generic "payment capabilities" protocol that the wallet/agent installs
• The Enbox agent would need a mechanism for apps to request "install this published record on my behalf" - a special type of protocol install
• The record would live outside any app's protocol namespace, making it discoverable without knowing which Cashu wallet the recipient uses

This is analogous to how archon-cashu reads verificationMethod[0] from the DID document, but using a DWN protocol record instead, keeping the DID document application-agnostic.

Design tensions

Concern	Protocol-scoped (Phase 1)	Platform-scoped (Phase 2)
Discovery	Sender must know recipient uses cashu-transfer	Any sender can find the key
Platform coupling	None	Requires Enbox awareness of payment capabilities
Multi-app	Different apps can have different P2PK keys	One key per DID
Complexity	Low	Medium - new platform protocol + agent install flow

Not in scope

• Changing the DID document to include secp256k1 keys (couples platform to Cashu)
• NUT-13 deterministic secrets (DWN sync is the recovery mechanism)
• Nostr-based key discovery (replaced by DWN-native approach)

References

• PR feat: Sprint 3 — NUT-11 P2PK, P2P DWN transfer foundation #6: NUT-11 P2PK foundation
• PR feat: Sprint 3b — complete P2P DWN transfers, wire dead code, safety improvements #7: P2P DWN transfer pipeline
• archetech/agent-skills archon-cashu