Accord contract developed in Accord Studio (https://studio.accordproject.org/).
Landing page for the front-end. Either load an existing payment contract or deploy a new archive.
Upload modal for the contract.
Uploading for legal contract. Contract parameters can be reviewed before deploying the payment contract from factory.
Deposit page for client/insurer. Once both have deposited, the contract can be initialised.
Once the contract is successfully initialised, either party may trigger for assessment.
Working professionally with smart legal contracts, I had realised that I had not seen a public implementation of the Accord Project (https://accordproject.org/) on Ethereum. Given that off-chain interaction was needed in order to interact with the legal text, it made sense that Chainlink could be used to bridge the gap between the legal contract engine (Cicero) and handling of payments on Ethereum.
What it does
In it's current state, Accordion is able to take an legal contract archive (*.cta) of a fixed design and initiate on a Chainlink node. The smart contract on Ethereum then handles initial user deposits - in this instance insurer/client - before initialising the contract for use. Once running, the smart contract can be triggered by either of the parties to assess the legal clause against a given input.
In this example the contract is an weather insurance agreement between two parties. A premium and payout is defined in the legal contract, along with the location to be monitored. The deployment flow is as follows:
- The legal contract is developed and exported as a (*.cta) file. This file is then upload to the Accordion app.
- Once uploaded, the user will verify the contract details and when happy will deploy the payment contract via a factory contract.
- With the payment contract deployed, the client and insurer must deposit the specified payment in ETH.
- The contract can then be initialised on the Chainlink node via the Accord Cicero engine.
- When successful, both the client and insurer can trigger the contract to assess it's status at a given time.
How I built it
An adapter had to be built in order to deploy the Cicero engine on a Chainlink node. This adapter handles both intialisation and execution of contact input. This was build from the NodeJS adapter template.
Cloud Functions & Storage
A cloud function was built to upload the legal archives from the front-end to a cloud storage bucket.
A factory contract was developed for this specific legal archive so that a known, fixed triggering mechanism would be available if many contract's were to be deployed. The payment template contract derived from this, stores data on the current payment state, as well as the logic to trigger the Chainlink oracle contract.
Truffle's Drizzle framework was used to develop a front-end to tie all of the above functionality together.
Challenges I ran into
Due to personal contraints, I had started the hackathon quite late into the process so did not get full functionality into the current build. With that said the core contract mechanics are in place and is operational.
Trying to package mutliple pieces of data in a Chainlink response also proved difficult at times. Originally, booleans were used to signal initialisation, but then I wanted to return a hash of the legal contract state. So, I opted to use the bytes32 format reponse and segment the response into different areas of use (ie. front half for hashing, rear for returning an address for processing).
The main challenge that I had ran into was the storage and management of both legal state and response data. Currently this information is stored on Cloud Storage (!) which a hash of the buffer stored within the paired smart contract. Ideally this should decentralised, either stored on-chain or distributed via IPFS.
Accomplishments that I'm proud of
Getting a PoC up and running in the time participating. Also getting the core functionality working - the verification of contracts against the smart contract variables, internal triggering of the contract based upon weather API data.
What I learned
How to correctly deploy factory contracts. Passing files to cloud functions for processing. Correctly formatting Chainlink responses for smart contract parsing. Always leave enough time for a front-end!
What's next for Accordion
- Get a more robust front-end operational. Currently extremely bare-bones and offers basic functionality.
- Find a more reliable way to hash data on-chain to gaurantee contract state.
- Generalise the Accord function format - look to create a model library aimed a Ethereum use (i.e. fixed format contract responses for wider use).