Appendix C. The SDK (Proofs-as-a-Library)

Jason St George. "Appendix C. The SDK (Proofs-as-a-Library)" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.1. /v/3.1/read/appendix/c-sdk/

The SDK (Proofs-as-a-Library)

At the top of the stack, the application layer, you work with a small vocabulary:

• “Prove this computation.”

• “Prove this provenance.”

• “Settle this payment under these privacy and finality constraints.”

• “Anchor this result to hardware with this security profile.”

The SDK turns those sentences into types. A claim is a first-class object: ComputationClaim, ProvenanceClaim, SettlementClaim, optionally decorated with requirements. The compiler and runtime then map those claims to whatever combination of proving backends, settlement rails, and verifiable machines currently clear the SLA at the best VerifyPrice.

Core types:

class Policy:
    max_verify_time_sec: float
    max_verify_cost_usd: float
    privacy_level: str              # e.g. "encrypted_io", "public"
    finality_target: str            # e.g. "1m", "30m", "2h"
    allowed_hardware_profiles: list # e.g. ["open_tee_v1", "pure_zk_only"]

class ComputationClaim:
    fn: Callable
    inputs: Any
    policy: Policy

class ProvenanceClaim:
    media_bytes: bytes
    device_profile: str
    policy: Policy

class SettlementClaim:
    payments: list  # [Payment(recipient, amount, asset), ...]
    policy: Policy

class Receipt:                       # = PIDL receipt, Def. 3 (app:verifyprice)
    receipt_id: str                  # hash of the serialized payload
    claim_id: str                    # hash of the claim being attested
    workload_id: str                 # canonical tag, e.g. "PROOF_2^20"
    proof_ref: str                   # hash/pointer to proof or transcript
    sla_tier: str                    # "bronze" | "silver" | "gold"
    verify_time_sec: float
    verify_cost_unit: float          # in the published reference unit
    result: str                      # "accept" | "reject" | "timeout"
    hardware_profile: str | None
    fer_id: str | None               # Facility Energy Receipt, if bound
    settlement_txid: str | None
    policy_tags: dict                # jurisdiction / policy context
    signatures: list                 # prover, verifier, [broker/router]
    schema_version: str              # "pidl/1"

The Receipt type is the PIDL receipt of Appendix A: Formal Model of Verification Asymmetry & VerifyPrice, Definition 3, field for field; the SDK adds no fields the receipt does not carry, so a receipt exported from one application verifies in another and aggregates into the same VerifyPrice series (§19: Layer 4: Truth & Work). proof_bytes travels alongside the receipt, addressed by proof_ref, rather than inside it.

SDK surface:

sdk = ProofSDK(networks=[...])  # PoUW chains, zk rollups, open-TEE clusters

claim   = sdk.make_claim(...)
receipt = sdk.prove_and_settle(claim, pay_with=user_wallet)
result  = sdk.verify(receipt)   # -> {accept: bool, metadata: ...}

Everything else—choice of proving backend, choice of settlement rail, choice of hardware profile—is a routing decision made under the hood, constrained only by the policy you declared.

Error model.

Every call either returns a Receipt whose result is accept, or raises. Failures are typed, not silent: PolicyUnsatisfiable (no backend clears the declared Policy at the current VerifyPrice — the SDK never quietly relaxes a policy to find a route); ProofRejected (a receipt with result = reject, returned inside the exception so the rejection itself is evidence); VerifyTimeout (result = timeout, counted in $\text{fail}(W)$); and, for settlement claims, SettlementAborted, which carries the refund receipt — a settlement that fails must end in refund_safe, and an abort path that cannot produce a refund receipt is a Red Line 2 incident, not an SDK error. Rejected and timed-out receipts are emitted to telemetry exactly as accepted ones are; a client that drops them corrupts the failure-rate field of every series it feeds.

Versioning.

Receipts, policies, and hardware-profile identifiers are versioned independently and each carries its own tag: schema_version on receipts (pidl/1), a policy_version on policies, and the trailing _vN on profile strings (Appendix E: Hardware Profiles). The SDK follows semantic versioning; a change to receipt fields or to the meaning of a policy field is a major version. A verifier must reject a receipt whose schema version it does not recognize rather than verify the subset it understands, and observatories publish VerifyPrice series per schema version until a migration completes, so a schema change is never mistaken for a cost change.

Example 1: Proofed medical inference on verifiable machines

policy = Policy(
    max_verify_time_sec = 1.0,
    max_verify_cost_usd = 0.001,
    privacy_level = "encrypted_io",
    finality_target = "30s",
    allowed_hardware_profiles = ["open_tee_v1", "pure_zk_only"]
)

@proofed(policy=policy)
def diagnose(image: EncryptedImage) -> Diagnosis:
    return model.predict(image)

# In request handler:
claim   = sdk.make_computation_claim(fn=diagnose, inputs=enc_image, policy=policy)
receipt = sdk.prove_and_settle(claim, pay_with=clinic_wallet)
result  = sdk.verify(receipt)

Example 2: Camera provenance anchored in open hardware

# On capture (running on "open_camera_v1" device):
raw_bytes = camera.capture()

policy = Policy(
    max_verify_time_sec = 0.5,
    max_verify_cost_usd = 0.0005,
    privacy_level = "hide_location_and_identity",
    finality_target = "5m",
    allowed_hardware_profiles = ["open_camera_v1"]
)

prov_claim = sdk.make_provenance_claim(
    media_bytes=raw_bytes,
    device_profile="open_camera_v1",
    policy=policy
)

receipt = sdk.prove_and_settle(prov_claim, pay_with=newsroom_wallet)
bundle = MediaBundle(media=raw_bytes, provenance_receipt=receipt.export())

Example 3: Private payroll over neutral rails

policy = Policy(
    max_verify_time_sec = 3.0,
    max_verify_cost_usd = 0.002,
    privacy_level = "shielded_settlement_with_auditable_receipts",
    finality_target = "2h",
    allowed_hardware_profiles = ["pure_zk_only"]
)

# Amounts are in the base asset (placeholder symbol NATIVE). A stablecoin
# leg here would be a Value-Capture Condition 1 bypass (part-ii,
# lem:value-capture) and appears in none of the reference applications.
payroll_batch = [
    Payment(recipient=alice_addr, amount=1000, asset="NATIVE"),
    Payment(recipient=bob_addr,   amount=1200, asset="NATIVE"),
]

settle_claim = sdk.make_settlement_claim(payments=payroll_batch, policy=policy)
receipt = sdk.prove_and_settle(settle_claim, pay_with=treasury_wallet)

The asset choice in that batch is not incidental. The Value Capture Lemma’s first condition (§10: Work Credits: Energy-Anchored Claims) is that users cannot pay in fiat, stablecoins, or other tokens at equivalent service quality, and §10: Work Credits: Energy-Anchored Claims names dollar stablecoins as the incumbent bypass channel; a reference application that settled payroll in one would be demonstrating the failure mode the thesis is instrumented to detect. NATIVE is a placeholder for whatever the base asset’s ticker becomes; the reference applications carry no other settlement asset.

New here? Start with the one-minute version.

Tip: hover a heading to reveal its permalink symbol for copying.