Hooks

Silo Protocol Hooks System

The Silo Protocol Hooks System provides an extensible mechanism for interacting with core actions like deposits, withdrawals, borrowing, repayments, leverage operations, collateral transitions, switching collateral, flash loans, and liquidations. Hooks allow external systems to execute custom logic before or after protocol actions, offering flexibility for validation, logging, or integration with external contracts. While the protocol is fully functional without hooks, they enhance its modularity and allow for seamless interaction with other decentralized systems.

  • Overview

  • Deposit function hook actions

  • Withdraw function hook actions

  • Borrow function hook actions

  • Repay function hook actions

  • Leverage Same Asset function hook actions

  • Transition Collateral function hook actions

  • Switch Collateral To This Silo function hook actions

  • Flash Loan function hook actions

  • Liquidation Call function hook actions

  • Share Token Transfer hook

  • Share Debt Token Transfer hook

Overview

The Silo Protocol is a decentralized lending protocol. It allows users to deposit assets, borrow funds, and manage collateral securely. One of the key features of the protocol is its Hooks System, which provides an extensible mechanism for interacting with protocol actions such as deposits, withdrawals, borrowing, repayments, liquidations, and other advanced actions like flash loans and leverage operations.

The hooks system allows external contracts or modules to execute additional logic at two key points: before and after the core logic of each protocol action. While the protocol is fully functional without hooks, the system provides an extension point for developers and users who wish to enforce additional checks, perform external calls, or execute custom business logic surrounding core operations.

Each action within the protocol (except for the share tokens transfer) is associated with two types of hooks:

  • Before Action Hook: Invoked before any logic of the action is executed. This can be used to perform validation checks, eligibility assessments, or custom logic before the main action takes place.

  • After Action Hook: Invoked after all logic of the action is completed. This allows developers to perform follow-up tasks such as logging, notifications, or additional off-chain and on-chain integrations.

Share tokens transfer only has an After Action Hook.

Some concepts

  1. Collaterals:

    • The protocol supports two types of collateral: Hook.COLLATERAL_TOKEN (borrowable collateral) and Hook.PROTECTED_TOKEN (non-borrowable collateral). Borrowable collateral earns interest as it is available for lending, while protected collateral provides security for the user, ensuring liquidity and immediate access to their funds.

    • Transitions between these collateral types (e.g., transitioning from Hook.PROTECTED_TOKEN to Hook.COLLATERAL_TOKEN).

  2. Token Transfers:

    • The hooks system also notifies about the share token transfers that occur during key actions like deposits, withdrawals, borrow operations or when share tokens are transferred via ERC-20 transfer or transfer from function directly.

    • For instance, Hook.SHARE_TOKEN_TRANSFER is invoked during deposit and withdrawal actions to handle share tokens and during borrow and repay actions to manage debt tokens.

  3. Transitioning Between Collateral Types:

    • Users can transition their assets between Hook.PROTECTED_TOKEN and Hook.COLLATERAL_TOKEN and vice verse without transferring the underlying assets. This transition is crucial for users who want to switch between protected and borrowable collateral, enabling interest generation or enhanced security.

Deposit function hook actions

  • Action: Hook.depositAction(depositType)

    • Context: This hook is invoked during deposit operations, allowing actions to be taken before and after executing the deposit logic. Depositors receive shares representing their stake in the vault, and this process can trigger other hook actions, such as token transfers, when these shares are minted. The protocol supports different types of deposits that determine liquidity and risk preferences.

    • Parameters:

      • depositType: This refers to the type of deposit being made, which can either be a borrowable or non-borrowable deposit, as defined by Hook.COLLATERAL_TOKEN and Hook.PROTECTED_TOKEN respectively.

    • Deposit Types:

      • Hook.COLLATERAL_TOKEN:

        • This represents a borrowable deposit. When a user deposits assets under this type, other users can borrow the assets within the protocol.

      • Hook.PROTECTED_TOKEN:

        • This represents a non-borrowable deposit. Deposits of this type are protected from being borrowed by other participants, providing a higher level of security for the depositor.

    • Before Deposit Data:

      • Structure: The data processed before the deposit is encoded as abi.encodePacked(assets, shares, receiver).

      • Fields:

        • assets: The assets (tokens) being deposited into the protocol.

        • shares: The shares generated from the deposit represent the depositor’s ownership or claim within the protocol.

        • receiver: The address of the recipient (typically the depositor) who will receive the shares generated from the deposit.

      • Purpose: The beforeAction hook is called before any logic of the deposit action is executed. External systems can perform additional checks or actions before the main deposit logic runs. For example, this hook could be used to check whether a wallet is on a restricted list (e.g., OFAC sanctions) and block the deposit if necessary. The core deposit logic (including input validation and collateral checks) does not rely on this hook.

      • Decoding Hook Input Example:

        Hook.BeforeDepositInput memory input = Hook.beforeDepositDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeDepositDecode function helps access fields like assets, shares, and receiver, allowing developers to apply pre-deposit checks.

    • After Deposit Data:

      • Structure: The data processed after the deposit is encoded as abi.encodePacked(assets, shares, receiver, receivedAssets, mintedShares).

      • Fields:

        • assets: The tokens deposited into the protocol.

        • shares: The shares generated from the deposit.

        • receiver: The address where the shares will be sent (typically the depositor).

        • receivedAssets: The actual assets received by the protocol after the deposit.

        • mintedShares: The number of shares minted due to the deposit reflects the depositor’s claim in the protocol.

      • Purpose: The afterAction The hook is called after all the logic for the deposit action is completed. It allows external systems to perform follow-up tasks or adjustments after processing the deposit. For instance, this hook can trigger notifications or other logic once the deposit is finalized.

      • Decoding Hook Input Example:

        Hook.AfterDepositInput memory input = Hook.afterDepositDecode(_inputAndOutput);

        • Explanation: This code example shows how developers can decode the data sent to the afterAction hook using the Hook library. The afterDepositDecode function allows easy access to fields such as receivedAssets and mintedShares, simplifying post-deposit logic.

Share Token Transfer Hook (During Deposit)

  • During the deposit, share tokens are minted to the depositor. This action triggers a Share Token Transfer Hook, which manages the token transfer logic. For more details, refer to the Share Token Transfer Hook section.

Withdraw function hook actions

  • Action: Hook.withdrawAction(collateralType)

    • Context: This hook is invoked during withdrawal operations, allowing for actions to be taken before and after executing the withdrawal logic. Different types of collateral influence the conditions under which withdrawals occur.

    • Parameters:

      • collateralType: This refers to the type of collateral being withdrawn, which can either be a borrowable or non-borrowable collateral, as defined by Hook.COLLATERAL_TOKEN and Hook.PROTECTED_TOKEN respectively.

    • Before Withdraw Data:

      • Structure: The data processed before the withdrawal is encoded as abi.encodePacked(assets, shares, receiver, owner, spender).

      • Fields:

        • assets: The assets (tokens) being withdrawn from the protocol.

        • shares: The shares being burned or redeemed in exchange for the withdrawal of the corresponding assets.

        • receiver: The address of the recipient (typically the depositor) who will receive the withdrawn assets.

        • owner: The owner of the assets (typically the depositor).

        • spender: The entity authorized to initiate the withdrawal.

      • Purpose: The beforeAction hook is called before any logic of the withdrawal action is executed. External systems can perform additional checks or actions before the main withdrawal logic runs. For instance, this could restrict withdrawals from a specific wallet that has violated protocol rules. The core withdrawal logic (including eligibility checks and asset transfers) does not depend on this hook.

      • Decoding Hook Input Example:

        Hook.BeforeWithdrawInput memory input = Hook.beforeWithdrawDecode(_inputAndOutput);

        • Explanation: This code shows how developers can easily decode the data sent to the beforeAction hook using the Hook library. The beforeWithdrawDecode function simplifies access to the relevant data, such as assets, shares, receiver, owner, and spender, allowing the developer to apply pre-withdrawal logic as needed.

    • After Withdraw Data:

      • Structure: The data processed after the withdrawal is encoded as abi.encodePacked(assets, shares, receiver, owner, spender, withdrawnAssets, withdrawnShares).

      • Fields:

        • assets: The tokens/assets withdrawn from the protocol.

        • shares: The shares that were redeemed in exchange for the withdrawn assets.

        • receiver: The address where the assets will be sent (typically the depositor).

        • owner: The owner of the assets.

        • spender: The entity that initiated the withdrawal.

        • withdrawnAssets: The actual assets withdrawn from the protocol (may differ slightly from the input amount due to factors such as fees or slippage).

        • withdrawnShares: The number of shares burned as a result of the withdrawal.

      • Purpose: The afterAction hook is called after all logic of the withdrawal action is completed. It allows external systems to perform follow-up tasks or adjustments after processing the withdrawal. For example, this hook could trigger on-chain or off-chain events such as notifications or accounting updates. The core withdrawal logic (e.g., asset transfers and share adjustments) is fully executed before invoking this hook.

      • Decoding Hook Input Example:

        Hook.AfterWithdrawInput memory input = Hook.afterWithdrawDecode(_inputAndOutput);

        • Explanation: This code example shows how developers can decode the data sent to the afterAction hook using the Hook library. The afterWithdrawDecode function allows developers to access data such as withdrawnAssets and easily withdrawnShares for post-withdrawal logic.

Share Token Transfer Hook (During Withdraw)

  • During withdrawal, share tokens are burned to release the depositor's stake in the protocol. This action triggers a Share Token Transfer Hook, which manages the token transfer logic. For more details, refer to the Share Token Transfer Hook section.

Borrow function hook actions

  • Action: Hook.BORROW

    • Context: This hook is invoked during borrowing operations, allowing for actions to be taken before and after the borrow logic is executed. Borrowing operations in the protocol result in the minting of a debt token to represent the borrower’s debt position.

    • Before Borrow Data:

      • Structure: The data processed before the borrow action is encoded as abi.encodePacked(assets, shares, receiver, borrower).

      • Fields:

        • assets: The assets (tokens) being borrowed from the protocol.

        • shares: The shares representing the borrower’s debt or stake in the system.

        • receiver: The address of the entity receiving the borrowed assets.

        • borrower: The address of the borrower.

      • Purpose: The beforeAction hook is called before any logic of the borrow action is executed. External systems can perform additional checks or actions before the borrow logic runs. For example, this could be used to check the borrower’s status or eligibility. The core borrowing logic (e.g., collateral checks and interest calculations) does not depend on this hook.

      • Decoding Hook Input Example:

        Hook.BeforeBorrowInput memory input = Hook.beforeBorrowDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeBorrowDecode function allows easy access to fields like assets, shares, receiver, and borrower, enabling developers to apply pre-borrow logic as needed.

    • After Borrow Data:

      • Structure: The data processed after the borrow action is encoded as abi.encodePacked(assets, shares, receiver, borrower, borrowedAssets, borrowedShares).

      • Fields:

        • assets: The assets (tokens) borrowed from the protocol.

        • shares: The shares representing the borrower’s debt or stake in the system.

        • receiver: The address where the borrowed assets are sent.

        • borrower: The address of the borrower.

        • borrowedAssets: The actual assets borrowed from the protocol.

        • borrowedShares: The debt shares representing the borrowed amount.

      • Purpose: The afterAction hook is called after all logic of the borrow action is completed. It allows external systems to perform follow-up tasks or adjustments after the borrowing process has finished. For example, this hook could trigger updates to the borrower’s debt position. The core borrow logic (e.g., interest rate application and debt accounting) is fully executed before this hook is called.

      • Decoding Hook Input Example:

        Hook.AfterBorrowInput memory input = Hook.afterBorrowDecode(_inputAndOutput);

        • Explanation: This code example shows how developers can decode the data sent to the afterAction hook using the Hook library. The afterBorrowDecode function allows easy access to fields like borrowedAssets and borrowedShares, simplifying post-borrow logic.

Share Token Transfer Hook (During Borrow)

  • During the borrowing process, debt tokens are minted to represent the borrower's liability in the protocol. This action triggers a Share Token Transfer Hook for the DEBT_TOKEN type, which manages the token transfer logic for debt tokens. For more details, refer to the Share Debt Token Transfer hook section.

Repay function hook actions

  • Action: Hook.REPAY (beforeAction and afterAction)

    • Context: This hook is invoked during the repayment of borrowed assets, allowing for actions to be taken before and after the repayment logic is executed. When a user repays their debt, their debt position is adjusted accordingly, and the corresponding debt tokens are updated.

    • Before Repay Data:

      • Structure: The data processed before the repayment is encoded as abi.encodePacked(assets, shares, borrower, repayer).

      • Fields:

        • assets: The assets (tokens) being repaid to the protocol.

        • shares: The shares representing the borrower’s debt or stake in the system.

        • borrower: The address of the borrower whose debt is being repaid.

        • repayer: The address of the entity making the repayment (can be the borrower or a third party).

      • Purpose: The beforeAction hook is called before any logic of the repayment action is executed. It allows external systems to perform additional checks or actions before the repayment logic runs. For example, this could be used to verify the borrower’s debt position or enforce rules around who can repay the debt. The core repayment logic (e.g., debt adjustment and token transfers) does not depend on this hook.

      • Decoding Hook Input Example:

        Hook.BeforeRepayInput memory input = Hook.beforeRepayDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeRepayDecode function simplifies access to fields like assets, shares, borrower, and repayer, enabling developers to apply pre-repayment logic as needed.

    • After Repay Data:

      • Structure: The data processed after the repayment is encoded as abi.encodePacked(assets, shares, borrower, repayer, repaidAssets, repaidShares).

      • Fields:

        • assets: The assets (tokens) repaid to the protocol.

        • shares: The shares representing the borrower’s debt or stake in the system.

        • borrower: The address of the borrower whose debt is being repaid.

        • repayer: The address of the entity making the repayment.

        • repaidAssets: The actual assets repaid to the protocol.

        • repaidShares: The shares representing the amount of debt repaid.

      • Purpose: The afterAction hook is called after all logic of the repayment action is completed. It allows external systems to perform follow-up tasks or adjustments after the repayment process has finished. For example, this hook could update the borrower’s debt position or trigger notifications. The core repayment logic (e.g., debt reduction and share adjustments) is fully executed before this hook is invoked.

      • Decoding Hook Input Example:

        Hook.AfterRepayInput memory input = Hook.afterRepayDecode(_inputAndOutput);

        • Explanation: This code example shows how developers can decode the data sent to the afterAction hook using the Hook library. The afterRepayDecode function allows developers to access data such as repaidAssets and easily repaidShares for post-repayment logic.

Share Debt Token Transfer Hook (During Repay)

  • During the repayment process, debt tokens are burned to adjust the borrower’s debt position. This action triggers a Share Token Transfer Hook for the DEBT_TOKEN type, which manages the token transfer logic for debt tokens. For more details, refer to the Share Debt Token Transfer hook section.

Leverage Same Asset function hook actions

  • Action: Hook.LEVERAGE_SAME_ASSET (beforeAction and afterAction)

    • Context: This hook is invoked during leverage operations where the same asset is used for both deposit and borrowing. It allows for actions to be taken before and after executing the leverage logic. Debt and collateral tokens are transferred during this process to reflect the leveraged position.

    • Before Leverage Data:

      • Structure: The data processed before the leverage action is encoded as abi.encodePacked(depositAssets, borrowAssets, borrower, collateralType).

      • Fields:

        • depositAssets: The assets being deposited into the protocol as collateral.

        • borrowAssets: The assets being borrowed from the protocol.

        • borrower: The address of the borrower leveraging the assets.

        • collateralType: The type of collateral being used (either Hook.COLLATERAL_TOKEN or Hook.PROTECTED_TOKEN).

      • Purpose: The beforeAction hook is called before any logic of the leverage action is executed. External systems can perform checks or actions before the leverage logic runs. For example, this could involve verifying the borrower’s collateral or eligibility for leverage. The core leverage logic (e.g., collateral and debt adjustments) does not depend on this hook.

      • Decoding Hook Input Example:

        Hook.BeforeLeverageSameAssetInput memory input = Hook.beforeLeverageSameAssetDecode(_inputAndOutput);

        • Explanation: This code shows how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeLeverageSameAssetDecode function simplifies access to fields like depositAssets, borrowAssets, borrower, and collateralType, enabling developers to apply pre-leverage logic as needed.

    • After Leverage Data:

      • Structure: The data processed after the leverage action is encoded as abi.encodePacked(depositAssets, borrowAssets, borrower, collateralType, depositedShares, borrowedShares).

      • Fields:

        • depositAssets: The assets deposited into the protocol as collateral.

        • borrowAssets: The assets borrowed from the protocol.

        • borrower: The address of the borrower leveraging the assets.

        • collateralType: The type of collateral being used.

        • depositedShares: The shares representing the borrower’s collateral deposit.

        • borrowedShares: The shares representing the borrower’s debt position.

      • Purpose: The afterAction hook is called after all logic of the leverage action is completed. It allows external systems to perform follow-up tasks or adjustments after the leverage process has finished. For example, this hook could update the borrower’s leveraged position or notify external systems about the new debt and collateral state. The core leverage logic (e.g., token and share adjustments) is fully executed before this hook is invoked.

      • Decoding Hook Input Example:

        Hook.AfterLeverageSameAssetInput memory input = Hook.afterLeverageSameAssetDecode(_inputAndOutput);

        • Explanation: This code example shows how developers can decode the data sent to the afterAction hook using the Hook library. The afterLeverageSameAssetDecode function allows developers to access data such as depositedShares and borrowedShares for post-leverage logic easily.

Share Token Transfer Hooks (During Leverage Same Asset)

  • Debt Token Transfer:

    • During the leverage process, debt tokens are minted to represent the borrower’s debt position. This action triggers a Share Token Transfer Hook for the DEBT_TOKEN type, which manages the token transfer logic for debt tokens. For more details, refer to the Share Debt Token Transfer hook section.

  • Collateral Token Transfer:

    • Simultaneously, collateral tokens are transferred to represent the borrower’s collateral position. This action triggers a Share Token Transfer Hook for both COLLATERAL_TOKEN and PROTECTED_TOKEN types, depending on the type of collateral used. For more details, refer to the Share Token Transfer Hook section.

Transition Collateral function hook actions

  • Action: Hook.transitionCollateralAction(withdrawType) (beforeAction and afterAction)

    • Context: The transitionCollateral function allows users to transition from one type of collateral to another (e.g., from Hook.PROTECTED_TOKEN to Hook.COLLATERAL_TOKEN) without transferring underlying assets. This transition enables users to adjust their collateral based on their preference to either protect their assets or make them borrowable to earn interest. The transition involves a combination of both a withdraw and deposit action, representing the change in collateral type.

    • Parameters:

      • withdrawType: This refers to the type of collateral being transitioned from, which can either be Hook.COLLATERAL_TOKEN or Hook.PROTECTED_TOKEN.

    • Possible Actions:

      • Hook.TRANSITION_COLLATERAL | Hook.COLLATERAL_TOKEN: Represents transitioning from a borrowable collateral type to a protected one.

      • Hook.TRANSITION_COLLATERAL | Hook.PROTECTED_TOKEN: Represents transitioning from a protected collateral type to a borrowable one.

    • Process:

      • The transition involves first withdrawing the collateral from the current collateral type and then depositing it into the new collateral type. For example, if a user transitions from Hook.PROTECTED_TOKEN to Hook.COLLATERAL_TOKEN, the protocol first withdraws the protected deposit and then deposits it as borrowable collateral, enabling the user to earn interest. This operation happens without transferring the underlying assets.

    • Before Transition Collateral Data:

      • Structure: The data processed before the transition of collateral is encoded as abi.encodePacked(shares, owner, assets).

      • Fields:

        • shares: The shares representing the collateral being transitioned.

        • owner: The address of the entity that owns the collateral.

        • assets: The assets (tokens) being transitioned between collateral types.

      • Purpose: The beforeAction hook is called before any logic of the transition collateral action is executed. It allows external systems to perform checks or actions before the transition logic runs. For example, this could include verifying the user’s collateral state or eligibility for the transition. The core transition logic, which includes the virtual withdrawal and deposit, does not rely on this hook.

      • Decoding Hook Input Example:

        Hook.BeforeTransitionCollateralInput memory input = Hook.beforeTransitionCollateralDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeTransitionCollateralDecode function simplifies access to fields like shares, owner, and assets, allowing developers to apply pre-transition logic as needed.

    • After Transition Collateral Data:

      • Structure: The data processed after the transition of collateral is encoded as abi.encodePacked(shares, owner, assets).

      • Fields:

        • shares: The shares representing the collateral that has been transitioned.

        • owner: The address of the entity that owns the collateral.

        • assets: The assets (tokens) transitioned between collateral types.

      • Purpose: The afterAction hook is called after all logic of the transition collateral action is completed. It allows external systems to perform follow-up tasks or adjustments after processing the transition. For instance, external systems could update the user’s collateral type or adjust accounting based on the newly deposited and withdrawn collateral. The core transition logic is fully executed before this hook is invoked.

      • Decoding Hook Input Example:

        Hook.AfterTransitionCollateralInput memory input = Hook.afterTransitionCollateralDecode(_inputAndOutput);

        • Explanation: This code example shows how developers can decode the data sent to the afterAction hook using the Hook library. The afterTransitionCollateralDecode function allows developers to access data like easily shares, owner, and assets, simplifying post-transition logic.

Share Token Transfer Hooks (During Transition Collateral)

  • Collateral Token Transfer:

    • Collateral tokens are transferred during the transition to reflect the user's updated collateral position. This action triggers a Share Token Transfer Hook both Hook.COLLATERAL_TOKEN and Hook.PROTECTED_TOKEN types. These hooks manage the token transfer logic to reflect the change in collateral type during the transition. For more details, refer to the Share Token Transfer Hook section.

Switch Collateral to This Silo function hook actions

  • Action: Hook.SWITCH_COLLATERAL (beforeAction and afterAction)

    • Context: This hook is invoked when collateral is switched to the current silo. The function allows for actions to be taken before and after executing the collateral switch.

    • Before and After Switch Collateral Data:

      • Structure: The data processed for the switch collateral action is encoded as abi.encodePacked(msg.sender).

      • Fields:

        • msg.sender: The address of the user switching their collateral to this silo.

      • Purpose: The beforeAction and afterAction hooks allow external systems to perform additional checks or tasks before and after the collateral switch process. This might include verifying if the user can switch their collateral or handling post-switch operations such as updating the user’s collateral information.

      • Decoding Hook Input Example:

        Hook.SwitchCollateralInput memory input = Hook.switchCollateralDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the beforeAction or afterAction hook using the Hook library. The switchCollateralDecode function simplifies access to the msg.sender field, enabling developers to apply pre- and post-collateral switch logic as needed.

Flash Loan function hook actions

  • Action: Hook.FLASH_LOAN (beforeAction and afterAction)

    • Context: This hook is invoked during flash loan operations, allowing actions to be taken before and after executing the flash loan logic. Flash loans involve borrowing assets without collateral and without changing the Silo state, provided that the loan is repaid within the same transaction, along with a fee.

    • Before Flash Loan Data:

      • Structure: The data processed before the flash loan is encoded as abi.encodePacked(receiver, token, amount).

      • Fields:

        • receiver: The address receiving the flash loan.

        • token: The asset (token) being borrowed.

        • amount: The amount of the token being borrowed.

      • Purpose: The beforeAction hook is called before any logic of the flash loan is executed. It allows external systems to perform checks or tasks before the loan is issued. For example, the hook could verify the receiver's eligibility to take the flash loan or ensure that the request complies with external conditions.

      • Decoding Hook Input Example:

        Hook.BeforeFlashLoanInput memory input = Hook.beforeFlashLoanDecode(_inputAndOutput);

        • Explanation: This code shows how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeFlashLoanDecode function provides access to fields like receiver, token, and amount, allowing developers to apply pre-flash loan logic as needed.

    • After Flash Loan Data:

      • Structure: The data processed after the flash loan is encoded as abi.encodePacked(receiver, token, amount, fee).

      • Fields:

        • receiver: The address that received the flash loan.

        • token: The asset (token) that was borrowed.

        • amount: The amount of the token borrowed.

        • fee: The fee associated with the flash loan.

      • Purpose: The afterAction hook is called after all logic of the flash loan is executed, including the repayment of the loan and fee. It allows external systems to handle follow-up tasks, such as logging the loan details, tracking the fee paid, or adjusting balances after the transaction completes.

      • Decoding Hook Input Example:

        Hook.AfterFlashLoanInput memory input = Hook.afterFlashLoanDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the afterAction hook using the Hook library. The afterFlashLoanDecode function provides access to fields such as receiver, token, amount, and fee, enabling post-flash loan logic.

Liquidation Call function hook actions

  • Action: Hook.LIQUIDATION (beforeAction and afterAction)

    • Context: This hook is invoked when a liquidation of an insolvent position occurs, allowing for actions to be taken before and after the liquidation logic is executed. Liquidation typically involves selling collateral to repay debt and involves both collateral and debt token transfers.

    • Before Liquidation Call Data:

      • Structure: The data processed before the liquidation is encoded as abi.encodePacked(siloWithDebt, collateralAsset, debtAsset, borrower, debtToCover, receiveSToken).

      • Fields:

        • siloWithDebt: The address of the silo holding the debt position.

        • collateralAsset: The collateral asset that will be liquidated.

        • debtAsset: The debt asset that the borrower owes.

        • borrower: The address of the borrower being liquidated.

        • debtToCover: The amount of debt to be covered by the liquidation.

        • receiveSToken: Whether the liquidator will receive the SToken in return.

      • Purpose: The beforeAction hook is called before any logic of the liquidation call is executed. It allows external systems to check the liquidation conditions or perform any preparatory tasks. For instance, this could be used to validate the borrower's insolvency or assess the assets being liquidated.

      • Decoding Hook Input Example:

        Hook.BeforeLiquidationInput memory input = Hook.beforeLiquidationDecode(_inputAndOutput);

        • Explanation: This code shows how developers can decode the data sent to the beforeAction hook using the Hook library. The beforeLiquidationDecode function provides access to fields such as siloWithDebt, collateralAsset, debtAsset, and borrower.

    • After Liquidation Call Data:

      • Structure: The data processed after the liquidation is encoded as abi.encodePacked(siloWithDebt, collateralAsset, debtAsset, borrower, debtToCover, receiveSToken, withdrawCollateral, repayDebtAssets).

      • Fields:

        • siloWithDebt: The address of the silo holding the debt position.

        • collateralAsset: The collateral asset that was liquidated.

        • debtAsset: The debt asset that was covered.

        • borrower: The address of the borrower whose position was liquidated.

        • debtToCover: The amount of debt that was covered by the liquidation.

        • receiveSToken: Whether the liquidator received the SToken in return.

        • withdrawCollateral: The amount of collateral that was withdrawn.

        • repayDebtAssets: The amount of debt assets that were repaid.

      • Purpose: The afterAction hook is called after all logic of the liquidation call is executed. It allows external systems to perform follow-up tasks, such as recording the liquidation results or adjusting balances for the borrower or liquidator.

      • Decoding Hook Input Example:

        Hook.AfterLiquidationInput memory input = Hook.afterLiquidationDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the afterAction hook using the Hook library. The afterLiquidationDecode function provides access to fields such as withdrawCollateral, repayDebtAssets, and other key data from the liquidation process.

Share Token Transfer Hooks (During Liquidation)

  • Debt Token Transfer:

    • During the liquidation process, debt tokens are transferred or burned to reflect the repayment of the borrower's debt. This action triggers a Share Token Transfer Hook for the DEBT_TOKEN type, which manages the transfer of the debt tokens during liquidation. For more details, refer to the Share Debt Token Transfer hook section.

  • Collateral Token Transfer:

    • Collateral tokens are transferred as part of the liquidation process to represent the liquidation of collateral. This action triggers a Share Token Transfer Hook for both Hook.COLLATERAL_TOKEN and Hook.PROTECTED_TOKEN types. These hooks manage the transfer of collateral tokens to cover the borrower’s debt. For more details, refer to the Share Token Transfer Hook section.

Share Token Transfer Hook (AfterAction)

  • Action: Hook.shareTokenTransfer(tokenType) (afterAction)

    • Context: During the deposit process, shares are minted for the depositor to represent their stake in the protocol. This triggers a token transfer action where share tokens are transferred. The Hook.shareTokenTransfer hook is invoked after the shares are minted.

    • Parameters:

      • tokenType: This refers to the type of share token being transferred, defined by Hook.COLLATERAL_TOKEN and Hook.PROTECTED_TOKEN.

    • Share Token Types:

      • Hook.COLLATERAL_TOKEN:

        • These are share tokens minted for borrowable deposits, representing the depositor's stake in the vault.

      • Hook.PROTECTED_TOKEN:

        • These are share tokens minted for non-borrowable deposits, representing a protected stake in the vault that cannot be borrowed.

    • After Token Transfer Data:

      • Structure: The data processed after the token transfer is encoded as abi.encodePacked(sender, recipient, amount, balanceOfSender, balanceOfRecipient, totalSupply).

      • Fields:

        • sender: The address sending the share tokens.

        • recipient: The address receiving the share tokens.

        • amount: The amount of share tokens being transferred.

        • balanceOfSender: The balance of share tokens remaining with the sender.

        • balanceOfRecipient: The balance of share tokens now held by the recipient.

        • totalSupply: The total supply of the share tokens in the protocol.

      • Purpose: The afterAction hook is called after the share tokens are transferred. It allows external systems to monitor or act upon token transfers. For instance, this could be used to trigger accounting or balance updates after the token transfer is complete.

      • Decoding Hook Input Example:

        Hook.AfterTokenTransfer memory input = Hook.afterTokenTransferDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the afterAction hook for token transfers using the Hook library. The afterTokenTransferDecode function provides access to data like sender, recipient, and amount, which can be used in post-transfer logic.

Share Debt Token Transfer Hook (AfterAction)

  • Action: Hook.shareTokenTransfer(tokenType) (afterAction)

    • Context: This hook is invoked during the transfer of debt tokens that represent a borrower’s liability in the protocol. It is triggered after the debt tokens are transferred or minted in response to borrowing operations.

    • Parameters:

      • tokenType: The type of token being transferred, which in this case is Hook.DEBT_TOKEN.

    • Possible Actions:

      • Hook.SHARE_TOKEN_TRANSFER | Hook.DEBT_TOKEN: This action represents the transfer of debt tokens minted during borrowing activities. The debt tokens are used to track the borrower’s debt position within the protocol.

    • After Token Transfer Data:

      • Structure: The data processed after the token transfer is encoded as abi.encodePacked(sender, recipient, amount, balanceOfSender, balanceOfRecipient, totalSupply).

      • Fields:

        • sender: The address of the entity transferring the debt tokens (typically the borrower).

        • recipient: The address of the entity receiving the debt tokens (typically the protocol or null if the tokens are being minted).

        • amount: The amount of debt tokens being transferred.

        • balanceOfSender: The remaining balance of debt tokens held by the sender after the transfer.

        • balanceOfRecipient: The balance of debt tokens held by the recipient after the transfer.

        • totalSupply: The total supply of the debt tokens in the protocol after the transfer.

      • Purpose: This hook allows external systems to monitor or react to debt token transfers after borrowing actions. It can be used to log or update a borrower’s debt position, track debt token balances, or trigger off-chain or on-chain notifications based on the transfer of debt tokens.

      • Decoding Hook Input Example:

        Hook.AfterTokenTransfer memory input = Hook.afterTokenTransferDecode(_inputAndOutput);

        • Explanation: This code demonstrates how developers can decode the data sent to the afterAction hook using the Hook library. The afterTokenTransferDecode function simplifies access to the transfer data, such as sender, recipient, amount, and token balances.

PreviousDeploy custom market step by stepNextSource code and addresses

Last updated