Backend

Concrete protocol internal documentation

Introduction

The purpose of the web3 backend is to act as a conduit between the frontend and the smart contract layer. The backend is also responsible for making requests to the risk engine in order to create specific policies and present them to the user.

The backend will also be responsible for making required calls to the smart contracts on behalf of the user, as well as keeping track of all pertinent up to date pricing

The Web3 backend is to be broken down into multiple micro-services (to be listed in System Architecture)

The web3 backend will maintain a clone of the smart contract state. This allows us to rapidly evaluate every loan in existence without incurring any blockchain limitations or gas consumption through the use of loops.

System Architecture

The web3 backend is broken into multiple smaller micro-services. These include the following.

Price Oracle

The price oracle is responsible for allowing accurate, current pricing information available at all times. This will be executed through multiple mechanisms, including a combination of on-chain data as well as reliable off-chain pricing data. A short explanation follows:

• The price oracle will have an open web socket with an archived node for the purposes of monitoring the current price of a given asset on Uniswap.

• The price oracle will utilize a minimum of two crypto pricing APIs.

• The price oracle will continuously evaluate the validity of all three sources of data. If one source is determined to be off by a given percentage, its values will be discarded to eliminate the possiblity of a rogue pricing source breaking the system.

• The price oracle will provide a continuous stream of data available to the other micro-services.

• The price oracle will have the ability to provide a continuous stream of pricing data to the frontend.

Coverage Service

The coverage service is responsible for communication with the risk engine. The coverage service will expose one API endpoint and a webhook

Borrower Service

The borrower service is primarily responsible for updating blockchain state. This is done by utilising the wallet service to provision a wallet that will call the appropriate smart contract function

Loan To Value (LTV) Monitor

The LTV monitor is at the heart of the protection schema. It is responsible for monitoring every loan for loan's health, and requesting blockchain executions based on loan's status.

• Maintain Database (DB) that mimics the smart contract state. This allows for rapid and efficient looping of all available loans.

• The LTV monitor places loans into one of four buckets. Health, LTV1 breached, LTV2 Breached and liquidated.

• The LTV will run a chron job for each bucket, with timing intervals optimized for extensibility.

• While checking the health status of each loan, the LTV monitor will place the loan in the bucket that matches the loans status.

• When a loan status is updated, the LTV monitor will call on the borrower service to update the state on chain as appropriate.

Wallet Service

The wallet service is a novel approach to efficiently handling nonce issues while making smart contract calls. The wallet service will maintain a stable of pre-whitelisted wallet addresses to interact with the smart contracts. The wallet service is also responsible for maintaining optimal gas availability in each wallet. For more detail click here.

Common Understandings

Integration within the Product Ecosystem

The web3 backend will be heavily integrated with all facets of the protocol. The following is a breakdown of specific integrations.

Integration with risk engine

The web3 backend communicates with the risk engine module to make requests for coverage via the coverage micro-service.

Integration with Frontend

The web3 backend will communicate with the frontend in order to present the coverage parameters provided by the risk engine. Additionally, the backend will receive requests from the frontend for execution.

Integration with Smart Contracts

The borrower service is primarily responsible for handling calls made to the smart contracts. Upon request from the frontend, the borrower service will call the required function on the smart contract. An example being the user requests a loan be taken out. The borrower service will call borrow on the core smart contract.