ProofMatter is the missing verification layer for the digital economy. Not just proof that a transaction was recorded — proof that a real-world action was actually executed, validated, and auditable over time.
Read the ProofMatter Infrastructure Paper (Coming Soon)
AI agents act autonomously — but no one can independently verify what they actually did. Enterprises report compliance — but the proof is still a PDF. Even blockchains only record that a transaction happened, not that a real-world action was actually executed.
attest_action, verify_attestation, get_trust_score. The protocol is designed to integrate with MCP-compatible agent frameworks such as Claude, GPT, or Gemini.
Three steps from business action to cryptographic proof. Minimal overhead for the proof creator; maximum confidence for the verifier.
A business action occurs — an invoice is approved, a CO&sub2; reduction is achieved, an AI agent completes a task. The executing party generates a cryptographic proof using a SyncTree structure. Only the root hash goes on-chain. Full data stays with the holder.
Counterparties co-sign. Accredited validators attest. Regulators endorse. Each attestation references the proof’s root hash and is recorded on-chain. The proof’s trust level rises from TL1 (self-signed) through TL4 (multi-validator). Dishonest attestations result in slashed validator stakes.
Any authorized party — a regulator, a customer, a trading partner — can verify a proof in seconds. They see only the fields they are authorized to see. The TrustMesh shows the full graph of attestations across all counterparties and validators. No PDFs. No human interpretation.
Most blockchain proof systems hash an entire document. To prove anything, you must reveal everything. SyncTree solves this with field-level selective disclosure.
ROOT HASH (on-chain) / \ Node #1f78 Node #gh8x / \ / \ ID: PO-123 Total: 123,45 Currency: EUR Discount: [MASKED] Each leaf = SHA256("Field:Value:Salt") Only ROOT HASH goes on-chain. Full data stays with the holder. ■ Revealed field — verifiable against root ■ Masked field — hash only; proves existence
Every field in a business object becomes a leaf node, hashed with a unique random salt. Only the root hash is published on-chain. The full data stays off-chain with the holder. Three roles define what each party can see:
The originator of the proof. Sees all fields and all salts. Controls which fields to reveal to which parties. Can generate Merkle proofs for any individual field on request.
Sees only the fields the holder has chosen to reveal, along with their salts. Can verify each revealed field against the on-chain root hash. Cannot see masked fields — not even their values.
Sees only a pre-defined subset of fields. All other subtrees are collapsed to hashes. A regulator checking CO&sub2; thresholds never sees contract terms. A bank checking invoice amounts never sees customer identities.
Constraints such as TotalValue ≤ 100,000 attach directly to leaf nodes
and propagate up the tree. If a constraint fails, the root validity is
false. A counterparty can reject a
proof based on constraint violations without ever seeing the masked fields.
Multiple counterparty approvals across versions of a business object form
the TrustMesh — the verified execution graph.
Proof-of-Execution is built for two equally important audiences: enterprises replacing unverifiable audit processes, and AI infrastructure requiring independent verification.
Companies claim emissions reductions — the protocol creates independently verifiable proof trails around such claims. Cryptographic records replace unverifiable PDF reports. Directly relevant to EU CSRD and CBAM regulations.
EU CSRD / CBAMEvery step from raw material to delivery is a proven, auditable record. “Green steel” claims backed by on-chain proof of the verified production process — not just a supplier certificate.
Supply ChainEU regulation mandates digital product passports for batteries, textiles, and electronics from 2027. The protocol provides the tamper-proof, machine-readable verification layer.
EU Mandate 2027Proves that supply chain claims — sustainably sourced, certified, conflict-free — actually happened, not just were stated. From fashion to semiconductors.
Cross-IndustryStatic PDF certificates replaced by living, verifiable proof records. Auditors become validators on the network — attestations are on-chain and cannot be backdated.
ComplianceProof that a digital asset was used, when, by whom, and under which license — immutable, machine-readable, and dispute-proof. Applicable to software, content, and data licensing.
Intellectual PropertyThe protocol does not build AI. It verifies the AI of others. As autonomous systems become embedded in critical infrastructure, independent proof of execution becomes essential.
FL participants can submit fake gradients without detection — so-called free-rider attacks. The protocol integrates as a Flower Framework custom strategy: each training round generates a Proof-of-Computation anchored on-chain. Participants stake UBT, train, submit proof — verified rounds earn rewards, unverified or dishonest rounds are slashed.
Flower Framework Integration
AI agents act autonomously but their actions leave no independently
verifiable trail. The protocol implements as an MCP (Model Context
Protocol) server — any Claude, GPT, or Gemini agent can natively call
attest_action,
verify_attestation, and
get_trust_score.
Agent trust scores build on-chain over time. Misconduct is slashed.
C2PA (Content Credentials) uses centralized Trust Lists and Timestamp Authorities — single points of failure. The protocol extends C2PA with blockchain-anchored timestamps, a decentralized Trust Registry via UBT staking, and AI Workflow Provenance records: which model, which parameters, and which training data produced a given output. Any party can verify provenance without trusting a central authority.
C2PA CompatibleEvery proof starts at TL1 and can accumulate trust over time as more independent parties attest to it. Trust is additive, transparent, and on-chain.
The originator generates and signs the proof. Establishes the cryptographic record. Useful for internal workflows and initial proof creation — not yet independently verified.
A business counterparty — buyer, supplier, partner — signs an attestation referencing the proof’s root hash. The TrustMesh begins to form. Suitable for bilateral business agreements.
A registered, staked validator on the network attests to the proof. Validators stake UBT and are slashed for dishonest attestations. Suitable for regulated compliance scenarios.
Three or more independent validators have attested to the proof. The highest standard for enterprise compliance — designed to support auditability and evidentiary integrity in regulated environments.
Reserved for multi-party verification scenarios involving auditors, certification bodies, or broad community attestation. Proofs at TLx carry the highest verification tier within the network and are suitable for regulator-facing reporting and public record.
Each counterparty signature and validator attestation references the proof’s root hash and is recorded on-chain. Multiple approvals across multiple versions of a business object form the TrustMesh — a directed graph where proofs are nodes and attestations are edges. Any party can traverse the TrustMesh to audit the full history of a proof, from initial creation through every subsequent attestation.
ProofMatter, the Proof-of-Execution protocol, is an active development project by Unibright / SPO Consulting GmbH. All phases and timelines are subject to change.
Learn how UBT powers the protocol, or get in touch to discuss enterprise integration.