DIMO Rewards & Staking
Reframing the incentive engine behind a decentralized vehicle network
Role
Product Design Lead, User Research, System Definition
Platforms
IOS & Android
Timeline
Oct 2024 — Dec 2024
Category
Automotive, Crypto, Incentive systems
DIMO is an open connected-car network that rewards drivers with $DIMO tokens for contributing vehicle data. Rewards were not just a feature. They were the primary growth engine of the network. They incentivized drivers to connect vehicles, drove hardware adoption, reinforced consistent data contribution, and aligned users with the long-term value of the ecosystem.
By late 2024, rewards were the most used and most discussed part of the app. At a high level, people understood that rewards existed. But to truly understand how they worked, users often had to read documentation or watch YouTube videos. This was manageable until staking entered the roadmap.
Why rewards exist
DIMO distributed tokens to bootstrap supply in a two-sided data marketplace. The network depends on drivers connecting vehicles and sharing high-quality real-time data. Without early economic incentives, growth would stall.
That increased value reinforces incentives for drivers, restarting the loop. Rewards were not a perk. They were the engine of network growth. When we decided to introduce staking, which allowed users to lock tokens to boost weekly rewards, the system was about to become significantly more complex. Before layering additional mechanics, I stepped back to evaluate the foundation.
The problem
Externally, users were confused about why they earned different amounts week to week, why driving more did not increase rewards, why some vehicles earned more than others, what qualification actually meant, how streaks and hardware impacted payout.
Internally, even experienced team members struggled to clearly explain how rewards were calculated.
The mental model was broken. The protocol distributed a fixed weekly pool of $DIMO across all connected vehicles, proportionally based on point contribution. Points were derived from software connections, hardware connections, streak duration, and staking participation. This created a technically sound but cognitively heavy system. Users often needed documentation to understand what was happening. Staking would expose this fragility.
How do we introduce staking without confusing users
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
before
These were not isolated UI issues. They reflected a system that lacked a coherent abstraction layer.
Reframing the problem
I reframed the question entirely. The issue was not how to add staking. The issue was that the reward system lacked a coherent abstraction layer. If we introduced staking on top of an already fragile mental model, we would compound confusion and risk damaging trust in the incentive engine.
I partnered closely with the Customer Support team to review recurring reward-related tickets. The patterns were consistent and revealing. Combined with internal audits and user testing, structural issues became clear. Instead of shipping another feature, we needed to restructure how the system was understood.
Exploration
Before committing to a new abstraction, I explored multiple structural directions. First, I stepped back to analyze the full reward system end-to-end. I synthesized how software connections, hardware connections, streak duration, staking multipliers, and proportional allocation interact at the protocol layer into a simplified internal model. I then prototyped alternative wallet models.
One direction preserved the original point-based system and attempted to clarify it through better labeling and progressive disclosure. While this improved readability, it did not reduce cognitive load. Users still had to understand fluctuating point weights and proportional distribution.
These explorations confirmed that incremental UI improvements would not solve the underlying problem. The system required a unifying progression layer rather than clearer point math.
Success criteria
To ensure the intervention addressed both cognitive clarity and business impact, I defined success across comprehension, behavior, and system integrity:
Introducing a unified layer
Instead of redesigning staking in isolation, I proposed restructuring how rewards were conceptualized in the product. I introduced Universal Car Levels, a unified progression system that abstracted economic complexity into a single, understandable advancement model.
Rather than requiring users to understand fixed token pools, proportional allocation, multiple point sources, streak decay mechanics, and staking lock multipliers, we translated all reward inputs into one progression layer.
Software connections, hardware connections, streak duration, and staking participation all contributed to a single car level. The higher the level, the greater the share of weekly rewards. This preserved protocol logic while dramatically simplifying cognitive load.
New wallet screen
Alignment and tradeoffs
The concept was well received across product, engineering, and users. The main resistance was urgency. To deliver value faster, we prioritized engineering delivery of the staking entry flow and sequenced withdrawal infrastructure later in the roadmap. Importantly, the protocol itself required a minimum six-month lock period for staking. That meant no user could withdraw earlier than six months, regardless of UI readiness. Our sequencing allowed us to launch the engagement mechanics immediately while building withdrawal support in parallel.
I worked closely with the protocol team to align naming and documentation. On the protocol layer, stake level 1 was labeled as level 2, which created potential confusion between technical and user-facing terminology. This required cross-functional coordination between protocol, product, and engineering to ensure the abstraction remained truthful to the underlying system.
Shaping trust and monetization
Based on user testing insights, I replaced fluctuating APY with relative boost framing. Annualized percentages created volatility anxiety and false expectations. Instead of exposing unstable annual rates, I positioned streak upgrades and staking as percentage increases relative to a user’s current level, dynamically calculated per individual.
Qualification states became clear and easy to spot. Active, pending, disconnected, and partially qualified states were no longer buried in the background. By showing connection health directly on the highly visited rewards page, users could immediately see if something was wrong and what it meant for their earnings. We also made the differences between device types easier to understand, which naturally helped users see why upgrading could increase their rewards.
Staking was framed as leveling up rather than interacting with a financial instrument. To make the experience a complete joy to use, I concepted the level-specific animation system, sourced and hired a motion contractor, and directed the creative execution end to end. The animations and loaders made the experience feel more premium and kept users engaged while on-chain transactions were taking place.
Results
Although staking was initially intended for crypto-native users, the simplified progression model broadened participation. Reward-related support tickets decreased as qualification logic became clearer. Users better understood device differentiation, which supported more confident hardware upgrades. Visible progression strengthened long-term engagement and retention. Staking evolved from a niche feature into a natural extension of the car progression system.
Over 8,700+ users staked on DIMO
Over 14M $DIMO Staked
Credits
Product Lead — Henry Hirshland
Creative Director — Courtney Cann
UI Animator – Kolom
