The gap nobody fills: cross-protocol budget tracking. An agent that shops via UCP, pays for APIs via MPP, and settles via x402 has no unified spending verification across all three. Each protocol tracks its own transactions in isolation.
— README.md, "How the Protocols Relate"
The gap as framed is cumulative behavior aggregation — transaction-history rollup across rails. There's a closely related, separable concern your matrix surfaces but doesn't name: cross-protocol current-state verification. That sits at the same layer regardless of how the budget-tracking question gets answered, and it's outside commerce / authorization / settlement.
The primitive that closes it is wallet auth: a signed boolean evaluating a condition over current on-chain state, layer-agnostic and protocol-agnostic.
Concretely, "does this counterparty wallet currently hold the credential required to route this payment — NFT, EAS attestation, or token threshold — on any chain it operates on?" is:
- A condition over current wallet state, not transaction history
- Signable as a boolean (ECDSA, JWKS-verifiable offline)
- Independent of which protocol routed prior payments — UCP, MPP, x402 traffic settles to the same chain state and is evaluated equivalently
- Doesn't require coordination between the protocols themselves
None of the 5 protocols in your matrix sign attestations about this. AP2 mandates authorize a future payment; ACP allowances scope a delegate; x402/MPP receipts confirm a single settlement. None bind a current-state claim layered above them.
The signing is load-bearing: an unsigned cross-protocol check is just another trust assumption — that doesn't dissolve the siloing problem, it relocates it.
Question, your call: is "cross-protocol verification" a separable layer worth a section in the doc (alongside commerce / authorization / settlement), or out of scope as you've framed it? Either answer works — if in scope, happy to drop a primitive description here for your editorial decision; if out of scope the gap line stands as documented and the doc keeps its current shape.
Disclosure: InsumerAPI implements wallet auth — condition-based access infrastructure. Signed booleans evaluating conditions over current wallet state, JWKS-verifiable offline, 33 chains. Docs: insumermodel.com/developers/. Naming it here so you know I'm not disinterested.
— Douglas
The gap as framed is cumulative behavior aggregation — transaction-history rollup across rails. There's a closely related, separable concern your matrix surfaces but doesn't name: cross-protocol current-state verification. That sits at the same layer regardless of how the budget-tracking question gets answered, and it's outside commerce / authorization / settlement.
The primitive that closes it is wallet auth: a signed boolean evaluating a condition over current on-chain state, layer-agnostic and protocol-agnostic.
Concretely, "does this counterparty wallet currently hold the credential required to route this payment — NFT, EAS attestation, or token threshold — on any chain it operates on?" is:
None of the 5 protocols in your matrix sign attestations about this. AP2 mandates authorize a future payment; ACP allowances scope a delegate; x402/MPP receipts confirm a single settlement. None bind a current-state claim layered above them.
The signing is load-bearing: an unsigned cross-protocol check is just another trust assumption — that doesn't dissolve the siloing problem, it relocates it.
Question, your call: is "cross-protocol verification" a separable layer worth a section in the doc (alongside commerce / authorization / settlement), or out of scope as you've framed it? Either answer works — if in scope, happy to drop a primitive description here for your editorial decision; if out of scope the gap line stands as documented and the doc keeps its current shape.
Disclosure: InsumerAPI implements wallet auth — condition-based access infrastructure. Signed booleans evaluating conditions over current wallet state, JWKS-verifiable offline, 33 chains. Docs: insumermodel.com/developers/. Naming it here so you know I'm not disinterested.
— Douglas