├── .gitignore ├── README.md ├── TrueFi2.0.md ├── images ├── LoanToken Lifecycle.png └── TrueFi Product Flows.svg └── roadmap.md /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | .DS_STORE -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # TrueFi Specification 2 | 3 | [TrueFi 2.0 Specification](TrueFi2.0.md) 4 | 5 | TrueFi is a protocol for creating interest bearing pools with a high APR for liquidity providers. TrueFi includes a utility and rewards mechanisms using TrueFi tokens (TRU) and rewards participants for maintaining stable, high APRs. Un-collateralized loans and decentralized lending are utilized in order to achieve high interest rates for pools. 6 | 7 | TrueFi is a product that we are actively designing and this document is intended to act as a plan and specification for design. TrueFi is being developed by [TrustLabs](https://www.trusttoken.com/) in partnership with [EthWorks](https://ethworks.io/). TrueFi is aiming to be released on Ethereum mainnet November 21st 2020. 8 | 9 | ### Terminology 10 | 11 | **Token** - An ERC20 token running on the Ethereum blockchain. 12 | **Stablecoin** - A token which is pegged to another asset. 13 | **DeFi** - Decentralized finance using smart contracts. 14 | **Pool** - A smart contract which allows accounts to pool tokens with the goal of earning interest. 15 | **Deposit Tokens** - Tokens deposited into a pool which are used to earn interest through lending or arbitrage opportunities. 16 | **Pool Tokens** - Tokens issued by a pool to represent share in the pool's deposit tokens. 17 | **TrueFi Token** - An ERC20 token used to provide utility in the TrueFi ecosystem. 18 | **TrueUSD** - A stablecoin used frequently in TrueFi to provide liquidity. 19 | **Prediction Market** - Exchange-traded market created for the purpose of trading the outcome of events. 20 | 21 | # Overview 22 | 23 | A lot of DeFi’s success so far has been built on collateralized lending. Platforms such as Compound, AAVE, and Maker have created a solid foundation which allows cryptocurrency holders to earn high interest rates in a permissionless manner. However, there is a massive opportunity for uncollateralized loans to yield even higher interest rates than existing collateralized lending protocols. Innovative projects such as AAVE are already building tools in this direction [credit delegation](https://docs.aave.com/developers/developing-on-aave/the-protocol/credit-delegation). 24 | 25 | Based on a small survey of partners, TrustLabs found that reputable institutions and crypto hedge funds funds are willing to offer 8-12% interest rates for large un-collateralized stablecoin loans. These rates are higher than what’s available in DeFi today, primarily because DeFi today does almost exclusively collateralized lending (which borrowers will systematically pay less for). Most retail investors do not have access to invest in funds of this type because their check size is too small. By sourcing funds via deposits in a smart contract, TrueFi can open up uncollateralized lending opportunities to investors of any size. 26 | 27 | TrueFi consists of four major pieces: 28 | 1. Tokenized Loans 29 | 2. Lending Pools 30 | 3. Credit Prediction Market 31 | 4. TrueFi Token (TRU) 32 | 33 | ### Tokenized Loans (LoanToken) 34 | 35 | A LoanToken is an ERC20 contract which represents the lender share of an uncollateralized loan. LoanTokens are an important building block of TrueFi, as they can operate independently from the TrueFi pools. Tokenized loans open up opportunities for secondary markets, though TrueFi will initially not allow for the transfer of LoanTokens. 36 | 37 | Creating a LoanToken requires a borrower address, principal loan amount, loan length, and interest rate. Users mint LoanTokens by depositing funds into the token contract, and the minted tokens represent a share in the funds repaid plus interest at the end of the term. LoanTokens are minted at a discounted rate, meaning for every $1 deposited, $1 + ($1 * rate * term) tokens are minted. Once a loan is funded, the borrower can call a function which allows them to borrow the funds from the smart contract. The borrower pays funds back, and at the end of the term LoanToken holders can exchange their LoanTokens 1:1 for their original funds plus interest. 38 | 39 | ### Lending Pools (TrueFi Pools) 40 | 41 | A Lending pool is an ERC20 contract with additional functions to support providing liquidity and staking TrustTokens. Lending Pools are another building block of TrueFi, allowing pool depositors to receive pool tokens which represent their share of a pool. Lending pools decide based on a set of rules which borrowers to fund, and thus chooses which LoanTokens to fund. 42 | 43 | Initially TrueFi will have a single lending pool. This pool will act as a pilot for future pools, and will only lend to a whitelist of trusted borrowers 44 | 45 | TrueFi can offer an interest rate that is at least as high as the highest stable rate available in DeFi today by depositing unused funds into existing defi protocols. TrueFi will only make loans when the proposed rate exceeds the rate offered by the selected defi protocol. 46 | 47 | ### Credit Prediction Market 48 | 49 | How can loans with no collateral be built on an anonymous platform such as Ethereum? TrueFi uses a prediction market to rate the credit worthiness of borrowers. Participants are rewarded for choosing borrowers that pay back their loans with high interest. Incorrectly predicting the outcome of a loan will cause funds to be lost. 50 | 51 | The prediction market operates independently of the TrueFi pools. The only goal of this market is to try to accurately assess the likelihood a LoanToken will be paid back in full. It is up to third parties or TrueFi pools to decide to fund the LoanTokens. The TrueFi Credit Prediction Market will help expand credit to wide set of borrowers as its systems for assessing and managing risk become more sophisticated. 52 | 53 | ### TrustToken (TRU) 54 | 55 | What is the purpose of TrustTokens in the context of TrueFi? TrustToken holders ultimately have say over who is a credible borrower in the prediction market. TRU gives holder the ability to rate credit for third parties. Currently the United States relies on a very small set of rating agencies, which are notoriously lack transparency and security. Through TRU credit rating, a permissionless system of credit can be built which operates purely through incentives. 56 | 57 | TrueFi will use TrustToken incentive rewards to bootstrap growth. Early adopters and liquidity providers are distributed TRU for participating in TrueFi. These participants can then use TRU in the credit prediction market, and have part ownership in building a new credit system. 58 | 59 | # Philosophy - Progressive Decentralization 60 | 61 | TrustLab's mission is to make financial freedom as accessible as the internet and open access to financial opportunities. 62 | 63 | In line with this philosophy, TrueFi will be built on the concept of progressive decentralization. Initially, the focus of TrueFi development will be to bootstrap the protocol and distribute TRU to the community of users and developers who participate in the protocol. The second phase will consist of automation and decentralization. Therefore the initial specification is rigid, with conservative parameters such as minimum/maximum APY and high TRU participation factor. It's important to remove these stops as the system grows. 64 | 65 | The long term goal of TrueFi is to become a market-driven, automated credit rating and lending system. Uncollateralized loans are extremely high risk, and building a permissionless solution to create these kinds of loans is very difficult. Therefore TrueFi will be launched with strict parameters and place the majority of the risk on TrustLabs and early adopters. 66 | 67 | # Technical Details 68 | 69 | ## LoanToken 70 | 71 | ### LoanToken Parameters 72 | - rate (APY) 73 | - term 74 | - amount 75 | - borrower 76 | 77 | ### LoanToken Lifecycle 78 | 79 | #### I. Fundraising 80 | - Mint/Burn Loan Tokens is enabled 81 | - Depositors can send deposit tokens to contract 82 | -> mint LoanTokens according to discount rate model 83 | - Can never deposit more than the principal 84 | -> Return amount over principal if sending more than principal 85 | - Fundraising is complete once we reach principal amount 86 | - During fundraising, can exchange LoanTokens for deposit tokens 87 | -> Funds aren't locked until Lending Phase 88 | 89 | #### II. "Approval" 90 | - Once smart contract has raised the principal amount of deposit tokens: 91 | -> Borrower can call a function to approve the loan 92 | -> Approving the loan withdraws funds to borrower address 93 | -> Loan expiry is set to: block.timestamp + length 94 | -> Mint/Burning Loan tokens is disabled 95 | 96 | #### III. "Lending" 97 | - Here we're waiting for block timestamp > expiry 98 | - Mint/Burning Loan tokens is disabled 99 | - Borrower can pay back deposit tokens at any time (but cannot withdraw) 100 | 101 | #### IIII. "Complete" 102 | - Once block timestamp > expiry, we enter the complete phase 103 | - Burning enabled (Minting disabled) 104 | - LoanTokens can be burned in exchange for a share of the deposit tokens in contract 105 | - Ideally borrower would have paid back (principal + principal * rate) 106 | 107 | ## Credit Prediction Market 108 | 109 | TrueFi uses use a prediction market to signal how risky a loan is. The Credit Prediction Market estimates the likelihood of a loan defaulting. Any TRU holder can vote YES or NO and stake TRU as collateral on their vote. If a loan is funded, TRU is locked into the market until the loan enters the complete phase. Locking TRU into the prediction market allows voters to earn and claim incentive TRU throughout the course of the loan. After the loan's term, if the voter is correct, they earn a TRU reward plus a portion of the losing side's vote. Lenders can use the credit prediction market as an indicator as to how safe or risky a given loan is. 110 | 111 | ### Voting Lifecycle 112 | - Borrowers can apply for loans at any time by deploying a LoanToken 113 | - LoanTokens are registered with the prediction market contract 114 | - Once registered, TRU holders can vote at any time 115 | - If a loan is funded, TRU is locked for the term of the loan 116 | - At the end of the term, the amount paid back is recorded, and payouts are determined based on the outcome 117 | 118 | ### Applying for A Credit Rating 119 | 120 | To receive a credit rating on a loan, a borrower deploys a LoanToken with parameters and calls a function on the credit market contract. Once applied, TRU holders can vote on loans. The ratio of YES to NO voters is a signal 121 | 122 | ### Loan Outcomes 123 | 124 | A borrower can pay back their loan at any time before the end of the term. Borrowers are expected to pay back principal + (principal * interest). If they return the full amount including interest, TrustToken voters that voted YES on the proposal receive a reward. If they fail to return the full amount including interest, TrustToken voters that voted YES on the proposal will have some of their TrustTokens burned. 125 | 126 | ### Staking Rewards and Payouts 127 | 128 | Two ways you get TRU by voting: 129 | - Reward over time for participation 130 | - Payout of prediction market 131 | 132 | Creating good staking payouts is difficult as creating too much of a reward for voting YES or NO could cause participants to always vote YES or NO. Creating too much of a punishment for losing could also cause nobody to participate in the rating system. For this reason, all participation is rewarded equally through TRU incentive distribution. In addition, a few adjustable factors are set up to adjust the punishment from losing the vote. 133 | 134 | #### Rewards 135 | 136 | Rewards are paid out proportionally to all participants, favoring participation in ranking higher interest loans by weighting rewards based on the total interest that would be paid over the course of a loan. Current reward can be claimed at any time so that there is more value to staking (rather than having to wait until the end of a loan). 137 | 138 | `chi = (TRU remaining in distributor) / (Total TRU allocated for distribution)` 139 | 140 | `interest = (loan APY * term * principal)` 141 | 142 | `R = Total Reward = (interest * chi)` 143 | 144 | - R is distributed to voters based on their proportion of votes/total_votes 145 | - Voters can claim their proportion based on time. 146 | 147 | `Claimable reward = R * (current time / total time) * (account TRU staked / total TRU staked) - (amount claimed)` 148 | 149 | #### Payouts 150 | 151 | After the expiry, a portion of the loser's TRU is paid out to the winner, and a portion of the loser's TRU is burned. A few factor in the prediction market contract help determine the payout: 152 | 153 | **lose factor:** % of TRU paid from the losing side to the winning side 154 | **burn factor:** % of lost TRU burned 155 | 156 | Initial factors will be set as follows: 157 | 158 | **lose factor:** 0.25 159 | **burn factor:** 0.25 160 | 161 | ## TrueFi Lending Pool 162 | 163 | The Lending Pool is a TrueFi pool which exposes depositors to un-collateralized loans. A select set of institutional borrowers will be chosen for this pool in order to keep the pool initially secure. Borrower addresses will be whitelisted and will be the only addresses which can be approved for loans. The pool will purchase LoanTokens based on a set of parameters. A function can be called passing in a LoanToken address, and if the LoanToken meets the pool criteria, the loan is approved and the pool funds are used to fund the loan. 164 | 165 | Capital that is not actively being loaned out will be used to provide liquidity in audited, high-interest rate defi smart contracts (such as Aave or curve.fi). 166 | 167 | #### Lending Pool Parameters: 168 | - minLoan: Minimum Loan Size 169 | - maxLoan: Maximum Loan Size 170 | - minRate: Minimum Loan APY 171 | - maxRate: Maximum Loan APY 172 | - minTerm: Minimum Term Length 173 | - maxTerm: Maximum Term Length 174 | - fee: Percentage Fee 175 | - riskAversion: Risk Aversion Factor Based on Expected Value 176 | - participationFactor: How Many Votes Required to Approve 177 | 178 | **riskAversion:** Measures how much worse it is to lose $1 than it is to gain $1. 179 | **participationFactor:** Ratio of # of TRU staked on loan to size of loan. 180 | 181 | ### Lending Pool Behavior 182 | - Whitelist borrowers 183 | - Borrowers register loan tokens with prediction market 184 | - Window of time where borrowers 185 | - Window of time where TRU holders can vote 186 | - Loans not approved refunds TRU 187 | - Proposals can be revoked by borrower 188 | 189 | #### Default Parameters 190 | 191 | The Lending Pool will have several initial parameters: 192 | 193 | - Risk Aversion: 1.0 194 | - participation: 1.0 195 | - Minimum loan size: 1M TUSD 196 | - Maximum loan size: 10M TUSD 197 | - Minimum % APR: 10% 198 | - Maximum % APR: 30% 199 | - Minimum Term: 1 day 200 | - Maximum Term: 30 days 201 | - Fee: 0.25% 202 | - Assets: TUSD only 203 | - Idle Funds usage: 100% CRV 204 | 205 | ### Loan Approval Calculation 206 | - Loan is approved if and only if `EV > 0` 207 | - `EV = (upside * probability_paid_back) - (downside * risk_aversion * probability_of_default)` 208 | - `upside = APY * loan_size * term` 209 | - `downside = loan_size` 210 | - `probability_of_default = no_votes / (no_votes + yes_votes)` 211 | - `probability_paid_back = yes_votes / (no_votes + yes_votes)` 212 | 213 | ## TRU Distribution 214 | 215 | 39% of TRU will be distributed to liquidity providers (LPs) over 4 years. The TRU intended to be distributed to LPs will be sent to a smart contract which is owned by a multisig. The multisig will have control over the smart contract, otherwise the tokens cannot be spent. The multisig can approve transfers to smart contracts which will hold funds for liquidity mining. 216 | 217 | Max Token Supply: 1,450,000,000 218 | 219 | | | | | | 220 | |-----------------|---------|---------------|-------------------| 221 | | Private Sale | 28.64% | 415,314,034 | 2 year unlocking [1] | 222 | | Team | 18.50% | 268,250,000 | 2 year unlocking [1] | 223 | | Future Team | 4.50% | 65,250,000 | 2 year vesting | 224 | | Incentive | 39.00% | 565,500,000 | LPs & stakers | 225 | | Company | 9.36% | 135,685,966 | 1/3 Unlocked, 2/3 unlocking [2]| 226 | | | | | | 227 | 228 | [1] Private sale tokens and Team tokens unlock quarterly beginning on November 21, 2020. The eight unlock dates are November 21, 2020, February 19, 2021, May 20, 2021, August 18, 2021, November 16, 2021, February 14, 2022, May 15, 2022, August 13, 2022. 229 | 230 | [2] The company tokens unlock 1/3 immediately to be able to support initial liquidity. Another 1/3 unlocks on November 21, 2021. The Final 1/3 unlocks on November 22, 2022. 231 | 232 | ## Liquidity Mining 233 | 234 | Of the 565M TRU to be used for incentives, we plan on distributing through multiple channels: 235 | 236 | | | | | | 237 | |--------|-----------------|-------------|---------------| 238 | | | Third Party LPs | TrueFi LPs | TRU Stakers | 239 | | Ratio | 0.25 | 0.3 | 0.45 | 240 | | Time | 1-12 Months | 4 years | 4 years | 241 | | Total | 141,375,000 | 169,650,000 | 254,475,000 | 242 | | | | | | 243 | 244 | These values were chosen in order to distribute TRU to early adopters of the protocol, and incentivise providing liquidity for TRU pairs on DEXs such as Uniswap and Balancer in the short term. We also want to reward long term users of the protocol by providing the majority of incentive distribution to users of TrueFi. 245 | 246 | There will be two types of distributions: one for providing liquidity on external market making protocols, and one for providing liquidity on TrueFi. These will be handled with similar but slightly different mechanisms. 247 | 248 | To farm TRU by providing liquidity outside of TrueFi, LP tokens need to be staked in exchange for farm tokens (see below). Holders of farm tokens can claim rewards in TRU as incentive for providing liquidity on external markets. These markets are: 249 | 250 | - Uniswap ETH/TRU 251 | - Uniswap TrueFi-LP / TUSD 252 | - Balancer 95% BAL / 5% TRU 253 | 254 | #### Balancer 95% BAL / 5% TRU 255 | - Meant to be the highest yield pool for the shortest amount of time. BAL holders can use BAL to farm TRU. 256 | 257 | #### Uniswap ETH/TRU 258 | - Incentivise TRU liquidity versus ETH. ETH holders can farm TRU using ETH with upside to both. 259 | 260 | #### UNI TUSD/TFI-LP 261 | - Provide liquidity for swapping pool tokens and TUSD. Useful for small investors that need TUSD liquidity going in/out of the pool. 262 | 263 | - Also the pool that should give the most yield for LPs. Earn yield through TrueFi, Uniswap fees, and TRU rewards. 264 | 265 | #### TrueFi LP (TFI-LP) 266 | - Incentivise depositing TUSD into the TrueFi Pool. Lowest yield but longest distribution of 4 years. 267 | 268 | #### TRU Staking 269 | - Variable reward incentivises voting on loans and rating credit. 270 | 271 | - Distributes the highest total amount of TRU. 272 | 273 | To farm TRU by providing liquidity within TrueFi, accounts will simply deposit tokens into one of the TrueFi pools. In addition to providing liquidity, TRU holders can stake TRU and vote to approve/disapprove loans within the LendingPool. Ways to farm TRU on TruFi include: 274 | 275 | - Providing Liquidity for a TrueFi pool 276 | - Voting & staking on loans in the Lending pool 277 | 278 | ## Distribution Smart Contracts 279 | 280 | LP tokens such as pool tokens, Uniswap LP tokens, etc. can be staked on any TrueFarm contract to earn TRU. Depositors of LP Tokens will be able to claim TRU rewards for staking. 281 | 282 | ### TrueFarm Contract 283 | 284 | A TrueFarm contract is an interface which allows any smart contract to reward TRU. 285 | 286 | ### Distributor Contract 287 | 288 | The distributor contract will be transferred the portion of TRU intended to be distributed. This ensures that the supply is permanently locked into the contract and can help calculate the circulating supply for oracles and price-tracking websites (such as CoinGecko or CoinMarketCap). The contract will only allow a certain amount of TRU to be withdrawn for distribution based on a function, guaranteeing the distribution formula is set over time. 289 | 290 | ### Future Incentives & Considerations 291 | 292 | Because TRU distribution will eventually run out, an alternative to reward voters on successful loans could be to award a percentage of the loan interest to stakers, thus creating an incentive to continue voting after TRU is distributed. Another option could be to introduce an inflationary model. 293 | -------------------------------------------------------------------------------- /TrueFi2.0.md: -------------------------------------------------------------------------------- 1 | # TrueFi 2.0 Specification 2 | 3 | TrueFi v2 is a series of upgrades to the original TrueFi specification. These upgrades improve and overhaul the TrueFi lending product, and focus on value accrual, decentralization, and automation. As the TrueFi roadmap is developed, upgrades will be made in phases synchronized with unlocked tokens entering circulation. 4 | 5 | [Original Specification (Phase 1)](README.md) 6 | 7 | ### Terminology 8 | 9 | **TRU Staking** - Depositing TRU into a smart contract in exchange for protocol fees and rewards. 10 | **stkTRU** - An ERC20 token which represents a share in the TRU staking pool. 11 | **tfLP** - An ERC20 token which represents a share of the TrueFi lending pool. 12 | **Liquidity Provider** - A party which provides liquidity to the TrueFi lending pool. 13 | **TRU Governance** - Decentralized voting using TRU to adjust protocol parameters and make upgrades. 14 | 15 | # Phase 2 16 | 17 | Phase 2 will focus on value accrual for TRU holders and protocol governance. This phase will include a staking and governance smart contract. In this phase ownership of TrueFi will be transferred from the current multisig contract to a timelock contract. The staking contract will allow TRU holders to stake TRU to earn a share of loan origination fees. 18 | 19 | ## Staking 20 | 21 | A staking functionality will be added which allows TRU holders to stake TRU in exchange for protocol fees. Depositing TRU into the staking contract will mint a new token for the staker called stkTRU. stkTRU is a standard ERC20 token that represents the depositor's share of the stkTRU pool. Holding stkTRU entitles an account to rewards for holding the asset over time. Rewards are claimed in the form of tfLP tokens and TRU. 22 | 23 | Users will no longer rate loans with TRU directly, but rather will rate using stkTRU. stkTRU holders are taking on a blended risk of all loans. In essence, they are staking on the security of the borrower approval process. Raters will earn a small TRU reward when participating in the rating process. 24 | If a loan is passed, all stakers earn the origination fee. In the future, when TrueFi moves to open-term loans, stakers will be entitled to origination fees and (upon governance approval) a percentage of the interest revenue. 25 | 26 | 100% of origination fees (in the form of tfLP) will go towards stakers. In addition, stakers will receive TRU incentives every block. In the future when open-term loans are implemented, stakers may also receive a % of the interest generated. Stakers who vote on loans will also receive additional TRU incentives. 27 | 28 | TRU staked in the protocol will be used as collateral in the case of loan defaults. In a default scenario, up to 10% of all staked TRU will be used to cover losses in the TrueFi pool. TRU stakers are taking on the risk of loan defaults in the protocol in exchange for the staking rewards. The percentage of TRU lost due to a default can be adjusted by governance. Liquidation events are determined automatically whenever a loan defaults. 29 | 30 | In order to ensure stakers are committed to taking on the risk of loans defaulting, a 14 day cooldown will be required for unstaking. This ensures stakers cannot unstake right before a default event. To ensure fees from loans are paid fairly, 50% of origination fees are paid at the start of the loan, and 50% are paid when the loan is successfully repaid. This fee split incentivises stakers to be actively staked when a loan might default, and rewards stakers that hold stkTRU for a long period of time. 31 | 32 | ### Staking Parameters 33 | - 14 day cooldown for unstaking 34 | - 2 day window to unstake after cooldown 35 | - Staking more during cooldown increases cooldown time 36 | - Maximum 10% penalty on loan defaults 37 | - 100% origination fees to all stakers 38 | - stkTRU required to approve loans 39 | - 50% of fees paid at start of loan 40 | - 50% of fees paid when loan is repaid 41 | 42 | ## Governance 43 | 44 | Governance in the TrueFi ecosystem is critical to achieving full decentralization. Currently the smart contracts are owned by a multisig, and upgrades are decided on via forum discussion and snapshot voting. Upgrades are then executed by multisig members. Holders of both TRU and stkTRU will be able to vote in governance. Governance will decide when to adjust protocol parameters or make smart contract upgrades. 45 | 46 | Important aspects of governance are as follows: 47 | * Governance ownership of smart contracts 48 | * Creating & voting on proposals 49 | * Executing code on-chain 50 | * Allowing for voting using both TRU and staked TRU 51 | 52 | Differences from Compound include: 53 | * Ability to delegate votes with TRU and staked TRU 54 | * Disallowing voting with locked TRU 55 | 56 | ### Governance Parameters 57 | 58 | * Voting period: 3 days 59 | * Proposal threshold: 100,000 TRU/stkTRU 60 | * Min & Max Time-lock delay: 2 days * 30 days 61 | * Quorum Votes: 10,000,000 62 | * Proxy contract & governance will be upgradable, subject to governance 63 | * Will have a ‘guardian’ at first 64 | * Guardian can be set to 0 through governance vote 65 | * Governance will be the timelock admin 66 | 67 | # Phase 3 68 | 69 | ## SUMMARY: 70 | Phase 3 will focus on overhauling how uncollateralized lending works in TrueFi. 71 | 72 | The first major upgrade will introduce multi-asset borrowing and liquidity pools for multiple assets. A new asset pool is created by passing an ERC20 token to a factory. This factory will deploy a new pool, and allow the TrueLender contract to borrow directly from this pool. LoanTokens can now support any ERC20 token and borrowers will repay the borrowed asset to the LoanToken contract when a loan term is completed. Each pool will have its own strategy for lending idle assets to other defi protocols to maximize yield. 73 | 74 | ## MULTI-ASSET BORROWING 75 | 76 | - Create lending pools for any ERC20 token. 77 | - Borrowers can apply to borrow one asset at a time 78 | 79 | ### Smart Contracts 80 | 81 | #### TrueFiPoolFactory 82 | * owner can update a whitelist which allows certain tokens 83 | * new function: create(address token) 84 | * create() deploys a new TrueFiPool 85 | * create() registers new pool address 86 | * create() can only create one pool per ERC20 token 87 | * create() defaults to using no TrueFiStrategy 88 | * public mapping of token address => pool address 89 | * support precision of new tokens 90 | * pool value is denominated in tokens (1.01 price = 1.01 ETH) 91 | * ability to add price feed 92 | 93 | #### TrueFiPool & TrueFiStrategy 94 | * Pools will now include a TrueFiStrategy smart contract 95 | * TrueFiStrategy is allowed to store idle funds in other defi contracts 96 | * Pools all use liquidExit() as calculated the same way 97 | * Use governance to add pools to the full TrueFi system 98 | * Use governance to set TrueFiStrategy for a given pool 99 | 100 | #### TrueLender 101 | * withdraw from any TrueFi pool 102 | * each loan has a single asset 103 | * reclaim() transfers asset back to its respective asset pool 104 | * TrueLender handles liquidations and transfers TRU to the asset pool a default occurred in 105 | * Need a mapping (address => parameters) to track lending params 106 | * register() function which sets up a new pool with default params 107 | * need to calculate the amount of votes differently 108 | 109 | #### LoanToken 110 | * each LoanToken has a stored asset() that returns address of ERC20 borrowed 111 | * call repay() to automatically pay back the loan with asset 112 | * burning LoanTokens returns asset 113 | * support precision of new tokens 114 | 115 | #### TrueRatingAgency 116 | * LoanTokens are created for specific assets and registered with TrueRatingAgency 117 | * Keep incentives the same for rating any loan 118 | * Store LoanTokens in same array we currently are 119 | 120 | #### TrueFiStrategy 121 | * allows transferring idle funds into defi opportunities 122 | * withdraw idle funds, deposit into defi opportunity, transfer tokens to pool 123 | * move funds out of opportunity when borrowers withdraw 124 | 125 | ### Liquidator 126 | * In liquidate function, check LoanToken asset type, transfer slashed TRU to respective pool 127 | * Support multiple price feeds for Liquidator 128 | * Governance decides what pools liquidator can track 129 | 130 | # Phase 4 131 | 132 | Phase 4 overhauls handling defaults and adds automatic interest rate pricing for borrowers. This phase is the most significant update for TrueFi and will likely be what the protocol looks like in the long term. Phase 4 also moves all farming to a single Liquidity Gauge contract to handle scaling farms in TrueFi. 133 | 134 | ## Liquidity Gauge / TrueMultiFarm 135 | A smart contract will launch which will replace the existing tfLP farms. Any valid tfLP token can be staked here. Each valid pool is assigned a weight, and distribution is weighted based on governance allocation of weights. At first all pools will be weighted equally. All current tfLP farm incentives will be migrated to the Liquidity Gauge. In this phase, snapshot votes will decide the allocation points, and a single weekly distribution of TRU for all farms. This model greatly simplifies farming TRU and scales for any number of assets. 136 | 137 | ## SAFU (Secure Asset Fund for Users) 138 | 139 | The SAFU is an overhaul of how TrueFi handles borrower defaults. In Phase 4, the SAFU contract is responsible for all bad debt accrued by the protocol. The SAFU can be funded by external parties and will use its funds to help cover defaults. When a default occurs, TrueFi Lending Pools transfer all bad debt assets to the SAFU in exchange for the full expected value of those assets. The SAFU is responsible for slashing staked TRU tokens, up to 10% of the defaulted amount. If the value of these tokens is not enough to cover the default the SAFU can use its own funds to help repay the lending pool for lost funds. 140 | 141 | ### Handling Defaults for Fixed Term Loans 142 | 143 | In the event of a default, the following occurs: 144 | 1. Up to 10% of TRU is slashed from the staking pool and transferred to SAFU to cover the amount of default, equal to principal amount plus full amount of expected interest (“Defaulted Amount”) 145 | 2. All LoanTokens for the defaulted loan are transferred from the Lending Pool to the SAFU 146 | 3. If the current SAFU funds are insufficient to cover the Defaulted Amount: 147 | - SAFU can sell TRU for the respective borrowed asset at its manager’s discretion 148 | 4. If the value of the SAFU funds(“Assurance Fund”) can not satisfy the Defaulted Amount: 149 | - The difference between the Defaulted Amount and the Assurance Fund is calculated (“Uncovered Amount”) 150 | - SAFU mints ERC-20 tokens representing claim for the Uncovered Amount (“Deficiency Claim”) 151 | - Lending Pool receives a Deficiency Claim for the Uncovered Amount assuming successful recovery 152 | - Lending Pool has a first priority claim on funds recouped through arbitration for the Deficiency Claim amount 153 | 5. If a debt is repaid: 154 | - The recouped funds will be used to purchase the asset that the Loan Token was originally denominated in, which will be transferred to the LoanToken contract 155 | - SAFU burns Loan Tokens for the underlying value of those tokens (“Recovered Amount”) 156 | - SAFU repurchases Deficiency Claim tokens from the Lending Pool up to the Recovered Amount 157 | - If there are additional recovered funds after repurchasing the Lending Pool’s Deficiency Claim, the SAFU keeps those remaining funds 158 | 6. If any portion of the original loan amount is not repaid after the completion of the legal recovery process: 159 | - Lending Pool’s remaining Deficiency Claim tokens are burned (decrease LP price) 160 | 161 | ### Default Algorithm 162 | 163 | ``` 164 | Smart Contracts: 165 | Liquidity Pool 166 | Staking Pool 167 | SAFU 168 | LoanToken 169 | StableCoin Token 170 | TRU Token 171 | DeficiencyToken 172 | Arbitration 173 | 174 | Variables: 175 | L = Expected Value of LoanToken in Liquidity Pool 176 | P = Amount of Loan Value Repaid 177 | μ = Ratio of LoanTokens held in pool to total LoanToken supply 178 | S = StableCoin Balance in SAFU 179 | D = Loan Deficit = L - P 180 | R = Remaining USD Deficit 181 | T = Balance of TRU in Staking Pool 182 | U = USD Price of TRU 183 | K = Slash Ratio of Staking Pool 184 | M = Max USD Staking Coverage = U * T * K 185 | Y = Arbitration Repayment Amount 186 | 187 | Algorithm: 188 | 1. Transfer L LoanToken from Liquidity Pool to SAFU 189 | 2. Calculate Loan Deficit 190 | D = L - μP 191 | 3. Slash TRU 192 | a. Calculate Max Staking Coverage 193 | M = U * T * K 194 | b. Transfer min(M, D)/U TRU from Staking Pool to SAFU 195 | 4. If S >= L : 196 | Cover the deficit using SAFU funds 197 | a. Calculate R = 0 198 | b. Transfer L StableCoin from SAFU to Liquidity Pool 199 | 5. If S < L : 200 | SAFU funds are insufficient to cover 201 | a. Calculate R = L - S 202 | b. Transfer S StableCoin from SAFU to Liquidity Pool 203 | 6. If (R > 0) : 204 | Deficit is still not covered 205 | a. Calculate D’ = R 206 | b. Add D’ deficiency value to loanDeficiency mapping and poolDeficiency mapping 207 | 7. If (Arbitration Complete) : 208 | Arbitration completes with Y StableCoin 209 | a. Transfer Y StableCoin from Arbitration to LoanToken 210 | b. SAFU burns L LoanToken for μ(Y+P) StableCoin 211 | c. Subtract D’ deficiency value from loanDeficiency mapping and poolDeficiency mapping 212 | ``` 213 | 214 | ### SAFU Smart Contract Architecture 215 | 216 | SAFU will effectively replace what was called “Liquidator”. SAFU will have the permission to slash TRU according to the above algorithm. Funds in the SAFU will be managed by an approved address, automating as much capital management as possible through defi. The initial version of SAFU funds management will be somewhat centralized. Allowing centralized management of SAFU funds is useful in order to maximize the capital efficiency when making exchanges between tokens. For example, the price impact of exchanging TRU on decentralized exchanges is much higher than the impact of OTC or centralized exchange opportunities. In following the ethos of progressive decentralization, future phases will include updates to the SAFU which remove the dependency on centralized parties to manage SAFU funds. 217 | 218 | ## Lines of Credit 219 | 220 | Lines of Credit (LOC) is a major step for automating lending and interest rate calculation in TrueFi. In this upgrade, borrowers with high enough credit scores will be able to open a line of credit with a credit limit. This will allow a borrower to withdraw and repay debt at any time with a variable rate rather than submitting requests for fixed term loans. Lines of credit and term loans are funded from the same liquidity pools and each have their own token representing unique risk and attributes. Interest rates will be calculated automatically for fixed and variable term loans based on the Credit Oracle. 221 | 222 | ### Mitigating Risk 223 | 224 | It’s important to take measures which protect lenders from downside. In addition, Line of Credit mechanisms need to be future-proof and flexible to support future changes such as new models or inputs. This current design assumes that a TrueFi credit score is the most important factor in calculating borrower credit limits and risk. Therefore, it is critical to calculate and closely monitor these scores as a more decentralized solution is built. 225 | 226 | Some centralized steps to lower risk include: 227 | - Regular check-ins on borrower health 228 | - Ability to reduce borrowers’ credit limits at any time 229 | - Borrower agreement legal covenants 230 | - Only allow “high-quality” borrowers with high credit scores access to Credit Lines 231 | 232 | Some of the main risks associated with Lines of Credit include: 233 | - Borrowers’ creditworthiness is changing in real-time depending on their trading positions 234 | - Market volatility 235 | - Lack of real-time credit monitoring 236 | - Borrowers attempting to withdraw funds quickly to cover positions elsewhere 237 | 238 | #### Loan Term 239 | 240 | Reduced term is instituted in order to lower risk by requiring borrowers with a line of credit to repay their full balance every term and establish repayment history. The term for lines of credit in TrueFi will be 365 days, starting when the line of credit request is approved. This number can be increased as stability of the product is established. 241 | 242 | ### Credit Oracle 243 | 244 | A smart contract is utilized as an oracle which returns credit scores, borrow limits, and borrow eiligibility. Until credit scores are automated in a trustless way, these parameters will be written by a manager to the smart contract. This way, accurate and effective scores can be implemented now, and in the future the same interface & contract can be used to provide trustless borrower data. 245 | 246 | Borrowers that are "on hold" are temporarily suspended from borrowing from TrueFi. Any borrower that does not have their score updated within 30 days or misses a 30 day payment will automatically be put on hold. Borrowers can be marked as "ineligible" by the contract owner, and ineligible borrowers will not be able to borrow from TrueFi. Borrowers marked as ineligible will be open to enter technical default once marked. 247 | 248 | ### Interest Rates Overview 249 | 250 | Interest rates will be calculated automatically based on a set of inputs including borrower credit scores. Borrowers will have the ability to take out loans calculated on a fixed term, fixed interest basis and a line of credit which is variable term, variable interest. Interest accrues on a per-block basis, increasing the virtual price of a lending pool as profit is realized. 251 | 252 | Interest for lines of credit accumulates per block on the principal borrow based on the variable rate. Borrowers utilizing lines of credit are required to pay the interest balance every 30 days. 253 | 254 | ##### Borrow Limit 255 | 256 | Credit limits and borrower scores are calculated off-chain and written to a smart contract. Borrow limits are calculated based on a credit limit and credit score. Limits are adjusted by a multisig and written to a smart contract. Limits must be calculated off-chain in order to keep borrower information private. 257 | 258 | A borrower cannot borrow more than 15% from any pool or more than their remaining credit limit. This is to both limit the risk of a single borrower defaulting in any pool, and manage the maximum amount a default can affect the entire protocol. 259 | 260 | A max_borrow_limit and credit_score for each borrower are written by a multisig and stored on-chain. An adjustment_ratio is calculated which decides how much to reduce credit limits for borrowers with lower scores. For each borrower, their credit_limit is calculated by multiplying max_credit_limit * adjustment ratio. 261 | 262 | Finally we calculate a pool_borrow_max, which represents the maximum a borrower can borrow from a single pool. Each borrower will have its own maximum borrow from each pool. A borrower cannot borrow more than their remaining credit limit or 15% of a single pool. 263 | 264 | #### Borrow Rates 265 | 266 | Borrow rates for fixed and variable term loans are calculated on-chain. Starting with a base rate collected from the Aave and Compound markets, rates are adjusted based on utilization and credit scores. A lower credit score causes higher interest rates to borrow, as do higher pool utilizations. These adjustments are based on inverse power function models with tunable parameters. Parameter tuning can allow for targeting particular creditworthy borrowers or pool utilization levels. 267 | 268 | The final_rate is equal to the base adjusted for utilization and credit score. We start with a base_rate which is a secured_rate + risk_premium. The secured_rate is the average 7 day borrowing rate for the Aave USDC market. The risk_premium is a value set by a multisig representing a premium for uncollateralized lending. 269 | 270 | Once the base rate is calculated, we then perform some calculations per pool, and per borrower, to adjust for pool utilization and credit scores. The general idea of these calculations is to incentivise borrowing from pools with low utilization, and punish borrowers with low credit scores. 271 | 272 | The utilization_adjustment is a formula which increases the interest rate for a specific pool. Pools with utilization above 50% have an increasing rate. Utilizations below 50% have a minimum effect on interest rates. Pools with utilization above 80% have a rapidly increasing rate. 273 | 274 | The credit_adjustment is a formula which increases the interest rate for borrowers with low credit. Having the highest credit score (255) will give you a 0% increase in interest rates. Then, every point lower than 255, interest rates increase by a small percentage. Borrowers with a score below 159 have a major increase in interest rates. 275 | 276 | Once all these values are calculated, we can get the final rate: 277 | 278 | final_rate = base_rate + utilization_adjustment + credit_adjustment 279 | 280 | #### Stable Borrowing 281 | 282 | Rates for fixed-term loans are calculated using the stable borrow rate. The stable rate is the final rate adjusted based on the term length of a loan. 283 | 284 | We add to the final_rate a time_adjustment, which increases the interest rate for stable borrowing by 1% per 30 days. We then calculate the stable rate: 285 | 286 | stable_rate = final_rate + time_adjustment 287 | 288 | #### Handling Deficiency in Lines of Credit 289 | 290 | If a borrower’s limit is dropped and they owe more than their limit, they will be given a cure period to repay their balance to below their new credit limit. If a borrower cannot repay, The SAFU will attempt to purchase the debt tokens from the lending pool in the same way it would with fixed-term loans. (see: SAFU Specification) 291 | 292 | ### Interest Rates Calculations 293 | 294 | In order to calculate interest rates on Ethereum, every time an input to an interest rate equation changes, the interest amount owed to lenders needs to be re-calculated. For a protocol such as Aave, this is straightforward, since every borrower in an Aave pool pays the same interest rate. For TrueFi, where interest rates vary between borrowers, this calculation becomes slightly more complicated. Therefore, TrueFi Pools will keep track of 2 types of interest for Lines Of Credit: 295 | 296 | - A base rate paid by all variable rate borrowers 297 | - A rate per-borrower (see buckets section below) 298 | 299 | #### Buckets 300 | 301 | Buckets are a solution designed to make lines of credit scalable. Every borrower is placed in a "bucket" consisting of all the possible credit scores. Credit scores are stored in the oracle as a uint8, which means the range of credit scores are 0-255. In order to be able to efficiently calculate the scores for a high number of borrowers, borrowers are grouped based on their score. When a change is made to utilization or rates, that change is applied to all borrowers with the same score. Thus, if 3 borrowers have a score of 192, all 3 borrower interest rates can be updated at the same time instead of updating 3 different scores. 302 | 303 | #### Borrow Limit 304 | 305 | Credit limits and borrower scores are calculated off-chain and written to a smart contract. Borrow limits are calculated based on a credit limit and credit score. A borrower cannot borrow more than 15% from the TVL of all pools or more than their max borrow limit (after adjusting for credit score). 306 | 307 | ``` 308 | max_borrower_limit = [written on-chain by multisig] 309 | 310 | max_pool_limit = 0.15 * truefi_tvl 311 | 312 | credit_limit = min(max_borrower_limit, max_pool_limit) * limit_adjustment 313 | 314 | limit_adjustment = borrower_score < score_floor ? 0 : (borrower_score/MAX_CREDIT_SCORE)^limit_adjustment_power 315 | 316 | score_floor = 40 317 | MAX_CREDIT_SCORE = 255 318 | limit_adjudtment_power = 0.75 319 | 320 | pool_borrow_max = min(0.15 * pool_value, credit_limit) 321 | 322 | remaining_credit_limit = pool_borrow_max - total_borrow 323 | ``` 324 | 325 | #### Borrow Rates 326 | 327 | Starting with a base rate, rates are adjusted based on utilization and credit scores. Higher utilization in a lending pool causes higher interest rates to borrow based on an inverse power model. Score adjustment uses an inverse power model. 328 | 329 | ``` 330 | risk_premium = [value set by governance] 331 | 332 | secured_rate = [returned by credit oracle] 333 | 334 | base_rate = secured_rate + risk_premium 335 | 336 | final_rate = min(rate_ceiling, base_rate + utilization_adjustment + credit_adjustment) 337 | 338 | rate_ceiling = 500.0% 339 | 340 | utilization_adjustment = utilization_adjustment_coefficient * (1/(pool_liquid_ratio)^utilization_adjustment_power - 1) 341 | 342 | utilization_adjustment_coefficient = 0.50% 343 | utilization_adjustment_power = 2 344 | 345 | credit_adjustment = credit_adjustment_coefficient * ((MAX_CREDIT_SCORE/borrower_score)^credit_adjustment_power - 1) 346 | 347 | MAX_CREDIT_SCORE = 255 348 | creditAdjustment_coefficient = 10.00% 349 | credit_adjustment_power = 1 350 | ``` 351 | 352 | #### Stable Borrowing 353 | 354 | Rates for fixed-term loans are calculated using the stable borrow rate. A stability adjustment is added to incentivise borrowers to take out shorter term loans. 355 | 356 | ``` 357 | term_days = term length in days 358 | 359 | stability_adjustment_coefficient = [value set by governance] 360 | 361 | stability_adjustment = (term_days / 30) * stability_adjustment_coefficient 362 | 363 | stable_rate = final_rate + stability_adjustment 364 | ``` 365 | 366 | # Phase 5 367 | 368 | Phase 5 will mainly focus on improving lines of credit. This phase also includes some smaller changes to token distribution and governance. The phase 4 version of lines of credit we will refer to as a "pilot" or LOC v0. This version will be launched with an initial set of borrowers (or one borrower) in order to test the feature and get feedback. 369 | 370 | We will refer to Lines of Credit as "LOC" and Fixed Term Loans as "FTL". The difference between the two is LOC allow borrowers to borrow at any time, up to their limit, as tracked in a smart contract. FTL allow borrowers to create discrete, tokenized loans with a fixed term and fixed interest rate. 371 | 372 | ## Lines of Credit v1 373 | 374 | LOC v1 is not only an overhaul of lines of credit, but also an overhaul of how fixed term loans (FTL) function. 375 | 376 | ### Automatic Caulcation of Borrow Rates 377 | 378 | The main feature of Phase 5 is that all interest rates will be calcuated automatically. At the time of drawing down a line of credit, a borrower will be bucketed with other borrwers that have the same score. The smart contract called Credit Model calculates the interest rates for both LOC and FTL. 379 | 380 | ### Handling Defaults for Lines of Credit 381 | 382 | Handling defauls for LOC is similar to fixed term loans with a few changes. 383 | 384 | In the event of a LOC default, the following occurs: 385 | 1. Up to 10% of TRU is slashed from the staking pool and transferred to SAFU to cover the amount of default, equal to principal amount plus full amount of expected interest (“Defaulted Amount”) 386 | 2. If the current SAFU funds are insufficient to cover the Defaulted Amount: 387 | - SAFU can sell TRU for the respective borrowed asset at its manager’s discretion 388 | 3. If the value of the SAFU funds(“Assurance Fund”) can not satisfy the Defaulted Amount: 389 | - The difference between the Defaulted Amount and the Assurance Fund is calculated (“Uncovered Amount”) 390 | - SAFU mints ERC-20 tokens representing claim for the Uncovered Amount (“Deficiency Claim”) 391 | - Lending Pool receives a Deficiency Claim for the Uncovered Amount assuming successful recovery 392 | - Lending Pool has a first priority claim on funds recouped through arbitration for the Deficiency Claim amount 393 | 4. If a debt is repaid: 394 | - The recouped funds will be used to re-purchase Deficiency Claim tokens from the lending pool which the default occurs in 395 | - SAFU repurchases Deficiency Claim tokens from the Lending Pool up to the Recovered Amount. Those tokens are burned by the Lending Pool 396 | - If there are additional recovered funds after repurchasing the Lending Pool’s Deficiency Claim, the SAFU keeps those remaining funds 397 | 5. If any portion of the original loan amount is not repaid after the completion of the legal recovery process: 398 | - Lending Pool’s remaining Deficiency Claim tokens are burned (decrease LP price) 399 | - Losses are incurred in the Lending Pool 400 | 401 | ### Smart Contract Design 402 | 403 | #### Credit Model 404 | 405 | The Credit Model module calculates interest rates for LOC and FTL. The adjuster works according to the Phase 4 specification for calculating interest rates, taking into account the borrow limit and credit scores for each borrower. 406 | 407 | #### BorrowingMutex 408 | 409 | BorrowMutex is a smart contract designed to restrict which products (LOC, FTL) a borrower can use. A borrower can choose between either a line of credit (LOC), or a fixed-term loan (FTL). The mutex tracks which product a borrower is using, and restricts the borrower from using the other product if they are already using one. A borrower can have one LOC per pool, or one FTL (between all pools). A borrwer can borrow up to their credit limit as calculated by the Credit Model. 410 | 411 | #### DebtToken 412 | 413 | DebtToken is a token which represents a claim on future funds from the SAFU. DebtTokens are used as an accounting method for tracking bad debt owned by a lending pool. When a default occurs in FTL or LOC, DebtTokens are minted by the SAFU and transferred to the lending pool. 414 | 415 | ## Borrower Staking 416 | 417 | One of the key drivers behind the demand for exchange tokens (BNB, FTT) is their ability to lower fees for traders and access opportunities on exchanges. Adding this type of use for TRU will create an incentive for borrowers to buy and lock TRU, thus driving demand and utility for the TRU token. Borrower staking adds the ability for borrowers to stake TRU in order to increase their credit limit and decrease their borrowing interest rates. Note that the "effective" credit score is not an indication of the borrower's credit worthiness rather it is an input used to drive rates and limits. 418 | 419 | ### Overview 420 | 421 | - Design TRU staking as general system that can enable future multi-asset staking on TrueFi 422 | - Borrowers can reduce interest rates marginally by staking TRU 423 | - Borrowers can stake TRU to expand credit limit by a percentage of staked value 424 | 425 | ### Implementation 426 | 427 | Interest rate calculations need to be refactored to include staking rates. The simplest way to accomplish this is by changing which bucket a borrower is placed into if they stake TRU. Because the staking system uses a “bucketing” technique for scalability, borrowers with the same score before staking TRU could have different scores after, thus breaking the buckets. Instead of calculating a new rate for a staked borrower, a new effective credit score is calculated for a staked borrower. 428 | 429 | Note that a borrower’s credit score or borrow limit are not increased in the credit oracle, rather their “effective” credit score is used by the CreditModel smart contract to adjust the rates & limits internally. If a borrower has a perfect score, their rates cannot go lower since they will be in the highest bucket. 430 | 431 | #### Credit Limit 432 | 433 | Credit limits are straightforward to adjust. An adjustment is added to a borrower’s credit limit based on the amount of TRU staked. The staked credit limit is calculated as follows: 434 | 435 | ``` 436 | conservative_stake_value = ltv_ratio * oracle_price * staked_TRU 437 | ``` 438 | 439 | The ltv_ratio is stored as a parameter initially set to 0.4. This means the borrower must stake additional debt over their previous limit by staking 40% TRU per dollar increase in their limit. 440 | 441 | #### Credit Score and Interest Rates 442 | 443 | An adjustment is applied when borrowing to adjust the interest rate. This adjustment does not affect the oracle credit score, rather it affects the score bucket a borrower is placed into when creating a loan. 444 | 445 | ``` 446 | staked_credit_adjustment = credit_adjustment(effective_score) 447 | 448 | effective_score = credit_score + conservative_stake_ratio^effective_score_power * (MAX_CREDIT_SCORE - credit_score) 449 | ``` 450 | 451 | The variables credit_score and MAX_CREDIT_SCORE are treated the same as the base model. The effective_score_power variable will be set to 1, and must be greater than 0. 452 | 453 | Conservative stake value is calculated as follows: 454 | 455 | ``` 456 | conservative_stake_value = LTV_ratio * oracle_price * staked_TRU 457 | ``` 458 | 459 | LTV ratio will be set initially to 40%. Oracle price is the 7 day average spot rate of TRU price as collected from the TRU ChainLink price oracle. staked_tru will be the amount of TRU staked by the borrower. 460 | 461 | ``` 462 | conservative_stake_ratio = 463 | min(100%, conservative_stake_value / borrow_amount) 464 | ``` 465 | 466 | borrow_amount is the fixed term loan amount XOR LOC pro forma borrowed amount. 467 | 468 | ### Smart Contracts 469 | 470 | The CreditModel contract will need to keep track of how staking changes a borrower’s limit and score. A new contract will be added called StakingVault which holds TRU stake and keeps track of how much stake each borrower has. 471 | 472 | #### StakingVault 473 | 474 | This contract will: 475 | - Allow borrowers to stake TRU 476 | - Lock TRU for the duration of a borrower’s fixed-term loan 477 | - Track how much TRU is locked for staked borrowers 478 | - Prevent borrowers from withdrawing TRU if they are below their staked credit limit 479 | - Allow SAFU to slash borrower TRU in case of a default 480 | 481 | When a borrower creates a fixed term loan, the borrow() function looks to see if the borrower has stake in the StakingVault. Once the loan is created, borrowers cannot stake more TRU or withdraw the TRU staked at the time the loan is created. 482 | 483 | For lines of credit, a borrower is automatically allowed to borrow based on their staked rate and limits. If the price of TRU falls, a borrower will have to add more stake or pay back a loan in order to avoid defaults. If a borrower is not meeting their staking requirements, the StakingVault will automatically prevent them from withdrawing further TRU. 484 | 485 | #### CreditModel 486 | 487 | The CreditModel contract would look at the StakingVault contract to calculate rates & limits for staked borrowers. The logic for adjusting borrow limits and interest rate discounts for borrowers with staked TRU is stored in this contract. 488 | 489 | #### SAFU and Defaults 490 | 491 | If any borrower enters default, the SAFU has permission to withdraw all the borrower’s TRU staked in the StakingVault. This TRU will be used as the first tranche to repay bad debt created after a default. If there is an edge case where the borrower has repaid their loan partially, TrueFi governance can decide to return TRU from the SAFU. 492 | -------------------------------------------------------------------------------- /images/LoanToken Lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TrueFi-Protocol/truefi-spec/d2752e44908e83d56d7b0fe015c3afa808bb53d8/images/LoanToken Lifecycle.png -------------------------------------------------------------------------------- /images/TrueFi Product Flows.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /roadmap.md: -------------------------------------------------------------------------------- 1 | # The TrueFi Protocol Roadmap 2 | 3 | 4 | # Vision for TrueFi 5 | 6 | **The goal of TrueFi is to become the most widely adopted and most trusted protocol for uncollateralized lending on blockchain.** TrueFi’s first borrowers are crypto-native trading firms and will gradually become a diverse set of companies and individuals, letting TrueFi act as a more general financing tool. 7 | 8 | The focus of the protocol needs to be on **providing an attractive risk-adjusted return over the long term**. Compared to other successful DeFi projects, TrueFi will target a relatively higher-risk, higher-yield segment of the market. Achieving this safely will require bridging the gap between centralized information (off-chain credit data, KYC/AML, legal agreements) and blockchains - a unique and valuable capability. 9 | 10 | The protocol will use community incentives (in the form of TRU) to accelerate growth and decentralize governance, but will be less and less dependent on incentives to boost yields over time. 11 | 12 | This document, (i) discusses the key changes necessary for TrueFi to become the foundational protocol for uncollateralized lending and (ii), proposes a roadmap with specific milestones to get there. 13 | 14 | 15 | # Phases 16 | 17 | Over the first half of 2021, TRU holders will be called upon to make material upgrades to the TrueFi protocol in order to improve the efficiency of TRU usage, migrate to and improve on-chain governance, and optimize the borrower approval process. 18 | 19 | TRU tokens are the native asset of the TrueFi protocol. In addition to community incentives (~40% of total token supply), [TRU are being distributed](https://blog.trusttoken.com/introducing-truefi-the-defi-protocol-for-uncollateralized-lending-9bfd6594a48) to private sale participants, the core team and management, and to future team members with quarterly unlocks over the next two years. As such, the protocol roadmap is oriented around each unlock period. As there is still much to be improved, each of the first few unlock periods are tied to 2-3 ambitious development goals. Crypto moves fast and these goals could change, but as of this writing, the deliverables described below seem like the highest value improvements to make for the long-term growth of TrueFi. 20 | 21 | 22 | ## Phase 1 - Nov 21st 2020 [Completed] 23 | 24 | 1. Launch Version 1 (“V1”) of the TrueFi Protocol 25 | 2. Issue TRU Tokens 26 | 27 | 28 | On November 21, V1 of the TrueFi protocol and the TRU tokens were shipped. In V1, institutional borrowers are onboard by completing a KYC/AML review, signing a legally-enforceable loan agreement with TrustToken, Inc. as the counterparty, and letting TRU holders assess their reputation with a [New Borrower Request](https://forum.truefi.io/c/Borrower-Requests/5) on the TrueFi forum before seeking TRU holders to stake on each of their individual loans for ultimate approval. New borrowers apply for smaller loans (usually $1-2mm) and then, after establishing some record of repayment with TrueFi, are allowed to apply for larger amounts. 29 | 30 | V1 has proven to be a substantial and fully-functioning protocol, accounting for $40 million+ of fixed-term lending activity from respected borrowers like Alameda Research, Wintermute Trading, Grapefruit Trading, and Invictus Capital. V1 has already generated $110,000+ in [returns](https://etherscan.io/address/0xa1e72267084192db7387c8cc1328fade470e4149#readProxyContract) to TUSD lenders (this does not include TRU incentives for lenders). Additionally, borrower demand has begun to outstrip TUSD supply for the first time, demonstrating growing interest from borrowers. 31 | 32 | This fixed-term model that went live in V1 has drawbacks however, especially in terms of TRU utilization. Because staking on an individual loan locks the staked TRU, that same TRU cannot be used for governance voting or providing liquidity. These aspects of the protocol will be improved in phases 2-4 over the coming months 33 | 34 | 35 | ## Phase 2 - By Feb 19th 2021 36 | 37 | 1. Add Liquid Exit 38 | 2. Improve staking model 39 | 3. Launch fully on-chain governance 40 | 41 | **Liquid Exit**: This upgrade addresses a key community request: the ability to exit the TrueFi Lending Pool directly into the asset that the lender used to enter the pool (for now, just TUSD). This process currently relies on Uniswap. With Liquid Exit, the Lending Pool will act as a liquidity provider and will buy TFI-LP tokens in exchange for TUSD. You can find more detail on Liquid Exit [here](https://docs.google.com/document/d/1YtDUkocD5OoYJi4PRALFihCUY6uut55pa2mvNx4mgeQ/edit?usp=sharing). 42 | 43 | **Improved Staking Model:** A [new staking model](https://github.com/trusttoken/truefi-spec/blob/master/TrueFi2.0.md#staking) will be introduced that will provide much clearer utility for TRU as well as an improved staker experience. Stakers will stake on the overall protocol rather than being forced to stake on individual loans. 44 | 45 | Additionally, **stakers will benefit two-fold from staking**: (1) earning fees paid by borrowers on loan origination (denominated in TFI-LP), and (2) accruing TRU incentives for staking 46 | 47 | Protocol stakers will not be _required_ to rate individual borrowers. However, since protocol stakers are exposed to all loans on the platform, it is in stakers’ best interest to vote against loans that they deem to be too risky for the pool. Stakers stand to have a percentage of their stake (initially, 10% per default) reclaimed by the protocol in the event of a loan default. Reclaimed TRU is transferred to the lending pool that took the loss. TRU holders may decide if stakers will be rewarded with TRU for voting. 48 | 49 | **On-chain governance:** A fully on-chain [governance model](https://github.com/trusttoken/truefi-spec/blob/master/TrueFi2.0.md#staking) will bring TrueFi governance on par with other fully decentralized protocols where there is **no centralized actor** with special privileges over the protocol. This will further strengthen TrueFi and set the stage for future potential changes, such as allowing Loan Tokens to be freely tradable. 50 | 51 | These improvements mean that staking is directly correlated with the growth of the protocol rather than any individual loan. More opportunities for stakers and token holders to vote on creditworthiness, participate in protocol governance, and earn fees related to the growth of the protocol. 52 | 53 | 54 | ## Phase 3 - By May 20, 2021 55 | 56 | 1. Add additional USD-backed stablecoins, specifically USDC, to the first TFI-LP pool 57 | 2. Add Lines-of-Credit 58 | 3. Implement a more robust credit model for onboarding borrowers 59 | 4. Allow Loan Tokens and Line-of-Credit Tokens to be tradable 60 | 61 | **Additional stablecoins**: USDC is the largest fully collateralized USD-backed stablecoin and has widespread adoption throughout DeFi. With a market cap of around $5bn, it’s ~12x the size of TUSD. Adding support for USDC will open up a larger set of depositors into the TrueFi pool. 62 | 63 | **Lines-of-credit**: Open-term loans are common among some of the centralized lending/borrowing markets and actively requested by some TrueFi borrowers. While key questions - such as do borrowers pay interest periodically, and does the loan compound indefinitely - remain to be worked out by the TrueFi community, a [basic spec](https://drive.google.com/file/d/1PjLmFCt3P1Kiz_guv-uYsH72H6D1LDVI/view?usp=sharing) of this proposal is available today. 64 | 65 | **Improved credit model**: TrueFi needs to become world-class at assessing risk. This requires reliably bringing off-chain information on-chain and combining that with existing protocol data such as repayment history. Credit will be assessed using a multivariable model that includes things such as legal jurisdiction, AUM, leverage, options exposure, and more. 66 | 67 | It’s crucial that the protocol can assess all of this data without revealing all of it publicly. The information for the credit model can be crunched off-chain in a [secure enclave](https://en.wikipedia.org/wiki/Trusted_execution_environment) and then a proof-of-computation can be uploaded to the blockchain and checked by the smart contract. This allows the smart contract to verify that the credit model was computed correctly, without certain private details (such as the amount of leverage a borrower is using) being exposed publicly. We expect the credit model to take into account more and more factors over time. 68 | 69 | **Tradeable Loan Tokens:** One of the financial primitives of TrueFi is that each loan that is taken from the platform produces a new Loan Token representing that debt. 70 | 71 | 72 | Right now, Loan Tokens are not individually tradeable. However in the future, TRU holders may implement a change so that they can be. Tradable Loan Tokens may open up the possibilities for other developers, protocols, and platforms to use them creatively in their own applications. A few examples: 73 | 74 | * Allowing investors to buy up all the debt from a particular borrower they trust 75 | * Protocols that work like closed ended funds (TrueFi’s pools are open-ended) 76 | * Protocols that accept loan tokens as collateral for loans 77 | * Many more! 78 | 79 | If TrueFi is able to execute on these proposed milestones, TrueFi has the potential to become the **foundation of uncollateralized on-chain lending across multiple protocols**. This will grant TrueFi participants access to a larger, more diverse set of borrowers and lenders, more staking opportunities, and more opportunities to exercise governance rights. 80 | 81 | 82 | ## Phase 4 - By August 18, 2021 83 | 84 | 85 | 1. Add support for arbitrary ERC20 tokens (e.g. WBTC pool, WETH pool, etc.) 86 | 2. Allow lending pools to provide liquidity on all Loan Tokens and_ line of credit _tokens 87 | 3. Allow other protocols to participate in Loan Token and Line-of-Credit primary fundraising 88 | 89 | By Phase 4, TrueFi should be widely used and proven out as a source of capital. At this point and going forward, many protocol improvements will be focused on improving interoperability with other assets and protocols. 90 | 91 | **Allow other protocols to participate in Loan Token and Line-of-Credit primary fundraising:** Today, a borrower can create a loan token which represents their request for $10mm from the TrueFi protocol. In the future, as TrueFi expands to become the basis for uncollateralized lending on-chain, a borrower could post a loan token representing their request to raise _$100mm_, some from TrueFi, but also from _any other protocol that wants to participate_. 92 | 93 | You can think of this as like **Kickstarter for debt:** anyone can participate and get a slice of the pie. The same will apply for lines-of-credit: a borrower looking to _increase_ their outstanding line-of-credit will automatically draw additional capital from any protocol (or individual) which has approved them for additional credit. 94 | 95 | 96 | ## Other Considerations 97 | 98 | 99 | 100 | 1. **L2 scaling solutions:** TrueFi likely won’t be a trailblazer here. TRU holders may wait and see what solutions work for other comparable projects and implement as needed. 101 | 2. **Protocol-to-protocol lending**:- A big and interesting market, but requires a different approach than lending to institutions. This is being explored, but is not yet firm enough to be added to the roadmap. 102 | --------------------------------------------------------------------------------