Crypto Ride

Team
Project Description
CryptoRide-MiniPay
- MiniPay Quick Start
Current Improvements
Future Updates
Challenges
Celo Network
Quick Start
Contract Overview
- Escrow
- Ride cancellation
iOS Overview
Licence

Team Members

Mitchell Tucker, iOS/Smart Contract Developer

Project Description

Introducing Crypto Ride, a new way to spend and earn cryptocurrency while reducing traffic and pollution. Crypto Ride upgrades the traditional ride-share architecture into the world of web3. Rides will be managed and controlled by smart contracts hosted on the Celo network. Tapping into a multi-billion dollar industry run by Uber and Lift. These companies control 99% of all ride-sharing services (USA) taking a 30% fee or more from drivers. Crypto Ride's decentralized architecture powered by the Celo Network would reduce fees and revolutionize the ride-share industry.

CryptoRide-MiniPay

MiniPay Video Walk Through

Google Maps API
ReactJs Dapp
Direct cUSD payments
Cross-platform

The incorporation of CryptoRide into MiniPay within the Opera browser streamlines passengers' ability to promptly request and schedule rides using cryptocurrency, removing the need to download extra software and ensuring compatibility across various platforms. Packaged within a straightforward web-based dapp written in React.js, it enables users to seamlessly request a ride and fulfill their role.

By maintaining the architecture similar to the iOS passenger app, it ensures simplicity and user-friendliness. The user interface is evenly divided between the primary Google Map View and a bottom view that details the ride state, allowing users to efficiently complete the ride process.

Upgrades

Enabling both the driver and passenger to log in with their Google accounts could help mitigate safety risks and enhance secure data entry within Google Firebase.
Simpler ride architeciure, allowing for less user interaction.

Drawbacks

Passenger and driver safety are compromised when passengers have the ability to request rides anonymously.
The constraints of web DApps in contrast to native mobile apps are apparent, especially concerning real-time location tracking and event handling. Web-based services often exhibit higher susceptibility to crashes, leading to frustration among users.

MiniPay Quick Start

Requirements

Git
npm 9.5.0
Android Phone
- Opera Mini Beta

Open a terminal and git clone the project repo

git clone https://github.com/MitchTODO/Crypto-Ride.git

cd into the miniPay section of the project
```
cd Crypto-Ride/MiniPayDapp
```
Install npm packages
```
npm install
```
Start Dapp

Note: This might open a browser window
```
npm start 
```

Current Improvements

MiniPay Passenger Intergration
- Allows passengers to efficiently book a ride directly via the Opera browser, leveraging the integrated MiniPay wallet for seamless transactions.

Future Updates

Superfluid Protocol
- Bring stability and automation to driver payments. Also allows for flexibility with Cancellation fees.
Carbon Credits 🌿
- Toucan Protocol brings carbon offsetting on ride emissions.
- Passenger rewards and tracking of carbon credits (Toucan Protocol)
Celo Social Connect 📲
- Ability of linking phone numbers to wallet address allowing the transfer of funds using phone numbers.
Masa Soul Names 🔖
- Soul names link human friendly names to wallet addresses.
Onboarding of Valora Wallet
- Abililty to onboard using that use Valora Wallet paying for tx fees and payouts.

General Updates

Location based ride share contracts.
Driver tipping & reviewing.

Challenges

Geo based matching of passengers to local drivers.

When a driver is actively looking for rides there location will be broad cast and updated to Google Firebase. As using a smart contract for location services would be too costly. From the passenger app we use the drivers locations to identify who is in the same proximity to the passenger location. Passenger will get a list of local drivers and there details, including rates,identities and work radius. Passenger can select what driver and fare they want priorities.

Calculating the fare estimates & keeping far market value.

The driver would be responsible for setting there rates, the rate would be used to create a fare estimate. Passenger can change the fare estimate to what they think is reasonable. This is simular to how mining fees are processed. If you set your fare estimate too low no driver is willing to accept the ride. While setting your fare estimate too high you will get a driver faster, but at a risk of over paying. This would create competition between drivers and passengers keeping far market value.

Driver receiving & accepting a ride.

Newly created rides would be emitted on the network along with payment of the ride. Drivers will listen for relevant events, if the driver doesn't accept or is slow to accept the ride. The ride will be offered to the next best driver. If no driver accepts the ride, the ride will be canceled with the payment returning back to the ride creator.

Spliting the cost between passengers.

When a passenger builds a ride they will be able to opt-in for ride sharing. If an existing ride that has has ride sharing enabled is within the same proximity and approximate destination the second passenger can submit a pickup. This will notify the driver with the updated ride. The ride cost will be split between when the second passenger is picked up and dropped off. The fare estimate would be locked in at what the first passenger agreed to.

Preventing bad actors in both roles (Driver & Passenger).

Use star rating and reputation system for both passenger and driver. Both roles will gain reputaion for completed rides and lose reputaion for canceling rides when it goes against policy. If a ride is canceled the user with the most reputation will be favored for how the cancellation fee would be executed.

Safe for everyone to use.

Adding identities could mitigate the risk assocated with ride sharing. Utilizing different social media plateforms a passenger could quickly profile a driver.

Why on the Celo network?

The Celo Network is optimized for mobile clients making Celo the perfect network for mobile driven dapps like Crypto Ride. Crypto Ride could in future support light clients to help internalize request for account and transaction data. Plumo Ultralight Sync.

What is needed?

Smart Contracts
- Ride share contract
  - Controls and manages the ride state.
  - Rating and reputation.
- Escrow contract
  - Used as the trusted third party between passenger and driver.
  This allows for more flexibility on how the funds are transferred based on the outcome of the requested ride ie cancellations.
- Token contracts
  - Used as payment for the ride service.
  - Celo's cUSD stable token.
Mobile Apps

Two separate apps for each role.
- Passenger
  - Can request a ride with when and where.
  - Get active driver location and fare estimates.
- Driver
  - Ability to accept & manage a ride
  - Stats on earnings
  - Geo location of work area
Google Firebase

Some aspects of the Crypta Ride would need to be centralized as they are too costly to be implmented in a smart contract.
- Driver location-tracking

Who would use this?

There would be two different user types. Users who want to earn and those who need a ride.

Drivers earn crypto for there ride services. They would have the ability to set there own rates. Giving them the power of what there time is worth.
Passengers spend crypto on a real world services without the need to transfer into native currency.

Summary

The most basic functionality of this project is just a smart contract with an app. Smart contract handles the ride states and payment, while the app allows the passenger and driver to facilitate there roles.

Critical Features

Geo base grouping of passengers to local drivers.
Location tracking for active drivers.
Handling of ride cancellations.
Passenger and Driver rating & reputation.
Driver identities.

Additional features could be added making the experience more familiar to existing ride sharing.

Driver rewards for good reputation
Direct messaging between passenger and driver
Tipping

Presentation

Ride Architecture

Simply the ride has four steps from start to finish, anywhere within the ride is cancellable by either party. The contract keeps track of the steps by using 6 different ride states. These states cannot be skipped and only called from the correct party. Here are some important topics for each state.

None
- Default state for all new address.
Passenger Announced Ride
- Passenger requests a ride and is waiting for a driver to accept.
- When the request is made, passenger sends price of ride which gets held by the escrow contract.
Driver Accepts Ride
- Driver has accept the ride and is waiting for passenger to confirm picked up.
- When the driver accepts the ride, passenger is notified the ride was accepted.
Passenger Confirms Pick Up
- Passenger confirms pick up and is waiting to be dropped off by driver.
Driver Confirms Drop Off
- Driver confirms dropping passenger off.
- Driver gets paid out from the escrow contract.
- Passenger will be request to rate the driver.
- Driver and passenger reputation will be increased.
- Ride complete.
Canceled
- Ride has been canceled.
- Reputation might be decreased for the party responsible for cancelling.

Quick Start

Requirements

Git
Contract (Optional)
- Truffle v5.5.29 (core: 5.5.29)
- Ganache v7.4.0
- Solidity 0.8.9 (solc-js)
- Node v16.17.0
- Web3.js v1.7.4
iOS Dapps
- macOS
- Xcode Version 13.4.1
- Target iOS 15.5
- Cocoa Pods 1.11.3 or greater

Video Demo

The first part of the demo video also walk-throughs the quick start guide.

Contract Deployment

By default the iOS dapps use a pre-deployed ride manager contract on the Alfajores Testnet.

Predeployed RideManager Contract

Download and Install

Open your terminal and git clone the project repo.

 git clone -b Crypto-Ride https://github.com/MitchTODO/build-with-celo-hackathon.git

cd into the smart contract selection of the project and install npm libraries.
```
 cd build-with-celo-hackathon/Crypto-Ride/SmartContracts
```
Install npm libraries with the following command
```
 npm install 
```

Compiling

With the same terminal run truffle compile to build the smart contracts.
```
 truffle compile
```
This will create a build folder containing the important contract details.

Migrating | Deploying

Depending on what network you are deploying to, your settings will be different. This readme will walk through on deploying to Alfajores Testnet.

You will need a wallet funded with CELO and access to the private key.

Launch Metamask to generate a new wallet. This wallet will act as the contract owner.
Copy your address and navigate over to Alfajores Testnet faucet to fund your wallet.
Within Metamask go to wallet details and copy the private key. Paste your private key in the truffle config file on line 79.
With the terminal run the truffle migration command with the network options set to testnet.
```
 truffle migrate --network testnet
```

Keep your terminal open you will need the output from the migrate command

iOS Dapps

Download and Install

If you havn't already lunch the terminal & git clone the project repo.

 git clone -b Crypto-Ride https://github.com/MitchTODO/build-with-celo-hackathon.git

With the same terminal cd into driver app.

 cd Hackathon/build-with-celo-hackathon/Crypto-Ride/iOS/CryptoRide-Driver

Run the following command to install the Pod libraries.

Note: This process will need to be done for both dapps
```
 pod install 
```
If your running on M1 chip use
```
 arch -x86_64 pod install
```

Building and Launch Simulator

If you are using your own ride manager contract change the address in the dapps to your ride manager address created during migration.

Note: This process will need to be done for both dapps

Open Xcode and select Open a project or file then navigate and open driver's workspace file.

Crypto-Ride -> iOS -> CryptoRide-Driver -> CryptoRide-Driver.xcworkspace
Select a iOS Simulator and build the App.

Note: You might need to change your siging & Capabilities

Continue to the Dapp walk through.

Contract Overview

The ride manager contract inherits three other contracts ReputationManager, AdminControls and DriverRole. With numerous utility contracts within.

-ReputationManager: Enforces a reputation system for passengers and drivers, based on different out comes of a ride.

-AdminControls: Adjustable settings within the ride manager contract. Only callable by the contract owner.

-DriverRole: Registration contract for drivers.

Escrow

Escrow component is built into the ride share architecture of the ride manager contract. Before a passenger announces a ride, they must approve the ride price from the token contract that will be used as payment. This in turn grants the escrow to transfer funds on behive of the passenger. Funds are held until one of two events.

No drivers accept the ride. Forcing the passenger to cancel and resubmit, in which funds are returned.
Driver accepts and completes the ride, having the escrow payout the driver upon passenger drop off.

Ride cancellation

Ride cancellation is allowed by both partys from when the ride is announced and before passenger confirms drop off. Funds are divide based on ride state, preventing bad actors.

Return Amount

Ride State	Passenger	Driver
Announced	100%	0%
Driver Accept	80%	20%
Passenger Pickup	50%	50%
Driver DropOff	20%	80%

As the ride progresses the potental for bad acting favors the passenger. Allowing a passenger to cancel the ride at the drop of location with the result of lower price. To further prevent this, cancellations by either party will result in a rating decrease while decreseing reputation to the indivial who cancelled.

iOS Overview

App architecture is desgin around Apple's MapView, views presented around the map are switch depending on different states. Core features between apps are very simular but views are different. Passenger is required to build rides and selected different aspects of the ride. While driver is design to wait and react for rides announced on the network.

Drivers locations

Googles Firebase and Realtime databases are used to orchestrate discovery and location of drivers.

Note conventional databases are used for locations services as blockchain would be to costly.

Driver

When a driver is ready to listen for new rides, they will post an entry to Googles Firebase. Entry contains information related to the driver (name, car details, ethereum wallet and city). As well as a geohash used for queries by passengers.
Driver will then start updating there current location to Googles Realtime database. This update will only occure if the driver has moved far enough away from there previous location and three seconds have elapsed. There location is mapped to there ethereum address.

Upon logout/stop driver app will delete both Firebase and Realtime entries.

Passenger

Upon launch the passengers app will query Firebase with a geoHash of the passengers currently location. This query will return active local drivers.
Passenger app will then use the drivers ethereum address to observing changes to the Realtime database for the current location of driver. These changes driectly updates the mapView displaying the drivers location close to realtime. Drivers are repersented as cars on the passengers map view.

Note newly active drivers take around 10 seconds to be add to the passengers map

By observing deletions drivers are removed

Wallet

Both passenger and driver apps have hot wallets designs for low amount of funds. Having the idea that you only tranfer the funds you need to make a ride then return the remaining amount back to cold storage. Users private key is saved to there Apple keychain providing a recovery mechanism for users. As of now only the driver role requires registration requiring a name, vehicle description and social profiles linked to the wallet address.

Wallet currently features two tokens CELO and cUSD.

Celo: Used to pay for the transaction cost associated with writing to the contract.
cUSD: Used as payment for the ride.

This was needed as the web3swift library is restrictive when it comes to transaction options. Preventing cUSD from being used to pay transaction cost featured by the Celo Network. This will most definitely will be fix in a future update.

Handling Events

Listening to contract events is a integral part of the app. Events are received by subscribing to a web socket provider and filtered on relevance to the current user. Events can force changes to the ride state allow for the progression and completion of a ride.

When a passenger announces a ride, driver will received an event. The event is check and if relevant to the driver, driver then has a 30 second window to view and accept the ride. If time elapses the ride will be dismissed and prop the next driver to accept the ride.

Licence

Crypto Ride is licensed under the Apache License 2.0