Epic: x402 agentic payments (Multipaz as the hardware-backed wallet)

[dzuluaga]

Goal

Make Multipaz the hardware-backed wallet for x402 agentic payments: an on-chain payment account held as a non-exportable key in the phone's secure hardware, surfaced as a portable credential, usable by an AI agent to authorize and settle payments (including human-not-present). Start on Hedera, extend to other chains.

Status

Hedera (Ed25519) works end to end on testnet today: a TEE-resident, recoverable account, biometric-gated signature, settled via a facilitator, shown as a first-class credential. The foundational library fix is up as a draft PR. Everything below is the path to broaden and harden it.

Workstreams

1. Multipaz library (upstream PRs)

• PR #1788 (Ed25519 keystore fix): get CI green, flip to ready, land review and merge. This is part feat(attesto-gate): signed Cart Mandate (ap2.CartMandate) — core + enforcement #1.
• certify() emits a document-changed event: one-line fix that removes the stale-claims workaround; separate follow-up PR.

2. Core-vs-extension decision

• Decide: generic x402 credential in core vs a documented, pluggable extension point, with the Multipaz maintainers. Drives where the payment document types live.

3. Credential / document types (part #2)

• Add the x402 payment document types (HederaAccountCredential, or a generic descriptor-driven credential) as the follow-up PR, once the decision lands.

4. Generic PaymentSigner seam

• Lock a generic, descriptor-driven PaymentSigner over SecureArea (no chain SDK in the sign path).
• Re-express the Hedera flow through it.
• Add Solana (Ed25519) as data to prove provider-agnosticism.

5. Provider breadth

• Hedera (Ed25519): demo done.
• Solana (Ed25519): add as data.
• Tron (secp256k1): blocked on hardware; needs the HSM path (workstream 6).
• Coinbase / Base / Polygon: future.

6. Tron / secp256k1 path

• External HSM signs settlement + Multipaz holds the authorization credential and runs OID4VP (chain key is custodial in the HSM).
• Optional: add secp256k1 to EcCurve (BouncyCastle) so the Cloud Secure Area can hold it server-side.
• Tron outreach: alternatives for hardware-backed secp256k1, eng bandwidth, devrel co-publishing.

7. Wallet to agent integration (the goal)

• Connect the hardware-backed x402 credential to the agentic flow (AP2) as its authorization and settlement instrument.
• Prove the human-not-present flow: provision and authorize once in hardware (with recovery), agent transacts later via AP2 mandates.

8. Outreach and content

• x402 GitHub issue / discussion (generic-in-core vs extension framing).
• Conference talk on Multipaz + agentic payments.
• Co-publish integrations (demos, sample apps, guides) with partner devrel teams.

Links

• Foundational fix (Ed25519 in AndroidKeystoreSecureArea): Fix Curve25519 (Ed25519) signing in AndroidKeystoreSecureArea openwallet-foundation/multipaz#1788

[AmitabhainArunachala]

Hi — this epic is exactly the buyer side I need for a live seller-side fixture.

I run a public x402/Base-USDC endpoint that can be used as an external counterparty while you test Multipaz/secure-hardware signing, AP2-style mandates, and human-not-present payment loops:

• Base URL: https://x402.167-172-95-184.nip.io
• Discovery: https://x402.167-172-95-184.nip.io/.well-known/x402
• OpenAPI: https://x402.167-172-95-184.nip.io/openapi.json
• Free liveness/demo: GET /health, GET /demo
• Cheapest paid probe: GET /price — $0.01 USDC on Base via x402/CDP facilitator
• Trust/agent-commerce routes: GET /audit/x402, POST /receipt/verify, POST /mandate/verify, POST /mcp/call

Minimal unpaid probe:

curl -i https://x402.167-172-95-184.nip.io/price

Expected result is HTTP 402 with machine-readable x402 payment requirements, network="eip155:8453", asset="USDC", and a payTo address in the response body/headers. A Multipaz-backed buyer wallet can then sign the authorization and retry with the payment proof.

Why this may be useful here: it gives the Multipaz/Attesto side a live, non-self seller to validate the hard parts of this epic — hardware-backed key custody, spending authority, request/resource binding, mandate expiry, and receipt/audit capture — without needing to stand up a merchant endpoint first.

I verified immediately before posting that /health, /.well-known/x402, /x402.json, /openapi.json, /demo, and the unpaid /price 402 challenge are live. Happy to keep this endpoint stable as an interop fixture if it helps the workstream.