Standards and interoperability

Proofable does not replace your sign-in, policy engine, agent runtime, or processor. It records results those systems can check. Wallet-signed checks use the CAIP-380 format. The Technical Whitepaper covers the architecture.

A signed CAIP-380 request proves who signed and that the request was not changed. A Proofable proof records the check result and whether it is still current. Those are related, not the same.

How Proofable uses these standards

Standard	What it provides	How Proofable uses it	Status	See
CAIP-2 / CAIP-10	Network and account identifiers	Accounts, agents, and profiles use the same chain and account IDs	Available	Portable proofs, Discover agents
CAIP-380 Portable Proof	A wallet-signed request format with a stable proof ID	Wallet-signed Proofable checks use this format. Other signed-in checks still create Proofable proofs	Draft	CAIP-380 spec, Portable proofs, Examples
MCP	Tools and context for any MCP client	Hosted MCP carries profile, proofs, listings, permissions, and checks before sensitive tools run	Available	MCP setup
OAuth / OIDC	Sign-in for people and MCP clients	Hosted MCP and app Connect	Available	MCP setup
ACP	Client to an agent session	Optional self-hosted session (OpenCode, Hermes, Claude ACP). Hosted jobs stay on Proofable	Works with	Private cloud agents
Enterprise Agent SSO	App access for agents with an active user	Keep Okta or your IdP. Proofable records agent limits and runs background jobs those systems do not cover	Works with	Agents
A2A	Agent discovery cards	Public cards show who the agent is and who approved it	Available	Platform A2A card, Discover agents
AuthZEN	A standard way to ask whether an action is allowed	A Proofable proof can be the evidence that decision uses	Works with	First guarded action, Whitepaper
AARM	Runtime checks before an agent acts	Proofable checks identity, limits, and current permission before an action, then records the result	Works with	First guarded action
ATF	Identity, behavior, access limits, and how to stop or revoke	Proofable covers those with identity, permission checks, deny, and revoke	Works with	Agent permissions, Proof lifecycle
ERC-8004	Public agent discovery	Proofable can publish registration metadata while keeping its own proof and permission model	Not registered	Platform metadata, Discover agents
x402	Pay for a single HTTP call	Payment settles the call. Proofable can still require a current proof before the call proceeds	Available	Pay per call
Phala	Confidential compute	Hosted AI can run in a Phala-backed confidential environment. The same proofs work on a private deploy	Available	Private cloud agents

Proofable uses these standards. It does not replace them. CAIP-380 remains the open specification for the signed request format. Proofable is not replacing identity, authorization, credential, or attestation standards. It provides the portable evidence layer connecting them:

SPIFFE and A2A can establish or describe an agent. OAuth and AuthZEN can determine what it may do. RATS/EAT can attest its environment or claims. VC and OpenID4VP can carry credentials across parties. CAEP can communicate trust-state changes. SCITT can add transparency and independent receipt verification. Proofable preserves the resulting identity, authority, decision, and effect records as portable proofs another relying party can independently appraise.

Layer	Existing work	Proofable relation
Identity	A2A, SPIFFE/SPIRE, OpenID AIIM	Consumes and links identity evidence; identity is not authority
Delegated authority	OAuth 2.0 Token Exchange (RFC 8693), Rich Authorization Requests (RFC 9396)	Records bounded authority as a separate layer, native or delegated
Authorization decision	AuthZEN	Records the decision and its policy context at the action boundary
Attestation and appraisal	RATS (RFC 9334), EAT (RFC 9711)	Carries evidence and keeps the appraisal result a separate dimension
Portable credentials	W3C VC 2.0, OpenID4VP	Complementary presentation formats; a proof/receipt can be appraised under any policy
Freshness and revocation	CAEP and Shared Signals, Bitstring Status List	Records current trust state instead of assuming a decision stays valid
Transparency	SCITT (RFC 9943)	Complementary model for signed statements that gain verifiable transparency later
Portable proof	CAIP-380	The canonical Proofable envelope that carries the record

Each layer answers a different question: who the agent is, what it may do, what was decided, what happened, and how strongly another party can rely on the record. Portable Proof keeps those answers as separate, linked records rather than collapsing them into one credential.

Check an example

Use a signed request from a check, or the published example:

import { verifyPortableProofEnvelope } from '@proofable/sdk';
import envelope from '../../../examples/caip-380/minimal-evm.json' with { type: 'json' };

const result = await verifyPortableProofEnvelope(envelope);
if (!result.valid) throw new Error(result.errors.join('; '));

This checks the proof ID, account binding, and signature on your machine. Current status still comes from Proofable or another service that stores the result. See Portable proofs.

Portable proofs

How the signed request format works.

Whitepaper

Architecture and trust model.

First guarded action

Check permission before a tool runs.

Discover agents

Public agent pages and discovery cards.

Overview

MCP

JavaScript SDK

HTTP API

Verifier catalog

Standards

Standards and interoperability

How Proofable uses these standards

Check an example

Next

Portable proofs

Whitepaper

First guarded action

Discover agents

​How Proofable uses these standards

​Related standards by layer

​Check an example

​Next

Portable proofs

Whitepaper

First guarded action

Discover agents

How Proofable uses these standards

Related standards by layer

Check an example

Next