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.
mTLS between nodes and registry — nobody talks to the network without valid credentials.
02
Per-message signatures
Every reputation and payment event is attributable and non-repudiable.
03
Verifiable credentials
Issued by the identity service; revocable instantly, network-wide.
04
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.
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
01
event
Take the event in question
A reputation or payment record your team wants to confirm is authentic.
02
signature
Check the per-message signature
Confirm the issuing party signed it — attribution and non-repudiation in one step.
03
proof
Validate the inclusion proof
Prove the event sits in the append-only ledger, unaltered — without trusting our word.
04
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 data
Driver identity and verification
Fares and local operating rules
Portable reputation (append-only ledger)
Local payments and card data
Signed payment events (hash + amount, no personal data)
Own-brand app and fleet
Cross-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.