| title | The Proof Layer |
|---|---|
| description | Portable proof of identity, ownership, and control for people and AI. |
| icon | book-open |
| sidebarTitle | Whitepaper |
Whitepaper - October 2026
Author: Christopher Leal, Founder & Protocol Architect, Proofable
Published by: Proofable
Legal entity: NEUS Network, Inc.
Contact: chris@proofable.me
Trust decisions still reset at application boundaries. People repeatedly prove control of accounts, domains, wallets, credentials, and assets. AI agents increasingly act across multiple tools and systems using credentials that reveal little about who authorized them, what they may do, or whether that authority is still current.
Proofable is the proof layer for apps and AI agents. It turns completed identity, ownership, risk, eligibility, and authority checks into portable proofs that other systems can evaluate under their own policy.
Before a protected action, a Proofable gate evaluates the relevant proofs, their current lifecycle state, and the authority attached to the request. If required proof is missing, stale, expired, revoked, or outside its permitted scope, the action is denied or routed through the required verification or approval flow.
Proofs are private and offchain by default. Proofable separates request integrity, verification outcome, lifecycle state, and current authority so that a valid historical proof never becomes permanent permission. The result is a reusable trust layer for systems that need to answer four questions at the moment software acts:
Who is acting?
Who authorized them?
What are they allowed to do?
What actually happened?
Authentication can identify a session. It does not carry a completed trust decision into the next system, and it does not establish current authority for a sensitive action.
People and applications repeatedly rebuild checks for identity, ownership, eligibility, control, and risk. Agents make the problem more consequential because they are often given credentials broader than the action they need to perform.
Possession of a session or API key says little about:
- who approved a payout;
- which resource a grant applies to;
- what limits govern the action;
- whether the authority has been revoked;
- or whether the approval is still current.
Proofable treats trust as a current decision about a subject, action, resource, and policy. It follows the same resource-centered principle used in zero-trust architectures: authority is not inferred from network location or possession of a broad credential. It is evaluated for the protected resource under current policy [10, 11].
| Principle | Meaning |
|---|---|
| Reuse first | Use an acceptable current proof before repeating a verification. |
| Local policy | Each relying party decides which issuers, verifiers, freshness, scope, and assurance it accepts. |
| Enforce at action time | Evaluate trust immediately before the protected action. |
| Private by default | Routine proof creation and evaluation do not require public disclosure or a blockchain transaction. |
Proofable reduces the enforcement path to five steps:
Resolve → Check → Verify → Evaluate → Act or stop
A proof is reusable only when the relying party accepts its source and it still satisfies current policy.
Proofable gives different systems one proof model, and each evaluates it under its own requirements. Related credential standards separate issuers from verifiers. Proofable preserves that separation while adding lifecycle state, local policy, and enforcement at the protected boundary [9].
| Role | Responsibility |
|---|---|
| Subject | The human, organization, account, agent, wallet, domain, asset, or other object the proof describes. |
| Verifier | Performs a defined check and returns a result limited to that check. |
| Issuer | Attributes the resulting proof to the service or verification path that produced it. |
| Controller | Grants scoped authority to an agent when delegation is required. |
| Relying party | Defines which proofs it accepts and which policy must hold before an action. |
| Gate | Evaluates current proofs and policy at the protected boundary. |
The protected system must enforce the gate on the server or inside the trusted runtime.
Any execution path that bypasses the gate bypasses the protection.
A Proofable proof is a saved verification result that another accepted integration can evaluate without repeating the original check. A proof records:
- what was checked;
- which subject it applies to;
- the verification outcome;
- the issuer;
- current lifecycle state;
- expiration;
- visibility;
- and any scope or constraints required to interpret it.
Portability means the result can move across integrations that choose to accept it. An integration checks any proof by its qHash through the Proofable API, within the visibility the owner set, and records that carry a CAIP-380 envelope can also be checked offline.
It does not mean every system must trust the issuer, that evidence becomes public, or that a historical success remains valid forever.
| State | Current use |
|---|---|
| Pending | Not acceptable until the required verification completes successfully. |
| Passed and active | May be accepted if issuer, subject, freshness, scope, and policy also pass. |
| Failed | Does not satisfy a requirement that expects a passing result. |
| Expired or revoked | Must not authorize future actions, even if the proof previously passed. |
Verification outcome and lifecycle state are separate. A prior success never overrides expiration or revocation. High-value actions should evaluate current state close to execution so that authority is not inferred from stale evidence.
Proofs are private and offchain by default. A public proof page is a disclosure choice and adds no assurance. Optional onchain anchoring can provide a durable reference, but the anchor is not the verification result and does not replace a current status check.
An agent needs two distinct records:
- Identity: what the agent is and who controls it.
- Authority: what that controller has permitted it to do.
Combining the two would turn capability into implied permission.
Capabilities describe what an agent can do. Delegation determines what it is allowed to do. A payment-capable agent, for example, may have no authority to pay a particular recipient, or its authority may be limited by amount, asset, network, resource, environment, or time.
- Bind the controller to the exact agent receiving authority.
- State allowed actions and explicit denied actions.
- Give explicit denial precedence over broader allowance.
- Scope authority to the relevant resource, environment, payment type, or operation.
- Apply spend limits and expiration to payments and other high-impact actions.
- Require human approval where policy demands an additional decision.
Delegation narrows what an agent may affect. It does not guarantee safe reasoning. Sandboxing, output validation, rate limits, secret handling, and human approval remain necessary controls around the runtime.
A gate turns current proof state into an enforceable decision at the point where data, value, permissions, or infrastructure can change. The decision remains local. Two applications may evaluate the same proof differently because they accept different issuers, freshness windows, scopes, assurance levels, or risk thresholds.
High-value decisions should bind authority to the exact action parameters.
A payment can bind: amount → asset → destination → network
A deployment can bind: repository → artifact → environment → operation
This reduces the gap between what was approved and what actually executes.
Following the security-considerations guidance in RFC 3552 [13], Proofable makes its core assumptions explicit:
- The relying party controls which issuers and verifiers it accepts.
- The protected action cannot execute through a path that bypasses the gate.
- Controller and subject signing keys remain uncompromised.
- Current status and revocation data are available when policy requires them.
- Replay and stale state. Enforce freshness and current lifecycle state. Expired or revoked proofs cannot authorize a new action.
- Subject substitution. Bind each proof to the actor and resource involved in the current action.
- Scope escalation. Authority for one action, resource, destination, or amount does not imply broader authority.
- Gate bypass. Do not expose an alternate execution path that avoids policy evaluation.
- Verifier or issuer compromise. Assurance is bounded by the sources the relying party chooses to trust.
- Availability failure. When required current state cannot be established, high-risk actions should fail closed.
The gate governs whether an action runs. It cannot govern how a model reasons, so assurance rests on the action boundary: an unsafe plan still stops when it reaches an action outside current authority. The integrator routes every protected action through the gate, leaves no alternate execution path, and keeps runtime sandboxing and endpoint controls on its own infrastructure.
Proofable uses existing standards for account identifiers, signatures, agent discovery, tool access, and payments instead of redefining those layers.
Portable Proof began with a simple premise: a verified result should not die inside the system that produced it. Proofable extends that primitive through identity, authority, execution, and outcomes so trust can move with an agent across systems.
CAIP-380 defines a canonical signed envelope for portable wallet verification requests [1].
Proofable implements that envelope for applicable requests while storing the resulting verifier outcome separately as a Proofable proof. Records Proofable produces itself, such as job outcomes and authority decisions, use the same envelope with Proofable as the signer, so their content can be checked offline.
For CAIP-380 requests, qHash is a deterministic SHAKE-256 hash of the canonical request [1, 12]. Proofable can use that value to correlate the signed request with the stored proof.
qHash proves correlation. It does not prove the verifier outcome. Likewise, a valid request signature proves request integrity; it does not prove that verification succeeded or that a previously issued proof remains active.
CAIP-380 uses CAIP-2 and CAIP-10 for chain and account identifiers [1–4]. Signing follows the chain's native scheme. The envelope accepts any CAIP-2 namespace. Detailed canonicalization and validation rules remain in the CAIP and implementation documentation.
| Protocol | Role beside Proofable |
|---|---|
| CAIP-2 and CAIP-10 | Chain and account identifiers for cross-chain bindings [2]. |
| CAIP-380 | Signed request envelope for applicable wallet verification [1]. |
| MCP | Tool and context interface where Proofable policy can be evaluated before sensitive actions [5]. |
| A2A | Agent discovery and interaction surface where Proofable identity and proof context can accompany an agent [6]. |
| ERC-8004 | Agent identity, reputation, and validation registry model that can coexist with Proofable proof and authority records [7]. |
| x402 | HTTP-native payment challenge and settlement layer. Proofable authority remains separate and can be evaluated before settlement [8]. |
These protocols solve different problems. An authenticated connection, discovery record, or payment rail does not establish current authority by itself. The relying party still evaluates accepted proofs and local policy before allowing the protected action. See Standards & interoperability for current implementation details and references.
Every agent gets an identity of its own, the context it needs, clear limits on what it can do, and proof of what happened. Those controls stay with the agent across models, tools, runtimes, and MCP.
The same proof-and-gate model applies across browser flows, backend services, agent runtimes, marketplaces, and payment boundaries.
Evaluate agent identity and scoped delegation before a tool call, write, deployment, payment, or private-data access.
Combine ownership, risk, identity, or eligibility proofs at the protected boundary and reuse them wherever the relying party accepts them.
Use domain, organization, account, and wallet proofs before partner handoff, privileged configuration changes, or sensitive API writes.
Evaluate identity, delegation, amount, asset, destination, and network before settlement proceeds.
Proofable is developed and operated by NEUS Network, Inc. Proofable maintains the hosted trust service, developer platform, SDK, MCP server, APIs, and implementation documentation.
Open standards used by Proofable remain governed through their respective standards processes. The live verifier catalog, proof schemas, API behavior, and SDK interfaces are maintained in Proofable's documentation and public repositories.
Proofable separates:
proof from policy;
identity from authority;
capability from permission;
request integrity from verification outcome.
Applications do not need to share one universal trust policy. They need a common way to carry verifiable facts and evaluate them under local policy when an action matters.
For people, that means completed verification does not need to reset at every application boundary. For agents, it creates a narrow and revocable path from identity → delegated authority → execution → receipt without treating login, capability, or payment as permission.
The model, runtime, application, or chain can change. The trust record can persist.
Trust should travel.
- Platform: proofable.me
- Documentation: docs.proofable.me
- SDK: proofable/sdk
- MCP: proofable/mcp
- Documentation repository: proofable/docs
- Trust Center: proofable.me/trust-center
- [1] Chain Agnostic Improvement Proposals. CAIP-380: Portable Proof.
- [2] Chain Agnostic Improvement Proposals. CAIP-2: Blockchain ID Specification; CAIP-10: Account ID Specification.
- [3] Ethereum Improvement Proposals. ERC-191 and ERC-1271.
- [4] Ethereum Improvement Proposals. ERC-6492: Signature Validation for Predeploy Contracts.
- [5] Model Context Protocol. Specification.
- [6] A2A Protocol. Specification.
- [7] Ethereum Improvement Proposals. ERC-8004: Trustless Agents.
- [8] x402 Foundation. x402 Specification.
- [9] W3C. Verifiable Credentials Data Model v2.0. W3C Recommendation.
- [10] NIST. SP 800-207: Zero Trust Architecture.
- [11] Ward, R.; Beyer, B. BeyondCorp: A New Approach to Enterprise Security. ;login:, 39(6), 2014.
- [12] NIST. FIPS PUB 202: SHA-3 Standard.
- [13] Rescorla, E.; Korver, B. RFC 3552: Guidelines for Writing RFC Text on Security Considerations.