DIP-4: Device Integrations

Headline: Expanding the ecosystem of DIMO compatible hardware devices and software connection methods

Author: The DIMO Foundation

Submitter(s): The DIMO Foundation [0xCED3c922200559128930180d3f0bfFd4d9f4F123]

Status: Deployed

Voting URL: Snapshot

Discussion Forum: Discord #🗳️governance forum

Vote Type: Level 3


This proposal outlines the method by which hardware manufacturers (like AutoPi) who produce compatible devices, as well as software developers (like SmartCar) who build digital integrations (collectively referred to as integration providers) bond $DIMO and receive a license.

The requirements for any integration providers are that they must:

  1. Pass a DIP that approves their license application;

  2. Bond 100,000 $DIMO tokens as a security deposit;

  3. Transfer the applicable amount of $DIMO for each integrations they enable; and

  4. Remain in good standing with the community.


As a part of the vision to establish DIMO as a decentralized universal protocol, it is important to develop a robust and diverse ecosystem of manufacturers producing DIMO compatible hardware and software companies providing digital integrations.

The goals of this proposal are to:

  • Onboard and retain hardware providers (OEMs), software integrations, retailers, distributors, and support channels that are tightly aligned with the interests of the DIMO protocol and its users;

  • Accelerate the development and integration of new device types and integration methods such as dash cameras, cheaper dongles, embedded hardware, and more; and

  • Optimize the operations and financing of device production, fulfillment, and installation.


Integration Providers & Device Licenses

In order to connect to DIMO users, their vehicles, and their data, integration providers must agree to various obligations, receive a license by passing a DIP, bond 100,000 $DIMO, and deposit $DIMO for each device they sell.


Integration providers commit to maintaining strict quality and security standards, provide support for their services, always act in good faith, and agree not to engage in unlawful activities. The following is illustrative but not exhaustive.

Connection methods must not:

  • Interfere with the users safe operation of their vehicle;

  • Damage the vehicle it is installed in;

  • Deliberately or negligently generate false data.

Connection methods must:

  • Comply with all local regulations;

  • Receive adequate support from the provider for a reasonable duration of time;

  • Perform as expected; and

  • Only share data with recipients that the user has opted into sharing with per the parameters of the DIMO protocol.


Prospective integration providers may receive a license by passing a DIP using the License Approval Template. The application must provide details about their business, their operating history, as well as specifications for the initial devices they intend to manufacture and/or software services they intend to provide.

The DIP must contain specifications for at least one device design, test units, and data samples and/or a code repository and a functioning demo. Licensed providers are able to submit additional and simplified applications for new devices and software methods at any time.

Integration Types

All integrations methods must be categorized as one of the following device types. New device types may be added by token holders with a valid governance vote.

Device TypeConcept ImageDescriptionTypical Price Point

Software Only


Leverages existing vehicle subscription programs and their APIs to establish a baseline of connectivity

No added charge. Vehicle manufacturer (e.g., Ford, BMW) may charge a subscription fee.


Records vehicle data from the CAN bus.



IoT hub that enables long term local storage and backup of data.


Dash Camera

Device that records camera footage and possibly other telemetry


Fleet Device

Telemetry devices designed for commercial use


AI Device

Device that supplements enhanced driving features (e.g., Comma AI)


Connection Specifications

The following are minimum device specifications.

Both Hardware & Software


Power management

DIMO compatible devices must implement power management to prevent phantom drain of the vehicles it connects to, and efficiently manage being in “sleep” mode.

Secure runtime

Security is of highest importance to DIMO for both safety and security of the users. To provide an additional layer of safety to the car and the user, DIMO devices must run signed and verified code. Hardware must use secure boot mechanisms.

Streaming interface

DIMO Integrations will provide a specification for how the data should be formatted (schema) and sent to the protocol (delivery). Initially, the data will be sent in compressed json, moving to more efficient binary methods of encoding such as protobuf or avro.

Approved geography

Currently, devices may only operate within the United States of America, Canada, and Europe. Support for new regions may be added by the DIMO community in future DIPs.

Hardware Only


Hardware secure element & EVM wallet

The identity of the device and the vehicle it is connected to is of high importance. In web3, this is known as a “wallet”, but is essentially a private key to identify the device. To limit spoofing, DIMO requires the private keys to be stored inside a hardware secure element. This key is also used for encrypted, secure transmission of vehicle data. Each device should contain its own EVM compatible wallet.

DBC logger configuration

Each vehicle is different and provides different signals on the canbus. To handle this variety of messages, DIMO maintains an open repository [OPENDBC]. To be compatible with DIMO, the device must accept dynamic configuration of signals for filtering, parsing, and delivery to the protocol.

OTA process

To be accepted into the program, the device manufacturer must routinely support and update their devices as new vulnerabilities are found. This must be able to be done via cellular connection.

3rd party certifications

Licenses & Bonding

While it is preferred that the integration provider is the party putting up the bond, it is also possible for a financing partner, such as a distributor, to put up the bond on behalf of the manufacturer.

Should applicants not have $DIMO or not want to interact with tokens, they may purchase $DIMO from the Foundation and/or have the Foundation put up the bond on their behalf.

The bonding amount may be altered by any future governance vote.

Slashing & License Revocation

Through a governance vote, DIMO token holders have the ability alter the manufacturer’s bonding requirements. Manufacturers must be given thirty days to adjust their bond to the new level.

Token holders are also able to ban devices from the network (e.g., if they’re not secure and provide false data) and/or suspend or revoke a manufacturer’s license through a valid governance vote if they violate the obligations specified above or there is demonstrable and material negligence or malice perpetrated by the manufacturer that harms users or the DIMO protocol generally.

Any manufacturer may renounce their license and receive back their bonded $DIMO after six months.

Connecting a Device to DIMO

Device Payment Requirements

For physical hardware, licensed manufacturers pay a set amount of $DIMO to mint a device and enable it to connect to the $DIMO network.

The $DIMO payment is set aside. Each month that the connection persists, the integration provider receives some of that $DIMO back as rebate for twenty four months until they earn back 70%.

Why add this complexity? It's to align incentives.

This rebate mechanism ensures that both integration providers and DIMO Integrations are long-term holders of $DIMO and that they have an incentive to produce resilient devices and services that users will love and want to keep connected.

The DIMO Treasury keeps any $DIMO that isn't returned to the manufacturer.

Cost of Device Minting

The amount of DIMO required for device minting varies by device type.

TypeDescriptionCost (in $DIMO)


Leverages existing vehicle subscription programs and their APIs to establish a baseline of connectivity



New hardware that users and purchase and install in their vehicle.


Similar to the bond required for licensing, device minting costs may be covered by financing partners, such as a distributor.

Temporary Licenses

For six months after the passage of this DIP, the following companies have a temporary license. Following six months, they will need to apply for a permanent license per the process defined above.


If passed, the DIMO Foundation will issue licenses per valid governance votes.

Copyright and related rights waived via CC0


Please cite this document as:

The DIMO Foundation, "DIP-4: Device Integration", no. 4, December 2022. [Online serial]. Available: [https://github.com/DIMO-Network/DIP]


Dec 7, 2022: added discussion forum and voting type to the DIP header.

Dec 7, 2022: adjusted review date to give people more time to claim the Airdrop prior to voting going live.

Dec 26, 2023: adjusted review date again to allow for fixes to delegation strategy prior to voting.

Dec 30: combined Micro and Standard Dongle to one category ("Dongle") and decreased minting price on all device categories.

Jan 6, 2023: final adjustment to review date — proposals go to vote on Tuesday Jan 10.

Jan 6, 2023: simplified the language on buying tokens from the DIMO Foundation and removed the preset exchange rate. Refer to DIP-6: The DIMO Foundation for more on exchanging tokens with the Foundation.

Jan 6, 2023: updated the language surrounding revoking a hardware manufacturer's license to include cause.

Jan 9, 2023: made device minting cost 25 $DIMO for all device types for now

Mar 29, 2023: passed DIP-4 & 5: Amendment 1


The contract addresses for $DIMO are 0x5fab9761d60419c9eeebe3915a8fa1ed7e8d2e1b on Ethereum and 0xE261D618a959aFfFd53168Cd07D12E37B26761db on Polygon. Please always confirm that you are interacting with these contract addresses and not those of a fraudulent imitator. This proposal may not be enacted if it violates Cayman Islands law. Please triple check that any communications are authentic as it’s common for scammers to try to trick you into sending them crypto or into revealing your private keys.

Last updated