Skip to content
This repository has been archived by the owner on Aug 9, 2021. It is now read-only.

Overview

Jump to bottom
yaojie edited this page Dec 20, 2018 · 5 revisions

Design Philosophy

After spending several days working with the smart contracts and attempting to make them tightly coupled, we realized that the gas costs are getting really high, even exceeding the limits set by Oraclize. We ended up decoupling the storage of important data across 2 contracts, namely FlightValidity, Userinfo storing the Bookings and Insurances accordingly.

We expect the user to either manually call the contract or re-upload their tickets to update the ticket status if it has not been updated, to claim their insurances in the event that the flight becomes delayed or cancelled.

FlightValidity.sol

This contract stores a mapping of queries to keep track of msg.sender and their respective queries for tickets. When __callback is called, the mapping clears the query and updates the ticket status - whether it is valid or invalid to purchase insurance for.

We currently use a mock endpoint at archwing-bookings to simulate a limited active endpoint, and only use the booking_number of the ticket to verify its candidacy. Ideally we would use the other fields as well, or a real endpoint. If you would take a look at the older commits you would notice we tried using Singapore Airline's API but it was very limited and too dynamic to be able to perform consistent tests.

We expect the user to consistently poll for ticket updates using the refresh button on the website, or call the contract directly from their clients. Here are some rules we set:

  • Only future flights can be added. (a.k.a flights that have not departed yet)
  • Future flights that are delayed or cancelled can be added, but will not be able to purchase insurance. The ability to add these flights are mostly due to the limitations of API at archwing-bookings.

UserInfo.sol

This contract keeps track of every user's loyalty points (we call them AWPoints) and the insurances they have bought. It is constructed with an initial seed fund to pay for insurances. It also has a function for the owner to pass in extra money. Ideally we should also have a function that allows withdrawal of funds within limits (as long there is enough inside to pay for insurances) We implement a simple buy/claim mechanism for insurances:

  • Users have to initiate a payout.
  • Users will be blocked from purchasing insurance if the contract does not have enough funds to pay them.
  • Multiple accounts can buy insurances for the same booking provided that the flight has not departed yet.
  • Users cannot buy insurance for flights that are cancelled or delayed beforehand.
  • Users will need to update the statuses of the respective fights on their own by calling checkFlightDetails before claiming any insurance payouts.
  • Users that have enough AWPoints will be able to purchase insurance for free. However, they will not gain additional AWPoints from doing so.
  • Users have to maintain the freshness of flight status before buying insurance. This means that the tickets that have already registered beforehand in their accounts have to be within 30 minutes of the transaction for the insurance purchase to succeed. This prevents people from registering large number of tickets, waiting for any to be delayed/cancelled and immediately purchasing insurances for them (the status stored in the system would be stale and still "vaild"), querying to update the status, and cashing out.
  • Balance will be transferred over to a holding map instead of a direct transfer to prevent against attacks.
  • Balance payouts have to initiated by the users. It will be drained before transferring to prevent re-entrancy attacks. We noted that withdrawing balance will incur a cost of SGD 0.01 as of 8/12/2018. The payout does not include this gas cost unfortunately.

ConversionRate.sol

This contract maintains the conversion rate the DApp will be using. It uses Oraclize (again) to query an external API for the current conversion rate to SGD. It is updated on initial deploy, and it keep tracks of the last updated time. Ideally, the company would update the price regularly on virtue of being honest, but we know that the company would update it only when the price goes up. As a stopgap, users can also opt to update the prices themselves by calling the method updateConversionToSGD, or just noting the lastUpdated time themselves and opt to not purchase any insurances from the company.

It calls the endpoint at https://min-api.cryptocompare.com/data/price?fsym=ETH&tsyms=SGD.

Clone this wiki locally