Certification

Explain what a digital certificate is, and how our system works end‑to‑end to create them.

What is a certificate? See example here.

Why you need this

City fleets (buses, trams, service vehicles) face increasing requirements to prove operational and environmental performance. Our system provides verifiable telemetry anchored on a blockchain so any stakeholder can independently check claims.

Key benefits

  • Regulatory compliance and audits: Produce tamper‑evident evidence for emissions caps, low‑emission zones, and ESG reporting.
  • Subsidies and incentives: Prove CO₂ reductions (or other metrics) to qualify for grants and credit programs.
  • Public trust and transparency: Share verifiable facts with city officials and citizens without revealing raw personal data.
  • Fleet optimization and maintenance: Confirm data integrity for diagnostics and preventive maintenance analytics.
  • Supply‑chain and vendor neutrality: Proofs live on a public ledger, so verification does not depend on trusting Staex.
  • Insurance and contracts: Offer strong evidence in performance‑based contracts (e.g., pay‑for‑clean‑miles).

What is a digital certificate?

A digital certificate is a JSON document that summarizes a period of telemetry (e.g., CO₂ readings for one week for Bus #42) and references on‑chain anchors of the underlying raw data. The certificate itself does not need to exist on‑chain; instead it points to the first and last blockchain transactions that anchor the raw telemetry for the certified period. Anyone can recompute the summary from trustworthy data and confirm that nothing was tampered with.

Certificate JSON fields

  • min, max, avg: Aggregate values over the chosen period.
  • device_name: Human‑readable name (e.g., "bus‑042").
  • device_public_key: Ed25519 public key used by the device to sign telemetry.
  • start_tx_external_id, end_tx_external_id: IDs of the first and last on‑chain transactions that anchor telemetry for the certified interval.
  • user_name: Name of the organization issuing the certificate.
  • created_at: timestamp of issuance.

The raw telemetry is off‑chain in user's database; the hashes and signatures for each data point are on‑chain.

{
    "avg": 10273.33,
    "created_at": "2025-10-21T07:25:22Z",
    "device_name": "mibo67",
    "device_public_key": "b0d41c8fcac6d75a9fb87b6f4537120835b9eb9c9cd30cec49fd1883c13d5f9d",
    "end_tx_explorer": "https://u2uscan.xyz/tx/0x18b892a53f59a5e43a021c94072979b6a86967333fa256836a12098a295186f5",
    "end_tx_external_id": "0x18b892a53f59a5e43a021c94072979b6a86967333fa256836a12098a295186f5",
    "max": 13400,
    "min": 5360,
    "start_tx_explorer": "https://u2uscan.xyz/tx/0xe70d4a073b6f4910c051008a28d11612654c7bbec0b0aea3f71005c58bf91c19",
    "start_tx_external_id": "0xe70d4a073b6f4910c051008a28d11612654c7bbec0b0aea3f71005c58bf91c19",
    "status": "ok",
    "user_name": "Staex"
}

How it works

  1. Capture: Each vehicle device measures telemetry (e.g., CO₂).
  2. Hash & sign: For each reading, the device computes a SHA‑256 hash of the payload and signs the payload (or hash) with its Ed25519 private key.
  3. Anchor on‑chain: We publish a transaction that contains the hash and signature (plus the device public key or a reference to it). This creates an immutable, timestamped anchor.
  4. Store off‑chain: The full telemetry payload is stored in user's database with a pointer to the on‑chain transaction.
  5. Certify a period: To prove a vehicle’s performance for a time window, we query the database for that period, compute aggregates (min/max/avg), and include the first and last on‑chain transaction IDs that cover the window.
  6. Verify: Anyone can fetch the raw telemetry for the same window, recompute hashes, check signatures with the device public key, and confirm that those hashes exist on‑chain between first_tx and last_tx. If everything matches, the certificate is valid.