Check it yourself.
Paste a certificate identifier and see the hour it was issued for, the gates it cleared, the version it was graded under, and whether the record still matches.
No hour on MISO-Central cleared both gates in the trailing year, so no certificate has been issued on that grid. The checker is here because a record you cannot check is a claim.
The sample certificate
This is the credential the files below encode: one Renewable Compute Credit, its signed provenance fields on the face, its recomputable sha256 in the provenance strip. It is a specimen of a simulated workload, marked as such. Every figure on it is a signed field of the JSON you can download and check.
The uncoolable upstream figure: the water consumed generating this job's electricity, recomputed from the certificate's own per-window generation mix using the Standard's published factors. It is derived, off-hash, and shown with the recompute recipe on the verification page. Water consumed, never withdrawn.
Measured or computed from live data now.
The board's own reading under load, not independent.
Derived from published figures, labeled.
Specified and severable, not built yet.
The bundle
Three files: the certificate, the same certificate as a signed JSON record, and a zero-dependency verifier that runs on any recent Node. These are the exact files handed out offline; the repository's leave-behind bundle is the source of truth and this page serves a synced copy.
Run it
With all three files in one folder, run the verifier against the signed JSON:
node verify_rcc.mjs sample_rcc_cert.signed.jsonIt recomputes the sha256 from the certificate's own inputs and confirms it matches the hash on the certificate. The exit code is driven solely by the hash, so an unsigned or older certificate still verifies. If a signature block is present, the verifier prints an additional line confirming the embedded public key signed this certificate's canonical bytes. The public key rides inside the envelope, so nothing is fetched.
What the signature proves honestly: that some key signed this exact record, and that the algorithm was not relabeled to look stronger than it is. What it does not yet prove: whose key it is. A local-dev marker means a non-production key. Binding a key to a trusted issuer identity is a trust-store concern outside this zero-dependency verifier.
The recompute recipe (canon v1)
The verifier is one implementation. The canonicalization is fixed and language-independent, so you can reproduce the hash in any language by following this recipe. It is the full specification, summarized; the canonicalization rules are the source of record.
- 01Take the certificate JSON and drop the provenance_certificate_hash field (it is the output, never part of its own input).
- 02Confirm canon_version is "1", then apply that ruleset.
- 03Round each number to its fixed number of decimals with banker's rounding, and emit it as a string.
- 04Render every timestamp in UTC, second precision, with a Z suffix.
- 05Serialize with sorted keys, compact separators, UTF-8 normalized to NFC, and segments in chronological order.
- 06Take the sha256 of those bytes. It must equal the certificate's provenance_certificate_hash.
Indirect (grid) water
Recompute it from the certificate's own generation mix and energy: sum over each fuel of (fuel share × energy in MWh × its consumption factor). The factors are published in the standard. The figure is water consumed, not withdrawn.
The canon version pins the ruleset. A future precision change bumps the version and leaves prior certificates verifiable under their own version, so a certificate never becomes uncheckable.
The energy basis
Every certificate's energy figure normalizes against one constant per hardware type: the board's power draw under a saturating load, read from the board's own telemetry. These are the values in force.
| GPU type | Form factor | kWh / GPU-hour | Mean board power (W) | TDP (W) | Share of TDP |
|---|---|---|---|---|---|
| H100-80GB | SXM | 0.6958 | 695.8 | 700 | 99.4% |
| A100-80GB | SXM | 0.3978 | 397.8 | 400 | 99.5% |
| A100-40GB | SXM | 0.3988 | 398.8 | 400 | 99.7% |
Each hardware type ran a saturating dense matrix-multiply (GEMM) load on a rented SXM instance while the board's own power telemetry (nvidia-smi power.draw) was sampled through the run. The published basis is the mean board power over that run.
This constant is the normalization basis a mint's energy figure derives from. It overlays the modeled TDP defaults, and every certificate carries it as basis_provenance telemetry.
The means land at about 99.5% of each board's rated TDP, which under a saturating load is expected: board telemetry under load is effectively the vendor's number, not an independent reading.
Inside the certificate
Every field on the credit traces to a source, and the whole record recomputes from its own inputs. The sample it describes ships in the verification bundle.
The uncoolable upstream figure: the water consumed generating this job's electricity, recomputed from the certificate's own per-window generation mix using the Standard's published factors. It is derived, off-hash, and shown with the recompute recipe on the verification page. Water consumed, never withdrawn.
Measured or computed from live data now.
The board's own reading under load, not independent.
Derived from published figures, labeled.
Specified and severable, not built yet.