The receipt envelope follows the draft CAIP-380 Portable Proof format and can be read independently of the NEUS app.
CAIP-380 proposal on GitHubSpec on docs.neus.network
Last updated: July 2026
CAIP-380 is a draft ChainAgnostic standard for a wallet-signed, chain-agnostic proof envelope. It uses CAIP-2 chain context, CAIP-10 account ids, W3C did:pkh profile identifiers, and a SHAKE-256 qHash over the standardized proof request fields. NEUS implements it in production: the same envelope your app verifies is the one the spec describes.
A NEUS receipt is a CAIP-380 envelope. The qHash, signer string, and signature verify against the published spec, not a NEUS API call. NEUS is the issuance and discovery layer; verification is a spec operation any integrator can run. The public verifier catalog and SDK remain usable by anyone, and receipts already held by apps and gates stay checkable even if NEUS infrastructure is unavailable.
W3C Verifiable Credentials is a general data model; CAIP-380 is a chain-agnostic, wallet-signed envelope purpose-built for portable proof with a stable qHash. The two are complementary, not mutually exclusive.
| Dimension | W3C Verifiable Credentials | NEUS (CAIP-380) |
|---|---|---|
| What it is | General data model for verifiable claims | Chain-agnostic, wallet-signed proof envelope with a stable qHash anchor |
| Chain support | Resolver-dependent; often chain-agnostic by design but heavy to verify | CAIP-2 / CAIP-10 native: EVM, Solana, and others from one envelope |
| Verification | Requires a resolver layer | qHash + signer string + signature verify against the spec, no resolver needed |
| Best for | Broad credential use cases (education, government, identity) | Portable trust receipts for apps, gates, agents, and partner flows |
ERC-7683 is an Ethereum token standard for cross-chain intents; CAIP-380 is a chain-agnostic proof envelope for portable trust. They solve different problems and compose cleanly.
| Dimension | ERC-7683 | CAIP-380 |
|---|---|---|
| Problem space | Cross-chain token intent execution | Portable trust receipt verification |
| Chain scope | EVM chains | Chain-agnostic (EVM, Solana, and others) |
| Output | Settled token transfer | A receipt (qHash) downstream systems reuse |
| Composes with NEUS? | Yes; NEUS can gate on token outcomes | CAIP-380 is the envelope NEUS issues |
MCP (Model Context Protocol) connects AI assistants to tools and context. Its authorization specification secures a client's access to an MCP server. NEUS adds agent identity, granted permissions, and reusable trust receipts that integrations can check across sessions.
CAIP-380 defines a draft format for portable proof receipts. Systems can read the standardized receipt fields without depending on the NEUS interface. NEUS records completed checks; applications decide which receipts to require and how to include them in their own audit logs.
NEUS is framework-neutral and model-neutral. Agent runtimes handle planning, tools, and memory; messaging protocols handle agent-to-agent handoff; model providers handle inference. NEUS supplies identity and permission receipts that those systems can check. It does not replace the framework, model, or messaging protocol. See the agents page for where NEUS sits in the stack.
NEUS uses the draft CAIP-380 Portable Proof format. The proposal documents the receipt fields, identifier, and signing format publicly; it is not a finalized standard.
CAIP-380 is a draft proposal for a wallet-signed, chain-agnostic receipt envelope. It uses CAIP-2 chain context, CAIP-10 account IDs, did:pkh identifiers, and a SHAKE-256 receipt ID over defined request fields.
You can validate the stored envelope’s receipt ID and wallet signature against the draft format. Checking current status, revocation, or the underlying provider result may still require NEUS or another compatible source.
Integrations that retain complete receipt envelopes can continue validating their receipt IDs and signatures. Live discovery, revocation status, and provider-backed refreshes require an available compatible service.
W3C Verifiable Credentials defines a broad model for verifiable claims. The draft CAIP-380 format defines a wallet-signed receipt envelope with chain and account references. An integration may use either or both.
ERC-7683 standardizes cross-chain token intents. The draft CAIP-380 format describes trust receipts. They address different parts of an integration and can be used together.
MCP connects assistants to tools and context, while its authorization specification secures client access to an MCP server. NEUS adds agent identity, granted permissions, and reusable trust receipts through a hosted MCP server.
NEUS records completed identity, ownership, and permission checks as signed receipts. Applications can reference those receipts in their own activity logs and access reviews.
IAM systems issue tokens and manage workload identities. NEUS permission receipts record who approved an agent and which limits apply. They complement IAM controls; they do not replace tokens, credentials, or runtime enforcement.
Read the trust receipts explainer, the protocol overview, or the CAIP-380 spec.
Portable trust receipts for people, apps, and AI agents. Prove identity, ownership, or permission before access, payment, or action.