Scope of the proposal
One wallet-signed envelope; apps validate off-chain; stable qHash.- Networks use CAIP-2 (
eip155:1,solana:mainnet,near:mainnet, …) - Account ids use CAIP-10 (
eip155:1:0x...,solana:mainnet:...,near:mainnet:alice.near) where an*AccountIdfield is emitted - Stable profile and proof URLs use W3C
did:pkh(did:pkh:eip155:1:0x...)
Identity and chain glossary
Rule of thumb: EVM browser flows can rely on hosted verify or pass an explicit EVM provider. Any non-EVM flow passes the wallet or provider explicitly and includes
chain as a CAIP-2 value. The envelope is chain-agnostic by design. Any namespace that publishes a CAIP-2 reference and a signing profile can participate.
Proofable anchor
qHash (0x…) is SHAKE-256 (256-bit) of the canonical subset did, verifierIds, data, signedTimestamp, and exactly one of chainId or chain. Every field inside data, including a nonce or timestamp, remains bound to the hash. Proofs
Inputs (conceptual)
Account + chain,verifierIds, data (canonical JSON), signedTimestamp, EVM chainId or any non-EVM chain (CAIP-2).
Canonical JSON normalizes strings and keys to NFC, sorts object keys by Unicode code point, preserves array order and null, and rejects undefined, sparse arrays, non-finite numbers, functions, symbols, and bigint values. An envelope must contain exactly one of chainId or chain.
Signer string
Six-line UTF-8, LF. The wallet must sign these exact bytes.POST /api/v1/verification/standardize returns signerString for raw HTTP and debugging; the SDK verify() path builds the same message client-side (or use standardizeVerificationRequest when you need the API round-trip).
What the envelope proves
The signature andqHash prove the integrity of the envelope and identify who signed it. A user wallet signs its own verification request; Proofable signs a statement it produced itself, such as an authority decision or job outcome. The proof owner and the envelope signer can be different accounts, and neither signature proves an effect outside the statement the signer actually made.
To confirm Proofable issued a record and that it is still current, read it by exact qHash with GET /api/v1/proofs/{qHash}, within the visibility its owner set. This works for every proof, with or without an envelope.
Offline verification
Proofable stores the envelope with its proof record. The owner can retrieve it by exactqHash; anonymous exact-qHash reads include it only when the proof is public and the owner enables portable-proof disclosure. Disclosure can change without changing qHash or the signature.
qHash, checks the DID and chain binding, reconstructs the six-line message, and verifies the signature locally. Each chain uses its native signing scheme. EIP-1271 smart accounts require chain state; pass an ethers provider as options.provider.
Use the small EVM fixture for adapter tests. Its timestamp is historical, so fresh can be false while its hash and signature remain valid.
Signing profiles
The envelope is chain-agnostic. Any chain with a CAIP-2 namespace and a signing scheme can produce a valid envelope. Proofable ships the profiles below and adds more as ecosystems publish signing specs.
To add a profile, extend the SDK verifier with the chain’s signature scheme and ship an offline fixture. The
qHash canonicalization, six-line signer string, and CAIP-2 / CAIP-10 / did:pkh binding stay the same across every profile.
Freshness
Proofable rejects a new request ifsignedTimestamp is older than 5 minutes or more than 60 seconds in the future. Historical offline verification reports freshness separately from cryptographic validity.
Spec and lifecycle
CAIP-380 (ChainAgnostic). Status: Draft. Proofable is the reference implementation. CAIP-380 is at Draft status in the official CASA registry. Per CAIP-1 the lifecycle isDraft → Review → Last Call → Final (there is no “Accepted” rung). Advancing it requires editor advancement and, for the cryptographic profile, a second independent implementation. See Standards & interoperability and the whitepaper.