The Proof Layer

Whitepaper - October 2026 Author: Christopher Leal, Founder & Protocol Architect, Proofable
Published by: Proofable
Legal entity: NEUS Network, Inc.
Contact: chris@proofable.me

Abstract

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?

1. Problem: trust resets at application boundaries

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.

2. Trust model

Proofable reduces the enforcement path to five steps: Resolve → Check → Verify → Evaluate → Act or stop

Reuse-first verification lifecycle: resolve, check current receipts, verify only missing or stale checks, evaluate policy, then act or stop. — Figure 1. Reuse accepted current proofs, verify only missing or stale requirements, and enforce policy before execution.

A proof is reusable only when the relying party accepts its source and it still satisfies current policy. Proofable does not create universal trust. It provides a common proof model that different systems can evaluate under their 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.

Proofable system architecture: integration surfaces feed the verification engine, which produces saved results that gates evaluate before protected actions. — Figure 2. Public interfaces feed one verification engine. Gates evaluate current proof state 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.

3. Portable proofs

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.

Privacy and anchoring

Proofs are private and offchain by default. A public proof page is a disclosure choice, not a higher assurance level. Optional onchain anchoring can provide a durable reference, but the anchor is not the verification result and does not replace a current status check.

4. Agent identity and authority

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.

Agent identity and authority model: agent identity receipt describes the agent, controller-signed delegation receipt grants specific actions and limits, runtime gate evaluates both before a protected tool call. — Figure 3. Agent identity and agent authority are separate. Sensitive actions require current, applicable delegation at runtime.

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.

Delegation boundaries

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.

5. Enforcement and security

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.

Gate evaluation pipeline: resolve policy and receipts, validate bindings and current lifecycle state, apply scope and constraints, then allow, require approval, or deny before execution. — Figure 4. Gate evaluation applies relying-party policy to current proof state before the protected action is allowed, constrained, approved, or denied.

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.

Security assumptions

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.

Threats addressed

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.

Out of scope

Proofable does not replace:

authentication;
endpoint authorization;
payment settlement;
runtime sandboxing;
secrets management;
rate limiting;
or observability.

It does not guarantee that an agent will reason safely. Integrators remain responsible for those controls and for ensuring that protected actions cannot bypass the gate.

6. Standards and interoperability

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 Portable Proof

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 request envelope and Proofable proof: the signed envelope proves request integrity, the Proofable proof records the verifier outcome and lifecycle state, qHash correlates them but does not prove the result by itself. — Figure 5. `qHash` can correlate a CAIP-380 signed request with a Proofable proof, while request integrity and verifier outcome remain separate claims.

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.

7. Applications and implementation

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.

Agent actions

Evaluate agent identity and scoped delegation before a tool call, write, deployment, payment, or private-data access.

Marketplace and partner access

Combine ownership, risk, identity, or eligibility proofs at the protected boundary and reuse them wherever the relying party accepts them.

Organization and domain control

Use domain, organization, account, and wallet proofs before partner handoff, privileged configuration changes, or sensitive API writes.

Payments

Evaluate identity, delegation, amount, asset, destination, and network before settlement proceeds.

Implementation and stewardship

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.

Conclusion: trust that travels

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.

Implementation resources

Platform: proofable.me
Documentation: docs.proofable.me
SDK: proofable/sdk
MCP: proofable/mcp
Documentation repository: proofable/docs
Trust Center: proofable.me/trust-center

References

Specifications and standards

[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.

Informative references

[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.

Overview

MCP

JavaScript SDK

HTTP API

Verifier catalog

Standards

Abstract

1. Problem: trust resets at application boundaries

2. Trust model