DIN Logo

Decentralized Ride Sharing: A Demo

Written by Topper Bowers and originally published on Medium

In a previous post, I said I’d save the technical details of how Lyft might decentralize. This is that post.

I’m going to use the example of a fictional ride sharing company called Decentracar.

There is a watchable demo of this process here:

In the traditional setting, all requests go through Decentracar in order for the riders and the drivers to trust each other.

ride sharing requires trust

Decentracar is the FUTURE though and is instead going to introduce Tupelo and a peer-to-peer network.

tupelo and the peer to peer network

You can read more about Tupelo here. If you’re completely new to Tupelo then the key thing to understand is that Tupelo uses a new data structure called a ChainTree that is unique to every object, person, etc. These ChainTrees are owned by a private key and can contain arbitrary information. ChainTrees are referenced by a DID (a unique identifier)

Decentracar still has a critical role to play in this ecosystem. It is going to provide the trust that riders and drivers need in order to participate in a marketplace. Tupelo is going to take care of making that trust available.



Drivers register with Decentracar and go through a thorough background check. The company also makes sure that the vehicle is licensed to operate in the jurisdiction they are operating in.

Riders register with Decentacar to make sure reviews are attached to a real-world person.

Decentracar writes the list of registered drivers and registered riders to its own ChainTree. It only writes DIDs (not full personal information) to these registrations. Using the WASM-based SDK it might look something like this:


Getting a Ride

As a driver rides around looking for a ride, they constantly update their ChainTree with their current location. This allows riders to trust that a driver isn’t saying they are in two places at once. This becomes important for things like determining surge pricing and proximity to rider at offer time.

driver locations

That might look something like this:

tupelo ridesharing

When the rider wants to get a ride, they send 5 DTokens to Decentracar (which will be a cancelation fee if necessary). They write their current location to their ChainTree and publish the fact they would like a ride out to the P2P network.

chaintree logic

The available drivers will see the message from the rider and do a couple of things:

  • Look at the rider’s ChainTree to make sure it is approved by Decentracar
  • Make sure the rider followed the rules and sent 5 DTokens over to Decentracar
  • Make sure the rider hasn’t accepted another driver.

If all of that checks out the driver can set their ChainTree to show that they have offered a ride to that rider.

The rider will now have received a few offers from drivers in various locations. The rider checks:

  • Is this a valid Decentracar driver?
  • Does the driver only have my pending offer (no double offers)?

The rider will take the closest driver with those offers and write to their ChainTree that they have accepted the offer.

The driver writes to their ChainTree that they also accept the offer.

We now have a locked contract. The driver comes to pickup the rider.

When the rider gets in, they both adjust their ChainTrees to show that the rider is in the car and start writing location data to their ChainTrees. Tupelo offers privacy options here so they do not need to actually broadcast their locations to the network, but can show each other that they are doing the right thing.

At this point the rider will start paying the driver as they move (as well as send a fee over to Decentracar). If there’s ever some discrepancy they can stop payments (or driving) and register their complaints with Decentracar which can act as the final say in the dispute (another key service of Decentracar).

If, however, everything goes smoothly they both can write to their ChainTrees that the ride is over and the process can repeat.

You might have noticed that Decentracar provided trust, but the actual transactions didn’t have to flow through Decentracar’s servers.

The rest was all rider and driver talking directly (over the p2p network).

Only in the case of disputes did the actual Decentracar servers have to get involved. Yet, the trust they established at registration permeated the system and allowed the marketplace to take care of itself.

Watch the demo to see how all of this plays out on Tupelo.

Want to build one of your own? Go code up Decentracar yourself using our docs and sdk.