Parallel Finance White Paper

Ⅰ. Abstract
This paper introduces three decentralized, Polkadot-powered protocols built to accelerate liquidity and adoption on the Polkadot network. The first is a Decentralized Money Market Protocol that offers lending and borrowing. The second is a Staking Derivative Protocol that tokenizes native DOT tokens. The paper then briefly outlines our protocol designs and parachain auction strategies. Finally, the third is an under collateralized lending market built to help teams form capital for parachain auctions.
Ⅱ. Introduction
The Polkadot ecosystem, since its inception, has a market cap of more than $40 billion at the time of writing [1]. Currently, DOT holders stake into the relay chain to earn an estimated 14% [2] annual return on their staked DOT. However, the staked DOT remains illiquid and it takes 28 days to unstake them. This requires DOT holders to face a high opportunity cost when utilizing DOT in other decentralized applications as they have to forego their staking income. Additionally, users need to earn more than 14% in these protocols otherwise they should just take the risk-free rate from staking. Unfortunately, there are no live applications in the Polkadot ecosystem that allow users who have staked DOT to get liquidity.
Our platform introduces a new financial primitive for staked DOT, which allows users to accrue interest from staking while still having a liquid asset not subject to lockups or lengthy unlock periods. This staked DOT financial primitive will be referred to as xDOT. Lenders will be able to earn interest income on their xDOT, and borrowers will be able to get loans against their DOT denominated in stable coins without selling their DOT.
Ⅲ. Lending Protocol
1. Overview
1.1 Supplying Tokens
The Parallel lending protocol uses a pool-based strategy that aggregates each user's supplied assets.
This lending protocol will have a DOT, xDOT, and USDT pool where users can deposit their assets and earn interest. This market is liquid, and so long as the total supplied amount is not being borrowed, it offers lenders liquidity, and the ability to turn their supplied asset into cash, and realize their earned interest.
Balances in this money market accrue interest based on the supply interest rate unique to that asset. The supply interest rate is calculated based on the current interest being paid, divided based on pool ownership amongst the current users supplying assets to that market. Users can view their balances (including accrued interest) in real-time. 
Token holders who are long DOT can use a Parallel's money market as a source of additional revenue by lending. Additionally, a user who owns xDOT could also lend that asset out in the money market, thus earning staking returns and interest at the same time.
1.2 Borrowing Tokens
Parallel enables users to borrow from the protocol with over-collateralized loans. Each borrow market has a floating interest rate, determined by the utilization of that market's assets.
In order to borrow an asset, users must deposit or approve an asset or assets as collateral that is/are more than the target outstanding borrowed amount, thereby setting the borrow. The borrow limit is dependent on the Loan to Value ratio of that specific market. In order to increase the borrow limit, users can either repay a borrowed asset or deposit more collateral.
As prices fluctuate, if the value of a user's supplied assets divided by the value of their outstanding borrowed amount declines below the collateral ratio, the user's collateral becomes available to purchase at the current market price minus a liquidation discount. This incentivizes an ecosystem of arbitrageurs to step in to reduce the borrower's exposure quickly and eliminate the protocol's risk to downwards price action, and a Loan To Value ratio below 100. Details of the liquidation mechanism are described in section 4.3.
2. Interest Rate Model
2.1 Internal Exchange Rate 
When a supplier deposits an asset to the money market, the internal supply position of the supplier will be added with a certain amount based on the initial exchange rate. The supplier earns interest through the appreciation of the internal exchange rate.
internalExchangeRate=totalCash+totalBorrows−totalReservetotalSupplyinternalExchangeRate=\frac{totalCash+totalBorrows−totalReserve}{totalSupply}internalExchangeRate=totalSupplytotalCash+totalBorrows−totalReserve​
Because to the total borrowed amount is saddled with interest, the internal exchange rate continually increases. This means that ultimately, the supplier can withdraw more of this asset with the new exchange rate than they could when they deposited.
2.2 Interest Rate Model Principle
Parallel Finance utilizes an interest rate model to balance an equilibrium between supplying and borrowing markets. The interest accrued from borrowers will be distributed evenly to all suppliers. Without considering the reserve, the relationship between the supply and borrow side can be described as the following:
SupplyRate⋅TotalSupply=BorrowRate⋅TotalBorrowSupplyRate \cdot  TotalSupply = BorrowRate \cdot  TotalBorrowSupplyRate⋅TotalSupply=BorrowRate⋅TotalBorrow
The following are the definitions for different variables in the money market:
Cash = Total Unborrowed Assets
Borrows = Total Borrowed Assets
BaseRate = Starting interest rates
Slope = Slope that defines the interest rate increases
 The utilization ratio U for each money market unifies supply and demand into a single variable:
UtilizationRatio=BorrowsCash+BorrowsUtilizationRatio=\frac{Borrows}{Cash+Borrows}UtilizationRatio=Cash+BorrowsBorrows​
2.3 Borrow Interest Rate
When demand is low, interest rates should be low, and vise versa when demand is high. The BorrowInterestRateBorrowInterestRateBorrowInterestRate
is defined as the following: 
{BaseRate+U⋅slopeaU≤targetBaseRate+Utarget⋅slopea+(U−Utarget)⋅slopebU>target\begin{array}{cc}
  \{ & 
    \begin{array}{cc}
      BaseRate+U \cdot slope_a & U\leq target \\
      BaseRate+U_{target} \cdot slope_a +  (U - U_{target}) \cdot slope_b & U> target \\
    \end{array}
\end{array}{​BaseRate+U⋅slopea​BaseRate+Utarget​⋅slopea​+(U−Utarget​)⋅slopeb​​U≤targetU>target​​
​
2.4 Borrow Interest Rate Parameters
Asset
​UthresU_{thres}Uthres​
 
BaseRate
​slopeaslope_{a}slopea​
 
​slopebslope_{b}slopeb​
 
USDT
85%
0%
5%
250%
DOT
70%
0%
15%
200%
KSM
70%
0%
40%
200%
Borrowing and Lending Interest Rate of USDT market on Parallel
Borrowing and Lending Interest Rate of KSM market on Parallel
Borrowing and Lending Interest Rate of DOT market on Parallel
2.5 Supply Interest Rate
For the sustainability and resilience of the protocol, suppliers' total interest earned must be less than the total interest product by borrowers. The supply interest rate is a function of the borrowing interest rate and includes a spread, S(such as 0.10), which represents the economic profit of the protocol:
SupplyInterestRate=BorrowingInterestRate⋅UtilizationRatio⋅(1−S)SupplyInterestRate=BorrowingInterestRate \cdot  UtilizationRatio\cdot (1-S)SupplyInterestRate=BorrowingInterestRate⋅UtilizationRatio⋅(1−S)
This protocol fee can be used to support further development of the platform, as insurance in case of a crypto economic attack, or provide emergency liquidity to the system.
2.6 Interest Rate Index
Each interest rate's history, for each money market, is captured by an Interest Rate Index, which is calculated each time an interest rate changes, resulting from a new block connected. A user's balance, including accrued interest, is simply the ratio of the current index divided by the index when the user's balance was last checkpointed.
The borrow balance for each account in the market is stored as an account borrow snapshot which is a Rust struct like this:
1
pub struct BorrowSnapshot {
2
    pub principal: Balance,
3
    pub interest_index: u128,
4
}
Copied!
This struct describes the balance at the time interest was last applied to the account.
Each time a block is connected, both the supply and borrow Interest Rate Index for the asset are updated to compound the interest since the prior index, using the interest for the period, denominated by r*t, calculated using a per-block interest rate.
Indexa,n=Indexa,(n−1)⋅(1+r⋅t)Index_{a,n} = Index_{a,(n-1)} \cdot  (1 + r \cdot t)Indexa,n​=Indexa,(n−1)​⋅(1+r⋅t)
2.7 Borrow Mechanism
A user who wishes to borrow and who has sufficient balances stored in Parallel may call
1
pub fn borrow(
2
    origin: OriginFor<T>,
3
    currency_id: CurrencyId,
4
    borrow_amount: Balance,
5
) -> DispatchResultWithPostInfo
Copied!
which is on the loans pallet. This function call checks the user's account value and the given sufficient collateral. It will update the user's borrow balance, transfer the tokens to the user's account address, and update the money market's floating interest rates.
Each account has a BorrowSnapshot structure to store a snapshot of the last settlement information of interest.
1
pub struct BorrowSnapshot {
2
    pub principal: Balance,
3
    pub interest_index: u128,
4
}
Copied!
The borrows accrued interest is calculated as follows:
accruedInterest=snapshot.principal⋅borrowIndexsnapshot.interestIndexaccruedInterest = \frac{snapshot.principal \cdot borrowIndex}{snapshot.interestIndex}accruedInterest=snapshot.interestIndexsnapshot.principal⋅borrowIndex​
A borrower has the right to repay an outstanding loan at any time by calling 
1
pub fn repay_borrow(
2
    origin: OriginFor<T>,
3
    currency_id: CurrencyId,
4
    repay_amount: Balance,
5
) -> DispatchResultWithPostInfo
Copied!
 which repays the borrow's principal and accrued interest.
3. Experimental Models
3.1 Curve Interest Rate Model
For most lending protocols, interest rates are adjusted by a piecewise function to bind the utilization ratio within a reasonable range. However, the negative feedback of this system is relatively weak and inflexible. The curve function on Parallel will solve the problem of inflexibility.
In order to achieve this goal, the interest rate change speed needs to gradually increase as the utilization rate increases. For the best way to fit it, it is necessary to combine the power functions and exponential functions and adjust the parameters.
BorrowInterestRate=∑cn1i1⋅e[cn1i2⋅(UtilizationRatio−cn1i3)]⏟Random+BorrowInterestRate=\underbrace{\sum_{}^{}c_{n1i1}\cdot e^{[c_{n1i2}\cdot (UtilizationRatio-c_{n1i3})]}}_{Random}+BorrowInterestRate=Random∑​cn1i1​⋅e[cn1i2​⋅(UtilizationRatio−cn1i3​)]​​+
∑bn2i1⋅(UtilizationRatio−bn2i2)bn2i3⏟Random+c\underbrace{\sum_{}^{}b_{n2i1}\cdot (UtilizationRatio-b_{n2i2})^{b_{n2i3}}}_{Random}+cRandom∑​bn2i1​⋅(UtilizationRatio−bn2i2​)bn2i3​​​+c
Take USDT as an example: the image below shows the difference of borrow interest rate changes between Parallel, Aave, and Compound. While Parallel, Aave, and Compound all have similar interest rates when the utilization ratio is below 80%, the curve function of PARA realizes higher interest rate changes when the utilization ratio approaches 1 compared with the other two markets. While we are optimistic that this mechanism will perform well, it will not be deployed before there are enough statistics on Parallel.
Curve Function of USDT market
3.2 Interest Rate Adjustment Mechanism
Interest rates of the same assets in different markets are sometimes extremely different. When the utilization ratio hits a higher percentage, the adjustment mechanism will be triggered, and the Off-chain worker will capture interest rates of different assets from other decentralized markets. Weights will be given to each market based on their effectiveness, to obtain the average market interest rate level. It is worth noting that the adjustment factor will only be triggered when the utilization rate reaches the threshold, in order to make the utilization rate back to an appropriate level. The Adjustment Factor and Borrow Interest Rate will be calculated by:
AdjustmentFactor=BorrowInterestRatePARA−∑ci⋅BorrowInterestRatei∑ci⋅BorrowInterestRateiAdjustmentFactor=\frac{BorrowInterestRatePARA-\sum_{}^{}c_{i}\cdot BorrowInterestRate_{i}}{ \sum_{}^{}c_{i}\cdot BorrowInterestRate_{i}}AdjustmentFactor=∑​ci​⋅BorrowInterestRatei​BorrowInterestRatePARA−∑​ci​⋅BorrowInterestRatei​​
BorrowInterestRateAdjusted=BorrowInterestRate⋅(1+AdjustmentFactor)BorrowInterestRateAdjusted=BorrowInterestRate\cdot (1+AdjustmentFactor)BorrowInterestRateAdjusted=BorrowInterestRate⋅(1+AdjustmentFactor)
4. Liquidation
Liquidation is essential for a Money Market Protocol. At the present stage, liquidation will be triggered by an off-chain liquidator [7]. When prices fluctuate a lot, the health factor of the accounts on Parallel will likely go down in order to diminish systemic risk. In addition, an oracle needs to be able to feed the prices as quickly as possible while unhealthy accounts need to be liquidated [8]. However, due to the throughput and gas fee on Ethereum, liquidation calls maybe delayed, which increases systemic risk.
Parallel introduces a liquidation solution built with a Substrate Off-chain Worker. It has three key components: Auto-liquidation Algorithm, On-Chain Liquidation Pool, and Flash Liquidation.
4.1 Auto Liquidation Algorithm
The Off-chain Worker will fetch all borrowers, debt, collateral, liquidation ratio from the state of Parallel blockchain, also the prices from oracle, then the protocol calculates the health factor of each borrower's account if there is a liquidation opportunity, then it will automatically send a liquidation transaction to on-chain. 
4.2  On-Chain Liquidation Pool
The on-chain liquidation pool is the only portal to execute a liquidation. Although a reserve fund is provided in the pool, liquidators can still trigger liquidation with their own fund without any capital in the reserve fund.
Any user and bot can send liquidation transactions, the liquidation pool will invoke a function in lend and borrow pool to promote liquidation.
In the event of liquidation, there will be a penalty for the borrower and a bonus for the liquidator. The liquidator's bonus comes from two parts: borrowers' collateral discount and borrowers' penalty. 
4.3 Flash Liquidation
Parallel introduces a new way of liquidation that allows the user to send a liquidation transaction without any capital. A function interface was provided to allow users to liquidate without any assets, aiming to provide a DeFi Lego component with Flash loan, DEX.
​
5. Oracle and Price feed
In order to secure the lending protocol, Parallel is required to have accurate and real-time market prices for different assets. An oracle has been introduced as a mechanism that brings off-chain data on-chain, in a credible and decentralized fashion. For now, most mature decentralized oracle solutions are designed for Ethereum. Some protocols like Chainlink are devoted to building a strong economic network for gathering price off-chain and feed price by submitting a specific transaction [11]. In Polkadot, there is already some early work to provide the decentralized oracle solutions by the Substrate community, but such solutions are far from production-ready. Parallel designs a semi-decentralized way to tackle the current situation. 
5.1 Off-chain Price Fetching
The Parallel team implements a simple but efficient client to fetch the prices from the mainstream exchanges. For each asset, the fetched prices are reduced into one with a median strategy. During each block, the authorized members can submit the price on-chain. To make it as secure as possible, the authorized members are elected by the governance of Parallel.
5.2 On-chain Aggregation Strategy
When the prices are submitted on-chain, several strategies such as a  median algorithm and an average algorithm are provided to gather them.
Median algorithm: 
MedianPrice=SortedPrices[counts/2]MedianPrice = SortedPrices[_{counts/2}]MedianPrice=SortedPrices[counts/2​]
Average algorithm:
AveragePrice=(∑i=0nxi)/nAveragePrice = (∑_{i=0}^nx_i) / nAveragePrice=(i=0∑n​xi​)/n
IV. Staking Protocol
1. Overview
Polkadot's relay chain uses a derived PoS (Proof of Stake) consensus to secure its network. Most parachains will also have a simplified PoS mechanism to incentivize their collators to produce valid blocks. The users' token like DOT serves as the staked assets which will be locked during nominating the validators and the collators. Also, a delay (aka, unbonding period) is often enforced by protocols when users want to cease participating, and unlock their assets. The staked assets can be slashed if the validators do harm to the network. Such restrictions impose economic costs on the holders of staked assets and require the holders have sufficient knowledge to choose validators. Parallel proposes two solutions to circumvent the limitations: delegated staking, and a lending pool with a bounded rate.
2. Validator Choosing Strategy
There are a few dimensions when choosing validators in Parallel's protocol. Here they are in order of priority, from high to low:
the reputation of the node operator
validator should trigger payout regularly
single operator with more validators has a higher probability to be slashed if downtime happened
the commission rate and nomination volume of the validator
the downtime and luckiness which wraps era points on Polkadot network and slash records in the past
the amount should not be controlled by one account, nor one active nomination
less than 200 DOT will be dropped (it is acceptable on Kusama since there are enough validators on the Kusama network)
These metrics can be uniformized in the following equation:
Score=R⋅((1−CR)/N)⋅(c⋅AEP/AEPA)⋅SRScore = R \cdot  ((1 - CR) / N) \cdot  (c \cdot AEP / AEPA) \cdot  SRScore=R⋅((1−CR)/N)⋅(c⋅AEP/AEPA)⋅SR
R: Reputation, 0 or 1. 
CR: Commission Rate. 
N: Nomination amount of one validator. 
AEP: Average Era Points of one validator in the past week. 
AEPA: Average Era Points of All validators in the past week. 
c: A constant shows how much influence of the Era Points of a validator. The default value is 1.
SR: Slash Record, default 1, set to 0 if ever slashed in the past month.
3. Nomination Workflow
Create stash accounts in the relay chain (if XCM is ready, then the parachain account should also work here).
Create controller account in relay chain (if XCM is ready, then the parachain account should also work here).
Transfer the fund from Parallel's system account to stash accounts.
Bond Max-1 KSM with Stash account.
Nominate validators chosen by the Parallel protocol based on the above strategy.
Bond extra KSM with Stash account if new fund comes in.
Unbond a certain amount of KSM if a request for unstaking occurs, wait until unbonding period ends.
Withdraw unbounded and transfer to the Parallel's system account which holds the unstaked assets.
Extrinsics:
set_controller: called using stash account
bond: stash account
bond_extra: stash account
unbond: controller account, max unbond queues: 32
rebond: controller account
withdraw_unbonded: controller account
nominate: controller account
set_payee: controller account
payout_stakers: check validators do submit this call before the deadline.
The above workflows can be executed with multi-signature accounts or XCMP (Cross Chain Message Passing), both share the same interfaces. A short-term solution is to use multi-signature accounts before XCMP of Kusama matures, but in the long-term, XCMP will always be favored. Such multi-signature accounts will the following:
Multi-Signature Account
With Polkadot, users can easily set up a multi-signature account. Parallel creates such accounts and the set of signatories comes from the council members of Parallel. The signatories watch the on-chain events and the balances of the multisig address and submit or approve specific extrinsic.
Cross Chain Staking with XCMP
With staking related XCM available, all above extrinsics can be submitted from the parachain account. On-chain logic can send accurate messages based on the on-chain analysis. This issue blocks us.
4. Delegated Staking
The holders deposit their staked assets into Parallel's system account in exchange for a voucher (aka, xDOT) which represents the ownership of the staked assets and shares the revenue of staking activities on the relay chain. Parallel's liquid staking protocol then nominates validators with a funded system account. xDOT can also be used as a collateral assets in the lending market. The price of xDOT is the same as DOT before there are high-quality open markets.
Exchange rate between xDOT and DOT:
Calculation: 
exchangeRate=Staked+RewardstotalXDOTexchangeRate =\frac{ Staked + Rewards}{ totalXDOT}exchangeRate=totalXDOTStaked+Rewards​
totalStakingAmout is the sum of initial staked assets with compound interest.
totalXDOT is the sum of xDOT up to now.
Instant Unstaking Pool
To mitigate the unbonding period, Parallel protocol proposes a funding pool that is subtracted from the totalStakingAmout. The fund in this pool can be redeemed by users with xDOT instantly. The quota each holder has available to use is proportional to the xDOT holdings per day, and holders can only redeem once from the instant pool per day. If holders want a higher quota, they can open an offer expressed as (xDOT, endingBlock, fees) in the market. Other holders with available quota can accept the instant redemption, and transfer DOT to the offer provider. The maker gets xDOT in the offer, and earns the fees. Partial offer fulfillment is also supported.
To maintain such a liquidity pool, the holdings of each stash account need to bond_extra/unbond/rebond regularly to meet the healthy threshold.
instantPoolFund / totalStakingAmout < threshold, withdraw_unbonded from stash accounts. And if it needs more then signal unbonding.
instantPoolFund / totalStakingAmount > threshold, transfer extra and signal bond_extra.
instantPoolFund / totalStakingAmount = threshold, signal rebond.
Here totalStakingAmount is the sum of instantPoolFund and the under-staking funds controlled by all stash accounts. Threshold can be configurable by governance. Stash accounts regularly unbonding and rebond each day to maintain cash flow, if unbonding signal increase cash percentage, otherwise decrease cash percentage.
5. Interest Lending Pool with Bounded Rate 
Parallel's system account can borrow DOT from the pool without collateral, and it won't be liquidated. To maintain the liquidity, the system's accounts can't borrow anymore if the utilization ratio is higher than a specific threshold, say 80%. It also starts unbonding staked tokens and repays the outstandings to maintain healthy liquidity in the pool. To mitigate the attack vector on the limited ROI of staking, the interested rate of such a pool is bounded to not exceed the evaluated ROI of staking, which is around 7.5% on Kusama.
6. Slash Insurance
A slash can still happen if a validator misbehaves, or there is an outage of many validators. Holders can purchase insurance for their holdings that last for a defined period. Partial fees of Parallel's staking protocol will be deposited into the insurance fund and accumulated. If a slash happens, the insurance beneficiary can get compensation from the fund. The cap of the compensation is defined by governance.
V. Governance
1. Overview
Parallel protocol is designed to be a fully decentralized financial platform that can serve millions of users and most of them may not be well off. On Parallel, there are 4 kinds of stakeholders,
the development team and open contributors
investors with Parallel's native token
a wealth of platform users
network maintainers
The governance process should incentivize each party to participate in the network activity and evolve the protocol to meet the broad users' requirements.
2. Parallel Native Token
At the early stage of Parallel's network, the native token can be used as an incentive to onboard users, raise funds from investors, and reward the development team and open contributors. In the end, these are the necessary operational overhead costs.
3. User Reputation
In the vision of Parallel, the Web3.0 translates to how much power the general users can exercise. Parallel designs a calculation method to make the reputation of each user as fairly as possible.
TradingScore=c⋅(1−1/x)TradingScore = c \cdot  (1 - 1/x)TradingScore=c⋅(1−1/x)
TradingScore: the base score of each user who trades on the platform
c: a constant, shows the highest score a user can reach by trading
x: numbers of trades
A user can follow another users, the followed user gets an extra score,
FollowedScore=p⋅TradingScoreFollowedScore = p \cdot  TradingScoreFollowedScore=p⋅TradingScore
p: a percentage
TradingScore: the following user's TradingScore
FollowedScore: can be accumulated and should not exceed 2 times of its own TradingScore.
A user can follow no more than 16 other users, and can't follow himself. Following other users should also include making a security deposit.
The total score will fade along with time if no trade happens.
TotalScore=TradingScore+FollowedScorenow−lastTradeTimeTotalScore =\frac{ TradingScore + FollowedScore}{ now - lastTradeTime}TotalScore=now−lastTradeTimeTradingScore+FollowedScore​
4 Democracy
The core logic of Parallel protocol is wrapped as a blockchain runtime. Thanks to Substrate, the runtime can be easily upgraded without a network fork or a choke. To make the upgrade meet the expectation of all the above stakeholders, every runtime upgrade will be voted on by the network participants with native tokens and with reputation.
TotalVotingPower=p/t⋅Sum(TokensVoted⋅LockedPeriod)+TotalVotingPower = p / t \cdot  Sum(TokensVoted \cdot  LockedPeriod) +TotalVotingPower=p/t⋅Sum(TokensVoted⋅LockedPeriod)+
(1−p/t)⋅Sum(c⋅Reputation) (1 - p / t) \cdot  Sum(c \cdot  Reputation)(1−p/t)⋅Sum(c⋅Reputation)
TotalVotingPower: the voted score of a specific democracy proposal.
TokensVoted: the tokens a single user voted with for the proposal.
LockedPeriod: the period the user wants to lock, if the proposal exercised.
p: percentage of the tokens' power, faded along with time no matter what.
c: conversion rate between the token and reputation.
If a proposal gets more ayes than vetos after the voting period ends, it will be scheduled with an on-chain deployment.
5. Council
The council performs daily affairs like:
configuring the adjustable parameters of Parallel protocol
interest rate model per market
addition or removal of a market
addition or removal of backed validators
the reserve fees of the platform
making emergency calls
canceling slash scenarios
approving the Treasury proposals
making tips to contributions, etc
The council member is elected by the token holders, and users with a reputation.
6. Treasury
Parallel charges a small fee for each deal. These fees go into the Treasury directly. The fee aims to fund the ecosystem, and to create healthy growth. Teams make spending proposals, and council members approve or disapprove of them. Council members can also tip the known contributions with a small number of native tokens.
VI. Summary
Parallel introduces a decentralized lending protocol with a floating interest rate determined by the underlying assets' supply and demand. The staking protocol also provides liquidity to bonding assets in the Polkadot ecosystem. Parallel balances the competition between staking and DeFi rewards to solve the usability issue for the representation token (xDOT). Finally, we hope to achieve more incredible benefits for users through double interest.
VII. Reference
1.
Polkadot Network https://polkadot.network/​
2.
Compound https://compound.finance/​
3.
Parachains https://wiki.polkadot.network/docs/en/learn-parachains​
4.
NPoS Staking https://research.web3.foundation/en/latest/polkadot/NPoS/index.html​
5.
On-chain Governance https://wiki.polkadot.network/docs/en/learn-governance​
6.
Cross-chain Message Passing (XCMP) https://research.web3.foundation/en/latest/polkadot/XCMP.html​
7.
Aave Liquidations https://docs.aave.com/developers/guides/liquidations​
8.
Faster Liquidations Improve Capital Efficiency  https://medium.com/liquity/how-faster-liquidations-improve-capital-efficiency-5589174f75c0​
9.
Introducing the Coinbase price oracle  https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068 
10.
Decentralized Data Model https://docs.chain.link/docs/architecture-decentralized-model​
11.
Off-Chain Reporting https://docs.chain.link/docs/off-chain-reporting​
​
Getting Started
Heiko Finance White Paper
Last modified 3mo ago
Ⅰ. Abstract

Ⅱ. Introduction

Ⅲ. Lending Protocol

1. Overview

1.1 Supplying Tokens

1.2 Borrowing Tokens

2. Interest Rate Model

2.1 Internal Exchange Rate

2.2 Interest Rate Model Principle

2.3 Borrow Interest Rate

​

2.4 Borrow Interest Rate Parameters

2.5 Supply Interest Rate

2.6 Interest Rate Index

3. Experimental Models

3.1 Curve Interest Rate Model

3.2 Interest Rate Adjustment Mechanism

4. Liquidation

4.1 Auto Liquidation Algorithm

4.2 On-Chain Liquidation Pool

4.3 Flash Liquidation

5. Oracle and Price feed

5.1 Off-chain Price Fetching

5.2 On-chain Aggregation Strategy

IV. Staking Protocol

1. Overview

2. Validator Choosing Strategy

3. Nomination Workflow

4. Delegated Staking

5. Interest Lending Pool with Bounded Rate

6. Slash Insurance

V. Governance

1. Overview

2. Parallel Native Token

3. User Reputation

4 Democracy

5. Council

6. Treasury

VI. Summary

VII. Reference
