QED Proof
Start free
Menu

How QED Proof turns a claim into proof

Five steps, from the moment an agent says it's done to a receipt no one can quietly change.

  1. 1

    Your agent makes a claim

    The claim names an action, a target and a deadline. The agent sends it the moment it thinks it's done.

    The claim
    POST /v1/claims
{ "agent_id": "release-bot",
  "action": "github.commit.push",
  "target": "Nuraveda-Labs/qed-proof",
  "params": { "branch": "main", "sha": "a1b2c3…" } }
  2. 2

    QED Proof checks the destination

    After the deadline, a verifier reads GitHub or the web directly, with read-only access. An error, a timeout or a missing permission gives Couldn't check, never Verified.

    Reads
    GitHub API, public URLs
    Never reads
    the agent's own logs or report
    Retries
    until the deadline, then decides
  3. 3

    A signed receipt

    The verdict and the evidence it rests on go into a receipt, canonicalised and signed with Ed25519. QED Proof stores fingerprints, not your content.

    VerifiedFailedMismatchLateCouldn't check
  4. 4

    An append-only log

    Receipts are leaves in an RFC 6962 Merkle log. Each receipt carries a proof that it's in the log. Removing or editing one would break every later root.

    Leaf
    sha256(0x00 ‖ receipt)
    Proof
    O(log n) inclusion path
  5. 5

    Anchored on Base Sepolia

    Every ten minutes, when there are new receipts, QED Proof records the log's root on Base Sepolia (testnet) as an EAS attestation; mainnet is next. After that, not even QED Proof can backdate a receipt.

    Chain
    Base (Sepolia today)
    Attester
    0x23a8…e523
    Schema
    0x8c23…28ec