Verify a certificate
Aquadrio's independence is not a claim you have to take on trust. Download a real sample certificate and confirm every figure yourself, offline, with no issuing authority and no Aquadrio software.
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.
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 RCC 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.