Mobility Open Blockchain Initiative (MOBI) is a global nonprofit smart mobility consortium. MOBI and our members are creating blockchain-based standards to identify vehicles, people, businesses, and MOBI Trusted Trips (decentralized identity linked with location into a verifiable trip). We are building a Web3 digital infrastructure (Citopia vinTRAK) for connected ecosystems and IoT commerce. Our goal is to make transportation more efficient, equitable, decentralized, and sustainable, all while preserving the data privacy of users and providers alike.

The Dealer Floorplan Audit (DFA) Pilot using Citopia vinTRAK zero knowledge proof of location verification is spearheaded by MOBI’s Finance, Securitization, and Smart Contract (FSSC) Working Group (WG) with contributions from Accenture, Altaventure, Amazon Web Services, BMW Bank, CEVT, Connections Insights, CO-OP Financial Services, ConsenSys, D.E. Consulting, DENSO, DMI, Ford Credit, Global Debt Registry, GM Financial, Honda, IOTA, Itochu, National Automobile Dealers Association (NADA), Nissan Motor Acceptance Company, On the Road Lending, Orrick, Quant Network, Quantstamp, Reply, RouteOne, Southeast Toyota Finance, Spring Free EV, Stellantis Financial Services, Tezos Foundation, Toyota Industries Corporation, Trade Log, and USAA.

When dealers buy vehicles from manufacturers (OEMs), they finance the purchase with the vehicle as collateral for the loan. To ensure that the collateral is safe, lenders perform audits to verify that the vehicles expected to be at the dealership are actually physically there — hence the name, dealer floorplan audit. If a vehicle is sold, the loan must be repaid under the lender’s terms. This is similar to the housing market where you must immediately pay your mortgage lender if you sell your house. In the housing market, mortgages are repaid out of escrow as part of the sales process. Dealer floorplan loans have no similar escrow process, so lenders currently employ human auditors (usually third party service providers) who provide a trust service to guarantee that their unsold vehicles are on the lot and that the sold vehicles are being paid according to the lender’s terms.

Floorplan auditing requires an extensive amount of manual work as auditors must physically go to dealer lots to count and verify that the vehicles are on the lot or otherwise accounted for. Furthermore, these audits are not done frequently enough to catch all potential errors. Therefore, lenders hold reserves to compensate for the risk, thus increasing the cost of the loans for dealerships.

To this end, MOBI and our members are building a digital infrastructure called Citopia vinTRAK. Auditors can incorporate the technology provided by vinTRAK to significantly improve their auditing process/application by reducing resources while being able to perform secure and privacy-preserving audits at any time and any frequency (with frequencies corresponding to different levels of risk at different dealers). This will eliminate substantial expenses for the lenders — fewer auditing resources, cheaper capital — and therefore lower the costs of loans for dealerships; a win-win.

Modern IT systems allow for the track and trace of connected devices with a big catch — the location of device users (Personal Identifiable Information, or PII) is exposed! Vehicles on dealer lots are filled with sensors that can provide accurate data about the vehicle’s condition, location, and other important information. While it is theoretically possible to use existing vehicle telematics to check location and automate the audit process, doing so potentially reveals customer PII, for example, if the vehicle is sold or loaned to a customer. In addition, each dealer lot may contain vehicles from multiple OEMs that do not share data with each other during the audit. As a result, lenders have continued with manual auditing.

MOBI’s DFA pilot uses Citopia vinTRAK zero knowledge proof of location verification capabilities to confirm the loan collateral without revealing vehicle location or any other data. Vehicle location within or outside a dealer lot at any moment in time can be proven and verified using Zero Knowledge (ZK) cryptography without revealing any clear text information about a vehicle’s location or identity (e.g. VIN number). The only public information required to verify the ZK proof and verification is the geofenced location of the dealership. During the audit process, the vehicle is asked “Are you in this geofenced location?” and the vehicle responds with the proof “Yes/No.” Lenders can vary how frequently the vehicles should generate such proofs in response to the varying levels of risk between different dealers. See Appendix A for ZK proof input/output and generation/verification.

An additional layer of privacy for the technology being demoed is the use of World Wide Web Consortium standards to create Citopia Self-Sovereign Digital Twins (C-SSDT). **A C-SSDT is a Digital Twin (DT) where only the owner/controller has access to the data stored inside the DT and can participate in autonomous transactions.

• Vehicle geolocation resides ONLY in the vehicle C-SSDT (MOBI and Lenders do not have access to this data)
• ZK verification of vehicle location (does not contain specific location or the VIN) resides in both the vehicle and the lender C-SSDTs (MOBI does not have access to this data)**

Together, these technologies enable the automation of DFA without the messy complications of handling PII associated with vehicles. This DFA pilot is foundational for many track-and-trace applications powered by ZK cryptography. Building on this innovative groundwork, OEMs can monetize connected vehicle data in future applications such as vehicle maintenance traceability, battery cross-border compliance, and usage-based services.

PILOT STAKEHOLDERS — See (**) above regarding C-SSDT. For this pilot, C-SSDTs are implemented on Citopia cloud.

OEMs:

• Create a secure account and self-onboard by creating C-SSDT
• Onboard vehicles by creating vehicle C-SSDTs (VIN, make & model) and generating secure API endpoints
• Connect vehicle C-SSDT to vehicle telematics via secure API connection (specifically only near real-time geocoordinate is needed. This data resides in the vehicle C-SSDT and is not shared with MOBI or Lenders)
• Allow communication between vehicle and Lender C-SSDTs via secure API connection >> Lender C-SSDT asks vehicle C-SSDT “Are you in this geofenced location?” the vehicle responds with the proof “Yes/No”

Lenders:

• Create a secure account and self-onboard by creating C-SSDT
• Provide periodic updated list of dealers and each dealer’s geofenced location(s) via secure API connection
• Provide periodic updated list of vehicles (VIN numbers) for each dealer via secure API connection
• Set vehicles’ ZK proof of location requirements for each dealer (e.g. ping vehicles 1-24 times a day)
• Set vehicles’ ZK proof of location report for each dealer (e.g. once every 1-3 days)

Our focus for phase 2 of the DFA pilot is to use in-vehicle telematics (specifically only near real-time geocoordinate is needed). As stated above, this data remains in the vehicle C-SSDT and is not shared with MOBI or Lenders. If you have questions, please contact griffin@dlt.mobi.

1. Why is near real-time geocoordinate data needed for this DFA pilot?
To generate ZK proof of location verification with PII and data privacy. The proof does not contain clear text information about vehicle location or VIN, therefore vehicle location is not shared with MOBI or Lenders.

2. What are the required in-vehicle telematics attributes?

• VIN
• Latitude and longitude within at least 5 decimal (approx 1.11m) degrees accuracy
• Timestamp in UTC (date and time)

3. What frequency of vehicle geolocation data is needed?
Maximum once/hour. Vehicle exact geolocation remains in the vehicle C-SSDT. Lenders receive the ZK proof and MOBI and Lenders do not have access to vehicle C-SSDT.

4. How is vehicle geolocation data shared?
A secured API connection directly to the vehicle C-SSDT. MOBI and Lenders do not have access to or see data.

• When an OEM creates a secure account and self-onboard, the OEM C-SSDT is automatically generated in the system
• OEM onboard vehicles by creating vehicle C-SSDTs
• Vehicle C-SSDTs generate API endpoints for C-SSDT to C-SSDT communication (e.g. Lender C-SSDT asks vehicle C-SSDT “Are you in this geofenced location?” and the vehicle responds with the proof “Yes/No”) Note: See Appendix A for ZK proof input/output and generation/verification
• Future phases of the pilot may include Dealer and Lender C-SSDTs asking the vehicle C-SSDT for additional telematics and/or sensor data for use in other applications

5. How long is the pilot duration?
Six months.

6. How often does the system need the updated list of vehicles (VIN list)?
Minimum once per day through a secured API connection directly to the Lender C-SSDT.

7. How often does the system need the updated list of dealers and their geofenced location(s)?
Minimum once per month through a secured API connection directly to the Lender C-SSDT.

8. How many vehicles are needed for the pilot?
There is no limit and the more the better. Minimum ten vehicles per dealer.

9. Which ZK proof system was used for this pilot and why?
For this pilot, Lenders are repeatedly pinging Vehicles at regularly defined intervals to request Proof of Location (PoL). As the number of requests for PoLs increases, the number of proofs increases quickly. Moreover, those proofs must be stored, as Lenders must be able to reference them in the future. And they should be fast to verify without heavy compute requirements. Therefore, proofs should be efficient (fast to generate without requiring a lot of storage and compute during proof generation) and succinct (small in size, and, therefore, fast to verify on regular computers/devices).

In light of these requirements, Citopia utilizes ZK-SNARKs (Zero Knowledge Succinct Non-Interactive Arguments of Knowledge) as the ZKP method of choice for vinTRAK ZK Proof of Location. SNARKs are a powerful cryptographic tool that have several advantages over other types of ZKPs for this use case due to the following key factors:

• SNARKs are private and trustless. SNARKs enable the verification of computations without trusting any third-party or revealing any information about the private inputs used in the computation. This makes them useful in situations where the privacy of the inputs is important, such as in financial transactions or in sensitive data processing (such as geolocation).
• SNARKs are scalable. SNARKs enable the verification of large computations with very low computational overhead. This is because the proof generated by a SNARK is very small (on the order of a few hundred bytes) and can be verified very quickly (on the order of milliseconds). This makes SNARKs suitable for verifying computations on large-scale systems, such as blockchain networks, where scalability is a critical concern.
• SNARKs are efficient. SNARKs are computationally efficient, meaning that they can be generated and verified using relatively low computational resources. More specifically, SNARKs have an O(N*logN) proving time and O(1) verification time. This makes them useful in situations where computational resources are limited, such as in low-power devices or in resource-constrained environments.

Overall, SNARKs offer computational efficiency, strong security, and privacy, making the approach a valuable tool for those handling sensitive or valuable data like geolocation or other PII.