Enterprise · security

Security by design, not by addendum.

Nobody talks to the network without valid credentials. Every reputation and payment event is attributable, non-repudiable, and verifiable by your own team — not because we promise it, but because the architecture makes it so.

The registry is deliberately small. The less it does and the less it sees, the smaller the attack surface for the operators that can't afford to fail.

  • Mutual authentication

    mTLS between nodes and registry — nobody talks to the network without valid credentials.

  • Per-message signatures

    Every reputation and payment event is attributable and non-repudiable.

  • Verifiable credentials

    Issued by the identity service; revocable instantly, network-wide.

  • Least privilege

    The registry is deliberately small — the less it does and sees, the smaller the attack surface.

Authentication & attribution

Credentials in, signatures on, attribution everywhere.

Identity is established before the first message, and carried by every message after it. There is no anonymous traffic on the network and no unsigned event in the record.

Who's allowed to talk

  • Mutual authentication (mTLS) between nodes and registry — nobody talks to the network without valid credentials.
  • Verifiable credentials issued by the identity service; revocable instantly via a revocation list propagated network-wide.
  • Least privilege. The registry is deliberately small — the less it does and sees, the smaller the attack surface.

What's on every event

  • Per-message signatures on every reputation and payment event — each event is attributable.
  • Non-repudiation. A signed event can't later be disowned by the party that produced it.
  • Verification needs no trust in us: the signature stands on its own cryptographic merit.
Data integrity

The ledger is append-only — and you can prove it yourself.

An event can't be altered or deleted retroactively. Cryptographic inclusion proofs let your team verify an event is authentic without trusting our word.Network layer · in build · roadmap

Append-only by construction

  • No retroactive edits. Once written, an event can't be altered or deleted.
  • No retroactive deletes. The historical record is the record — permanently.
  • Reputation and payment events accrete in order; tampering breaks the chain visibly.

Verify without trusting us

  • Cryptographic inclusion proofs confirm an event is genuinely in the ledger.
  • Your team runs the check against the proof — no privileged access, no API trust assumption.
  • Authenticity is a property of the math, not of our goodwill.
How a team verifies an event
  1. event

    Take the event in question

    A reputation or payment record your team wants to confirm is authentic.

  2. signature

    Check the per-message signature

    Confirm the issuing party signed it — attribution and non-repudiation in one step.

  3. proof

    Validate the inclusion proof

    Prove the event sits in the append-only ledger, unaltered — without trusting our word.

  4. verdict

    Conclude, independently

    Authentic or not — a judgement your team reaches on its own evidence.

Operation & practice

Run like critical infrastructure, isolated by plane.

Multi-region operation, isolation between the operation and network planes, and sensitive data kept out of the ledger by policy — backed by a security program sized for operators that can't fail.

Multi-region, plane-isolated

A multi-region registry with isolation between planes — operation versus network — so a fault in one doesn't cross into the other.

Sensitive data out of the ledger

Sensitive data is kept out of the ledger by policy. Access auditing and traceability of governance actions are built in, not bolted on.

Program, testing, response

A security program, penetration testing, and incident response appropriate to critical infrastructure — practiced, not merely documented.

Trust model · what the registry can see
Stays in your node (yours)What the registry sees (minimal)
Trip routes and passenger dataDriver identity and verification
Fares and local operating rulesPortable reputation (append-only ledger)
Local payments and card dataSigned payment events (hash + amount, no personal data)
Own-brand app and fleetCross-network routing and protocol versioning

Build status. The network layer the registry, ledger, roaming and protocol carry is on the roadmap and shown as a target architecture, not a live service. The operation plane the node, apps, dispatch, payments and tracking is what ships today.

Certifications

We declare a certification only once it's real.

Specific certifications — for example ISO 27001 or SOC 2 — will be declared only once obtained or verifiably in progress. We claim none of them on this page.

What we will do is walk your security team through the architecture, the controls, and the verification model — under NDA where appropriate.

  • Claimed today: nothing — no certification is asserted here.
  • When we'll claim it: only on issuance, or when verifiably in progress.
  • What stands now: mTLS, per-message signatures, verifiable credentials, least privilege, an append-only ledger, and inclusion proofs.
  • Under NDA: the full security detail for your team to assess.
Talk to us

Bring your security team. Verify everything yourself.

Attribution, non-repudiation, an append-only record, and inclusion proofs — designed so your team can confirm authenticity without trusting our word. We'll walk all of it, under NDA where it matters.