WEAVE is an open framework for making trust-minimized Claims about your assets. Claims are backed by cryptographic Proofs and bundled into Attestations.
Anybody can verify them independently to generate Verifications.
Intrinsic claimvalues you directly witness or gather
Aggregated claimvalues derived from other claims (sum, and/or, greater_than, etc)
Reference claimpointers into structured data (json, xml)
02
AnyProof
Each intrinsic claim carries its own proof. Each datatype supports a specific set of Proofs.
Wallet signatureprivate key signature
Onchain referenceasset balance for a specific blockchain/block
Vlayer Web ProofsTLSNotary attests an HTTPS response
Merkle Proofproved Merkle tree inclusion
ZK Proofselective and verifiable disclosure
03
AnyVerifier
Verifiers independently re-confirm the attestation and sign a verification.
DAG integrityverify claims form a valid DAG
Proof validityverify each proof independently
Recompute everythingreplay aggregations and references deterministically
Envelope Signaturecheck the attester signature
Permissioned or openwhitelist specific verifiers, or allow anyone to verify
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 and how to prove it
Choose the values you can stand behind and the kind of verifiable proof you can provide for each: a signed measurement, an onchain balance, a notarized HTTPS response, or a value derived from other claims.
2
Select a runtime environment
Each runtime environment has its own strengths and weaknesses: a regular backend process, a Chainlink CRE workflow, or a secure enclave. WEAVE is infra-agnostic.
3
Generate an Attestation
The framework topologically orders your claims into a DAG, signs the envelope with ECDSA, and emits a canonical JSON: deterministic, byte-for-byte reproducible.
4
Select a storage layer
Attestations/Verifications are self-contained JSON documents that can be published anywhere: onchain, IPFS, Arweave, or behind an HTTP API. WEAVE is storage-agnostic.
5
Allow for permissioned or open verification
One or more Verifiers re-confirm every claim and return a signed Verification. Restrict to a set of trusted third parties, or let anyone check.
Runtime
Runtime agnostic to fit your needs.
3 runtime environments are supported for generating Attestations/Verifications:
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 on which 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 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 only.
In code
Code example.
Stablecoin issuer Meridian reserve attestation for mUSD: wallet control, onchain reserves, a notarized
price feed and an independent audit, woven into one signed DAG.
reserve-attestation.ts
import {...} from"weave";
const meridian = awaitgenerateKeyPair(); // the issuer signs the attestation envelopeconst auditor = awaitgenerateKeyPair(); // independent auditor signs externally, shown for demo purposesconst WALLET = "0xd8da6bf26964af9d7eed9e03e53415d37aa96045"; // EVM reserve treasury// Fordefi MPC example: personal_sign request to the vault; the threshold key co-signs (EIP-191), no raw key ever exposed.const newFordefiRemoteSigner = ({ vaultId, accessToken }) => ({
signMessage: (msg) => fordefi.personalSign({ vaultId, accessToken, message: msg }),
});
const walletSigner = newFordefiRemoteSigner({ vaultId: FORDEFI_VAULT_ID, accessToken: FORDEFI_API_TOKEN });
// the treasury wallet signs an ownership message bound to "meridian".const walletClaim = NewEvmWalletClaim("wallet", WALLET);
// Treasury reserves, both read on-chain at a fixed block: USDC via erc20const usdcReserveClaim = NewErc20BalanceClaim("usdcReserve", 8_200_000_000_000n, 6, USDC, "USDC", WALLET, 1);
const ethReserveClaim = NewEthBalanceClaim("ethReserve", 4_200_000_000_000_000_000_000n, WALLET, 1); // 4,200 ETH (wei)// ETH/USD spot, proven straight from the price API over TLSNotary (Vlayer)const { claim: ethUsdClaim, proof: ethUsdProof } =
awaitcreateVlayerWebProof({ id: "ethUsd", request: { url: PRICE_API } }, vlayer);
// Auditor's signed PDF report, fetched + sha256-checked at verify time, not inlined on the wire.const auditReportClaim = NewSourceClaim("auditReport", "pdf", { locator: "https", url: AUDIT_PDF, sha256: "9f2c…" });
// One-line summary of the total USD value the issuer's circulating mUSD must be backed by.const auditSummaryClaim = NewStructuredTextClaim("auditSummary", "Auditor: Halberd & Co\nTotalBackingUSD: 21000000");
const attestation = awaitnewAttestationBuilder("meridian", meridian)
// Intrinsic claims — each carries its own proof scheme.
.addIntrinsicClaim(walletClaim, awaitcreateEvmSignedMessageProof(walletClaim, { attester_id: "meridian", wallet: walletSigner }))
.addIntrinsicClaim(usdcReserveClaim, createEvmBalanceProof(usdcReserveClaim, { block_number: 18_500_000n }))
.addIntrinsicClaim(ethReserveClaim, createEvmBalanceProof(ethReserveClaim, { block_number: 18_500_000n }))
.addIntrinsicClaim(ethUsdClaim, ethUsdProof)
// Foreign witnesses — the auditor signs its PDF report and the USD statement.
.addIntrinsicClaim(auditReportClaim, awaitcreateEcdsaProof(auditReportClaim, auditor), pdfBytes)
.addIntrinsicClaim(auditSummaryClaim, awaitcreateEcdsaProof(auditSummaryClaim, auditor))
// Reference claims — the ETH price (a numeric scalar) and the auditor's figure.
.addReferenceClaim("treasuryAddr", "#wallet/address", "string")
.addReferenceClaim("usdcHolder", "#usdcReserve/holder", "string")
.addReferenceClaim("ethUsdPrice", "#ethUsd/@jsonDecode(result)/price", "numerical_with_decimals")
.addReferenceClaim("backingUsd", "#auditSummary/@tableDecode(.)/0/TotalBackingUSD", "numerical")
// Aggregated claims, recomputed by every verifier.
.addAggregationClaim("selfCustodied", { operation: "equal", operands: ["#treasuryAddr", "#usdcHolder"] })
.addAggregationClaim("ethReserveUsd", { operation: "multiply", operands: ["#ethReserve", "#ethUsdPrice"] })
.addAggregationClaim("totalProvedBackingUsd", { operation: "add", operands: ["#usdcReserve", "#ethReserveUsd"] })
.addAggregationClaim("backingSufficient", { operation: "greater_than_or_equal",
operands: ["#totalProvedBackingUsd", "#backingUsd"] })
.build();
Let's get in touch now.
We can assist you in building your Proof-of-Reserves, and more. Recurring services
include:
Run Attestation and/or Verification services for you
Access WEAVE artefacts through our public web explorer
Access WEAVE artefacts through our private HTTP API
Visualize claim values over time through our public dashboard