Signed receipts: why every API response carries one

Every call produces a signed JSON receipt. Auditor-ready, regulator-ready, end-customer-attributable. Here's the why.

Every API response Joule Cloud sends includes a header pointing to a signed receipt. Here's why we do it, and what you do with them.

The problem receipts solve

A cloud bill is usually a single number: "You owe $14,328 for AWS this month." The provider's billing pipeline produces that number from raw event streams the customer never sees. If you want to know why — which queries cost what, which container ran where, which model was used for which inference — you reverse-engineer it from your own observability. The hyperscaler's billing pipeline is a black box and a leap of faith.

This becomes a problem when you have to defend the bill. To your CFO, sure. But increasingly: to an auditor, to your CSRD assessor, to your AI Act regulator, to your own customers who want to attribute carbon back to specific transactions. "Trust me" stops being good enough.

Receipts as primary evidence

A Joule Cloud receipt is a small signed JSON document covering one workload run:

{
  "receipt_id": "rcpt_018a3c...",
  "workload": { "id": "chatcmpl_3a91...", "kind": "ml-inference" },
  "silicon":  { "vendor": "nvidia", "model": "H100 SXM5 80GB",
                "operator": "Nebius", "region": "eu-fi" },
  "execution": { "start_unix_ns": 1782219834000123456, "duration_ms": 312 },
  "energy":   { "total_joules": 0.31, "method": "nvidia-smi-power-draw",
                "method_confidence": "measured-direct" },
  "carbon":   { "gco2eq_total": 0.07, "grid_intensity_gco2_per_kwh": 110 },
  "operator": { "legal_entity": "Nebius B.V.", "dc_pue": 1.15 },
  "verification": { "signature_algo": "ed25519", "signature": "9c6...",
                    "tier": "L2" }
}

The receipt is signed with an ed25519 signature produced by a 3-of-5 FROST threshold quorum. The signing key never exists as a single secret; three of five independent signers must agree. Anyone with the operator's public key can verify the receipt without trusting us.

Why FROST 3-of-5

Because "trust me, we signed it" isn't materially different from "trust me, the bill is right". If our signing key were a single secret, a hostile insider or a successful breach could forge receipts retroactively. The FROST threshold construction means:

• The key never gets reconstructed in any single process or hardware device.
• Any three of five independent signers (separate operators, separate keys) can produce a valid signature; fewer than three cannot.
• Compromise of two signers is insufficient to forge.
• The verifier needs only the public group key.

This is the IETF threshold-signature standard (RFC 9591). Our Rust implementation, jouleclaw, is open-source.

What you do with them

Defend the bill

Your monthly bill is the sum of receipts in your account's billing window. If a line item looks wrong, you can find the specific receipt(s) and inspect what happened: silicon, region, duration, joules, method-confidence. "This 4,000 J spike was your fine-tuning job on 2026-06-12, running on H100 in eu-fi for 23 minutes." No mystery.

File CSRD ESRS E1 Scope 2 cloud emissions

The Corporate Sustainability Reporting Directive requires you to disclose Scope 2 emissions, with cloud computing increasingly under specific scrutiny. Receipts are primary evidence: per-workload energy, per-workload carbon, per-workload operator's legal entity, signed. Run jc compliance export --format esrs-e1 --period q2-2026 and hand the output to your auditor. No more "we estimated the cloud share at 6%".

Answer AI Act Annex XI energy-disclosure

For AI systems above certain thresholds, the EU AI Act will require providers to disclose energy consumption of training and (more controversially) inference. Receipts contain per-inference energy and the model + silicon that produced it. Auditable.

Attribute energy per end-customer

If you run a multi-tenant SaaS, each of your customers' usage of your AI feature is currently invisible to your billing. Pass X-Customer-Tag: cust_xxxx with each call; the tag appears on the receipt; you can split your monthly bill back across your customer base, accurately. Some teams turn this into a paid feature: per-customer carbon attribution that they sell as part of their own ESG offering.

The verifier ships separately

The jc receipt verify command is a single binary. A separate jouleclaw verify binary (no Joule Cloud auth required) exists for auditors who want to verify receipts without an account. Both are open-source.

# anyone, anywhere, can run this
jouleclaw verify --pubkey operator-pubkey.hex receipt.json
# Verified: 1 passed, 0 failed

What receipts are not

• They are not invoices. The bill aggregates receipts; the invoice is what your finance system pays.
• They do not contain payload content. We never log prompts or response bodies. The receipt has operational metadata only.
• They are not a substitute for your own observability. They tell you what we measured; your APM tells you what your code did.

What's next

Receipts are mandatory and free across every Joule Cloud surface starting now. The verifier is stable. The schema is versioned (v1.0) and will not break.

If you'd like a deeper walkthrough of the receipt format, see Energy receipts. If you want to integrate verification into your CI / audit pipeline, see the CLI reference.