Any claim,
Any proof,
Any verifier

WEAVE allows digital asset issuers to publish Attestations containing multiple Claims about their assets. Each Claim is backed by cryptographic Proofs. Verifiers can verify Attestations independently and publish Verifications.

Get started How it works →

The model

A modular and open framework for Web3

WEAVE is built to support any kind of claim and proof you could think of.

Any Claim

Three kinds of claim, many datatypes — composed into a single Directed Acyclic Graph (DAG).

Datatypes numbers, decimals, booleans, strings, objects, ERC-20 balances, etc
Intrinsic claim values you directly witness and prove
Aggregated claim values derived from other claims
Reference claim pointers into structured data

Any Proof

Each intrinsic claim carries its own proof. Schemes are pluggable and pinned to the datatypes they can attest.

Wallet signature public/private key pair signature
Blockchain reference balance read at a named block
Vlayer Web Proofs TLSNotary attests an HTTPS response
Merkle Proof proved Merkle tree inclusion
ZK Proof selective and verifiable disclosure

Any Verifier

Verifiers independently re-confirm the attestation and signs a report.

DAG verify claims form a valid DAG
Proof verify each proof independently
Recompute replay aggregations and references deterministically
Signature check the attester key over canonical JSON
Permissioned or open whitelist specific verifiers, or anyone

The process

From something you claim to a proof anyone can check.

Five steps take a claim out of your system and into a document the world can verify without trusting you.

1

Decide what to claim

Choose the values you can stand behind and the kind of verifiable proof you can provide for each — a signed measurement, an on-chain balance, a notarized HTTPS response, or a value derived from other claims.

IntrinsicAggregatedReference
2

Select a runtime environment

Each runtime environment has its own strengh and weaknesses. WEAVE is infra-agnostic.

Chainlink CRESecure enclaveBackend process
3

Select a storage layer

Attestations and Verifications are self-contained documents. WEAVE is storage-agnostic.

Onchain registryIPFSArweavePostgreSQL
4

Generate & publish an Attestation

The framework topologically orders your claims into a DAG, signs the envelope with ECDSA P-256, and emits canonical JSON — deterministic, byte-for-byte reproducible.

Canonical JSONECDSA envelopeUUID + versioning
5

Verification — permissioned or open

One or more Verifier re-confirms every claim and returns a signed report. Restrict to a set of trusted third-partiers, or let anyone check.

N verifiersOpen or permissionedThird-party report

Runtime

Runtime agnostic to fit your needs.

A WEAVE deployment is made of two types of processes: one that creates the attestation, and N that verify it. 3 runtime environments are supported:

Chainlink CRE

Tamper-proofReliable

Runs across a decentralized node network, with consensus over the result.

Pros

No single point of failure — built-in redundancy and high availability
Execution is tamper-proof: the network agrees the agreed code ran
Strong assurance for high-stakes or adversarial settings

Cons

Higher latency and cost per run
More moving parts to operate and reason about

Secure enclave

Tamper-proofCentralized

Runs inside a hardware TEE that remotely attests which code executed.

Pros

Tamper-proof, confidential execution — signing keys never leave the enclave
Remote attestation proves exactly which binary ran
Cheaper and faster than a decentralized network

Cons

Single point of failure until you add your own redundancy
Side-channel CVEs and attestation plumbing to keep up with

Offchain service

SimplestLowest costCentralized

An ordinary server, container or function that you operate.

Pros

Simplest, cheapest and fastest to build and run
Any language, any infrastructure — total flexibility
Plenty when the attester is trusted or the proofs stand on their own

Cons

No tamper-proof protection or guarantee
Single point of failure until you add your own redundancy

A common pattern: the single attester on a CRE or secure enclave for high-stakes claims, while verifiers run on plain offchain services and lean on the cryptographic proofs and envelope signature only.

In code

Code example.

The attester signs once; any verifier re-checks every claim and recomputes every derived value, then returns a signed report. Each step emits a self-contained canonical-JSON document.

attest.ts

import {
  AttestationBuilder,
  generateKeyPair,
  NewNumericalClaim,
  NewAggregatedClaim,
} from "weave";

const aliceKey = await generateKeyPair();

// Bundle witnessed values + a derived total into one signed DAG.
const attestation = await new AttestationBuilder("alice", aliceKey)
  .addClaim(NewNumericalClaim("rev-us", 125_000_000n))
  .addClaim(NewNumericalClaim("rev-eu",  98_000_000n))
  .addClaim(
    NewAggregatedClaim("rev-total", "sum", ["#rev-us", "#rev-eu"]),
  )
  .build();

↓ attestation — wire form

{
  "version": "0.12.0",
  "id": "35e64efe-…",
  "attester": { "id": "alice", "public_key": "MFkw…" },
  "created_at": "2026-05-21T16:43:42.756Z",
  "claims": [
    {
      "id": "rev-us",
      "datatype": "numerical",
      "value": "125000000",
      "proof": { "type": "ecdsa_p256_sha256", "public_key": "MFkw…", "signature": "8WlS…" }
    },
    {
      "id": "rev-eu",
      "datatype": "numerical",
      "value": "98000000",
      "proof": { "type": "ecdsa_p256_sha256", "public_key": "MFkw…", "signature": "kP2x…" }
    },
    {
      "id": "rev-total",
      "datatype": "numerical",
      "aggregation": { "operation": "sum", "operands": ["#rev-us", "#rev-eu"] }
    }
  ],
  "signature": { "type": "ecdsa_p256_sha256", "value": "JZC8…" }
}

Any claim, Any proof, Any verifier

Any Claim

Any Proof

Any Verifier

Decide what to claim

Select a runtime environment

Select a storage layer

Generate & publish an Attestation

Verification — permissioned or open

Chainlink CRE

Secure enclave

Offchain service

Let's get in touch now.

Any claim,
Any proof,
Any verifier