Yevgeny Khessin

The through-line

Yevgeny Khessin's argument starts from a single conviction about ownership: "when you buy a car that data should really be yours that's our true belief right it's the second most expensive thing people buy after their house in their life" [1]. Everything else follows from that. A decade spent building automotive IoT APIs with Ford, GM, Chrysler and most of the brands people know taught him a lesson he now repeats as the founding premise of DIMO: "the data being owned by the car company does not create a developer ecosystem" [1]. The same career arc runs through his account of moving from dumb cars to smart cars, through OnStar and connected vehicles, and through consulting on autonomous cars for clients including Ford, VW and Mitsubishi, arriving at a preference for flatter, peer-connected architectures over the vertically integrated systems the industry built first [3].

The second half of the conviction is about who fills the vacuum if the industry does nothing. There are 140 car brands in the world, they used to cooperate on physical standards for cars, and "they haven't done this in any digital format in the last 30 or 40 years" [1]. His fear is concrete: on the current path "Google's going to end up being the company that provides a stop white API and the connectivity API to the parking garage and all these things and that's not a world they want to live in" [1]. DIMO is his attempt to build that missing digital infrastructure as an open protocol before a centralized one hardens into place, and he frames it deliberately broadly, starting with the vehicle but designed as digital infrastructure for moving objects generally [3].

On why OEM-owned data kills the developer ecosystem

The critique is not that automakers collect data but that they hoard it and then fail at the basics of controlling it. "All of the existing solutions that we have today do not focus on privacy and most of the OEM Solutions don't even have basic roles and rights to say you can see this not that" [1]. Meanwhile the data is already in circulation: "any car made in the last 10 years your data is already being sold now" [1]. He has also engaged with the wider surveillance picture, where vehicles carry cameras pointed inside and outside the cabin and pass information about occupants to third parties as they drive [2].

His answer is granular consent rather than blanket refusal. Some owners will want no sales at all, "I think that's a use case that should be served if you only asset you should be able to completely say only mine" [1], but he expects most people to trade: "we're mostly capitalists um most people would agree to data sales as long as they're able to say I will sell this and not that and they have something to earn some value to get out of it" [1]. The first implementation of that is permissioning at the field level, so an owner can share "just my odometer just just my VIN" and nothing more, depending on the application [1]. He credits the prompt partly to Vitalik, who "tweeted about that you know can we get some fancy ZK or maybe just at least data permissioning please" [1], and the next step is exactly that: "I personally speed a lot so I would like some ZK please" [1], meaning proofs that reveal a mileage range and a rough region without exposing the underlying trace.

On proving vehicle data is real

Opening a protocol to anyone creates two problems a car company never has to face. "When you're building an open protocol for vehicles people can create fake ones" [1], and "whenever you create an incentive you have people who definitely want to gain the system" [1]. His validation stack answers both in layers. Hardware comes first, and he is candid about its limits: "it's not something that can be made completely trustless as much as I would like to uh Hardware needs support" [1], so manufacturers are approved, expected to use high quality chips and to support devices long term. An approved manufacturer deploys its own contract, and each device is minted at end-of-line test with its serial number and address captured, which makes signature checking against the device's secure element the first validation any data receives [1].

The second layer proves the data came from a real car rather than a script. Every vehicle built in the last 30 years uses the CAN bus, which he describes as "most similar to ethernet if everything was only UDP broadcasts", two wires, eleven bits, three of header and eight of data [1]. A modern car carries 100 to 200 modules constantly reacting to each other: press the accelerator, engine RPM rises, the transmission sees it and shifts [1]. DIMO's devices, the macron launched two months earlier with about 8,000 units sold and the autopi at roughly 10,000 to 12,000, interrogate as many modules as they can "to try and generate a proof of what this vehicle is", capturing serial numbers, firmware versions and the VIN, signing it in the secure element and turning it into a verifiable credential that feeds both rewards validation and any developer's own checks [1].

The third layer answers the obvious follow-up: "what if uh it's plugged into a wall" [1]. Without enough density for vehicle-to-vehicle checks today, he borrows other people's infrastructure. The autopi's cell connection reveals which tower a packet passed through, which can be cross-checked against the device's reported location, and a genuinely driven car will touch several towers in a week [1]. The macron rides the helium Network, which reports the path a packet took and which hotspots it hit, so "we're building trust based on another deepend project that's providing Lura coverage", with a minimum number of hotspots required to count as a valid vehicle [1]. The endgame is to drop the intermediaries entirely: as the fleet grows, cars validate each other, starting somewhere dense like New York [1]. Combined with charging networks and other verifiable infrastructure, this produces a digital history that is "very hard to fake because you would have to fake helium you would have to fake theot charging Network and 50 other cars" [1].

On what should get built on top

The use cases he names are the ones that fail today for want of shared data. Charging infrastructure companies keep coming to DIMO because "they don't know where to put it the city does doesn't know that and the company making the car doesn't give it to them", so finding a charger and finding a compatible charger are core applications of the network [1]. Payments are the second, and here he is openly resisting a default: every car coming out in 2030 is set to carry an in-car payment machine, and "Visa will be the norm which is another world I don't want to live in", against which he sets machine-to-machine payments on a blockchain with lower fees [1].

The third category is public goods, where the same collection that "can be misused" becomes civic infrastructure [1]. A car driving around knows the weather, which matters in places with no weather stations, and the pothole example is his sharpest: "the average city United States spends $60 to $70,000 to hire a contractor to drive around and tell them where the potholes are when we're all here driving around we probably drove here right this data could be made available for cities" [1].

On interoperability and the autonomous future

His long-range case comes from launching Ford's self-driving fleet in Miami and Austin, and from a fleet product covering parking and requesting and unlocking a car that worked well until the team moved it to a different city, where every city and every parking lot presented a different API [3]. That experience underpins his skepticism about bilateral integration. Once robots on wheels from different brands have to talk to each other, the instinct is that Ford integrates to every other car company and then every other company does the same, and "while Accenture might be very happy with that in reality that's just not functional" [1]. He is explicit about the conclusion: "there needs to be a common standard for this Mobility Smart City future with optimized transportation to work it can't just be left up to uh a centralized API" [1]. Open source products and specifications carry weight in this argument for him as a way to improve security and level the playing field [3], as does his own sense of the difference between centralized and decentralized systems, which he ties back to being born in Ukraine [3]. He also keeps the question of where the human sits in an autonomous world in view [3], and thinks of the connected devices in the network "as future robots using AI right to help us be more efficient as Humanity" [1].

Takeaways

• The founding premise of DIMO is that OEM ownership is what blocks innovation: "the data being owned by the car company does not create a developer ecosystem" [1].
• Privacy should be granular, not binary. Owners should be able to share "just my odometer just just my VIN" and eventually prove things with zero-knowledge techniques rather than disclosing raw driving data [1].
• Data validation is layered: device minting at end of line with captured serial and address, signature checks via secure element, CAN bus interrogation of 100 to 200 modules to build a verifiable credential, and movement proofs from cell towers or helium hotspot paths [1].
• Cross-vehicle validation is the intended endgame, making fraud require faking helium, a charging network and 50 other cars at once [1].
• Concrete near-term applications are charging siting and compatible-charger discovery, machine-to-machine payments as an alternative to a Visa default in 2030 vehicles, and public goods like pothole and weather reporting that cities currently pay $60,000 to $70,000 to contract out [1].
• Bilateral OEM-to-OEM integration will not scale for autonomous fleets; a common standard is required and "it can't just be left up to uh a centralized API" [1].
• Fragmentation is lived experience, not theory: a Ford connected fleet product for parking and unlocking worked in Miami and broke on moving to another city because every city and parking lot had different APIs [3].