[VEN-2895]: Flash loan implementation #545

Debugger022 · 2025-01-07T15:45:22Z

Description

This PR introduces the implementation of flashloan functionality along with Partial Repayment for the Core pool on BNB Chain. Flashloan enable users to borrow assets without collateral, provided the loan is repaid within the same transaction. This enhancement includes the following changes:
a major new feature: multi-asset flash loan support in the Venus Protocol's Comptroller contract. It adds the necessary interfaces, storage, access control, and execution logic to enable secure and flexible flash loans, including whitelisting for authorized accounts and handling of fees and repayments. Several contracts and interfaces are updated to support this new functionality.

Flash Loan Feature Implementation

Added a multi-asset flash loan execution flow in PolicyFacet, including phased logic for fee calculation, asset transfer, receiver contract interaction, and repayment/fee handling. This includes checks for asset enablement, parameter validity, and sender authorization.
Defined new interfaces for flash loan receivers (IFlashLoanReceiver, IFlashLoanSimpleReceiver) to standardize interaction with contracts receiving flash-loaned assets.

Storage and Interface Refactoring

Upgraded storage contracts and facet inheritance from ComptrollerV17Storage to ComptrollerV18Storage to support flash loan data and authorization. Updated all relevant imports and contract inheritance.
Updated interfaces (ComptrollerInterface, IPolicyFacet, ISetterFacet) to expose new flash loan and whitelist functions.

Repayment Options

Full Repayment when borrowed amount and fees has been repaid .
Partial Repayment when Unpaid balance becomes an ongoing debt position for the initiator

Events and Observability

Added new events for flash loan execution and whitelist status changes to improve protocol observability.

Access Control and Whitelisting

Added whitelisting functionality for flash loan initiators, including the setWhiteListFlashLoanAccount method in SetterFacet, event emission, and corresponding interface updates.

Interface and External Contract Support

Defined interfaces for flash loan receivers (IFlashLoanReceiver and IFlashLoanSimpleReceiver) to ensure contracts interacting with the flash loan system implement the required logic for asset repayment.
Updated imports and contract interface definitions to support flash loan-related functionality and external protocol fee handling.

NOTE : deployments needs to done with new contract changes .

chechu · 2025-03-11T13:59:44Z

contracts/Tokens/VTokens/VBNB.sol

We cannot modify this contract. vBNB is not upgradable

Yes, I know but vBNB is inheriting the vToken contract which is been modified so I had to modify the vBNB as well.
we can create a separate contract for the vToken which would contain the old logic(without flashloan) and can inherit that one to the vBNB to maintain the consistency. let me know wdyt?

contracts/Comptroller/Diamond/facets/PolicyFacet.sol

chechu · 2025-03-11T14:05:47Z

contracts/Comptroller/Diamond/facets/PolicyFacet.sol

+        }
+
+        // Call the execute operation on receiver contract
+        if (!IFlashLoanReceiver(receiver).executeOperation(assets, amounts, fees, receiver, "")) {


The initiator could be a different address of receiver. I think we should use msg.sender instead. wdyt?

Sorry, I was meant the other way:

if (!IFlashLoanReceiver(receiver).executeOperation(assets, amounts, fees, msg.sender, param)) {

Refactored.

contracts/FlashLoan/base/FlashLoanSimpleReceiverBase.sol

contracts/Tokens/VTokens/VToken.sol

chechu · 2025-03-11T14:48:01Z

contracts/Tokens/VTokens/VToken.sol

+     * custom:access Only Governance
+     * custom:event Emits FlashLoanFeeUpdated event on success
+     */
+    function _setFlashLoanFeeMantissa(uint256 fee) external returns (uint256) {


Shouldn't we have two fees? one for the protocol and another one for the suppliers?

I guess we should have one fee for protocol, as suppliers are getting the interest rate by suppling the assets to the market. we can discuss this point.

Let's say the flash-loan borrower asks for 100 tokens. With the current implementation (one fee), we calculate the fee (let's say 10) so the borrower has to return 110. With the current implementation, the fee (10) is "socialised" among the suppliers (the exchange rate has increased, because the available cash has increased after the flash loan).

I think the protocol reserve should receive part of those 10 tokens. Here is when a second fee value is needed. Let's say 50%. So, 5 tokens are for the suppliers (socialised via an increase in the available cash), and 5 tokens are for the PSR contract.

chechu · 2025-03-11T14:50:31Z

contracts/Comptroller/Diamond/facets/PolicyFacet.sol

+        }
+
+        for (uint256 k; k < len; k++) {
+            (assets[k]).verifyBalance(balanceBefore[k], amounts[k] + fees[k]);


Don't we have to transferFrom first, to receive the tokens from the receiver? AFAIU, the receiver is not going to transfer the funds, they will only approve them

Direct transfer would be executed by the executeOperation in FlashLoanSimpleReceiver receiver contract in the current scenario. we can implement the approve logic as well. let me know your thoughts

I think we agreed on following the approve approach

contracts/Tokens/VTokens/VToken.sol

kkirka · 2025-09-25T02:18:40Z

contracts/Comptroller/Diamond/facets/PolicyFacet.sol


+    /**
+     * @notice Executes a flashLoan operation with the requested assets.
+     * @dev Transfer the specified assets to the receiver contract and handles repayment.


Suggested change

* @dev Transfer the specified assets to the receiver contract and handles repayment.

* @dev Transfers the specified assets to the receiver contract and handles repayment.

kkirka · 2025-09-25T02:18:47Z

contracts/Comptroller/Diamond/facets/PolicyFacet.sol

+        VToken vToken,
+        address payable initiator,
+        address payable receiver,
+        uint256 amountRepayed,


Suggested change

uint256 amountRepayed,

uint256 amountRepaid,

kkirka · 2025-09-25T02:20:23Z

contracts/Comptroller/Diamond/facets/PolicyFacet.sol

+            uint256 accrueResult = vToken.accrueInterest();
+            require(accrueResult == 0, "Failed to accrue interest");
+
+            uint256 debtError = vToken.borrowDebtPosition(initiator, leftUnpaidBalance);


Hm, I thought it was on the receiver's balance sheet. If not, I guess @Exef can avoid a borrow behalf in his code

we were opening debt position for the user's EOA that executed flashLoan which is onBehalf.

receiver is the contract that receives flashloan amount . we can't open borrow position for a contract .

kkirka · 2025-09-25T02:24:38Z

contracts/Comptroller/Diamond/facets/PolicyFacet.sol

+            if (debtError != 0) {
+                revert FailedToCreateDebtPosition();
+            }
+        } else {


Shouldn't we transfer the fee regardless of whether it was a full repayment or not?

kkirka · 2025-09-25T02:29:31Z

contracts/FlashLoan/interfaces/IFlashLoanReceiver.sol

+     * @param premiums The premiums (fees) associated with each flash-borrowed asset.
+     * @param initiator The address that initiated the flashLoan operation.
+     * @param param Additional parameters encoded as bytes. These can be used to pass custom data to the receiver contract.
+     * @return True if the operation succeeds and the borrowed amount plus the premium is repaid, false otherwise.


We should document the second returned value as well

kkirka · 2025-09-25T02:36:12Z

contracts/Tokens/VTokens/VToken.sol

+     * @custom:access Only Governance
+     * @custom:event Emits ToggleFlashLoanEnabled event on success
+     */
+    function toggleFlashLoan() external returns (uint256) {


I'd prefer to have a setter with an explicit true or false parameter. This way we can avoid race conditions between, e.g., a guardian transaction and a VIP transaction.

kkirka · 2025-09-25T02:39:42Z

contracts/Tokens/VTokens/VToken.sol

        ensureAdmin(msg.sender);
-        require(accrualBlockNumber == 0 && borrowIndex == 0, "market may only be initialized once");
+        require(
+            accrualBlockNumber == 0 && borrowIndex == 0 && (initialExchangeRateMantissa_ > 0),


Saving space?

I used yarn prettier.

kkirka · 2025-09-25T02:47:56Z

contracts/Tokens/VTokens/VToken.sol

        }

        /* Revert if protocol has insufficient underlying cash */
        if (getCashPrior() < borrowAmount) {


We don't need cash if we don't transfer anything

Suggested change

if (getCashPrior() < borrowAmount) {

if (shouldTransfer && getCashPrior() < borrowAmount) {

kkirka · 2025-09-25T02:50:52Z

contracts/Tokens/VTokens/VToken.sol

+        uint error = accrueInterest();
+        if (error != uint(Error.NO_ERROR)) {
+            // accrueInterest emits logs on errors, but on top of that we want to log the fact that an attempted reserve factor change failed.
+            return fail(Error(error), info);


With the proposed implementation this return value is ignored and operations continue as normal even if interest accruals fail. I don't think we want that.

…initiator'

contracts/Comptroller/Diamond/facets/FlashLoanFacet.sol

chechu · 2025-09-29T11:55:59Z

contracts/Comptroller/Diamond/facets/FlashLoanFacet.sol

+            revert SenderNotAuthorizedForFlashLoan(msg.sender);
+        }
+
+        if (!approvedDelegates[onBehalf][msg.sender]) {


I think we can skip this if msg.sender == onBehalf

msg.sender can't be onBehalf as msg.sender will be the user's receiver contract and onBehalf is necessary to get the actual user's address to open the borrow position in case of partial repayment .

contracts/Tokens/VTokens/VToken.sol

contracts/Comptroller/Diamond/facets/SetterFacet.sol

contracts/FlashLoan/interfaces/IFlashLoanSimpleReceiver.sol

chechu · 2025-09-29T12:13:34Z

contracts/Tokens/VTokens/VBep20Delegator.sol

 * @author Venus
 */
-contract VBep20Delegator is VTokenInterface, VBep20Interface, VDelegatorInterface {
+abstract contract VBep20Delegator is VTokenInterface, VBep20Interface, VDelegatorInterface {


Shouldn't we implement borrowDebtPosition in this contract, and delegate it to the implementation (using delegateToImplementation), as we are doing for the rest of the functions?

contracts/Tokens/VTokens/VToken.sol

contracts/Comptroller/Diamond/interfaces/IFlashLoanFacet.sol

chechu · 2025-09-29T16:25:49Z

contracts/Tokens/VTokens/VTokenInterfaces.sol

+        address asset,
+        address sender,


chechu · 2025-09-29T16:26:39Z

contracts/Tokens/VTokens/legacy/VBep20DelegatorR1.sol

+    /**
+     * @notice open a debt position for the borrower
+     * @dev This function checks if the borrow is allowed, accrues interest, and updates the borrower's balance.
+     *      It also emits a Borrow event and calls the comptroller's borrowVerify function.
+     *      It reverts if the borrow is not allowed, if the market's block number is not current, or if the protocol has insufficient cash.
+     * @param borrower The address of the borrower
+     * @param borrowAmount The amount of underlying asset to borrow
+     * @return uint Returns 0 on success, otherwise returns a failure code (see ErrorReporter.sol for details).
+     */
+    function borrowDebtPosition(address borrower, uint borrowAmount) external returns (uint) {
+        bytes memory data = delegateToImplementation(
+            abi.encodeWithSignature("borrowDebtPosition(address,uint256)", borrower, borrowAmount)
+        );
+        return abi.decode(data, (uint));
+    }
+


I didn't expect this change in the R1 contract. We don't need it, right?

chechu · 2025-09-29T16:35:51Z

contracts/Tokens/VTokens/VToken.sol

        uint allowed = comptroller.redeemAllowed(address(this), redeemer, vars.redeemTokens);
        if (allowed != 0) {
-            revert("math error");
+            return failOpaque(Error.COMPTROLLER_REJECTION, FailureInfo.REDEEM_COMPTROLLER_REJECTION, allowed);


Why are we changing the revert with a return? External integrations can expect the revert in these cases, not checking the returned value. There are several instances of this

chechu · 2025-09-29T16:38:38Z

contracts/Tokens/VTokens/VToken.sol

-                0
-            );
-        }
+        ensureNoMathError(vars.mathErr);


I wouldn't change the returned values, if it's possible. I would revert this change

chechu · 2025-09-29T16:41:01Z

contracts/Tokens/VTokens/VToken.sol

-        (uint repayBorrowError, uint actualRepayAmount) = repayBorrowFresh(liquidator, borrower, repayAmount);
-        if (repayBorrowError != uint(Error.NO_ERROR)) {
-            return (fail(Error(repayBorrowError), FailureInfo.LIQUIDATE_REPAY_BORROW_FRESH_FAILED), 0);
+        uint err;


I understand this is to try to optimize the size of the contract. Now that we don't have the simple flash loan function, I suppose we can keep this as it was, to minimize the changes

I will revert the changes. The function can be handled with a single err variable, but I will maintain the original structure.

Debugger022 added 3 commits January 7, 2025 21:11

feat: flash loan contracts

dba9c60

feat: single asset flash loan

dcd4f1f

feat: multiple asset flash loan

aba2937

chechu assigned Debugger022 Jan 13, 2025

Debugger022 added 7 commits January 20, 2025 14:14

feat: add mock contracts for flash loan receiver

fb92c44

test: add tests for the multi asset flash loan

4112b43

test: add tests for the single asset flash loan

12583d2

refactor: reduce vToken size to keep it under 24kb

adb7d8b

test: refactor tests as per flashloan feature

212c067

test: add fork test for single asset flash loan

1c60161

test: add fork test for multi asset flash loan

26f5663

Debugger022 closed this Jan 23, 2025

fix: ci/cd issues

558b0f5

Debugger022 reopened this Jan 24, 2025

Debugger022 added 2 commits January 28, 2025 14:20

Merge branch 'develop' into feat/VEN-2985

b88270c

fix: evilXToken test

27f3047

Debugger022 requested review from GitGuru7, kkirka, chechu and web3rover and removed request for GitGuru7 January 29, 2025 12:16

Debugger022 marked this pull request as ready for review January 29, 2025 12:17

Debugger022 changed the title ~~[WIP] [VEN-2895]: Flash loan implementation~~ [VEN-2895]: Flash loan implementation Feb 27, 2025

chechu reviewed Mar 11, 2025

View reviewed changes

Debugger022 added 5 commits March 12, 2025 18:46

fix: pr comments

7b5d653

fix: pr comments

bce9a10

refactor: introduced two fees for flash loans

c0fd071

refactor: use approve instead of transfer funds in flash loan

e5c1d0d

Merge branch 'develop' into feat/VEN-2985

041c3ba

kkirka reviewed Sep 25, 2025

View reviewed changes

Debugger022 added 3 commits September 25, 2025 11:09

fix: minor fixes

8ed2d89

fix: resolve comments

01d36ee

refactor: replace toggleFlashLoan with setFlashLoanEnabled function

2bc16e6

Exef mentioned this pull request Sep 25, 2025

[VPD-70] Leverage Manager contract VenusProtocol/venus-periphery#12

Draft

4 tasks

Debugger022 added 5 commits September 25, 2025 17:10

refactor: update flash loan parameters to use 'onBehalf' instead of '…

08ca797

…initiator'

refactor: remove checkAccrueInterest function

d3bf53c

feat: move flashLoan functions to new FlashLoanFacet

18eb4c8

fix: small optimization

f511491

fix: minor fixes

e313deb

Debugger022 requested review from chechu, web3rover, kkirka and GitGuru7 September 25, 2025 14:40

chechu reviewed Sep 26, 2025

View reviewed changes

contracts/Comptroller/Diamond/facets/FlashLoanFacet.sol Outdated Show resolved Hide resolved

Debugger022 added 4 commits September 26, 2025 15:12

refactor: update repayment handling in flashloan

947e632

fix: minor fixes

243fc8c

Refactor: removed PSR check transferOutUnderlyingFlashLoan

3ec2d14

fix: Lint

e570b0b

chechu reviewed Sep 29, 2025

View reviewed changes

contracts/Comptroller/Diamond/interfaces/IFlashLoanFacet.sol Show resolved Hide resolved

Debugger022 added 3 commits September 29, 2025 18:54

feat: add deployments for new flashLoan changes

9445b3a

fix: fix comments

09024d5

refactor: removed simple flashLoan functionality

bb75513

chechu reviewed Sep 29, 2025

View reviewed changes

Debugger022 added 3 commits September 30, 2025 10:22

fix: minor fixes

12bccb7

refactor: revert some changes

b312653

fix: remove unused errors

fad2194

	* @dev Transfer the specified assets to the receiver contract and handles repayment.
	* @dev Transfers the specified assets to the receiver contract and handles repayment.

	if (getCashPrior() < borrowAmount) {
	if (shouldTransfer && getCashPrior() < borrowAmount) {

[VEN-2895]: Flash loan implementation #545

Are you sure you want to change the base?

[VEN-2895]: Flash loan implementation #545

Uh oh!

Conversation

Debugger022 commented Jan 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Debugger022 Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Debugger022 Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Debugger022 Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkirka Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Debugger022 commented Jan 7, 2025 •

edited

Loading

Debugger022 Sep 25, 2025 •

edited

Loading

Debugger022 Sep 25, 2025 •

edited

Loading

Debugger022 Sep 25, 2025 •

edited

Loading

kkirka Sep 25, 2025 •

edited

Loading