Glossary of Terms & Abbreviations

The first of three Secure Element chips embedded in a vehicle at manufacture. Located in the engine bay, housed within the ECU. Holds an independent Ed25519 keypair generated in hardware. Wipes its key if the ECU housing is physically breached. Must co-sign every identity proof alongside CN-2 and TN-3.

The second Secure Element chip. Embedded into the vehicle's structural chassis at the body-in-white stage during manufacture — physically part of the frame, not a bolt-on component. Holds an independent Ed25519 keypair. Triggers a tamper alert and key wipe if the frame is cut or structurally compromised.

The third Secure Element chip. Located behind the dashboard in the telematics module. Serves as the communication hub: collects signatures from EN-1 and CN-2, assembles witness data, and forwards it to the Proof Server for ZK proof generation. Holds its own independent Ed25519 keypair. Does NOT generate ZK proofs directly — that is the Proof Server's role.

A tamper-resistant microchip designed to generate and store cryptographic keys in hardware. Keys are generated inside the chip and cannot be extracted — private key material never leaves the chip in plaintext. ShieldVIN uses one SE chip per vehicle node (EN-1, CN-2, TN-3), each generating its own independent Ed25519 keypair.

The electronic control module that manages engine functions in a vehicle. The EN-1 Secure Element chip is housed inside the ECU enclosure. If the ECU housing is physically breached, EN-1 detects the intrusion and wipes its key, invalidating future identity proofs.

The primary communication network inside a vehicle that allows microcontrollers and devices to communicate without a central host computer. EN-1 and CN-2 communicate their signatures to TN-3 over the vehicle's CAN bus during proof generation.

The elliptic curve digital signature algorithm used by all three SE chips (EN-1, CN-2, TN-3) to sign identity proofs. Each chip generates its own independent Ed25519 keypair in hardware at the time of manufacture. Note: Midnight wallets use Schnorr/secp256k1 (BIP340) — Ed25519 is exclusive to the SE chips.

A cryptographic method that allows one party to prove a statement is true to another party without revealing any information beyond the truth of that statement. ShieldVIN uses ZK proofs so each stakeholder receives only the specific facts they are entitled to (e.g. "stolen: yes/no") without exposing owner identity, build data, or other parties' information.

The ZK proof system used by Midnight Network. A type of zk-SNARK that produces succinct proofs without requiring a trusted per-circuit setup. ShieldVIN proofs are generated using PLONK over BLS12-381 and JubJub curves.

A polynomial commitment scheme used within Midnight's PLONK proving system. KZG commitments allow a prover to commit to a polynomial and later reveal evaluations at specific points, enabling succinct and efficiently verifiable proofs.

A pairing-friendly elliptic curve used by Midnight Network for ZK proof generation. Provides the high security level and pairing operations required by the PLONK proving system.

A twisted Edwards curve defined over the BLS12-381 scalar field. Used alongside BLS12-381 in Midnight's proof system for in-circuit operations. Circuit arithmetic over JubJub is significantly more efficient than over general curves.

The token used to pay transaction fees on Midnight Network. ShieldVIN treats DUST as an internal operational cost — not a revenue stream. All client-facing fees are billed in fiat (USD/GBP/EUR). ShieldVIN holds a DUST reserve internally to cover on-chain transaction costs. On testnet, tDUST is used and generated by delegating tNIGHT in the Lace wallet.

Testnet versions of Midnight's tokens. tNIGHT is obtained from the Midnight testnet faucet and delegated in the Lace wallet to generate tDUST, which is used to pay transaction fees on the testnet. Neither has real monetary value.

A family of public-key cryptographic algorithms based on the algebraic structure of elliptic curves over finite fields. Both the SE chip signatures (Ed25519) and Midnight's proof system (BLS12-381, JubJub) are based on ECC.

The domain-specific language used to write ZK smart contracts on Midnight Network. Compiled by the Compact Compiler (v0.30.0) to generate circuit artifacts used by the Proof Server. ShieldVIN's on-chain logic is written in Compact in vehicle_identity.compact. Key syntax: export circuit, export ledger, witness, pragma language_version.

A local Docker service (midnightntwrk/proof-server) that generates ZK proofs using the compiled Compact circuit. Receives private witness data (the three Ed25519 signatures) from TN-3 and produces a proof for submission to Midnight Network. The Proof Server generates the ZK proof — TN-3 does not.

The Compact built-in function persistentHash<T>(value: T): Bytes<32> — a SHA-256 hash. Used in ShieldVIN circuits for creating tamper-evident commitments (e.g. chassisHash, ownershipHash). Do not use sha256() or transientHash() — these are not valid Compact functions.

A Compact keyword that wraps witness-derived values being written to public ledger fields. Required when a private witness value is promoted to public state. Enables selective disclosure — only the fields explicitly wrapped with disclose() are revealed in the proof output.

The on-chain record minted on Midnight Network at the point of vehicle manufacture. Contains cryptographic commitments (hashes) of the vehicle's build data and the three SE chip public keys. Serves as the vehicle's permanent, tamper-evident digital identity. A VIT is minted once and follows the vehicle through its entire lifecycle — transfers, service events, and decommissioning are all recorded against it.

A 17-character alphanumeric code defined by ISO 3779 that uniquely identifies a motor vehicle. The VIN is stamped on a metal plate attached to the vehicle. VIN fraud (cloning) involves copying a VIN from a legitimate vehicle onto a stolen one. ShieldVIN makes VIN cloning cryptographically detectable — a cloned VIN plate cannot produce a valid 3-of-3 chip proof.

ShieldVIN's proposed hardware specification standard governing the design, placement, tamper response behaviour, and key management requirements of the three SE chips (EN-1, CN-2, TN-3) embedded in ShieldVIN-enrolled vehicles. Defines minimum security requirements for OEM implementation.

ShieldVIN's proposed standard governing the on-chain data structure of a Vehicle Identity Token — the ledger fields, data types, lifecycle states (ACTIVE, STOLEN, FLAGGED, RECOVERED, DECOMMISSIONED), and the rules for how each field may be written or updated.

ShieldVIN's HTTP/JSON API specification for querying and updating a vehicle's VIT. Defines all request/response shapes, endpoint paths, role credentials, rate limits, proof latency SLAs, and error codes. All six portals and the Verification API use VAP-1. The full spec is in src/specs/VAP-1.md.

ShieldVIN's proposed W3C-style consortium governance model. Defines how consortium members (OEMs, government agencies, insurers) participate in governing the ShieldVIN system — including credential issuance, fee schedule decisions, standard updates, and new member admissions. The VGM-1 authority issues all VAP-1 role credentials.

A SHA-256 hash of the vehicle's off-chain build specification record, stored in the VIT at minting. Links the on-chain identity token to the manufacturer's off-chain build data without exposing that data on-chain. Enables third-party verification of build integrity without a data breach risk.

A cryptographic hash commitment representing vehicle ownership on-chain. Stored as Bytes<32>. Computed as H(ownerSecret ∥ salt) — the owner's secret and a salt, never the owner's identity. Owner identity is resolved off-chain by the relevant authority using their own records. No personal data ever reaches the blockchain.

An identifier stored in the VIT at minting that links a vehicle to its manufacturing facility and OEM. Used by the Manufacturer Portal to scope all operations to a manufacturer's own fleet — a manufacturer can only query or manage vehicles with a matching factoryCode.

A Midnight.js SDK provider that manages encrypted private state on-device using AES-256-GCM LevelDB. Stores witness data (e.g. the owner's secret) that is used in ZK proof generation but never submitted to the public ledger.

A Midnight.js SDK provider that reads public state from the Midnight Network via the GraphQL Indexer. Used for cached status checks — no ZK proof is needed to read publicly disclosed ledger fields such as vehicle status, transfer count, or mileage.

A Midnight.js SDK provider that acts as an HTTP client to the local Proof Server. Sends witness data to the Proof Server and receives back the generated ZK proof for inclusion in the transaction.

A Midnight.js SDK provider that manages the DUST token balance used to pay on-chain transaction fees. ShieldVIN holds a central DUST reserve managed via this provider — clients never interact with DUST directly.

A Midnight.js SDK provider that submits signed transactions (including the ZK proof) to the Midnight Network node for inclusion in the ledger.

New in Midnight.js v4. Manages ZK circuit artifacts (proving/verification keys) required by the Proof Server. Browser environments use @midnight-ntwrk/fetch-zk-config-provider; Node.js environments use @midnight-ntwrk/node-zk-config-provider. Required — cannot be omitted in v4.

The Midnight Network service (v4.0.1) that indexes public ledger state and exposes it via a GraphQL API. Used by the PublicDataProvider for fast public state reads. ShieldVIN uses the Indexer for cached status queries and real-time status-change notifications (webhook triggers).

The current Midnight Network software stack (released 2026-03-30). Key versions: Ledger 8.0.3, Node 0.22.3, Proof Server 8.0.3, Compact Runtime 0.15.0, Compact Compiler 0.30.0, Midnight.js 4.0.2, Wallet SDK Facade 3.0.0, Indexer 4.0.1, DApp Connector API 4.0.1. All ShieldVIN development targets this stack.

A vehicle manufacturer that designs and builds vehicles under their own brand (e.g. Toyota, BYD, Ford). In ShieldVIN, OEMs are responsible for embedding the three SE chips during manufacture and minting the VIT at end-of-line. OEMs are billed a per-vehicle minting fee (Stream 1 revenue), tiered by annual production volume.

A vehicle fraud technique where a criminal copies the VIN plate from a legitimately registered vehicle and applies it to a stolen vehicle of the same make, model, and colour. Accompanied by forged documentation, this allows the stolen vehicle to be sold as legitimate. ShieldVIN eliminates this: a cloned VIN plate cannot produce a valid 3-of-3 hardware proof, so the fraud is detected at the first verification.

The UK government agency responsible for vehicle registration, driving licences, and road tax. A primary government portal user in the UK jurisdiction. Operates under the government VAP-1 role. Billed via enterprise contract (Stream 5), not per-query.

US state government agencies responsible for vehicle registration and driver licensing. A primary government portal user in US jurisdictions. Operates under the government VAP-1 role. Billed via enterprise contract (Stream 5).

The annual roadworthiness inspection required for vehicles over three years old in the UK. MOT stations are a category of service centre in the ShieldVIN system, using the Dealer & Service Portal to record inspection events and verify vehicle identity.

The manufacturing stage where the vehicle's structural body panels and frame are welded together before painting or component installation. The CN-2 Chassis Node is embedded at this stage — before the body is painted and before any trim or interior is installed — making it physically part of the vehicle's structure.

Software systems used by large manufacturers (e.g. SAP, Oracle) to manage production, supply chain, inventory, and logistics. At Phase 3, the ShieldVIN Manufacturer Portal will expose an ERP integration API to allow OEMs to trigger VIT minting directly from their production line management systems.

A compact, URL-safe format for representing claims between parties as a signed JSON object. All VAP-1 role credentials are JWTs issued by the VGM-1 governance authority. Credentials are device-bound and carried in the HTTP Authorization: Bearer header on every API request.

The duration for which a cached result remains valid. In ShieldVIN: cached status certificates have a TTL of 24 hours standard, reduced to 1 hour for any vehicle whose stolen flag has recently been updated. Expired cache entries require a new live ZK proof to refresh.

A unique random value included in live proof requests to prevent replay attacks. The requester generates the nonce; it is signed by all three SE chips and included in the ZK proof. The nonce is echoed back in the response so the requester can confirm the proof was generated for their specific request and not recycled from a prior proof.

The cryptographic protocol that secures network communications. VAP-1 requires TLS 1.3 as the minimum version for all API connections. No plaintext (HTTP) connections are accepted.

The ISO standard defining the format and content of Vehicle Identification Numbers. Specifies the 17-character structure: 3-character World Manufacturer Identifier (WMI), 6-character Vehicle Descriptor Section (VDS), and 8-character Vehicle Identifier Section (VIS). VAP-1 validates all VINs against this format.

The ISO standard for country and subdivision codes. Used in VAP-1 requests to specify jurisdiction (e.g. GB-ENG for England, US-CA for California). Jurisdiction codes determine which government authority has access rights and which stolen flag disclosure rules apply.

A standard format for describing REST APIs in machine-readable form. The ShieldVIN Verification API (api.shieldvin.org) will publish an OpenAPI specification for use by insurer and lender integrations. Available in the API Portal Dashboard alongside SDK downloads.

An HTTP endpoint registered by an API customer to receive real-time notifications when a specific event occurs. In ShieldVIN, insurers and lenders can register webhooks to be notified when the status of a policy or financed vehicle changes (e.g. a vehicle changes to STOLEN). Triggered by monitoring the Midnight Network GraphQL Indexer for state changes.

VAP-1 role assigned to vehicle manufacturers. Grants access to the Manufacturer Portal: mint VITs, manage their own fleet, issue recall flags, manage dealer credentials, authorise hardware recovery. Scoped to VINs with a matching factoryCode — a manufacturer cannot query or modify another manufacturer's vehicles. Billed per VIT minted (Stream 1).

VAP-1 role assigned to police and border agency personnel. Grants full Government Portal access plus law-enforcement-specific disclosure: when a vehicle status is STOLEN, the VIN is additionally disclosed to this role (withheld for non-stolen vehicles and all other roles). Can file stolen reports and generate signed evidence packs for court submission. Credential issued by national authority via VGM-1.

VAP-1 role assigned to government agencies (DVLA, DMV, transport ministries). Grants Government Portal access: VIN lookup, fleet/batch queries, jurisdiction dashboard, recall visibility, node rotation log, evidence pack export. Higher rate limits than law enforcement. Billed via annual enterprise contract (Stream 5) — never per-query.

VAP-1 role used by both insurance companies and finance lenders for API access. Grants access to the Verification API: status checks, ownership verification, mileage history, and service count. Cannot write to the ledger. Billed per query (Stream 2). Finance lenders use this same role — they are not distinguished at the API level.

VAP-1 role for authorised vehicle dealers. Grants Dealer Portal access: identity checks, ownership transfer, hardware recovery initiation, QR code generation, finance verification packs. Service centres share this subscription tier with access scoped to identity checks and service recording — not ownership transfer or finance tools. Billed monthly (Stream 3).

VAP-1 role for private vehicle owners. Scoped to vehicles where the holder can prove ownership (knows the ownerSecret preimage for the current ownershipHash). Grants Owner Portal access: identity card, ownership proof generation, stolen reporting, private sale transfers, share QR codes. 1 free identity check per month; $5 per private ownership transfer (Stream 4).

EU regulation (applied in the UK as UK GDPR post-Brexit) governing the collection, storage, and use of personal data. ShieldVIN is GDPR-compliant by construction: no personal data is stored on-chain. Ownership is represented as a cryptographic hash commitment. ShieldVIN's privacy architecture complies with GDPR Article 25 (data protection by design and by default).

US state law (California) governing consumer data privacy rights. ShieldVIN's on-chain zero-personal-data architecture ensures compliance — no consumer data is stored on the blockchain. Off-chain portal data is handled under standard data processor agreements.

South Africa's data protection law, analogous to GDPR. Relevant as ShieldVIN's founding jurisdiction (South Africa, CIPC registration). ShieldVIN's no-PII-on-chain design is compliant with POPIA's conditions for lawful processing of personal information.

EU regulation establishing a framework for electronic identity and trust services. ShieldVIN is pursuing alignment of VAP-1 verification outputs with eIDAS 2.0 verifiable attestation formats. Successful alignment would provide a significant distribution advantage for EU market entry — VAP-1 credentials could be issued as eIDAS-compliant verifiable credentials.

The US federal database of vehicle title, theft, and salvage information. A primary existing system that ShieldVIN complements and supersedes in enrolled jurisdictions. NMVTIS is reactive (depends on timely reporting) and carries no cryptographic proof. ShieldVIN provides real-time, hardware-backed proof.

The South African government body for company registration and IP rights. ShieldVIN's provisional patent is to be filed with CIPC first (South Africa) before the UK IPO filing — establishing South African priority date. The CIPC provisional patent application must be filed at cipc.co.za before the IPO filing.

The UK government body responsible for granting patents, trademarks, and designs. ShieldVIN's UK provisional patent application must be filed with the IPO within 12 months of the CIPC South Africa filing to claim South African priority under the Paris Convention.

The process of verifying the identity of a customer before granting access to a service. In ShieldVIN, each portal performs its own off-chain KYC appropriate to the user's role — e.g. a law enforcement agency verifies officer credentials; a dealer verifies business registration. KYC is an off-chain portal concern; no identity data from KYC is stored on-chain.