A new form of car insurance for car rentals: By using your DIMO data, rental dates, and driver attestations from EAS, we’re generating an NFT that can be used in prediction markets – will the car crash during the rental period, or not?
Turo is a web2 car-sharing application whose business model involves being a short-term commercial auto insurance broker. They seem to be a monopoly in the niche so we doubt they’re capital efficient. We aim to disrupt Turo with decentralization.
Deconstructing insurance we find it’s basically just legalized gambling. We can do that peer-to-peer with a prediction market on pre-built protocols like Polymarket, Augur, or an entirely new prediction market specifically for PredictaDrive. That leaves 2 oracle problems: bundling trusted attestations about the car, driver, and trip to be sold as a binary prediction, and resolving the bet trustlessly at the end of the event.
For this project, we’re building a single, specific layer of a future decentralized car rental platform: insurance for hosts (aka the “renters”) cars. We start by using the NFTs that are issued to owners of DIMO-connected cars, allowing users to select which vehicle they want to rent out. A host inputs the start date and end date of the rental period, then fills in some information about the driver/renter of their vehicle (name, 0x address). Finally, a host can see a preview of their rental contract, and then use the corresponding metadata to mint a new, unique NFT. The idea here is that this NFT could then be used on those aforementioned prediction markets to serve as a new form of car insurance. The host would put down bait money to attract betters on a single principle: Will the car crash, or not? The host is basically betting that the car will crash, while other users will be attracted to bet against them.
There are additional considerations we’d like to take into account in the future, such as using the DIMO SDK to get even more data from a hosts car – for example, getting the current mileage on the car and packaging that within the NFT metadata, then checking the mileage on the end date/time to ensure that the car has been driven (to prevent bad actors from renting a car, not driving it, and betting against the crash prediction). Or, checking to ensure that the renter refilled the gas tank upon return of the vehicle (aka end date), and if not, charging them a market rate fee automatically to cover the cost of gas for the host. There are endless possibilities here to be explored using the robust data that DIMO provides.
Additionally, managing the prediction market is beyond our scope for this hackathon. Building a “car is damaged/undamaged” oracle out of the available DIMO infrastructure to resolve prediction events is a problem we propose DIMO should help to solve in the future. In the future, we’d also like to use EAS (Ethereum Attestation Service), with a secure schema that can be built to ZKP-in sensitive driver’s license verifications. Most basically: does the driver/renter of the car have the attestations to prove that they are a licensed driver?
We foresee a future where vehicle owners can post cars to an EAS-driven dapp, riders can post EAS-based trip requests and when matched, the trip goes up on a prediction market to fund various layers of insurance. Instead of purchasing a policy from a broker and paying a premium, driver and vehicle owner post “bait” capital to entice market participants to take opposing positions with their capital. Given vehicle, location, schedule, and driver reputation (all of which runs on EAS) the P2P prediction market will set the most frictionless, capital-efficient rates. The insurances resolve at end of trip and funds are transferred to the winning gamblers based on DIMO oracle data in alignment with other EAS attestations (for example a police report or before/after images of damage) as needed.
There are many more steps to this idea but we’re taking the first obvious step, presuming remaining steps can be resolved at future hackathons with EAS, DIMO data, prediction markets, and carefully incentivising stakeholders.
The frontend is a React app that's initialized with Vite. At its core, it’s basically just a series of forms strung together that compile into JSON metadata for the minting of the NFT at the end of the user flow. We’re using both the WalletConnect/Wagmi library to allow users to connect to their DIMO address via whichever wallet they prefer. Because this is all just a test environment, you’ll notice that this also uses Metamask – that’s how we connect to the Sepolia testnet for minting of these “test” NFTs for now. In a production environment, there’d be no requirement to connect two wallets. The backend is using Node.js and Moralis. The Moralis API gives us easy access to the NFTs that a user has associated with their wallet that they connect via the frontend. We parse through these, making sure that only DIMO NFTs end up in the application, and filter through these based on a user's vehicleID so that, if a user has multiple vehicles on the network, we can correspond the NFT image with that unique vehicle. We also created a very basic smart contract in Solidity, which was deployed to the Sepolia testnet via the Remix IDE. The contract uses OpenZeppelin with a simple mintNFT function. We then use ethers.js in our React application to handle the minting of the “rental contract” NFTs. As a fun aside, we also used ethers.js and Infura.io to support ENS for the “Drivers Wallet” input field – so instead of having to type out a users full 0x address, you can simply input “vitalik.eth” and have that ENS be resolved to the full address. All coding was done in VS Code, aside from the Solidity smart contract in Remix. Code management was done through Github.