On DIMO Tokenomics

These thoughts are my own and do not reflect the official position of the DIMO Foundation.

Bitcoin is incredible as a secure store of value because its tokenomics (the rules by which BTC is issued and consumed) are rigid and predictable in their design. We love Bitcoin, but $DIMO is not meant to be an inflation proof digital gold. Rather it's a utility token that powers a dynamic protocol that is constantly evolving. In this piece we’ll cover how $DIMO tokens are used now, and how they could be used in the future to maximize the utility for DIMO users.

Principles

Before considering how DIMO’s token design should evolve, it’s important to first establish guiding principles. Good tokenomics for DIMO must:

1) Incentivize and reward positive contributions to the network. For DIMO this means users who generate valuable data and spend in the marketplace, hardware OEMs that make it easier to connect, and developers that build apps and integrations.

2) Not deter other participants like automakers and app developers. Despite the dynamic nature of DIMO and its tokenomics, there should be zero doubt in the minds of Ford, Geico, Uber, or the DMV that DIMO will always remain a neutral, open, and reasonably priced platform to build on. They need to have full trust that they can build their business on DIMO without any possibility that the rug will be pulled out from underneath them.

3) Be sustainable. Token burn shouldn’t result in a future where there are no tokens left.

4) Be reasonably predictable. The token supply shouldn’t rapidly inflate and the prices to utilize DIMO shouldn’t wildly fluctuate.

5) Be implementable. We live in the real world and tokenomics must be technologically feasible, commercially enforceable, and comply with regulations.

6) Vest authority with a decentralized and aligned community of stakeholders.

7) Be simple and understandable.

Tokenomic Mechanisms

There are several solid tokenomic mechanisms that comply with the principles and they can be deployed in any combination with one another, so long as each principle is covered. Some of these mechanisms have already been implemented and some could be introduced in the future. 

While the blockchain industry hasn’t typically embraced ambiguity in future protocol design, it’s time to get past this. The sophisticated use cases and governance frameworks of protocols like DIMO allow us to safely iterate on token design over time. You wouldn’t expect or want Google to lock in their budget for the next 100 years and it’s time to stop expecting the same from networks that exist in a dynamic environment.

The table below gives a high-level of relevant mechanisms, with more detail on each following.

Note: All mechanisms except the last one are live in DIMO tokenomics today, but all can be improved on as discussed below. I expect the community to play an active role in expanding on these mechanisms over time.

Baseline Rewards

Booting up a two-sided market is a big challenge. It’s hard to build up demand if there isn’t any supply, and it’s hard to build up a supply if there isn’t any demand. For DIMO to be a success, it needs to build up the supply of drivers and connected vehicles on one side and the demand for that vehicle data and connectivity on the other.

Helium showed how decentralized physical infrastructure networks (DePIN) can build up a robust supply side of a network with token rewards while the demand side catches up. DIMO’s Baseline Rewards are designed to accomplish the same thing for DIMO. Each week 1,105,000 $DIMO are issued to drivers simply for remaining connected. Vehicles that have maintained a connection for longer, and that send richer data, earn more than others.

Baseline Rewards could be a promotional mechanism for bootstrapping where these rewards shrink to zero over time as demand picks up. In this future, users would earn $DIMO through another mechanism, such as the ones listed below, and would also join to get value from apps.

Or protocol revenue could be recycled back into the Baseline Rewards Pool to top it back up and keep it going indefinitely. 

$DIMO tokenholders will make the decision on whether to continue Baseline Rewards or let it wind down depending on how use cases emerge and the network evolves.

• Status: Live today
• Similar to: Helium
• More info: DIP-2
• Principles conflicts: Isn’t sustainable forever without topping up
• Future: Either let it fade out or top up the pool to keep it going

Promotions & Airdrops

One of the oldest and most frequently used tools that projects employ is the airdrop. An airdrop most often refers to the mass distribution of tokens to reward users who participated in the network in the past. These show that the project values its early contributors and also helps to decentralize the network governance among loyal users.

DIMO has already deployed one airdrop of up to 67.5 million tokens to users who connected their car, purchased a DIMO miner, and/or referred other users. More details on how that was done can be found here.

The idea of conducting multiple airdrops is growing in popularity and DIMO could continue to design and deploy new airdrops or special promotions to launch new regions (e.g., Mexico, Australia, Dubai, Korea), new products in the marketplace (e.g., a smart insurance app powered by DIMO), and new device categories (e.g., motorcycles). While most airdrops have been retroactive, it’s possible to design a compliant airdrop that lays out rewards for a specific action a user could take in the future.

Grants, bounties, and other types of similar promotions have long been effective ways of rewarding developers and other ecosystem partners.

• Status: One airdrop conducted
• Similar to: Most crypto projects
• More info: Airdrop Announcement
• Principles conflicts: None
• Future: The community can consider a grants program, as well as additional airdrops

Flat Protocol Fees

DIMO can capture value from usage via flat network fees for various on-chain actions, such as adding a car and transferring a miner.

Flat fees have the benefit of being easy to enforce and the drawback of being unrelated to the value created in those transactions. For example, should transferring a car on-chain cost the same for a new Ferrari and a fifteen year old Ford Taurus? At least DIMO would be in good company among blockchain projects with such fees. It costs the same to send 10,000,000 ETH as it does to send one, which is both a feature (fairness) and a bug (regressive).

Today, the network charges a 25 $DIMO fee per hardware miner. Up to 70% can go back to the device manufacturer if the device stays connected over two years. This generates revenue for the network that can be used for funding development or rewarding drivers. It also incentivizes the manufacturer to build quality devices that users will like.

Natural examples of on-chain transactions where fees could be added in the future include: vehicle creation; vehicle transfer; sharing a vehicle; minting a trip; transmitting data; and/or emitting a credential (although this may not always be on-chain). Already, the DIMO Mobile app trains users to expect other fees in the future by warning them their 10 $DIMO minting fee has been waived.

Such fees alone could generate sufficient demand to drive the DIMO Network. Each year hundreds of millions of cars are built and resold and trillions of trips are taken. Even the smallest fees could generate billions in revenue at scale.

• Status: Live today
• Similar to: Bitcoin, Ethereum
• More info: DIP-4
• Principles conflicts: Can disincentivize positive contributions (e.g., charging to mint a trip) but amounts should be small, if implemented, and should be worth the benefits received
• Near-Future: Add additional fees and equate to a fiat value rather than a quantity of $DIMO (e.g., $5 USD worth of $DIMO)

Lock-up for Licenses

Parties that require the trust of DIMO participants should have skin in the game and a long-term incentive to do the right thing. One way to accomplish this is by requiring that they bond (lock-up) $DIMO tokens in order to maintain a license and deploy products to the network.

A bond in this context is comparable to a security deposit, like one you might put down when you move into a new apartment. If the licensee misbehaves, they may have some or all of their bonded tokens taken away. While this is not a staking program that generates yield for the licensee, it does force them to be long-term holders of the token.

It’s important to use this requirement sparingly for select trusted parties since it creates a barrier to entry. It’s wise to have a major device manufacturer jump through these hoops, but foolish to have a small app developer put up significant time and resources just to start experimenting on their exciting consumer app.

Today, licensing is a requirement enforced on-chain for hardware manufacturers. It’s actually impossible to connect a DIMO Miner without an on-chain license and a payment of the flat protocol fee. Licensing requirements have already been passed for node operators and clients, but these haven’t been implemented as an on-chain license just yet.

• Status: Live today
• Similar to: ETH, MATIC (and all other proof of stake chains), GRT, LPT 
• More info: DIP-4, DIP-5
• Principles conflicts: None
• Near-Future: Add additional licenses and implement a mechanism to rebalance the bonded amount based on $DIMO market price (e.g., if price doubles, the bonding requirement is reduced and some bonded tokens are returned to prior licensees)

Vehicle Data as a Service

Vehicle data and connectivity is valuable, and apps and data consumers will pay to get it. These connections can either be monetized with a universally defined fee structure or a revenue sharing agreement.

Fee structure

For example, a fee structure might be arranged such that it’s free for certain volumes and types of data, then $0.25 USD worth of $DIMO per car per month to stream its location, another $0.25 to stream its telemetry data, and another $0.50 per month to send commands (such as lock and unlock) to the car.

Both Helium and Hivemapper use such a format for assigning a fixed price to a unit of data. And similar to both, DIMO could introduce a data credit for each data type that simplifies the process of spending a volatile $DIMO token.

Revenue share

Currently DIMO employs a revenue share arrangement whereby Digital Infrastructure Inc., the first licensed node operator, helps to store and sell aggregate and anonymized user data for the best rates it can get, passing along 90% of the revenue to users in $DIMO. By not assigning fixed prices to data, the network preserves optionality and enables price discovery and competition across node operators. In a future with multiple node operators, users will be able to opt-in with those that do the best job of monetizing their data, effectively turning node operators into data coops.

Fees generated from data as a service could power the network on their own. McKinsey estimates that the data from advanced connected vehicles will soon reach $600/year before you even deeply consider the more advanced applications that can be built with that data. 

Today, 1% of these fees are burned, 9.9% goes to the node operator, and 89.1% goes to the user. In the future, these fees could be reallocated and flow back into the treasury, get burned, go directly to the users selling their data, and/or top up rewards pools.

• Status: Live today
• Similar to: Helium, Hivemapper 
• More info: DIP-3, DIP-5
• Principles conflicts: None
• Future: Add additional node operators to increase competition and/or migrate to a universal fee structure once more is known about the nature of data demand

Rebates & Direct User Incentives

DIMO makes it easy for apps to offer sign-on bonuses to users. Let’s say a bank wants to give a user a bonus for refinancing their car. This is live today, and such payments go to the user in $DIMO.

Any app is also free to offer ongoing incentives to users in $DIMO as well. Eventually this type of rebate could become explicitly part of variable token fees as described later.

• Status: Live today
• Similar to: Airline miles earned by signing up for and using credit cards
• More info: DIP-3
• Principles conflicts: None

Variable Transaction Fees

The most fair and highest opportunity tokenomic mechanism is also the hardest to implement, at least today.

Wherever possible, marketplaces and payments infrastructure opt to take a bulk of their revenue as a percentage of transaction volume rather than as a flat fee. Credit cards take 2-4% of each swipe and Apple takes 30% of all payments made in iPhone apps. Uber, Turo, AirBnB, and eBay all take most of their fees as a percentage.

Why is this better?

First, it means it makes it possible for businesses to offer new or cheap services to users. An iPhone app that doesn’t charge users doesn’t pay anything. Similarly, a free app that helps owners compare their lap times and car stats from the track shouldn’t have to pay much. 

Second, businesses only have to pay when they themselves have money flowing in to cover fees. If you sell sneakers on eBay and your volume and prices fall, you pay less. An app that helps users sell expensive cars has enough cash changing hands to afford greater fees.

And, together, this creates the biggest opportunity for the platform. DIMO has the opportunity to build the new rails to power the $10,000,000,000,000 automotive industry and adjacent services. Capturing even a few percentage points of market share and taking even half a percent in fees would mean billions in revenue for DIMO. It turns out a lot of money is spent on cars.

What might this look like using examples and a 0.5% fee?

Someone selling their car in a DIMO powered online car marketplace for $10,000.

$10,000 * 0.5% = $50 USD converted to $DIMO and captured by the protocol

Someone makes their $75 monthly insurance payment to a DIMO powered smart insurance app that allows you to pay per mile.

$75 * 0.5% = $0.375 USD converted to $DIMO and captured by the protocol

These fees could be burned, flow back into the treasury, be returned to the user as a partial rebate (like an airline point), and/or top up rewards.

The biggest challenge with this mechanism is in scalably enforcing that fee. If you share your car data with Geico for cheaper insurance, whereby you eventually login on Geico and put in your credit card, how can the DIMO protocol know how much you’re paying?

This responsibility could be pushed to the node operators that serve data to these businesses. As a condition of their license, they could be required to maintain a terms of service that requires a fee collection for vehicles they report data on. Fees could then be burned, shared with users, or stored in the treasury. This is effectively how Braintrust works.

Even this is challenging though. What happens if a broker uses DIMO data to connect a driver to an insurance company? Is the fee only on the broker's commission? How can DIMO get a cut of that monthly payment if the insurance company isn’t directly using DIMO data?

The more likely option involves moving more payments infrastructure onto blockchain rails, and this should happen over time. This seems likely, especially when you consider how slow and expensive existing payments infrastructure is.

This may seem far-fetched now, but consider that if the iPhone were pitched to you in 1995, you wouldn’t be able to imagine how Apple would make billions on its 30% app store fees. There were no cell data networks, it wasn’t safe to put a credit card online due to lack of encryption, and “apps” at that time were physically bought in office depot on floppy disks or CD-ROMs.

We bet that, in 2035, cars will have wallets, payment rails will be updated, and it will become increasingly feasible to route payments appropriately, safely, and easily with blockchain infrastructure. At this time, implementing such a percentage based fee should become easy.

• Status: Hypothetical
• Similar to: Braintrust (and Visa, Apple)
• Principles conflicts: Difficult to implement today
• Future: Consider introducing at a time when DIMO and blockchain adoption make implementation feasible

Balanced Flows

It’s important that sound tokenomics do more than just extract fees wherever possible and reward contributors. They must also be sustainable (can’t burn away completely or flow uncontrollably in one direction and get out of balance) and they must ensure that the privilege to govern DIMO remains in the hands of aligned stakeholders.

Some of the mechanisms listed above create inflows of resources (e.g., fees) and some create outflows (e.g., Baseline Rewards). It’s important that any implementation consider the available resources and all potential inflow and outflow scenarios to ensure that the appropriate amount of tokens remain available and in circulation to create the right incentives and keep the network usable.

Currently, there is no automated rebalancing mechanism in place. Inflows are limited as demand starts to build up and a massive reserve of tokens is allocated to cover the outflows. Token holders will be able to vote on specific interventions (e.g., adjust the Baseline Rewards formula, reallocate tokens, etc.) or implement new mechanisms to automatically keep flows in balance.

One popular mechanism to accomplish this is Helium’s Burn Mint Equilibrium. Explaining how this works could be another equally long post, but the important takeaway for our purposes is that there are ways to programmatically tie inflows to outflows and to place guardrails around them to prevent wild fluctuations in distributions.

Balanced Authority

It’s also important to consider the implications on power dynamics for designing the balance of token distributions. As explained here, the $DIMO token gives the holder rights to vote on how the protocol works. Ideally, drivers, automakers, app developers, and other stakeholders will remain in the appropriate balance when it comes to governance authority.

Currently, $DIMO tokenomics ensure nearly all authority rests with drivers and, to a lesser extent, hardware manufacturers. This will have to be addressed in the future by either finding ways to get $DIMO into the hands of automakers and app developers (where they earn it or they need to buy it) or by altering the governance structure to ensure they have a voice. There have been discussions in the past that perhaps the automakers should get a cut of the rewards for connected vehicles since they build the components that generate the data and can be instrumental in onboarding users and expanding data availability if they cooperate. This is something that should be considered more in the future.

The Optimism Collective took a page from the US Constitution and established a bicameral legislature. One house governed by tokens and another governed by key stakeholders. For various governance votes, both houses have to agree.

In the context of $DIMO, a similar structure could mean that the $DIMO token holders, primarily made up of drivers, might have to also get the support of a coalition of automakers before changing certain key pillars of the DIMO protocol.

Payment Denomination & Data Credits

The choice of how to denominate fees can be flexible, but there are tradeoffs. Due to the historical lack of liquidity and exchange availability, DIMO currently prices all tokenomic amounts in $DIMO. While simple, this has the drawback of subjecting participants to volatile fluctuations in the fiat cost of transacting on $DIMO. The 25 $DIMO per device fee could be dramatically cheaper or more expensive (priced in USD) depending on the week.

As DIMO becomes more available, it makes sense to alter the token design to price such fees and deposits in USD equivalent amounts. E.g., a rule specifying that creating a device costs $5 USD worth of $DIMO.

One way to do this would be by altering the nominal $DIMO fee for each transaction based on the current market price. Helium does this with their implicit burn mechanism. This is convenient, but it’s more challenging to build pricing oracles into every service, harder for users to calculate tax implications, and less predictable for users.

The data credit is another popular tool that other projects have introduced to achieve a similar effect. As mentioned earlier, Helium popularized the data credit in the blockchain world, but such credits have a long history in the traditional setting as well (e.g., AWS credits).

These work by allowing users to convert large chunks of token before they’re needed, leaving them with credits ready to be spent. This way, users can avoid holding a volatile $DIMO token as well, which is good (simple and safe for them) or bad (they have no skin in the game) depending on how you look at it.

Shortly, amendments will be introduced to redenominate the pricing of fees and bonding requirements in DIP-3, DIP-4, and DIP-5 to USD equivalent with an implicit burn style implementation to start. All payments will still be in $DIMO, this would only affect the amounts charged. After, a community discussion will be had on the benefits and engineering effort to implement a data credit model.

Driving Ahead

DIMO can take over the world’s mobility infrastructure and be a massive success as currently designed, or with some of the changes suggested above, or with other changes not mentioned in this document, so long as the principles are adhered to.

Proposals that seem to make sense to see sooner than later include: dynamic repricing of fees and bonding amounts paid in $DIMO to move up or down with market price and the addition of new flat fees, charged in $DIMO, for minting, sharing, and transferring a vehicle. 

Do you agree? DIMO truly is a community owned project and anyone is free to join the Discord and join the conversation in the # 🧠token-design channel. 

The foundation has been laid and it’s time to build.