> ## Documentation Index
> Fetch the complete documentation index at: https://docs.proofable.me/llms.txt
> Use this file to discover all available pages before exploring further.
# Standards and interoperability
> How Proofable works with existing identity, authority, execution, payment, and evidence standards.
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](/learn/standards/caip-380) format. The [Technical Whitepaper](/whitepaper#standards-and-interoperability) 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](/learn/standards/caip-380), [Discover agents](/agents/named-agent-card) |
| 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](https://standards.chainagnostic.org/CAIPs/caip-380), [Portable proofs](/learn/standards/caip-380), [Examples](https://github.com/proofable/sdk/tree/main/examples/caip-380) |
| MCP | Tools and context for any MCP client | Hosted MCP carries profile, proofs, listings, permissions, and checks before sensitive tools run | Available | [MCP setup](/mcp/setup) |
| OAuth / OIDC | Sign-in for people and MCP clients | Hosted MCP and app Connect | Available | [MCP setup](/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](/deployment/private-cloud) |
| 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](/agents) |
| A2A | Agent discovery cards | Public cards show who the agent is and who approved it | Available | [Platform A2A card](https://proofable.me/.well-known/a2a/agent-card.json), [Discover agents](/agents/named-agent-card) |
| 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](/mcp/guarded-action), [Whitepaper](/whitepaper#standards-and-interoperability) |
| 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](/mcp/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](/agents/agent-delegation), [Proof lifecycle](/verification/lifecycle) |
| ERC-8004 | Public agent discovery | Proofable can publish registration metadata while keeping its own proof and permission model | Not registered | [Platform metadata](https://proofable.me/.well-known/agent-card.json), [Discover agents](/agents/named-agent-card) |
| 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](/gates/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](/deployment/private-cloud) |
Proofable uses these standards. It does not replace them. [CAIP-380](https://standards.chainagnostic.org/CAIPs/caip-380) remains the open specification for the signed request format.
## Related standards by layer
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](https://a2a-protocol.org), [SPIFFE/SPIRE](https://spiffe.io), OpenID AIIM | Consumes and links identity evidence; identity is not authority |
| Delegated authority | [OAuth 2.0 Token Exchange (RFC 8693)](https://www.rfc-editor.org/info/rfc8693), [Rich Authorization Requests (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396) | Records bounded authority as a separate layer, native or delegated |
| Authorization decision | [AuthZEN](https://openid.net/wg/authzen/specifications/) | Records the decision and its policy context at the action boundary |
| Attestation and appraisal | [RATS (RFC 9334)](https://www.rfc-editor.org/rfc/rfc9334), [EAT (RFC 9711)](https://www.rfc-editor.org/rfc/rfc9711) | Carries evidence and keeps the appraisal result a separate dimension |
| Portable credentials | [W3C VC 2.0](https://www.w3.org/TR/vc-data-model-2.0/), [OpenID4VP](https://openid.net/) | Complementary presentation formats; a proof/receipt can be appraised under any policy |
| Freshness and revocation | [CAEP and Shared Signals](https://openid.net/), [Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/) | Records current trust state instead of assuming a decision stays valid |
| Transparency | [SCITT (RFC 9943)](https://www.rfc-editor.org/rfc/rfc9943) | Complementary model for signed statements that gain verifiable transparency later |
| Portable proof | [CAIP-380](/learn/standards/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:
```javascript theme={"system"}
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](/learn/standards/caip-380).
## Next
How the signed request format works.
Architecture and trust model.
Check permission before a tool runs.
Public agent pages and discovery cards.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.