fizzy by AXA: Ethereum Smart Contract in details
Hi everyone, been a long time, almost a year! We are excited to bring you the May 2019 version of fizzy’s Smart Contract (on the Ethereum Blockchain), enabling you to purchase insurance against flight delays and cancellation as well! This article will hopefully enlighten you regarding its functioning.
We’ll give you everything you need to understand the Smart Contract, so you may continue reading even if it’s the first time you hear about Ethereum!
By the way, we now cover 80% of flights worldwide!
What is fizzy?
fizzy is a fully automatic flight delay and cancellation insurance, with a blockchain twist.
You may visit https://fizzy.axa, enter your flight details, get a custom quotation (what you will pay for the insurance and what you will receive if there is a delay of 2 hours or a cancellation), subscribe and follow your policies.
The pricing of your policy depends directly on the risk of delay and cancellation that is calculated independently for each flight by our custom pricing algorithm. This algorithm relies on 8 years of historical data and is updated weekly, making sure that the price you get is always the closest to the reality of the delay / cancellation risk.
If you subscribed a policy and your flight is cancelled or lands with 2 hours of delay (depending on your product choice), you’ll receive your compensation directly on your bank account. No claims, no paperwork, no hassle! fizzy takes care of monitoring your flight and the Smart Contract will decide whether you are eligible to compensation or not.
What is Ethereum?
Ethereum is a public Blockchain. Which means everyone can read the content of the transactions that are validated by the nodes of the network.
However, Ethereum comes with a pretty interesting icing on the cake: Smart Contracts!
The principle is easy: anyone can host a piece of code on the Ethereum blockchain. It is then possible to call this piece of code with a transaction and make it run on the Ethereum Blockchain.
Both the pieces of code and the transactions are readable by anyone (with a tad bit of retro-engineering, hence this article).
In a nutshell: fizzy’s Smart Contract can accept different types of transactions. Those transactions carry information, and that information is used to run a piece of code and produce a result!
fizzy’s Smart Contract
… can be found at this address on the Ethereum blockchain: 0xdc3d8fc2C41781B0259175BdC19516f7Da11cBA7
In order to have a look at the status of the contract (i.e. all transactions From / To this contract), you can use the free block explorer etherscan: https://etherscan.io/address/0xdc3d8fc2c41781b0259175bdc19516f7da11cba7
By clicking on any TxHash (the address of a transaction sent to the Smart Contract), you’ll be able to see its details.
Our Smart Contract has several functionalities. 4 of them are dedicated to flight delay and cancellation:
- addNewInsurance: to register new policies in the Smart Contract.
- SetFlightLandedAndArrivalTime: to set the actual arrival time of a flight (in case it wasn’t cancelled).
- triggerCondition: to set the status of the flight (in case it didn’t land a scheduled).
- manualInsuranceResolution: this function may for instance be used if you choose to cancel your policy before the flight.
So, the Smart Contract is used twice for each policy: at subscription and at flight landing. You can find below a high-level description of the workflow between the fizzy app and its Smart Contract (including the name of the functions used to send transactions to the Smart Contract).
As you can see, in this scenario, all data is processed internally by the fizzy app before being registered in the Blockchain, where the Smart Contract takes the decision to compensate or not, providing you with an immutable, decentralized, opposable proof (i.e. you can easily — after reading this article — double check that fizzy used the right data for your flight).
What happens when I subscribe to an insurance on https://fizzy.axa ?
Once you have entered your flight details, chosen a product and a level of coverage, subscribed to your insurance policy (i.e. provided the necessary personal information and payment) on https://fizzy.axa, you’ll receive an e-mail confirmation including the TxHash (an address for a transaction in the Ethereum Blockchain) for your policy subscription.
At this point, fizzy took your flight and insurance details, packaged them and sent them to the Smart Contract in order to register them in the blockchain. Don’t worry, no personal information other than the flight details and a randomly generated ID are stored in the Blockchain.
If you follow the link in the e-mail, you’ll land on a page describing the specifics of the transaction (using etherscan, as described above). You can see in the “Input Data” box that we indeed used the addNewInsurance function with the following parameters:
- flightId: the ID of this flight (flight code + departure date). Different customers could potentially cover the same flight.
- productId: the unique ID of this product.
- premium: what you paid to subscribe.
- indemnity: what you’ll get in case the insurance conditions are met (delay or cancellation).
- limitArrivalTime: the time of arrival after which you’ll be compensated (in case you chose a policy covering delay).
- conditions: the conditions for which the policy will be « triggered » (i.e., you’ll receive your indemnity). In this new version, fizzy offers two different products. Either a delay (2h) and cancellation insurance, or a cancellation only insurance. This line will define which one of those your policy is.
Those values are not immediately readable by a human. In order to see how to convert them, please check the last chapter of this article.
What happens when my flight lands?
fizzy will track your flight through requests to the data provider Flightstats around the time of arrival. The actual time of arrival Flightstats generates is then leveraged by the Smart Contract to update and close the policy status.
Depending on the flight status, the function used at this point will vary:
- setFlightLandedAndArrivalTime: if the flight landed in the scheduled airport, this function will provide the Smart Contract with the actual arrival time of the plane.
- triggerCondition: otherwise, this function will provide the Smart Contract with the flight status, in order to see if it respects the conditions of the policy (as of today, this function can only be used to provide a cancelled flight status).
Both these functions carry two pieces of information: the flightId and a value that will allow the Smart Contract to take the decision to compensate or not for this flight.
- setFlightLandedAndArrivalTime: carries the actual landing time of the flight.
- triggerCondition: carries the other conditions that may trigger the compensation (as of today, the status « cancelled »).
The last chapter includes link to help you read the details of those transactions.
How is the decision of compensating a policy taken and communicated?
As previously mentioned, sending the transaction to the Smart Contract to register information is not the end of the line. That information will be used to create a result: the decision to compensate or not for your flight.
The functions we talked about in the previous chapter are used by the Smart Contract to update and close the policy on the Smart Contract. In doing so, the Smart Contract will also generate an event (InsuranceUpdate) containing the decision to compensate or not. This event is captured by fizzy, which will trigger the payment of your compensation, if needed.
As seen in the event definition, the last piece of information is the status of the policy:
0: Open; 1: ClosedCompensated; 2: ClosedNotCompensated
How to convert the values used by the Smart Contract in human-readable data?
The values registered in fizzy’s Smart Contract have different types. Depending on the one you want to read, you’ll have to use different methods.
a. flightId
The first data appearing in all the transactions is the flightId. It takes this shape: 54502e3230382e31353538323234303030303030000000000000000000000000
To read it, you first have to convert it with a hexadecimal to string converter, like codebeautify.
Once converted, this value will become: TP.208.1558224000000. Those characters represent your flight:
- TP208: your flight code (TP is the airline code and 208 the flight number).
- 1558224000000: the date of departure of this flight (local time), in timeStamp.
You still have one step to go to get a proper date of departure: converting the timestamp. You can do so by using epochconverter, for instance.
In that case, the timestamp stands for the 19th of May 2019.
ProTip: for a quick check of the flightId directly on etherscan, you can also try to view the input of the transaction as « UTF-8 ». You should be able to isolate and confirm your flight code with this method.
b. premium and indemnity
Those values are simply encoded in hexadecimal, several online converters can do the work to convert it. (Or you could train to calculate 16 squared, cubed, to the fourth, etc. 😉)
c. conditions
The characteristics of your insurance described in binary (one active bit = a characteristic of the policy). As of today, we only propose a 2hour delay cover and a cancellation insurance.
- If « conditions » is equal to 9 (i.e. 1001 in binary): you are covered for both delay and cancellation.
- If « conditions » is equal to 1 (i.e. 0001 in binary): you are covered for cancellation only.
d. limitArrivalTime
This data registers the landing time after which fizzy will compensate you for the delay of your flight (as of today, this is the scheduled landing time + 2 hours). It is also a timestamp encoded in hexadecimal, meaning that:
- First you got to convert it from hexadecimal to a string using codebeautify.
- Convert the resulting string in a human readable date using epochconverter.
This limit time of arrival is stated in UTC (only the date of departure is stated in local time, for ease of comprehension by the traveller).
e. actualArrivalTime
This data, registered in the Blockchain through the « setFlightLandedAndArrivalTime » function, is a timestamp encoded in hexadecimal as well (see d.).
f. conditionToTrigger
Similarly, to the « conditions » definition, this data contains the conditions of the insurance that have been triggered. As of today, the only « condition » that can appear is a cancellation. In that case, the value of conditionToTrigger will be 1 (i.e. 0001 in binary).
What else?
I hope this helped you understand the fizzy project a bit better! Please do not hesitate to suggest additional content or explanation.
