|
| 1 | +# FlashyFi |
| 2 | + |
| 3 | +FlashyFi is an application that leverages several powerful features of Radix to enable a completely new approach |
| 4 | +to flash loans. Unlike other flash loan applications that require users to deposit their tokens into a liquidity pool, |
| 5 | +FlashyFi allows each user to lend their tokens and NFTs without ever transferring them out of their accounts. |
| 6 | + |
| 7 | +With many other flash loan applications, the tokens to be lent must first be locked in a smart contract, preventing them |
| 8 | +from being used, traded, or transferred directly until they are withdrawn from the contract. However, FlashyFi takes a |
| 9 | +different approach by keeping all tokens in their user's account and allowing a central component to temporarily |
| 10 | +withdraw them, lend them to another user and return them before the transaction ends. As each flash loan lasts only for |
| 11 | +the duration of a single transaction, the tokens never truly leave the account. |
| 12 | + |
| 13 | +# Demo |
| 14 | + |
| 15 | +A demo frontend is available at https://backyard-coder.github.io/flashyfi |
| 16 | +Please take a look at the about page for some usage instructions and a discussion of the demo's limitations. |
| 17 | + |
| 18 | +The publicly hosted frontend is offered as a bonus and should not be the basis for evaluation. The evaluation should be |
| 19 | +based solely on the code in the pull request. While I promise that I will not make any substantial changes to the |
| 20 | +application after the submission deadline, I reserve the right to fix bugs that significantly affect the liveness or |
| 21 | +functionality of the application. |
| 22 | + |
| 23 | +If you would like to deploy the frontend locally, you can follow the instructions described in the |
| 24 | +[frontend README](flashyfi-frontend/README.md). |
| 25 | + |
| 26 | +## Technical implementation |
| 27 | + |
| 28 | +FlashyFi is built on the following two characteristic features of the Radix network: |
| 29 | + |
| 30 | +- Transient resources: Transient resources can be used to securely implement flash loans. A user who takes out a loan |
| 31 | + receives not only the lent tokens but also a special receipt NFT. As long as this NFT exists the transaction cannot |
| 32 | + succeed. It thus acts as a safety, preventing the user from taking the loan and then ending the transaction |
| 33 | + without repaying it. The only way to destroy the NFT is to give it back to the FlashyFi component, which will only |
| 34 | + accept it if the loan is repaid. |
| 35 | +- Flexible access rule model: The Radix network has a flexible and powerful mechanism for defining access rules, |
| 36 | + including the ability to exchange factors/keys that grant access to an account. FlashyFi takes advantage of this |
| 37 | + feature and defines the account access rules such that not only the user but also the central FlashyFi component can |
| 38 | + withdraw tokens from the account. This is secure because the FlashyFi component always returns the withdrawn tokens. |
| 39 | + |
| 40 | +For the technical details please take a look at the [Scrypto source code](flashyfi-scrypto/src/flashyfi.rs) as it |
| 41 | +contains extensive documentation. |
| 42 | + |
| 43 | +## Lender Usage |
| 44 | + |
| 45 | +To lend tokens, users must first "flashyfi" their account by registering it with the central FlashyFi component and |
| 46 | +granting that component access to the resources held in the account. Users can use the demo frontend to define which |
| 47 | +tokens or NFTs they want to lend and for what fee. Experienced Scryptonauts may examine the transaction manifests shown |
| 48 | +in their wallets to learn what's going on in the background. |
| 49 | + |
| 50 | +## Borrower Usage |
| 51 | + |
| 52 | +As a borrower, one would likely use flash loans in the context of automated processes, such as exploiting arbitrage |
| 53 | +opportunities. For this, a backend API would be required. This backend would select the optimal accounts from which to |
| 54 | +borrow each resource and would take into account the fees set by the account owner. |
| 55 | + |
| 56 | +As such a backend is unsuitable for demonstrations, the FlashyFi frontend includes the ability to simulate a flash loan. |
| 57 | +To do this, visit the app's homepage, select a resource, specify an amount to borrow and a transaction manifest will be |
| 58 | +generated for you. This manifest performs/simulates the following 4 steps: |
| 59 | + |
| 60 | +1. Borrow tokens from one or more accounts |
| 61 | +2. Exploit an arbitrage opportunity (in the generated manifest, the XRD Faucet component is used for this). |
| 62 | +3. Repay the borrowed tokens and pay the fee incurred. |
| 63 | +4. Deposit the profit generated, if any, into your account. |
| 64 | + |
| 65 | +## Outlook |
| 66 | + |
| 67 | +Currently, FlashyFi is primarily designed for many users to lend tokens from their individual accounts. |
| 68 | +However, the FlashyFi blueprint is flexible enough to connect not only account components but also any other components |
| 69 | +that implement the methods `withraw_by_amount`, `withraw_by_ids` and `deposit_batch`. This enables users to integrate |
| 70 | +components holding significantly more liquidity, such as AMM-style DEXs, giving a second purpose to the tokens that are |
| 71 | +currently locked away in those components. |
0 commit comments