Skip to main content
The claims contract is the on-chain consumer of zkTLS claims. It knows which verifier keys are valid on this network, checks a claim’s signature and time, and records each payment nullifier once.

​
Functions

verify checks the signature last, because Soroban’s ed25519_verify panics on failure instead of returning an error.

​
What a claim must bind

The orchestrator accepts a verified claim only if:
  • satisfied is true. Every predicate in the payment policy held.
  • The policy is the one registered for the order’s rail and direction.
  • The context_digest matches the order. The contract recomputes it from on-chain data, so a claim made for one order cannot settle another.
  • The nullifier is unspent.

​
Network binding

Verifier keys are registered per network, and the network is part of the claim’s domain. A claim signed for testnet fails on a mainnet orchestrator.

​
Why the contract checks a signature, not the proof

The payment proof is an interactive zero-knowledge proof between the phone and an attested verifier. It is not a succinct proof that a contract can check by itself. The verifier runs in an AMD SEV-SNP enclave, checks the capture receipts and the proof, and signs the claim with a per-epoch key that never leaves the enclave. The contract trusts that key through the registry. See the trust model.