Energy receipts

Every request and every workload run on Joule Cloud produces a receipt. The receipt is a small JSON document carrying what ran, where it ran, how much energy it consumed, and a cryptographic signature so an auditor can confirm nothing was edited after the fact.

The bill is the receipts. The receipt is the audit trail.

What a receipt looks like

{
  "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,
    "peak_watts": 547,
    "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,
    "dc_ref_renewable_share": 0.99
  },
  "verification": {
    "signature_algo": "ed25519",
    "signature": "9c6563f6a7d4…",
    "tier": "L2"
  }
}

The fields, briefly

Section	What it tells you
`workload`	What ran — the kind, the id, your custom labels
`silicon`	Which chip on which node served it
`execution`	Wall-clock start and duration
`energy`	Joules consumed, plus how we measured them and how confident we are. See What is a joule, here
`carbon`	CO₂eq derived from the local grid mix at the moment the request ran
`operator`	The legal entity that operates the data centre, plus published PUE / renewable share
`verification`	Cryptographic signature over the entire receipt

How signatures work

Receipts are signed with ed25519 using a FROST 3-of-5 threshold key (the operator's group public key is published in the console under Security). The signing layer is a Rust CLI based on the IETF FROST standard, so the signing key is never reconstructed in any single process — a quorum of independent signers produces each signature.

To verify a receipt outside the console: pull the operator's public key from the portal, take any signed receipt JSON, and run the verifier:

jc verify --key signer_pubkey.hex receipt.json
# Verified: 1 passed, 0 failed

Where receipts live

In the response header — X-Receipt-Id on every successful response
In the console — searchable, exportable
Via API — GET /v1/receipts/<id> returns the full JSON
In bulk — jc export --since 30d writes them as a tar of newline-delimited JSON

What you can do with them

The point of receipts is to make the bill defensible — to you and to anyone you have to explain the bill to.

Reconcile spending against your own observability stack: a usage spike on your side should match a joule spike on ours, line for line.
Track per-customer carbon: if you sell your AI feature to clients, attribute the joules + carbon back to each client transaction.
File CSRD / ESRS E1 Scope 2 cloud emissions: the receipts are primary evidence, signed, with hardware attestation. Your auditor can verify them independently.
Answer the EU AI Act Annex XI energy-disclosure question: receipts include per-inference energy — what regulators will eventually ask for.

Privacy

Receipts contain operational metadata (joules, silicon, region) but never your payload. We do not log prompt content or response content into the receipt. If you supply a X-Customer-Tag header with each request, that tag appears on the receipt and you can use it to attribute receipts to your own end-customers; nothing else is recorded.

To see how the silicon-side energy comes to be in the receipt, read What is a joule, here. To see how the silicon got picked, read Routing & placement.