Somehow (likely the result of millions of dollars worth of presentations from consultants) automakers got it in their head that the best thing about connected cars was going to be the ability to sell subscriptions to drivers for everything in the car. This blended well with the new concept of Software Defined Vehicles and their dreams of getting some sweet, juicy software margins.

Instead, customers are rejecting the approach. Last year customer backlash led BMW to drop their plan for heated seat subscriptions and almost daily tweets like the one pictured below pop up across social media.

In public perception cars have always had a connection to freedom, and adding layers of subscriptions is at odds with that. Automakers must embrace the idea that they are creating a connection, a relationship, with car and driver that goes beyond the transactional.

The connection between driver, car, and company should be enriched over time, not used for singular promotions. By creating a digital identity for each vehicle, drivers will build up their own history of ownership, including the drives and milestones they achieve. Each step in their journey is a step in the relationship with their vehicle and the companies and services they interact with.

Opening up third party access to vehicle data and connectivity is a critical part in strengthening the relationship. Users are going to use these apps and services no matter what, and supporting users in digital freedom — using their data and connectivity throughout the internet — is in line with the original spirit of freedom vehicles have long embodied.

This comes back to the first principles. Is your technology increasing the options, choice, capabilities, fun, or freedom of your users or restricting it?

If you follow the headlines in the auto space, you’ll notice that increasingly more of those headlines relate to the software that runs on and data that comes from the car. The auto industry has been talking about “Software Defined Cars” (SDVs) for over a decade now, but there is a subtle change that is occurring.

The core concept of the SDV is that by defining more of the components of the vehicle as software, it can become upgradeable. The emerging battleground today is who should have the right to own and manage that software and by extension, the ability to use the data.

As a driver, being in control can mean the difference between wanting to sue your automaker for sharing data with an insurance company without your knowledge or happily sharing your data for a discount because you’re fed up with your bill.

At a geopolitical level, the US Government, eyeing the incredibly low prices and flashiness of new Chinese EVs, is **trying to limit software from China from these vehicles. **It wants your car to be like your iPhone: hardware made in China, software made in the US. Of course the concerns are founded in the question: who is in control of the software and the data?

When we started DIMO we set out to build a credibly neutral infrastructure layer for vehicles. In a future with autonomous vehicles, frequent software updates for cars, and connected cities, there must be some way to verify data and state across these connected objects, and we believe that infrastructure must be open source. Without an open source foundation we run the risks of privacy being taken away and abuses running rampant. We’ll build a better a better way with DIMO.

When people talk about data ownership, the default assumption is that at some point, a user will be able to sell that data to some data consumer in a transaction. Many have tried to ascribe a lot of value to this model of data ownership, but it’s just not as big of an opportunity as people think. Data relationships however are quite different in their size and opportunity.

A data relationship differs from a data purchase. Data purchase, particularly when it’s aggregated and anonymized data, like a user contributing data to a pool, is passive, lacking a feedback / action loop from the data purchaser. Even if the data is a stream, it’s a single purchase.

This is not what DIMO is building (although we support it). We’re building the ability for users and developers to have relationships which require data. Here’s what a few loops might will look like on DIMO:

• A car dealer sells a DIMO Device with the DIMO Mobile app to a driver.

• That user shares their data back with dealer. The dealer pays for this data, with some revenue going back to the user and some going back to the DIMO protocol.

• If the driver’s vehicle throws an error code, both driver and dealer can see that data. Dealer can offer a targeted service, user pays, and the car gets fixed.

Data and dollars are being exchanged, but the basis of the value is in how data will drive decisions between the two parties.

Relationships create more economic value than transactions, as is obvious because this implies the existence of more than 1 tx. Relationships are many txs, and are informed by feedback loops.

Socially, relationships are dynamic and perpetuating. One relationship may lead to another (friend introduces you to another friend). This happens in the data world too:

• A user uses DIMO and to collect their vehicle data.

• The user shares data with car mechanic AI agent, paying a subscription. The car AI agent pays protocol.

• Along the line, the agent recommends a service and service provider, referring the user to a shop and collecting revenue for referral.

This relationship benefits multiple parties at once.

Data ownership only matters if it goes along with the ability to enter data relationships. Relationships are possible with 3rd party developers building on your platform, and this, not just a large set of aggregated data, is the DIMO mission. We want to make every car on Earth programmable by any developer.

Connect you car today, start collecting your data, and soon you can start to connecting it to more entities and relationships.

The amount that is being built within the DIMO Ecosystem is very exciting. New products mean new ways for users with connected vehicles to have a better connected car experience, and they create network value. Here are a few “coming soon” teasers.

Carvis.ai is sourcing feedback from the DIMO community for their AI mechanic product. They are looking for testers who will help them hone features while they build a DIMO integration. Fill out their survey here.

We’re also working with Toucan Protocol on an activation for DIMO as part of #OnchainSummer on Base. As part of this, you’ll be able to voluntarily offset carbon from your driving. Keep your eyes out for this come August.

There are a slew of other teams building on DIMO, and as their products come into being you’ll see the ecosystem grow.

At Digital infrastructure Inc., we’re focused on the DIMO Mobile app. More UX upgrades are coming very soon with release 1.15, which lands in just a few weeks in July.

The Macaron also got an important update this week with firmware 0.9.3, which will continue to help the Macaron operate with better power efficiency. This sweet little device keeps getting better.

Last but certainly not least, If you haven’t seen it yet, check out the trips sample app. With this web app, our team is dialing in our trips engine, so that apps across the DIMO Ecosystem can build using this primitive. Ride hailing, safety, and many other kinds of apps will benefit from a trips engine.

Login with your wallet to explore trips you’ve taken with your vehicle, another and perhaps the best and most informative way to actually view your vehicle data.  https://trips-sandbox.drivedimo.com/

We’re talking with hundreds of companies across the auto space. Some have already become partners (checkout the DIMO Mobile app marketplace) while others are working out how they can use vehicle data to build better, cheaper, or new apps and services across auto and mobility. This possibility is only now starting to open up with the @DIMO_Network Platform.

In the next 3-6 months we will see the first apps rolling out that are built on DIMO APIs.

Some of these apps will be new ways to onboard your car. Users will connect their car to DIMO and utilize the vehicle data entirely in that app, whether for maintenance, insurance, or roadside assistance.

The same onchain activity will occur, the same protocol revenue (checkout the first burn) but the user experience will be distinct. You should think of apps built on DIMO the same way apps are built on Ethereum, Solana, or other blockchains — along with your wallet, your vehicle ID can interact with each distinct dapp.

DIMO is no different. You may use a different app to book maintenance, different app to connect socially to your car club, and a different app for insurance. This sets DIMO apart from most other DePIN projects and really makes DIMO more like consumer or social products in the crypto space, where your profile is composable. We’ll know we’re on the right track when millions are having that seamless connection experience.

If you want to explore vehicle data, we want to hear from you. Check out the DIMO docs here: https://docs.dimo.zone/developer-platform

1. The DIMO Developer Console, which will make it extremely easy for developers to sign up and get started;

2. The Wallet as a Service (WaaS) which will be a cutting edge implementation of account abstraction, allowing users to create an account on DIMO (within DIMO Mobile or other apps) and easily share data across the DIMO ecosystem;

3. Vehicle decoding progress: we’re finally starting to deploy more vehicle codes that provide users more data about their vehicles and enrich the value of the DIMO Developer Platform.

All of these are major developments. Within the next few weeks we’ll have the Developer Console live making it easy for developers to create their Developer license and start building. As they consume data, these developers will need DIMO Credits, creating protocol burn, as hypothesized in this draft proposal. Protocol revenue is good.

The DIMO Wallet as a Service is also unique and important. We’re using building blocks Turnkey and Zerodev to create an embedded wallet that will service the entire DIMO Ecosystem. Let’s say you’re signing up for DIMO Mobile: you’ll be able to create an account with an email address and you’ll still be able to do any onchain actions required, but the web3 will be in the background. If another app — let’s say a used car marketplace — wants to allow DIMO users to connect and share car data, they can embed a “Login with DIMO” button that makes use of the same wallet, providing a seamless experience for users. It’s web3 without the wires, a consumer experience that anyone can grasp.

These pieces above become even more useful when there is more vehicle data. In the last months, we’ve had a few community decoders come forward. One decoder has provided more than a dozen pull requests with new data for a range of vehicles on DIMO. We’re working with another decoder with massive quantities of vehicle codes to get their codes in queue for testing and deployment. Last but not least, we’re finalizing the deployment of UDS queries, another type of vehicle data protocol. Within the week we’ll publish a public spreadsheet of the data queue so that any user can find out what data they are able to collect for their vehicle.

The foundation is improving constantly. Soon enough, the magic will be live and in users’s hands.

• The DIMO Developer Platform launched and is growing, meaning more useful apps are coming to drivers.

• Alongside that, tokenomics updates are coming that will formally introduce a mechanism for driving protocol revenue and network value from developer activity. Drafts to be shared this week.

• DIMO Town Halls will be instituted to share more consistent updates, as well public roadmaps for all DIMO products and initiatives.

Coming Soon to DIMO

Over roughly the last 6 months since DIMO launched and shipped +8,000 DIMO Macarons, we’ve been busy building some foundational pieces for growth and value. We haven’t spent enough time talking about what’s being built, why it all matters, and how our users and community will benefit. Time to do something about that.

I’ll start with the DIMO Developer Platform. A few months ago we released what is really the first version of the platform, including the DIMO Developer License (11 developers are already licensed), which enables other applications to start building on DIMO. We’re working with companies that do insurance, maintenance, fleet products, AI, and more who will use these developer tools and infrastructure.

Why does this matter? Two reasons. First, that means more products will be available to drivers using DIMO today, increasing the utility of the apps and services we have created. A network where any automotive need is accessible to any driver from an app is immensely valuable, and not something automakers can compete with today. We believe this utility is the key to bringing DIMO to tens of millions of people.

Second, there are Tokenomics proposals coming within a week that will finally set the rules for protocol revenue by laying out how developers pay to the protocol when they access vehicle data. We’ll be borrowing from the Helium data credit model.

Here’s a summary of what that governance will look like in a nutshell: let’s say you want to share your data with a company that will remotely diagnose an issue or sell you dynamic insurance — that company will pay in dollars for data credits, and the dollars are used to burn an amount of $DIMO. There will be a public draft available for comment by the community by the end of this week, so keep your eyes peeled for the numbers.

When will this all be in place? Several smart contracts already are! The DIMO Developer License and the DIMO Data Credits are ready. The DIMO Developer Console is launching at the end of June. These pieces need to be stitched together, but this all means that later this summer, protocol revenue will formally start accruing. We have dozens of companies that are lined up to start working with the APIs, and our BD team is bringing those teams on so that utility of the network and network revenue increase constantly.

As a commitment to our community, we’ll publicize formal roadmaps for all products, including the token (the token is a product after all) and we’ll start a monthly DIMO Town Hall to discuss these updates. Announcements coming this week on the schedule.