Technical Proof

Live anchoring evidence

The most recent index snapshot and its SHA-256. Anyone can re-download the canonical bytes, re-hash them, and compare against the anchors recorded on the ledgers listed above.

1. Open the snapshot JSON and compute its SHA-256 - it must equal the hash in this table.
2. Call SnapshotAnchor.isAnchored(hash) on Flare, or open the anchor transaction and check it carries the same hash. Runs before 23 September 2026 also carry a legacy anchor: the IndexAnchored event on BNB Chain and the payment memo on XRPL.
3. The city values you purchased must match the values inside the snapshot.

How the anchor is built

Since 2026-09-23 the anchor of record is one call on Flare: the publisher key writes SnapshotAnchor.anchor(sha256, date, runId), the contract stores the block number and timestamp, and it refuses to overwrite a hash that already exists - the first timestamp is the evidence. DeterminationRegistry reads isAnchored(sha256) to mark a verdict settlement-grade. What an anchor proves is that this hash was published by our key before any dispute existed; the Flare block timestamp now plays the role the XRPL ledger timestamp played in v2.

Before that, the same hash was written into a memo on a 1-drop XRPL payment between two accounts we control, and XrplAnchorVerifier proved it on Flare through an FDC XRPPayment attestation. Those 994 legacy anchors remain verifiable and the accounts stay published above; no new memo anchors are sent. The shape, for checking the old ones:

// what the XRP Ledger receives for one snapshot anchor
Payment
  Destination     <anchor account below>
  Amount          "1"                    // 1 drop of XRP - the memo is the point, not the value
  DestinationTag  20260919               // the run's UTC date, YYYYMMDD
  Memos[0].Memo
    MemoType      "wdm/index-anchor"
    MemoData      <snapshot SHA-256>     // 32 bytes - fits one memo field exactly

// Why native XRP and not RLUSD, on an anchor that carries no value:
// Flare's FDC XRPPayment attestation covers native XRP only, and its response exposes
// firstMemoData and destinationTag. Keeping this shape means a Flare contract can later
// verify the same anchor trustlessly; an RLUSD anchor could not be attested at all.

Payment is native XRP and is verified against the ledger: the amount actually delivered (in drops, not the amount sent) must cover the drops fixed in the quote, and a DestinationTag issued with the quote binds the payment to that order. The quote converts the USD price at the FTSOv2 XRP/USD rate on Flare when it is issued and is valid for ten minutes. XRPL has no smart contract to recompute the price, so that binding and the public ledger take the place of on-chain price enforcement - and because the payment is native XRP, the same FDC XRPPayment attestation that proves anchors can prove a payment to a Flare contract.

Flare Confidential Compute - signature chain implemented, hardware attestation not yet

What is built: the consumer contract accepts a result only if the signature chain below recovers to the configured TEE address, and the enclave is a Go program whose build is byte-for-byte reproducible, so anyone can rebuild it and compare the code hash. What is not yet true: the enclave currently signs with a test key on the Coston2 testnet, not a production Confidential Space instance, so the chain proves the result came from whoever holds that key - not that it came from attested hardware. Treat this as a demonstrated mechanism, not an active guarantee:

// WeatherFccConsumer.sol - signature chain verified on every TEE result
resultHash = keccak256(abi.encodePacked(
    keccak256(resultData),   // hash of the raw data produced inside the enclave
    actionId,                // request identifier (issued by requestWeather)
    keccak256(bytes(tag)),   // action tag (e.g. "kweather-fetch")
    status                   // execution status code
));
digest = keccak256(abi.encode("TEE_ACTION_RESULT", block.chainid, resultHash));
signer = ecrecover(EIP191(digest), v, r, s);   // personal_sign prefix
require(signer == teeAddress);                  // accepted only if it recovers to the TEE key

The full request → confidential fetch → signed relay loop passes end to end (fcc-extension/e2e.mjs), the Go enclave rebuilds to an identical hash from a cold cache and a different directory (fcc-extension/go/verify-reproducible.sh), and its output is pinned byte-identical to the reference implementation by a golden vector. Those parts are verifiable today. Production attestation waits on FCC reaching production on Flare - it is not available on mainnet yet, which is why this path stays on Coston2.

// BlindSettlement.sol - what the chain receives for a blind settlement
(uint32  cityId,
 uint64  evaluatedAt,
 bytes32 conditionCommitment,   // keccak256(cityId, metric, op, thresholdE2, salt)
 uint8   outcome,               // 0 not met · 1 met · 2 no verdict (< 3 sources)
 bool    settleable,
 uint8   nSources,
 bytes32 indexCommitment,       // keccak256(temp*100, humidity, wind*100, rain*100, indexSalt)
 bytes   sealedReport)          // wdm-seal-v1, opens only with the requester's key
// no threshold · no index · no per-source reading - anywhere on chain

Reproduce it yourself

All verification is offline-capable: hash the downloaded bytes with any SHA-256 tool and compare with the on-chain values. Runnable references: app/scripts/agent-e2e.mjs (purchase), app/scripts/agent-percall-e2e.mjs (metering), contracts test suite (33 passing), fcc-extension/e2e.mjs (TEE loop).