Change the end user fee

FEE_MANAGER should be used to perform these actions.

Set the management fee

Management fee is taken at deposit time. You can set it by calling the setManagementFee(uint256 newManagementFee) where newManagementFee is the amount of assets (ie. ERC20) taken at each deposit.

Set the performance fee

Performance fee is computed based on the global rewards generated by the Vault. It can be set by calling the setManagementFee(uint256 newManagementFee) where newManagementFee is the fee in bps unit.

Change commission recipients

ADMIN should be used to perform these actions.

Set fee recipients

To set the difference recipients of the commissions, you can call the setFeeRecipients(FeeRecipient[] memory recipients) function where recipients is an array of the following structure:

struct FeeRecipient {
        address recipient;
        uint256 managementFeeSplit;
        uint256 performanceFeeSplit;
}

where:

• recipient is the address of the fee recipient

• managementFeeSplit is the share of the recipient on the management fee (in bps)

• performanceFeeSplit is the share of the recipient on the performance fee (in bps)

The sum of all managementFeeSplit and the sum of all performanceFeeSplit must be 100 * 10^decimal.

Vault administration (partner)

Vaults are managed by partners using several key admin roles:

• SYS_ADMIN: wallet responsible for contract administration and other role attribution

• FEE_MANAGER: wallet responsible for changing the end user fee, the split between multiple recipients, and for claiming the commission.

• SANCTIONS_MANAGER: wallet responsible for enabling the OFAC sanctioned wallet check.

• CLAIM_MANGER: wallet responsible for claiming additional rewards from the lending protocols

• PAUSER: wallet responsible for pausing all interaction with vault contracts, managed by Kiln as a security failsafe

• UNPAUSER: waller responsible for unpausing the contract

It is recommended to have multi-sig wallets for these roles with a strong quorum security.

NOTE: You can only have 1 wallet assigned as SYS_ADMIN, but multiple wallets assigned to all other roles.

Upgradability structure (Kiln)

Kiln DeFi Vaults

Kiln DeFi vaults follow the beacon proxy pattern where all vaults fetch their implementation address from a VaultUpgradeableBeacon smart contract.

This is administered by 4 roles:

• PROXY_ADMIN: a multisig quorum between Kiln and third parties responsible for attributing the below roles

• PAUSER: a wallet responsible for pausing all interaction with vault contracts, managed by Kiln as a security failsafe

• FREEZER: a multisig quorum between Kiln and third parties responsible for freezing Vault implementation (to make it non-upgradeable)

• IMPLEMENTATION_MANAGER: a multisig quorum between Kiln and third parties responsible for upgrading Vault implementations

Kiln DeFi Connectors

Kiln DeFi Connectors also follow the beacon proxy pattern where each connector implementation address is fetched from a ConnectorRegistry contract.

This is administered by 4 roles:

• ADMIN: a multisig quorum between Kiln and third parties responsible for attributing the below roles

• PAUSER: a wallet responsible for pausing all interaction with connector contracts, managed by Kiln as a security failsafe

• FREEZER: a multisig quorum between Kiln and third parties responsible for freezing connector implementations (to make some of them non-upgradeable)

• CONNECTOR_MANAGER: a multisig quorum between Kiln and third parties responsible for upgrading connectors implementation

Partners can choose any asset available to supply on the supported protocols and chains below.

For each unique 'protocol <> asset <> chain' combination, a dedicated vault is deployed for the integration.

For example, if an partner wants to create a strategy around USDC on Ethereum mainnet for AAVE v3, Compound v3, and on Base for Compound v3, then 3 vaults will be deployed:

• USDC <> Aave v3 <> mainnet

• USDC <> Compound v3 <> mainnet

• USDC <> Compound v3 <> Base

Supported protocols, assets and chains

Please be aware that assets with negligible Total Value Locked (TVL) or minimal yield generation are not listed in our documentation for convenience. We aim to update this page on a monthly basis so the details below may change.

For the latest information, you can always access the lending protocol directly through the links provided below or you can use this link that provides a single view of all protocols and asset yield.

We are always evaluating new DeFi protocols to support, and can quickly add new protocols based on demand. If your preferred integration or chain is not listed here please contact us to discuss. Adding support for more can be simple.

There are 2 ways to query reporting data for Kiln DeFi:

1. Using Kiln Connect API (recommended): a simple REST API doing all aggregation for you

2. Using Kiln public TheGraph instances directly

Get a user position(s) and total rewards inside of Vault(s)

Route: GET /v1/defi/v1/stakes

Goals

• Get a list of positions inside a list of vaults

• Positions include current deposited balance and total rewards and withdrawn amounts

• This data can be used to showcase current holdings of a user in Kiln DeFi vaults

Query parameters

• wallets: comma-separated list of wallet address to fetch position data for

• vaults: comma-separated list of vaults, where each value has the protocol_address format

These are not exclusive and can be used together. Some use-cases could be:

• query all current positions of a vault or a list of vaults

• query all current positions of a user or a list of users

• query all current positions of a user or a list of users within a vault or a list of vaults

Specs: https://docs.api.mainnet.kiln.fi/preview.html#tag/defi/operation/getDefiStakes

Get Operations on a position

Route: GET /v1/defi/v1/operations

Goals

• Get all operations performed on a list of positions inside a list of vaults

• Operations include deposit and withdrawal operations

• This data can be used for accounting reconciliation

Query parameters

• wallets: comma-separated list of wallet address to fetch position data for

• vaults: comma-separated list of vaults, where each value has the protocol_address format

These are not exclusive and can be used together. Some use-cases could be:

• query all operations of positions on a vault or a list of vaults

• query all operations of positions of a user or a list of users

• query operations of positions of a user or a list of users within a vault or a list of vaults

Specs: https://docs.api.mainnet.kiln.fi/preview.html#tag/defi/operation/getDefiOperations

Get Statistics of a vault

Route: GET /v1/defi/v1/network-stats

Query parameters

• vaults: comma-separated list of vaults, where each value has the protocol_address format

Specs: https://docs.api.mainnet.kiln.fi/preview.html#tag/defi/operation/getDefiNetworkStats

Kiln DeFi Vault smart contracts adhere to the standard, making integration straightforward. When users deposit tokens, they receive shares representing their position. For a better user experience, we recommend abstracting any asset-to-share conversions and always displaying asset amounts on the UI instead of share amounts.

Here is the ABI of the Vault contract:

1. Depositing

Before depositing 'x' assets, ensure the user has approved the vault to spend 'x' on their behalf via the asset contract.

• Check Allowance: Call the allowance(address owner, address spender) → uint256 function on the ERC20 asset contract.

• Increase Allowance: Use the approve(address spender, uint256 amount) → bool function on the ERC20 asset contract to increase the allowance to the desired deposit amount.

Before depositing X assets, you must make sure the user approved the vault to spend X on its behalf on the asset contract.

Note: Only have the user approve the exact amount they intend to deposit into the vault.

To deposit an amount of the vault's ERC20, the transaction sender must call the deposit(uint256 assets, address receiver) function, where assets is the amount of ERC20 to deposit in the strategy, and receiver is the address that should own the deposited position.

(Optional) If you need to compute the amount of shares the user will receive before making a deposit, you can preview the amount by calling previewDeposit(uint256 assets), where assets is the amount of ERC20 to deposit.

2. Get the balance in assets

3. Exiting a position

Case 1: exit part of a position

In this case, we expect the user to input the amount of ERC20 they want to withdraw and then call the withdraw(uint256 assets, address receiver, address owner) function. Here:

• assets is the amount of ERC20 to withdraw.

• receiver is the address that will receive the redeemed ERC20.

• owner is the address of the position owner (the same as the transaction sender).

Case 2: exit a position fully

To exit the entire position, the best approach is to determine the user's share amount and redeem it. Follow these steps:

1. Retrieve the share amount of the user's position using the balanceOf(address owner) function, where owner is the address of the position owner.

2. Redeem the shares by calling the redeem(uint256 shares, address receiver, address owner) function, where:

   • shares is the amount of shares to redeem.

   • receiver is the address that will receive the redeemed ERC20.

   • owner is the address of the position owner (the same as the transaction sender).