Making Vehicle Identity
Cryptographically Impossible
to Steal or Clone
A proposal for integrating Midnight Network's zero-knowledge proof technology with automotive manufacturing — creating a three-layer hardware identity system that makes VIN cloning and chassis number fraud permanently impossible on new vehicles.
Vehicle Identity Fraud Is a Growing Crisis
Every year, billions of dollars are lost to vehicle theft, and a significant portion of that comes not from the theft itself but from what happens after — the criminal reuse and resale of stolen vehicles using fraudulent identities.
What Is VIN Cloning?
Every vehicle on the road carries a Vehicle Identification Number — a 17-character code that acts as its permanent identity. It links to registration records, insurance policies, service history, and ownership titles. VIN cloning is the criminal practice of copying this number from a legitimate, legally owned vehicle and applying it to a stolen one.
The result is that a stolen car gets a false identity that can pass basic checks at title offices, used car dealerships, and online marketplaces. The stolen vehicle can then be sold, registered, and insured as if nothing happened.
The core vulnerability in the current system is that a VIN is just a number stamped on a metal plate. It carries no cryptographic proof that it belongs to the physical vehicle it is attached to. Anyone with the right tools can stamp any number onto any plate.
How Criminals Do It
A thief steals a vehicle, then locates a similar make and model that has been written off as salvage or scrap. They purchase the salvage vehicle cheaply, strip its VIN plate, and apply it to the stolen car. With the VIN in place, they produce forged ownership documents and register the stolen car under the scrapped vehicle's identity in a different state or jurisdiction.
At this point the vehicle has a technically valid VIN, a believable paper trail, and can be sold to an unsuspecting buyer or shipped overseas.
The Damage It Causes
When authorities discover a cloned vehicle, it is seized on the spot. The buyer loses every dollar they paid, may still owe a car loan on a vehicle they no longer have, and can face accusations of handling stolen goods.
Insurance companies pay out fraudulent claims. Manufacturers see their vehicle data compromised. Law enforcement spends enormous resources tracking stolen vehicles through a system that was never designed to catch sophisticated fraud. And the legitimate owner of the donor VIN sometimes faces false traffic violations, criminal queries, and registration problems.
Weaknesses in the Current System
Existing databases like NMVTIS (US) or HPI (UK) are reactive — they rely on timely reporting and cross-state data sharing, which is often inconsistent. Metal VIN plates can be replicated with embossing presses available to anyone willing to search online. 3D printing now makes factory-accurate plate reproduction faster than ever.
Digital odometer fraud, chassis number alteration, and cross-border title washing (moving a vehicle through multiple jurisdictions to clean its history) all exploit the same fundamental weakness: there is no cryptographic link between the physical vehicle and its recorded identity.
The Scale of the Problem
In the United States alone, the FBI estimates vehicle theft losses exceed $7.4 billion annually. In South Africa, the figure runs into tens of billions of rand per year. Across Europe, approximately 580,000 vehicles are stolen annually. In many markets, stolen vehicle rings operate across borders with sophisticated networks for re-plating and re-registering cars.
Insurance companies price this risk into premiums for all drivers — meaning even honest car owners pay more because of a fraud problem that technology has not yet properly addressed.
Cryptographic Vehicle Identity — Built on Midnight Network
The solution is to replace the VIN plate as the sole source of truth with a cryptographic identity that lives across three separate hardware nodes inside the vehicle itself, anchored permanently to the Midnight Network blockchain.
Why Midnight Network?
Most blockchain solutions for vehicle identity would put all the data on a public ledger — which creates a different kind of problem. You do not want a vehicle's full ownership history, location data, or service records freely visible to anyone who looks up a number.
Midnight Network's core innovation is selective disclosure powered by zero-knowledge proofs. This means a system can prove something is true — "this VIN is authentic," "this vehicle is not stolen," "this owner has valid title" — without revealing the underlying private data.
A police officer gets a yes/no answer on whether a vehicle is stolen. An insurance company gets confirmation of ownership history. A potential buyer gets proof the vehicle has a clean identity. Each party gets exactly what they need and nothing more.
The Core Concept
At the point of manufacture, every new vehicle would have three separate Secure Element chips embedded in different physical locations throughout the vehicle. Each chip independently generates and holds its own cryptographic keypair — the private key is created inside the chip and never leaves it.
A vehicle identity record — a Vehicle Identity Token — is created on the Midnight Network at the moment of manufacture. This token links the vehicle's VIN, chassis number, engine serial, and build data to the combined signature of all three hardware nodes.
To verify a vehicle, all three nodes must cooperate to produce a zero-knowledge proof. If any node is missing, swapped, or tampered with, the proof fails. There is no plate to swap, no sticker to peel off, and no database entry to falsify. The vehicle either proves its own identity or it does not.
A thief would need to simultaneously replace the engine control unit, cut and swap the structural chassis module, and replace the telematics system — all without triggering a network alert — and still could not reproduce the original cryptographic keys. Each chip generates its own keypair in hardware isolation at manufacture. The private keys never leave the chips and cannot be read out even by the manufacturer. Without the original chips, the proof cannot be generated.
Zero-Knowledge Proofs
Prove a claim is true without revealing the data behind it. "This car is not stolen" can be verified without exposing the owner's name or address.
Three-Node Multi-Signature
All three hardware nodes must cooperate to sign any verification request. Remove one node and the entire system fails — by design.
Immutable Ledger
Once minted on Midnight Network, the Vehicle Identity Token cannot be altered. Every ownership transfer, service event, and insurance claim is recorded permanently.
Selective Disclosure
Different stakeholders see different information based on their role. Police get status only. Buyers get ownership history. Manufacturers retain full build data.
Privacy Compliant
Owner personal data never touches the blockchain. Only proofs and hashes are stored on-chain, keeping the system compliant with GDPR and similar regulations worldwide.
New Vehicles Only
This system is designed exclusively for new vehicles at the point of manufacture. The SE chips must be embedded during production — there is no older-vehicle programme, keeping the hardware standard clean and unambiguous.
System Architecture & Flow
The system operates across four distinct stages: manufacturing, minting, lifecycle tracking, and verification. Each stage has defined actors, data flows, and cryptographic events.
Three Secure Elements. Three Physical Locations. One Unbreakable Identity.
Each new vehicle would carry three tamper-resistant Secure Element chips, embedded in separate physical locations throughout the vehicle. All three must participate to generate a valid identity proof. This is the foundation of the system's physical security.
A "Secure Element" (SE) is a tamper-resistant hardware chip that stores cryptographic keys and performs cryptographic operations. It cannot be read out — even if physically disassembled. This same technology is used in bank cards, passports, SIM cards, and Apple Pay. The difference here is that three of them are deployed simultaneously, and all three must co-sign every authentication request.
ECU Secure Element
Embedded within the Engine Control Unit housing during manufacture. Physically bonded to the ECU's internal circuit board — removal destroys the chip.
Structural Chassis Element
Embedded deep within the vehicle's structural frame — in the A-pillar or firewall — during the body-in-white stage of manufacturing, before the vehicle is painted and trimmed.
Connectivity Secure Element
Embedded within the vehicle's telematics and over-the-air update module, behind the dashboard. This node acts as the communication orchestrator — it collects signatures from EN-1 and CN-2, assembles the signed witness data, and passes it to a local proof-generation component. The resulting ZK proof is then submitted to the Midnight Network.
Why three nodes? A single chip can potentially be cloned by state-level actors using electron microscopes and sophisticated hardware attacks. Two chips are harder but not impossible to defeat simultaneously. Three chips embedded in physically separate, structurally different locations of the vehicle — requiring different technical specialisations to attack — makes simultaneous compromise effectively impossible at any meaningful scale. The cost and complexity of defeating all three exceeds the value of any single vehicle.
What Each Player Sees and Does
One of the system's core advantages is that different stakeholders get exactly the information they need — and nothing more. This is selective disclosure in practice.
🏭 Car Manufacturer
The manufacturer is the root of trust in the system. They initiate the Vehicle Identity Token at the point of manufacture and control the key generation ceremony. After manufacture, they retain a supervisory role but cannot alter the identity record.
What they do
Install the three Secure Element chips during vehicle assembly. Run the key generation ceremony that triggers each chip to generate its own independent keypair — the private key is created inside the chip and never leaves it. Extract the three public keys and mint the Vehicle Identity Token on Midnight Network, recording VIN, chassis number, engine serial, build spec hash, and all three public keys. Submit the first transaction that creates the authoritative record.
What they can see
Full build data for their own vehicles. Tamper alerts from any of the three nodes. Aggregated fleet-level identity verification statistics. Recall management — ability to flag specific VINs for safety actions without altering the identity record.
System Requirements
What They Cannot Do
After the minting event, the manufacturer cannot alter, forge, or replay a vehicle's identity. Each chip independently generated its own keypair in hardware isolation — no master key was ever created or shared. The manufacturer cannot access individual owner data. They cannot read the private state of another manufacturer's tokens.
🚔 Law Enforcement
Police and border control officers need fast, reliable answers about vehicle identity. The system gives them exactly that — a binary yes/no response on vehicle status, without requiring access to owner details or purchase history.
What they see at a checkpoint
An officer uses a certified verification device (phone app, patrol car terminal, or portable scanner). They trigger a verification request on the vehicle. The vehicle generates a ZK proof from all three nodes. Midnight validates it. The officer gets back a cached status response in under 1 second, or a live proof result in under 30 seconds when full hardware verification is required.
The officer does not see the owner's name, address, or purchase price. They see: Is this vehicle authentic? Is it reported stolen? Are there any outstanding flags? That is all they need.
System Requirements
Stolen Vehicle Reporting
Authorised law enforcement agencies can flag a Vehicle Identity Token as stolen via a secured portal. The flag is submitted as a transaction and finalised on the Midnight Network in the next block — typically within seconds. Once confirmed, any subsequent verification query on that VIN returns "STOLEN" status regardless of what any physical plate says. Cached status certificates for the vehicle are invalidated, reducing to a 1-hour TTL.
🛡️ Insurance Companies
Insurance companies currently price vehicle theft risk into all premiums. They have enormous financial incentive to support a system that makes VIN fraud impossible. They also benefit from verified ownership history when processing claims.
What they can verify
At policy inception, the insurer can request a ZK proof that confirms the vehicle's identity is valid and the applicant has legitimate title. At claim time, they can verify the vehicle's current ownership status, check for prior undisclosed claims, and confirm the vehicle identity has not been flagged since coverage began.
What they cannot see
Previous owners' personal details. Specific service history items not related to the claim. Location data or usage patterns.
System Requirements
Premium Impact
Vehicles enrolled in the system could qualify for a verified identity discount on premiums — incentivising consumer uptake while reducing the insurer's risk exposure. Early modelling suggests theft-related claims could drop significantly in participating fleets within 3–5 years.
🚗 Dealerships (New & Used)
Dealerships are both sellers and buyers of vehicles. They currently rely on paper-based VIN checks and third-party history services that can be manipulated. The system gives dealers a cryptographically guaranteed identity check at point of trade.
New vehicle sales
The manufacturer transfers the Vehicle Identity Token to the dealer at delivery. The dealer transfers it to the buyer at point of sale. This becomes part of the standard handover documentation — a digital certificate of authentic identity delivered alongside the physical keys.
Used vehicle trade-ins and purchases
A dealer takes in a used vehicle and immediately runs a full identity verification. They see the clean ownership chain, service event count, and any flags. If the vehicle fails verification, the dealer is protected from unknowingly purchasing a stolen vehicle.
System Requirements
🏛️ Government & DMV / DVLA
Government vehicle registration authorities become a participant in the ownership transfer chain rather than the primary source of truth. The blockchain record becomes the authoritative identity layer; government databases sync from it rather than being the sole record.
What changes
When a vehicle is sold and the token is transferred on the Midnight Network, the DMV system receives a cryptographically verified notification of the ownership change. The government can use this to auto-update registration records, eliminating the gap where a stolen and re-plated vehicle could be registered with forged paperwork.
Cross-border cooperation
Because the identity record lives on a global blockchain, a vehicle stolen in Germany and re-registered in a different country would fail a ZK verification at any connected checkpoint. The identity flag crosses borders instantly.
System Requirements
👤 Vehicle Owner / Buyer
For the end consumer, the system should be invisible in day-to-day life. They do not need to understand blockchain or cryptography. They need to know their vehicle is protected and that they can prove it is theirs if needed.
What changes for the owner
When buying a new or used vehicle, the owner receives a digital ownership credential stored in a secure wallet app. This credential is their proof of title. If their vehicle is stolen, they report it through an authorised channel and the token is flagged immediately — preventing resale anywhere in the world.
Privacy protection
The owner's personal details are never stored on the blockchain. Their credential proves they hold valid title without revealing their name, address, or any personal information to the system.
Owner Experience
Stakeholder Access Matrix
| Data / Action | Manufacturer | Police | Insurance | Dealer | Government | Owner |
|---|---|---|---|---|---|---|
| Vehicle authentic? (Yes/No) | ✓ Full | ✓ Full | ✓ Full | ✓ Full | ✓ Full | ✓ Full |
| Stolen / flagged status | ✓ | ✓ + Can set | ✓ | ✓ | ✓ + Can set | ✓ |
| Ownership count / transfer history | Count only | — | ✓ | ✓ | ✓ | Own only |
| Previous owner identities | — | — | — | — | — | — |
| Build specification data | ✓ Own fleet | — | Basic | Basic | Basic | Basic |
| Service event count | ✓ | — | ✓ | ✓ | — | ✓ |
| Insurance claim history | — | — | ✓ Own claims | — | — | Own only |
| Recall / safety flags | ✓ + Can set | ✓ | ✓ | ✓ | ✓ | ✓ |
| Transfer / sell token | At manufacture | — | — | ✓ (new sales) | — | ✓ |
| Flag vehicle as stolen | — | ✓ | — | — | ✓ | Report only |
What Car Manufacturers Would Need to Agree On
For this system to work at scale, manufacturers cannot each build their own incompatible version. A shared framework of standards is required — covering the hardware chip, the data format, the smart contract interface, and the governance model.
This is not unprecedented. The automotive industry has done this before with OBD-II (the diagnostic port standard), with ISO standards for CAN bus communication, and with ISO 18000 for RFID in vehicle manufacturing. A new standard for cryptographic vehicle identity follows the same model.
VSE-1: Vehicle Secure Element Standard
The foundational hardware standard. All manufacturers adopting the system must use chips that meet this specification.
VSE-1.1Physical Specification — Common form factor, operating temperature range, vibration and shock resistance meeting automotive-grade standards (AEC-Q100 Grade 1 or equivalent). Minimum IP67 rating. Designed for the lifetime of the vehicle (15+ years).
VSE-1.2Cryptographic Specification — Support for threshold key generation (3-of-3 scheme). Elliptic curve cryptography (minimum Ed25519 or equivalent). Hardware random number generator. Secure boot. Physical unclonable function (PUF) binding to manufacture-time state. Anti-rollback for firmware.
VSE-1.3Communication Specification — CAN bus or automotive Ethernet (AUTOSAR-compatible) interface for inter-node communication. Standardised command set for proof generation requests. Challenge-response protocol to prevent replay attacks.
VSE-1.4Tamper Response Specification — Mandatory key wipe on physical penetration of housing. Network alert transmission via TN-3 on tamper detection in EN-1 or CN-2. Tamper event logged immutably on the Midnight Network with timestamp.
VIT-1: Vehicle Identity Token Standard
Defines the data structure of the identity record on Midnight Network.
VIT-1.1Required Fields (Public) — Token ID (UUID), manufacturer code (ISO 3166 + manufacturer ID), VIN hash (not plain VIN), token creation timestamp, current status (active / stolen / flagged / end-of-life), version of the VIT standard.
VIT-1.2Required Fields (Private / ZK-accessible) — Plain VIN, chassis number, engine serial, build spec hash, factory location code, production date. These are stored in the private state layer and accessible only via ZK proof to authorised roles.
VIT-1.3Ownership Record — On-chain ownership is represented as a cryptographic commitment (hash of owner secret + salt) — never a name or identity. Transfer count is publicly visible. The commitment is updated on each transfer. No personal identity is ever stored on-chain; ownership history is provable by count and verifiable ZK proof of the current commitment, without revealing individual owner details.
VIT-1.4Event Log — Standardised event types: MANUFACTURE, SALE, SERVICE, CLAIM, FLAG_STOLEN, FLAG_RECOVERED, FLAG_RECALL, END_OF_LIFE. Each event is a timestamped, immutable entry with the proof that authorised it.
VAP-1: Verification API & Protocol Standard
VAP-1.1Query Protocol — Standardised REST/GraphQL API for all external parties. Authentication via OAuth2 + role-based access tokens. Rate limiting per role. All queries logged for audit purposes.
VAP-1.2Response Format — Standardised JSON response schema. Status field always present. Data fields vary by role. Timestamp and proof hash included for auditability. Maximum response latency: 30 seconds for live vehicle ZK proof; under 1 second for cached status responses.
VAP-1.3Offline Mode — Cached status certificate format. Maximum cache validity: 24 hours for standard checks, 1 hour for stolen flag updates. Certificate anchored to a Midnight Network block hash and independently verifiable on-chain.
VGM-1: Governance Model
The system needs a governance layer to manage standard updates, dispute resolution, and access revocation.
Governance Body
A standards consortium — similar to the W3C model — with seats for manufacturers (weighted by production volume), government representatives, insurance industry, and consumer advocacy groups. Midnight Network has a seat as the technical infrastructure provider.
Decisions on standard changes require a supermajority (two-thirds). Emergency security patches can be fast-tracked by a smaller executive committee.
Dispute Resolution
When identity disputes arise — for example, two claims to the same VIN — the governance body's arbitration process is triggered. The on-chain audit trail provides the evidence. The process is defined in the VGM-1 protocol and outcomes are implemented via authorised smart contract calls.
This is particularly important for insurance disputes and legal proceedings involving vehicle identity.
Who This Changes — and How
Automotive Manufacturing
Manufacturers gain a powerful differentiator. A vehicle with cryptographic identity becomes a premium product feature — "this car cannot be stolen and resold." Manufacturing lines require integration of the chip provisioning process, which adds minimal cost per vehicle at scale.
Primary stakeholderInsurance Industry
The biggest financial beneficiary. Theft-related claim costs drop directly. VIN fraud-related disputes are eliminated. Underwriting models for vehicles in the system improve significantly. Premium discounts become a competitive tool for acquiring customers.
Primary stakeholderLaw Enforcement
Investigators gain an unambiguous, cryptographically secured record of vehicle identity. VIN cloning rings are disrupted at the fundamental level — the fraud becomes impossible rather than just harder to detect. Cross-border identity verification is standardised.
Primary stakeholderVehicle Finance & Lending
Banks and finance companies lending against vehicle assets get reliable verification that the collateral is authentic. Fraudulent finance applications using stolen vehicle VINs are blocked at the point of identity verification. Repossession processes are simplified.
Secondary stakeholderGovernment & Tax Authorities
Vehicle registration databases become secondary to the blockchain record, reducing fraud in registration systems. Import/export vehicle fraud is disrupted. Accurate vehicle history supports more reliable taxation of vehicle sales.
Secondary stakeholderParts & Aftermarket
The system extends naturally to major component authentication. Engine, transmission, and chassis part replacements can be logged against the vehicle's identity record, creating a verified service history that increases resale value and supports warranty claims.
Secondary stakeholderShipping & Logistics
Vehicle export fraud — where stolen vehicles are shipped internationally with false identities — is disrupted. Port authorities can run identity verification on vehicles in transit. International law enforcement sharing is enabled through the common verification API.
Secondary stakeholderUsed Vehicle Marketplace
Online platforms for vehicle sales (classifieds, auction sites, dealers) can integrate the verification API to display confirmed identity status on listings. Consumers know within seconds whether a listed vehicle is authentic. Fraud listings are caught before they result in a sale.
Secondary stakeholderLegal & Forensics
The immutable audit trail becomes evidence in criminal prosecutions of vehicle theft rings. Legal disputes over vehicle ownership have a definitive, court-admissible record. Forensic investigators have a trusted reference against which physical evidence can be checked.
Secondary stakeholderWhy Not Another Blockchain?
Midnight Network is not the only blockchain. The choice is deliberate, and the alternatives were all considered. This section explains why each credible alternative fails on the specific requirements of this system — and why those failures are structural, not fixable.
The Four Requirements That Drive the Choice
The Alternatives
Ethereum (L1 and L2 rollups)
EliminatedAll contract state on Ethereum is publicly readable. Every VIN, ownership hash, transfer event, and verification query is visible to any node operator. ZK-EVM rollups (StarkWare, zkSync, Polygon zkEVM) add proof-based computation but the underlying state model remains transparent — they prove correctness of computation, not confidentiality of data.
Reason: Public state model is structurally incompatible with selective disclosure. No role-based disclosure primitive exists. Query patterns visible. GDPR compliance arguments are fragile.
Cardano (native, without Midnight)
EliminatedCardano's eUTXO model is well-understood and secure. Datum fields in a UTXO are readable by all nodes. There is no native ZK proof system and no selective disclosure primitive. ZK verification can be implemented in Plutus scripts but is expensive and not optimised for this use case.
Reason: Same public-state limitations as Ethereum. Midnight Network was built specifically as the Cardano partner chain to solve these problems — it is the correct layer.
Hedera Hashgraph
InsufficientFast throughput, low fixed fees, and a governing council of recognisable corporate names (Google, IBM, Boeing). The Hedera Consensus Service (HCS) is used for supply chain audit logs and would make a capable tamper-evident event ledger. The EVM-compatible smart contract layer has the same public state problem as Ethereum. No native ZK proof layer. No selective disclosure primitive.
Reason: HCS could serve as a secondary audit log layer. It cannot produce privacy-preserving identity proofs. The centralised Governing Council also creates geopolitical dependency risk for a global vehicle identity standard.
Polygon ID (iden3 / Circom)
Wrong design spacePolygon ID is the most technically relevant alternative — it uses ZK proofs for identity credentials and supports selective disclosure of credential attributes. It is actively used for digital identity applications. However, Polygon ID is designed for human identity credentials, not physical hardware-backed assets. There is no concept of a proof that must be co-signed by three hardware security modules embedded in a physical object. The credential model assumes a single human holder.
Reason: Credential model vs. physical asset model are different design spaces. The 3-of-3 SE chip co-signature — the core security mechanism — has no equivalent primitive in Polygon ID. Circom/Groth16 also requires a trusted setup ceremony per circuit, a governance complication for an evolving standard.
Existing Vehicle History Blockchains (VINchain, MOBI)
Different categoryBlockchain-anchored vehicle history projects record service events, ownership transfers, and odometer readings with a tamper-evident ledger. They solve provenance transparency. They cannot prove that the physical vehicle present at a roadside check is the vehicle in the record — they rely on honest reporting by garages, dealers, and owners. A criminal can simply not report a theft, or clone a VIN from a legitimately maintained vehicle.
Relationship: Complementary, not competing. ShieldVIN's lifecycle event log covers the same provenance ground as a by-product of the identity system. These projects could integrate with ShieldVIN as data consumers.
Why Midnight Network Satisfies All Four Requirements
disclose() primitive in Compact controls exactly which fields leave the private witness. Role-based outputs are enforced in-circuit, not by application logic.Additional Advantages
PLONK proof system — Midnight uses a PLONK proof system with KZG polynomial commitments over the BLS12-381 pairing curve and JubJub Edwards curve for internal operations. Unlike Groth16 (used in many ZK identity systems), PLONK with a universal trusted setup does not require a new ceremony per circuit — making circuit upgrades and standard evolution practical without re-ceremony.
Compact DSL — TypeScript-familiar syntax for ZK circuit development. Lower barrier than writing raw Circom or Rust circuits. Designed for application developers, not cryptographers.
Cardano settlement layer — inherits Cardano's Ouroboros finality and established security properties. Not a new unproven network.
Ecosystem precedent — AirLog, an aviation maintenance record privacy DApp, demonstrates the identical use-case pattern on Midnight — tamper-evident, privacy-preserving maintenance history for a regulated physical asset. ShieldVIN is the automotive equivalent at global scale.
Strategic alignment — Midnight Network is actively seeking enterprise use cases that validate its "rational privacy" positioning at real-world scale. ShieldVIN is precisely that use case.
How the Business Works
ShieldVIN generates revenue across five distinct streams: a one-time vehicle identity token minting fee, a verification API for insurers and lenders, monthly dealer portal subscriptions, a consumer platform for private ownership transfers, and enterprise and government contracts. All client-facing fees are billed in standard fiat currency — no crypto wallet is required from any user. DUST transaction costs are an operational expense absorbed by ShieldVIN internally. Customers reach ShieldVIN through three surfaces: the API for enterprise integration, the dealer portal for registered dealers, and the consumer platform for private sellers and owners.
Revenue Stream 1
Vehicle Identity Token Minting Fee
A one-time fee charged to the manufacturer at the point of minting the Vehicle Identity Token onto Midnight Network. Volume-tiered pricing reflects OEM scale — the system is designed so that the largest manufacturers, who drive the most on-chain activity for Midnight, receive the most competitive rate.
Revenue Stream 2
Verification API — Insurer / Lender / Fleet
Per-query billing for insurers, finance lenders, and fleet operators. Five distinct query types reflect the cryptographic cost and commercial value of each verification. All billed in fiat currency via card or invoice — no crypto knowledge required from the API consumer.
| Query Type | Payer | Rate |
|---|---|---|
| Status Check (cached) | Commercial requesters — govt covered by contract | $0.15–$0.35 |
| Ownership Verify (ZK proof) | Insurer underwriting, lender approval, fleet check | $1.75–$2.50 |
| Full Identity Proof + Transfer | Dealer DMS at point of sale, govt registration | $9–$15 |
| Live Tamper Check (real-time) | Repossession, insurance investigation — govt by contract | $6–$12 |
Revenue Stream 3
Dealer Portal — Monthly Subscription
Registered dealerships subscribe monthly for access to the ShieldVIN dealer portal. This integrates into their existing DMS workflow or runs as a standalone web app. The subscription covers unlimited status checks, ownership verifications, and ownership transfer processing for their inventory volume.
Revenue Stream 4
Consumer Platform — Private Ownership Transfer
Private sellers and buyers use the ShieldVIN web or mobile app to execute a cryptographic ownership transfer. This is the product that closes the private sale fraud gap — currently the most common vector for VIN cloning. The transfer is a digital handshake: seller initiates, buyer confirms, proof recorded on-chain.
Revenue Stream 5
Enterprise & Government — Partnerships and Integration Contracts
Three sub-streams targeting long-term institutional relationships. These have the longest sales cycles but the highest contract values and most durable recurring revenue.
| Sub-stream | Model | Indicative Rate |
|---|---|---|
| Insurance Partnerships | Revenue share from demonstrated fraud claim savings. 1–3% of verified savings attributed to ShieldVIN. Multi-year agreements with major insurers. | Custom / savings share |
| Government Integration Contracts | Model B path: one-time integration fee per jurisdiction ($500K–$2M) + annual maintenance ($100K–$400K). Government gets API access; law enforcement access covered. Long-term goal is Model C: regulatory mandate. | $600K–$2.4M / jurisdiction |
| Enterprise Data Products | Anonymised aggregate data (no PII — consistent with privacy architecture) sold to automotive research bodies, safety regulators, urban planners. Available from Year 4 when fleet scale is sufficient. | Annual licence |
Three Ways to Access ShieldVIN — All Fiat, No Crypto Required
ShieldVIN API
Embedded infrastructure — invisible to the end user.
Insurers embed ShieldVIN into their policy underwriting platforms. Fleet operators query via API. Government agencies integrate into registration and enforcement systems. Billed by invoice or card at contracted volume rates.
Think of this like Stripe: the buyer interacts with the merchant's checkout, Stripe processes the payment. ShieldVIN processes every vehicle identity query behind the scenes.
ShieldVIN Dealer Portal
Web app and DMS plugin — for registered dealerships.
Dealers verify incoming stock, process ZK ownership transfers at point of sale, and provide buyers with a cryptographic proof receipt. Billed monthly via card or direct debit. DMS integration (CDK, Reynolds & Reynolds) available for franchised dealers — no workflow disruption.
ShieldVIN Consumer App
Web and mobile — for private sellers and owners.
Private sellers and buyers complete ownership transfers without a dealer. $5 flat fee paid by card, Apple Pay, or Google Pay. Owners view their full record, export a signed PDF, and set recall alerts at no cost. The brand is visible and the experience is designed for non-technical users.
Vehicle Lifetime Value
A vehicle that lives 15 years and changes hands 4 times generates the following cumulative revenue for ShieldVIN across all four streams:
| Revenue Component | Basis | Range |
|---|---|---|
| Chip kit + Minting | One-time at manufacture (both streams combined) | $25–$45 |
| Ownership Transfers | 4 transfers × $2–$5 each | $8–$20 |
| Service Events Recorded | 8–12 events × $0.50–$2 each | $4–$24 |
| Pre-Sale Buyer Checks | 3–4 checks × $3.50–$12 each (via ShieldVIN Platform) | $10–$48 |
| Insurance Queries | Covered by insurer annual subscription (not per-query) | Subscription pool |
| Lifetime Total per Vehicle | 15-year vehicle life, 4 ownership changes | ~$47–$137 |
Comparison: HPI currently extracts approximately £50–£160 per vehicle over its lifetime from recurring checks alone — with no hardware component and no on-chain infrastructure. ShieldVIN's lifetime revenue is comparable, generated across a broader set of value-creating events, with the additional chip kit margin on top.
Cost Structure
DUST Economy Contribution
Every vehicle mint, ownership transfer, service record, and lifecycle event consumes DUST as the Midnight Network transaction fee. At tens of millions of events per year across an enrolled global fleet, ShieldVIN becomes one of Midnight's largest institutional on-chain activity drivers.
This is not a revenue source for ShieldVIN — it is a sustained, predictable demand signal for the Midnight token economy. A global vehicle identity system would:
Drive millions of DUST transactions per year. Establish Midnight as the infrastructure layer for a critical regulated industry. Create enterprise adoption that validates the "rational privacy" positioning. Demonstrate ZK proofs working at automotive scale and speed, proving the technology to every adjacent industry.
Four Phases to Global Standard
Build the core smart contract on Midnight Network testnet. Develop the proof-of-concept key generation ceremony. Engage 2–3 founding manufacturer partners and a major insurer. Establish the governance consortium legal entity. Publish the VSE-1 draft standard for industry feedback.
Success metric: Working ZK vehicle identity proof on testnet. Signed MoU with at least one Tier 1 manufacturer.
Deploy on a limited model line with a founding manufacturer partner (limited production run of 5,000–20,000 vehicles). Integrate with one or two national law enforcement agencies and two major insurers. Run live checkpoints in a defined geography. Collect performance data and refine the standard.
Success metric: Live vehicles on public roads with working ZK identity. Zero false positives. Full live proof under 30 seconds; cached status queries under 1 second.
Expand to all vehicle lines of founding partners. Onboard additional manufacturers. Government integration in at least three jurisdictions. Insurance API live with commercial pricing. Full API open to dealerships and fleet operators.
Success metric: 500,000+ vehicles enrolled. Active in 3+ countries. Commercially self-sustaining on verification fees.
Lobby for regulatory mandate in high-theft markets (similar to how the EU mandated vehicle immobilisers in 1998). Expand to all new vehicle production globally. Open the verification API to consumer-facing apps. Extend to component-level authentication for major parts.
Success metric: Recognised in ISO or UNECE vehicle safety regulation. 5M+ vehicles enrolled.
Risks and Mitigations
Every significant infrastructure project carries risks. Being clear-eyed about them is part of building a credible proposal.
Technical Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Secure Element chip can be physically attacked and key extracted | Low | High | 3-node requirement means one chip compromise is insufficient. Regular chip security certification. Side-channel attack resistance built into VSE-1 spec. |
| Node communication intercepted — man-in-the-middle on CAN bus | Medium | Medium | All inter-node communication is encrypted and uses challenge-response nonces. Replay attacks are blocked by design. Challenge is unique per session. |
| Midnight Network downtime or outage | Low | Medium | Offline status certificates allow verification to continue for up to 24 hours without live network access. Decentralised validator set means no single point of failure. |
| Quantum computing attack on elliptic curve cryptography | Low (10+ years) | High | VSE-1 standard includes a crypto-agility requirement — chips must support firmware updates to post-quantum algorithms when they become standardised. Governance body monitors this. |
Commercial & Adoption Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Manufacturers refuse to agree on a common standard (standards war) | Medium | High | Engage neutral standards bodies (ISO, SAE) as the formal custodians of the standard. Start with willing early adopters. Insurance and government pressure accelerates adoption. |
| Consumer resistance to "tracking" technology | Medium | Medium | Clear, consistent privacy messaging. The system does not track location. Owner controls their data. ZK proofs mean even verification queries reveal nothing about the owner. |
| Cost of chip integration adds to vehicle price in a price-sensitive market | Medium | Low | At scale, three SE chips add approximately $15–$40 to vehicle cost. Insurance premium discounts of $50–$200/year more than offset this for consumers. |
| Competing solution developed by a rival blockchain | Low | Medium | First-mover advantage is significant in standards. If the VSE-1 and VIT-1 standards are adopted by manufacturers first, competing systems face massive switching costs. |
Regulatory Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Regulatory bodies refuse to accept blockchain-based identity records | Medium | High | Engage regulators early in pilot phase. Build the verification API to produce outputs compatible with existing government database formats. Position as a supplement to, not replacement of, existing systems initially. |
| GDPR or similar privacy regulation creates compliance issues | Low | Medium | Midnight's ZK architecture means personal data is never on-chain by design. The system is GDPR-compliant from the ground up. Engage a privacy law firm to validate the architecture before launch. |
| Jurisdictional fragmentation — different countries require different implementations | High | Medium | Design the API with jurisdiction-specific response profiles. Governance body includes government representatives from multiple jurisdictions. Start in two or three aligned markets (e.g., UK + Germany + South Africa). |
Regulatory Landscape by Jurisdiction
The jurisdictional fragmentation risk is real but manageable. The following table maps the key regulatory touchpoints in the four primary target markets. None of these regulations prohibit ShieldVIN — several actively incentivise it.
| Market | Relevant Regulations | Impact on ShieldVIN | Path to Compliance |
|---|---|---|---|
| European Union | GDPR (Regulation 2016/679) · eIDAS 2.0 · EU Type Approval Regulation (2018/858) · Directive 2019/1 (competition in automotive aftermarket) | GDPR is the dominant constraint. eIDAS 2.0 introduces a European digital identity framework that ShieldVIN is architecturally aligned with. Type Approval regulation governs changes to vehicle components — SE chip installation requires type approval pathway. | No PII on-chain satisfies GDPR by design. Engage the European Data Protection Board for an informal opinion before Phase 2. Work with UNECE WP.29 (vehicle regulations) to define an SE chip installation as a certifiable option rather than a modification. Participate in eIDAS 2.0 working groups. |
| United Kingdom | UK GDPR · Data Protection Act 2018 · Vehicle Excise and Registration Act 1994 · Road Traffic Act 1988 · DVLA regulations | UK GDPR (post-Brexit) mirrors EU GDPR but the UK ICO is a single regulator — one engagement point. DVLA is the national vehicle registry. Road Traffic Act defines what constitutes acceptable vehicle identification for law enforcement. Single jurisdiction makes the UK the ideal first market. | Engage the ICO at pilot stage for a Data Protection Impact Assessment (DPIA) validation. Work with DVLA and DVSA on the VAP-1 API specification to ensure outputs are accepted for registration and enforcement purposes. NPCC engagement for law enforcement integration. |
| United States | CCPA / CPRA (California) · State motor vehicle laws (50 states) · NMVTIS (49 U.S.C. § 30502) · NHTSA regulations · UCC Article 9 (secured transactions) | No federal privacy law equivalent to GDPR — but CCPA/CPRA applies to California residents and functions as a de facto national standard for consumer-facing products. NMVTIS requires reporting of vehicle history data. State-level vehicle title laws are fragmented across 50 jurisdictions — this is the primary complexity in the US market. | Architecture already satisfies CCPA (no personal data on-chain). For NMVTIS: build a read/write integration so ShieldVIN lifecycle events automatically update NMVTIS records — this turns a regulatory obligation into a feature. Engage AAMVA (American Association of Motor Vehicle Administrators) to develop a model state statute for ShieldVIN-authenticated title records. Start with 3–5 state pilots rather than national rollout. |
| South Africa | POPIA (Protection of Personal Information Act, 2013) · National Road Traffic Act 93 of 1996 · eNaTIS (National Traffic Information System) regulations · National Credit Act (vehicle finance) | South Africa has one of the highest vehicle theft rates globally — making regulatory alignment a shared government priority. POPIA is aligned with GDPR principles and the no-PII-on-chain architecture satisfies it by design. eNaTIS is the national vehicle registry equivalent of DVLA. Single national system reduces fragmentation risk. | POPIA compliance achieved by same architecture as GDPR. Engage the Department of Transport and RTMC (Road Traffic Management Corporation) to position ShieldVIN as a solution to SA's documented vehicle crime problem — the government motivation to cooperate is high. SA insurance industry (concentrated market — 3 major insurers hold 70%+ of motor book) are natural pilot partners given claims exposure. |
Regulatory Strategy Summary
The sequencing is: pilot in the UK first (single regulator, single registry, motivated law enforcement, concentrated insurance market), then use the UK pilot data to engage EU and South African regulators, then approach the US market with a model state statute and AAMVA partnership. Entering all four markets simultaneously is not required — and not advisable. One live, clean, audited deployment is worth more than four simultaneous engagements.
Market Size & Revenue Potential
Total Addressable Market
Global new vehicle production value of annual identity provisioning (80M+ vehicles × estimated system value per vehicle)
Serviceable Market (Year 5)
Assuming 12% of new vehicle production enrolled by Year 5, at blended revenue per vehicle of ~$25 including minting + lifecycle queries
Insurance Premium Savings
Estimated annual insurance claim savings in enrolled markets by Year 5, which would be shared partly as revenue with the system operator
Investment required (Phases 1–2): An estimated $12–$18M covers the technical build, standards body establishment, regulatory engagement, and the first pilot programme. This is well within the range of a Midnight Network ecosystem development grant combined with strategic investment from one or two founding manufacturer partners and an insurance company.
Operating cost note — DUST: Every on-chain operation (vehicle mint, ownership transfer, verification query) consumes DUST as the Midnight Network transaction fee. At scale, this is a material operating cost that is not reflected in the revenue table above. DUST cost modelling is included in the Excel financial model's Scenarios tab. Revenue figures shown are gross; net margins will depend on DUST price and transaction volume at each phase.
Building the Right Team
ShieldVIN requires expertise at the intersection of automotive hardware engineering, zero-knowledge cryptography, standards governance, and enterprise sales. The founding team is being assembled around this proposal.
Technical Lead
Role open — seeking candidate
ZK circuit design experience on the Midnight/Cardano stack. Background in automotive embedded systems or Secure Element firmware. Ideally with experience at a Tier 1 automotive supplier (Bosch, Continental, Aptiv) or cryptographic hardware vendor.
Standards & Policy Lead
Role open — seeking candidate
Experience navigating ISO, SAE, or UNECE standards processes. Automotive regulatory background. Network into DVLA, NHTSA, or equivalent government agencies in target pilot markets.
Automotive Industry Lead
Role open — seeking candidate
Senior relationships with OEM procurement or technology strategy teams. Understands the production line integration process. Has navigated a new hardware mandate into a vehicle production programme before.
Advisory Roles Sought
Cryptography & ZK Research
Academic or applied researcher with ZK proof system expertise. Validates the technical approach, reviews the Compact circuit design, and advises on the post-quantum migration strategy required by VSE-1.
Insurance Industry
Senior figure from a major insurance group (Lloyd's of London tier). Validates the claims data thesis, opens introductions to actuarial teams, and advises on API pricing and data sharing protocols for insurers.
Law Enforcement / Government
Retired senior officer from a national police vehicle crime unit or equivalent government body. Validates the law enforcement use case and assists with government pilot negotiations and type approval pathways.
Midnight Network / Cardano Ecosystem
Technical representative from Midnight Network or IOG. Ensures ShieldVIN is built on the right abstractions and positioned correctly within the Midnight ecosystem and developer roadmap.
If you are Midnight Network: We are actively looking for a co-development partnership as the primary next step. The right first move is a technical meeting to assess fit, validate the Compact circuit design approach, and agree on the scope of Midnight's involvement in Phase 1. That conversation shapes who the right technical lead is for this project.
Why This Project Belongs on Midnight
This is a proposal to open formal discussions with the Midnight Network team about co-developing and co-sponsoring this vehicle identity system as a flagship enterprise use case.
What we are asking from Midnight
Dedicated technical partnership and SDK support for vehicle identity smart contract development. Co-development of the ZK proof circuit optimised for SE hardware — targeting under 30 seconds for live proofs at Phase 2, with a long-term target of under 10 seconds as SE hardware matures and subject to Midnight's proof system roadmap. Participation in the governance consortium as a founding member. Joint go-to-market with Midnight's enterprise and government relations teams. Consideration of an ecosystem development grant for Phase 1 and Phase 2 funding.
What Midnight gets in return
A live, regulated, globally-visible use case that validates the "rational privacy" positioning at scale. Tens of millions of DUST transactions per year at full deployment. A reference implementation that other industries (healthcare, finance, supply chain) will study and replicate. Relationships with major automotive manufacturers — one of the world's largest industries. Proof that ZK proofs work at real-world speed and scale.
The core alignment: Midnight Network was built to solve exactly this kind of problem — where you need to prove something is true without exposing private data, where multiple parties with different access levels need to interact with the same underlying record, and where the consequences of data exposure or record tampering are severe. Vehicle identity is not a niche use case. It touches every person who owns a car. It is regulated globally. It involves billions of dollars. It is exactly the right problem for Midnight to solve first.
The following items require validation from the Midnight engineering team before the ShieldVIN contract can advance beyond design-intent stub to a deployable implementation. We raise them explicitly so they can be addressed at the first technical meeting.
ShieldVIN's hardware authentication model depends on proving that each Secure Element chip signed a session challenge nonce with its private key. This requires an Ed25519 signature verification primitive in the Compact circuit. As of March 2026, no verifyEd25519() function exists in CompactStandardLibrary. We need the Midnight team to advise on one of three paths: (a) Is a verifyEd25519 builtin planned in an upcoming Compact release? (b) Can it be constructed from the existing EC primitives (ecMul, ecMulGenerator, hashToCurve)? (c) Should ShieldVIN adopt a JubJub-native or alternative credential scheme that Midnight already supports natively through its PLONK/JubJub proof system?
Research into the Compact model confirms that a single circuit cannot conditionally return different data to different caller roles at runtime — there is no msg.sender equivalent. The confirmed pattern is separate circuits per role (verifyPolice, verifyInsurer, etc.), each with its own witness context and disclosure set. We would like the Midnight team to validate this approach and advise on any preferred structural patterns from existing enterprise DApps before committing to the production contract layout.
Two viable patterns exist: Option A — one contract instance per vehicle (clean isolation, higher deployment overhead); Option B — a single registry contract using Map<Bytes<32>, VehicleStatus> keyed by VIN hash (efficient at millions-of-vehicles scale, confirmed Map type in Compact). At full deployment ShieldVIN targets tens of millions of enrolled vehicles. We would like the Midnight team's recommendation on which architecture is operationally preferred at that scale, and whether there are gas/proof-cost implications that favour one over the other.
This document is an opening proposal. The technical detail, business model, and framework proposed here are starting points for discussion — not final specifications. We welcome Midnight's input on architecture, positioning, and partnership structure.
Technical Terms
Plain-English definitions for technical terminology used throughout this document.