Flashloan

Flash Loans in Helios Finance

Flash loans are a special DeFi mechanism that allows users to borrow assets with no upfront collateral, provided the loan is returned within the same transaction (single block) . In Helios Finance, this means you could, for example, borrow 100 BTC instantaneously and use it for arbitrage or liquidation, as long as you repay the 100 BTC plus a small fee in the same transaction. If the borrower fails to repay on time (or meet specified conditions), the entire transaction is reverted, ensuring the protocol remains safe and no funds actually leave the pool permanently. This atomic, all-or-nothing property makes flash loans powerful for advanced users without exposing lenders to additional risk.

Flash Loan Mechanics

When using a Helios flash loan, the protocol taps into the pool’s liquidity (the assets deposited by suppliers, which are represented by interest-bearing hTokens in Helios). Any asset in Helios with borrowing enabled can be flash-borrowed from the pool’s reserves, up to the amount of available liquidity. No collateral is required upfront because the loan is conditionally secured by the transaction itself – if the borrower doesn’t pay back by the end, the transaction reverts entirely. This “one-block borrow” concept has no real-world analog but leverages blockchain atomicity to guarantee repayment.

Behind the scenes, Helios’s Pool contract provides two methods for flash loans:

• flashLoan() – Borrow one or multiple assets in a single transaction (multi-asset flash loan) . This advanced version also allows an optional debt opening: instead of fully repaying, the borrower can choose to let some or all of the amount turn into a normal loan at the end of the transaction (more on this below). FlashLoan can even waive the fee entirely for certain whitelisted “flash borrower” addresses, if Helios governance designates any (e.g. for specific use cases).

• flashLoanSimple() – A gas-optimized version for a single asset. It always requires full repayment by the end of the transaction (no option to open debt) and always charges the standard fee (no fee waivers). This is ideal for straightforward flash loans involving just one token.

Both functions will transfer the requested assets to a receiver contract and then invoke a callback on that receiver to execute the user’s custom logic. In Helios, the user must deploy a contract implementing the required interface (IFlashLoanReceiver for flashLoan() or IFlashLoanSimpleReceiver for flashLoanSimple()). This contract will receive the funds and control the flow during the flash loan.

Key points of the flash loan mechanism:

• Single-Transaction Execution: The borrow, use, and repayment (or debt conversion) all happen within one blockchain transaction. If any step fails or the funds aren’t returned as expected, the entire transaction is reversed (meaning no one loses funds and it’s as if nothing happened).

• No Upfront Collateral Needed: Unlike normal loans, flash loans don’t require posting collateral at the time of borrowing. The guarantee is purely the atomic execution – either you return assets plus premium or the system reverts the action.

• Use of hTokens: The liquidity for flash loans comes from assets that other users have supplied to Helios (and for which they hold hTokens). When a flash loan is executed, the pool temporarily withdraws the underlying assets (BTC, ETH, stablecoins, etc.) from the reserves. If the assets are returned, the pool’s balances (and thus the value backing hTokens) are restored, plus the premium fee which becomes additional yield for liquidity providers .

• Developer Access: Flash loans are primarily a tool for smart contract developers. The borrower must have a contract that can execute arbitrary operations with the borrowed funds and then ensure repayment. Typical use cases include arbitrage trades, self-liquidation or refinancing of positions, and moving collateral between protocols – all done atomically without initial capital.

Fee Model (Flash Loan Premium)

Every Helios flash loan incurs a small premium (fee) on the amount borrowed. By default, the flash loan fee in Helios is 0.05% of the amount(will be subject to change). This means if you borrow 100 BTC, you must return 100.05 BTC in the same transaction. This fee rate is configurable via Helios governance – it’s stored as FLASHLOAN_PREMIUM_TOTAL in the protocol parameters and can be adjusted (in basis points) through a governance vote .

The collected premium is split between liquidity providers and the Helios protocol (treasury) according to set ratios :

• Liquidity Providers’ Share: By default, 100% of the flash loan fees go to the pool’s liquidity providers. The fee is added to the reserve, increasing the reserve’s liquidity index and thereby effectively accruing to hToken holders as extra interest. (For example, after a flash loan, depositors in that asset will see a slight increase in the interest earned due to the premium that was paid back into the pool.)

• Protocol/Treasury Share: Helios can allocate a portion of the flash fees to its treasury if desired. This portion is tracked by FLASHLOAN_PREMIUM_TO_PROTOCOL. If, say, the premium to protocol were set to 10% of the total fee, then liquidity providers would get the remaining 90%. (For example, with a 0.05% total fee, 0.045% would go to LPs and 0.005% to treasury in that scenario.)

Fee waivers: In Helios, certain addresses can be approved as Flash Borrowers via the ACL (Access Control List), allowing them to take flash loans without paying the fee. This is intended for trusted contracts or use cases (perhaps inter-protocol arbitrage or bridge contracts) where the protocol is comfortable waiving the premium. By default, unless an address is whitelisted by governance as an approved FLASH_BORROWER, the fee applies to everyone for flashLoan(). (The flashLoanSimple() method does not support fee waivers at all , so even whitelisted addresses must pay the fee if using the single-asset function.)

Collateralized flash loan fee: If a flash loan is taken with the intention of opening a regular debt (see Supported Modes below), the flash loan premium for that portion may effectively be waived. In other words, when a user uses flashLoan() and chooses to incur a normal borrow instead of repaying, Helios does not charge the one-time flash loan fee on that amount. This makes sense because that portion becomes a standard loan that will accrue normal interest over time, rather than a true one-block loan. The borrower will still owe the regular ongoing interest on the new debt, but no 0.05% instant fee is taken for the converted amount. However, any portion of the flash loan that is returned immediately (mode 0) will incur the 0.05% fee as usual.

Execution Flow and Callback

Using a flash loan in Helios involves a specific sequence of actions and a callback mechanism. Below is the typical flow, step-by-step:

1. Initiating the Flash Loan: Your smart contract (the flash loan receiver) calls the Helios Pool contract’s flashLoan() or flashLoanSimple() function. You specify the asset(s) and amount(s) you want to borrow, the address of your receiver contract, and additional parameters. For example, to borrow 10,000 USDC and 1 BTC in one go, you would call flashLoan(receiver, [USDC, BTC], [10000e6, 1e8], [0,0], address(this), params, 0) – here we requested USDC and BTC with modes 0 (meaning we intend to return both) and provided our contract as the receiver. If using flashLoanSimple for a single asset, the call would be similar: flashLoanSimple(receiver, USDC, 10000e6, params, 0). (The params and referralCode fields can usually be set to an empty byte array and 0, respectively, if not needed. The referral code is an optional feature currently inactive in Helios, so it’s typically just 0 .)

2. Fund Transfer to Receiver: The Pool contract verifies that each requested asset is available in the reserve (and that flash loans are allowed for those assets). It will also check that borrowing is enabled for those assets (flash loans won’t work on assets that are not enabled for borrowing) and that the requested amounts do not exceed the available liquidity. Once checks pass, the Pool contract transfers the requested amounts of each asset from the pool to your receiverAddress contract. These funds are essentially taken from the reserves (temporarily reducing the backing of hTokens until they are returned).

3. Callback – executeOperation: After sending the funds, the Pool contract calls the executeOperation(...) function on your receiver contract. This is the callback where your contract implements its custom logic. Depending on which flash loan function was used, the signature of executeOperation differs:

   • For flashLoan() (multi-asset), your contract must implement executeOperation(address[] assets, uint256[] amounts, uint256[] premiums, address initiator, bytes params) returns (bool). Helios will pass in the arrays of assets and amounts you borrowed, an array of the fee amounts (premiums) for each (calculated as amount * 0.05% unless waived), the initiator address (the original caller of the flashLoan, usually your own address), and the params data blob you provided.

   • For flashLoanSimple() (single asset), the interface is executeOperation(address asset, uint256 amount, uint256 premium, address initiator, bytes params) returns (bool) – with the single asset and amount and their fee .

   In this callback, you can now use the borrowed funds freely: execute arbitrage trades, swap assets, refinance loans on other platforms, or any other logic. This is where the flash loan’s power is realized, as you have a large amount of BTC, ETH, or stablecoins at your disposal mid-transaction. For example, you might use the 10,000 USDC to buy an underpriced asset and then sell it somewhere else for 10,200 USDC, netting profit.

4. Preparing Repayment: Before your executeOperation function finishes, you must arrange to repay the flash loan (for any assets you intend to return). Typically, this means ensuring your contract now holds at least amount + premium of each borrowed asset that must be paid back. You do not manually send the funds back to the Pool; instead, you give the Pool contract permission to pull the funds from your contract. In practice, inside executeOperation your contract will call the ERC-20 approve() function to approve the Helios Pool to transfer the owed amounts from your contract. For example, if you borrowed 10,000 USDC, you should approve the Pool for 10,000 + 0.05% = 10,005 USDC. If you borrowed 1 BTC, approve 1.0005 BTC for the Pool (assuming a 0.05% fee). If you are using flashLoan() and plan to not repay a portion because you want it converted into a normal loan, then you wouldn’t need to have that portion on hand or approve it – instead, you must have sufficient collateral (or credit line) to cover it, as described next.

5. Completing the Flash Loan: When your executeOperation function returns, it should return true (a boolean flag indicating success; returning false or failing will revert the whole transaction). The control goes back to the Pool contract. Now the Pool will attempt to settle the loan. For each asset borrowed:

   • If you indicated mode = 0 for that asset (or you used flashLoanSimple which always implies mode 0), the Pool contract expects full repayment. It will internally call to transfer the amount + premium from your receiver contract. Thanks to the approval in the previous step, the Pool can pull the funds. If the full amount plus fee isn’t available (e.g. your contract balance is too low or you didn’t approve enough), this transfer will fail and cause a revert.

   • If you specified an interestRateMode = 1 or 2 for that asset in flashLoan() (meaning you chose to open a debt for that asset instead of repaying), then the Pool will not pull the principal amount back. Instead, it will record that amount as a normal borrow on behalf of the onBehalfOf address you provided. Essentially, a regular loan is opened for that asset as if the user borrowed it from Helios. (Mode 1 corresponds to a stable-rate loan and 2 to a variable-rate loan, though stable-rate availability depends on the asset’s configuration. In most cases, variable-rate (2) is used .) The Pool will still attempt to collect the premium fee if one was due, but as noted earlier, in the current Helios implementation, when converting to a debt position, the flash fee is effectively zero for that principal. The borrower will now owe that asset to the protocol under standard loan terms, secured by their collateral or via a credit delegation arrangement. This is an active research area and will be subject to change in near future.

   • If some assets in a multi-asset flashLoan were fully repaid (mode 0) and others were converted to debt (mode 2), the Pool handles each accordingly. It’s possible in one flash loan call to return some assets immediately while incurring debt on others.

   After handling repayment or debt creation for each asset, the flash loan transaction is complete. All this happens within one block. If every asset is accounted for (either returned or properly turned into an outstanding loan), the transaction succeeds and the flash loan is effectively closed. If any asset was not returned and could not be converted into a valid debt (for example, due to lack of collateral or violation of borrowing constraints), the entire transaction will revert, undoing all intermediate actions. This ensures that the pool neither loses liquidity nor ends up with an under-collateralized loan.

To illustrate the callback, here is a simplified example of a flash loan receiver contract implementing executeOperation for a single-asset flash loan:

contract MyFlashLoanReceiver is IFlashLoanSimpleReceiver {
    address constant POOL = /* Helios Pool contract address */;

    // This function is called by Helios after it sends the funds
    function executeOperation(
        address asset,
        uint256 amount,
        uint256 premium,
        address initiator,
        bytes calldata params
    ) external override returns (bool) {
        // Your custom logic using the flash-loaned funds:
        // e.g., arbitrage, swap, repay another protocol debt, etc.

        // At the end, ensure the Pool can be repaid
        uint256 totalOwed = amount + premium;
        IERC20(asset).approve(POOL, totalOwed);
        return true;
    }
}

In the above code, Helios Pool will send amount of asset to the contract, then this function executes. The contract does whatever is needed with amount. Finally, it approves the Pool to take amount + premium back. If this contract were to use flashLoan() for multiple assets, it would implement the version of executeOperation with array parameters and loop through each asset to approve the necessary amounts.

Supported Flash Loan Modes

Helios flash loans support two modes of operation for each asset borrowed in a flashLoan transaction:

• Standard (No Debt) Mode: “Uncollateralized” flash loan. This is the classic flash loan behavior – you borrow assets with no collateral and you must repay them within the transaction. In flashLoan() this corresponds to an interestRateMode of 0 for a given asset (and in flashLoanSimple all loans are implicitly mode 0). Use this mode when you just need temporary liquidity and you intend to give back everything plus fees. For example, if you need 100 BTC just for the duration of a transaction to execute an arbitrage, you would use mode 0 (no debt), borrow 100 BTC, do your trade, then return 100.05 BTC by the end. If you fail to return it, nothing happens except a transaction revert – you won’t get to keep the BTC (and your transaction costs still apply).

• Collateralized (Debt) Mode: “Flash Borrow with collateralization”. This mode allows a flash loan to seamlessly become a regular loan if not repaid. In flashLoan(), you achieve this by setting the interestRateMode to 1 (stable) or 2 (variable) for one or more of the assets you borrow. At the end of the transaction, any asset with mode 1 or 2 will not be taken back by the pool. Instead, the amount is left outstanding as a normal borrow on the protocol, and it will be linked to the onBehalfOf address provided in the flashLoan call. Essentially, you have used your existing collateral (or someone’s credit delegation to you) to secure that portion of the flash loan, turning it into a standard loan. This is useful for scenarios like refinancing debt or leveraging up in one transaction. For instance, suppose you have supplied BTC as collateral in Helios and you want to borrow USDC against it. You could do a flash loan of USDC with mode 2 (variable debt) on USDC and onBehalfOf = your own address. During the flash loan, you might swap some of that USDC for more BTC (increasing your collateral), and in the end, you do not repay the USDC – it becomes a normal variable-rate USDC loan on Helios, now backed by your increased BTC collateral. You’ve effectively taken a loan and increased collateral in one atomic step (leveraging yourself) without going through multiple transactions.

  • Credit Delegation: The onBehalfOf parameter allows the debt to be opened in someone else’s account (with their permission). If using credit delegation, the onBehalfOf address must have pre-approved a debt allowance for the asset to the flash loan initiator. Helios will then assign the debt to that third party’s account (who gave you borrowing permission) . This is an advanced use case, but it follows the same mode concept.

  • No Flash Fee on Debt Mode: As noted earlier, when you use the debt mode, Helios does not charge the one-time flash loan fee for that asset. You are starting a regular loan, so you will pay normal interest over time, but you save the 0.05% immediate premium that would otherwise apply. Assets in standard mode in the same flashLoan will still pay the fee, but assets in debt mode do not pay the flash fee (assuming the transaction succeeds and the debt is opened).

Isolation Mode Compatibility: Helios supports an Isolation Mode for certain high-risk or new collateral assets. If the account taking a flash loan is using an isolated asset as collateral, there are restrictions on what can be borrowed. Isolation mode assets can only be used to borrow specific, approved stablecoins, up to a debt ceiling. This rule applies to flash loans that open debt positions as well. In practical terms: if you attempt to use a collateralized flash loan (debt mode) and the onBehalfOf address is backed by an isolated collateral, the only assets you’re allowed to leave as debt are the approved stablecoins for that isolation mode. Any attempt to open a debt in a different asset would fail the protocol’s risk checks and revert the transaction. The flash loan will only succeed if it adheres to the isolation mode constraints (e.g. borrowing a stablecoin like HUSD against an isolated collateral like a new token, and staying within that token’s debt ceiling). If you are just doing a standard flash loan (no debt) in isolation mode, there’s no special restriction – since you’re not opening a new debt, you just need to repay as normal.

Restrictions and Safety Checks

Helios Finance implements several safeguards and checks around flash loans to maintain protocol security and solvency:

• Borrowing Enabled Only: You can only flash borrow assets from Helios that have borrowing (and flash loans) enabled in their reserve configuration. If an asset is paused, disabled for borrowing, or otherwise restricted by governance, flashLoan calls for that asset will not be allowed. (Helios can selectively disable flash loans per asset if needed to mitigate risk, though by default it’s enabled for all borrowable assets.)

• Sufficient Liquidity: The amount requested for each asset cannot exceed the available liquidity in the pool. Helios will not mint new tokens or use other users’ collateral to fulfill a flash loan – it uses what’s currently free in the reserve. If, for example, the pool only has 50 BTC free (unborrowed), you cannot flash borrow 100 BTC. This ensures flash loans don’t put the pool into a temporary negative balance.

• Atomic Reversion on Failure: If the borrower does not return the funds and does not have them converted into an allowed debt by the end of the transaction, the entire transaction fails (reverts). This means any intermediate actions the borrower took (trades, etc.) are undone. This all-or-nothing enforcement is what makes an unsecured loan possible — there’s never a scenario where the borrower gets to keep the funds without providing collateral or repayment. From the protocol’s perspective, either the flash loan is repaid (or safely turned into a collateralized loan) or it never happened at all.

• Approval for Repayment: The flash loan receiver contract must approve the Pool to pull the owed amounts before finishing execution. If the approval isn’t given or is insufficient, the subsequent transfer will fail and cause a revert. This requirement prevents a borrower from absconding with funds – the Pool doesn’t rely on the borrower voluntarily paying back; it takes the funds as long as they’re available in the contract. Developers using flash loans must be mindful to set these approvals, and Helios will enforce that the callback contract indeed returns true and allows the withdrawal.

• Collateral and Credit Checks for Debt Mode: If using the debt mode (interestRateMode 1 or 2 in flashLoan), the borrower (or onBehalfOf account) must have adequate collateral in Helios at the moment of conversion to support the new debt, or a credit delegation line in place. All normal borrowing conditions are applied. This includes checking the user’s health factor won’t drop below 1, respecting loan-to-value (LTV) ratios of collateral, and ensuring the debt doesn’t exceed any borrow caps or isolation mode debt ceilings for that asset. If any of these checks fail (e.g., you try to open too large a debt for your collateral or an unsupported asset in isolation mode), the flash loan will revert rather than create an invalid loan.

• Reentrancy Protections: The Helios Pool contract is built to prevent dangerous reentrancy or callback abuse. The flash loan is executed in a controlled manner: funds transfer then callback then repayment. It’s not possible to initiate another flash loan from within a flash loan on the same Pool (the contract will block it to maintain consistency). Additionally, developers of receiver contracts should avoid actions that could lead to recursive calls into Helios in the same flash loan, as those will likely be prevented by the Pool’s internal guards.

• Interface Compliance: The receiver must implement the correct interface and return the expected boolean. If the Pool calls your contract and the function isn’t present or doesn’t return true, the call will fail and revert the transaction. Helios likely uses an isContract check on the receiver address to ensure it’s a contract (not an EOA) before attempting the flash loan, adding an extra layer of safety to prevent sending funds to non-contract addresses by mistake.