DIMO 2024 Developer Roadmap Introduction

The Automotive industry produces trillions of dollars of economic activity each year. Across manufacturing, sales, financial services, insurance, maintenance, personalization and more, there are tens of thousands of companies in the space. Every one of them is grappling with an industry that is changing faster than ever before due to electrification and autonomy.

Underpinning these dual transformations is the connected car stack. Today, it’s fragmented, opaque, and underdeveloped. Even in this nascent stage, existing connected mobility platforms have established a worrying trend of building in silos, missing the mark on security, and abusing user privacy, as you can see from examples like these: The Markup, Detroit Free Press, Mozilla, NYTimes.

DIMO's mission is to create an open data network that unifies and modernizes the automotive industry. DIMO connects every car that’s a 2008 or newer to a global vehicle platform. It is built for developers who want to produce next generation mobility applications.

To definitively address the issues of openness, privacy, and security, the DIMO Protocol:

• Is built on blockchain with open source technology to remove counterparty risk — no for-profit corporation can tamper, restrict access, block innovation, or lock developers out;

• Securely stores user and vehicle data in an encrypted manner so that by default, users are the only ones who have access; and

• Allows users to manage who they share their data with using smart contracts in an auditable and easily revocable manner;

After three years of building and testing the core infrastructure, we’re now ready to welcome developers to start building on top of it. This is a major milestone, and it represents the beginning of a new chapter in the growth of DIMO.

When new developers start building on DIMO, two things happen:

1. We create more utility for the drivers and fleet managers who have vehicles connected; and

2. We validate the value of the network infrastructure that we have been investing in.

These two outcomes should be exciting to the whole community. Here’s how we get there.

DIMO core developers intend to accomplish everything below in the 2024 calendar year, except the features under “Future Investments.”

Better Tools For Developers

It should be very easy to build on DIMO and offer your services to drivers. Developer tooling facilitates getting your services into the hands of the drivers quicker.

Live Today

There is already a rich catalog of APIs available for developers to retrieve data and issue commands to vehicles available here.

• SDK: Our first SDK for TypeScript and JavaScript developers to build interfaces and solutions for vehicle data. The SDK supports all REST and GraphQL endpoints. Our SDK roadmap is publicly available here.

  • Developers can now use the SDK to build robust applications more efficiently and with less set-up time.

• Telemetry API: The Telemetry API is our GraphQL implementation for vehicle signals, supporting advanced functionalities such as aggregation and customizable intervals. It replaces the Device Data API endpoint while storing data in the industry-standard VSS format.

  • Developers can now get customized aggregated data efficiently and fetch only what is needed.

• Trips API Improvements: The Trips API underwent a major improvement, the endpoint now lists the latitude and longitude at the start and the end of each trip. An estimated location for trip start is also provided to facilitate capturing data with consideration of potential signal losses between trips.

  • Developers can now use Trips API to build ride sharing or trip planning applications. Combine Trips with your own logic for task or inventory management to build the next delivery solutions.

Upcoming

• Credentials API: Developers can retrieve and check validity of issued credentials, like Proof of VIN or Proof of Movement.

  • When anyone can mint a vehicle on DIMO, we need to differentiate which vehicles are valid and we’ll do that with credentials/claims that are issued against it. A vehicle with several valid credentials is more valid than one without.

  • Developers may want to issue their own credentials to vehicles and drivers related to their insurance status, title status, reputation, etc.. 


• Events API: Requesting crash events, charging events, hard brake events. Query for data that is not a signal, such as “fuel level.”

  • Why: Vehicle history can be thought of as a series of events that in summary, compose its lifecycle. 


• Developer Console: A self-service management interface. Developers will be able to provision a Developer License and obtain easy access to the API, self-served and permissionless.

  • Initial versions will require a MetaMask or some other external owned account (EOA) to perform on-chain activities. Once WaaS (see below) is live, it will enable integrations with fiat onramps and developers will no longer need to fumble with crypto in order to build.

• Wallet as a Service (WaaS): DIMO Account template provided by smart contract accounts from ZeroDev and Turnkey. A seamless account provisioning and login experience for the developers and end users. In the future, we’ll provide templates for how developers can offer one-time payments or subscriptions to customers in the marketplace, without worrying about the chain.

• DIMO Credits: DIMO Credits (commonly referred to as “DCX”) are stablecoins pegged to one-tenth of a cent that can be created by burning $DIMO. This offers developers a simplified and stable currency to pay for transactions and vehicle data. 


  • DIMO Credits can be used for issuing developer licenses, minting vehicles, and other on-chain protocol payments.

  • DCX Smart contract is live, awaiting integration with the Developer Platform.

• Instant Offer Oracle: Allows you as a developer to request the valuation of a specific vehicle to price it on an onchain market.

Data Enrichment

DIMO is built on the foundation that vehicle data is valuable. The more data that exists about a vehicle, the more applications and uses can be built with it. In 2024, we’ll dramatically increase the amount of data that can be collected from vehicles and the amount of data available to developers via API.

Better Data From Vehicles

DIMO allows users to get data from the vehicle either by using aftermarket hardware, like the DIMO Macaron or DIMO AutoPi, or through software connections if you have an app for your car. We expect to see another kind of integration, and embedded device, in the future.

Below you can read about our roadmap for increasing the amount of data that users can collect about their own vehicles.

• Decoding: DIMO core developers are deploying DBC codes and PIDs for more vehicles. Part of this will be publishing a place where you can track what “signals” have been deployed and what's in the pipeline.

  • Codes and signals are now starting to be contributed by several community members. If you have expertise with vehicle decoding or CAN bus hacking and would like to be rewarded for contributing data, please contact us at [email protected].

  • Note: Just because a particular signal is stored in DIMO does not mean that signal will be visible in DIMO Mobile or any other app built on the network.

• Better and More Software Integrations: We’ll be integrating more endpoints from existing sources like SmartCar, adding High Mobility as a connectivity option, and adding fleet API integrations.

  • Integrate Connection Management, untapped Vehicle Endpoints, and Make Specific endpoints from Smartcar.

  • Integrate Ford Pro APIs.

  • Integrate additional 3rd party connectors such as High Mobility.

• Transparent Tracking of Collectable Data: DIMO Explorer has become out of sync with actual data collectable from particular vehicles, and it needs to be improved to provide users more insight. It will become the single place to see what data is available across integration types from a given vehicle.

Open Ecosystem

• Device Definitions onchain: Digital Infrastructure Inc. has put the canonical registry of vehicle Make Model Year combinations (what we call Device Definitions) onchain with a Tableland integration in advance of community permissions. In the future we’ll open community submissions of vehicle definitions & open contributions to existing dataset.

• Open Minting (Permissionless Minting): Anyone can pay in DCX to mint a vehicle, but this requires you to be familiar with submitting txs. This will mint a car without the VIN, but the vehicle will not earn until it has sufficient integrations (software or hardware connection).

  • This allows for more and simpler onramps to DIMO. Mint your car, come back and connect it later.

  • It will also open up valuable platform aspects, like allowing someone to create their Vehicle Identity with a CarFax (for example).

  • Using WaaS we will allow for the abstracting away of the blockchain in favor of web2 tools and APIs.

Future Investments (2025 and beyond)

• Vehicle Simulator:
Vehicle simulation in sandbox.

• DIMO Node & Node Payment: Node provider gets paid when developer calls api.

• Generic Device: A non-earning device type for developers to use. Allows full usage of the platform without baseline.

• Credentials SDK:
Developer SDK for issuing credentials (car is blue, car is insured, etc)

• Charging API: A dedicated endpoint that allows you to retrieve the specific charging cycles a vehicle has undergone. Timestamps beginning and ending chart, time and voltage.

• For use cases like charging networks, dynamic charging, charging planning and more, developers want to access data by charging cycle.