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.

Kiln actively monitors all deployed smart contracts for suspicious activity and promptly responds to incidents.

Partners can hold the PAUSER role for added control, while Kiln continues to monitor and collaborates with partner security teams for investigations.

Alternatively, partners may delegate the PAUSER role to Kiln, allowing Kiln to swiftly pause contracts in response to incidents, which some partners prefer for faster response times.

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

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

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

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

Kiln DeFi

Kiln DeFi is a suite of smart contracts that our partners can use to enable native integration of DeFi protocols into their wallets or platforms. The solution is 100% onchain, fully automated, and provides a simplified integration. Utilize the Kiln API for native integration directly within your platform or customize our widget to fit your needs.

The platform is currently integrated with many protocols allowing partners to leverage Kiln's tech stack to offer these services to their end users

Values

Kiln DeFi is designed with the same principles as other smart contract-based products:

• Transparency: All actions, including deposits, withdrawals, and fee dispatching, occur on-chain and are easily trackable via event emissions.

• Security: The audited contracts are secured with numerous on-chain and off-chain safety measures in place to protect users' funds and rewards.

• Flexibility: partners can choose from multiple DeFi protocol integration types and create custom offerings.

Project Licence

Kiln DeFi is under the BUSL-1.1 licence, some smart contract public interfaces are under MIT licence.

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.

Kiln aims to provide a secured and enhanced experience of DeFi through the Kiln DeFi smart contracts.

Kiln DeFi products have been audited multiple time by various security firms and are under exhaustive monitoring and security practices to limit security risks as much as possible.

Kiln DeFi

Audits

Bug Bounty

• Cantina

• Immunefi

A $500,000 max bounty program is live since September 9th 2024. All bug reports must come with a working PoC impacting asset listed in the "Assets in Scope" section of the program which only addresses smart contracts.

For any findings you can also directly contact security@kiln.fi.

Kiln DeFi Vault smart contracts adhere to the ERC4626 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

curl https://api.kiln.fi/v1/defi/v1/stakes?users=$ADDRESS1&vaults=$VAULT1,$VAULT2 \
   -H "Authorization: Bearer $API_TOKEN"

200
{
  "stakes": [
    {
      "current_balance": 1880000,
      "asset": "0x94a9d9ac8a22534e3faca9f4e7f2e2cf85d5e4c8",
      "total_rewards": 42000,
      "asset_symbol": "USDC",
      "total_deposited_amount": 1980000,
      "total_withdrawn_amount": 100000,
      "vault": "0x9aB5F9101a3C1B868e2c422E294cc2ee685551D5",
      "chain": "ethereum"
    },
    {
      "current_balance": 1880000,
      "asset": "0x94a9d9ac8a22534e3faca9f4e7f2e2cf85d5e4c8",
      "total_rewards": 1330,
      "asset_symbol": "USDC",
      "total_deposited_amount": 1980000,
      "total_withdrawn_amount": 100000,
      "vault": "0x8aB6F9101a3C1B868e2c422E294cc2ee686662Ab",
      "chain": "ethereum"
    }
  ]
}

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).

If you want to perform your own code review, you can use the verified contract links on common block explorers like Etherscan.

All the code is available under the BUSL-1.1 licence.

Ethereum mainnet

BNB mainnet

Arbitrum mainnet

Polygon mainnet

Optimism mainnet

Smart contract risk

It is important to acknowledge the inherent risk that the Kiln smart contracts may contain vulnerabilities or bugs.

Our smart contracts have undergone comprehensive audits conducted by industry leaders such as Spearbit and Quantstamp. Access reports and read more about our security practices and .

Blockchain protocol risk

Ethereum and other supported EVM chains, are rapidly evolving technologies developed by decentralized collectives, operating independently of any central authority such as Kiln. It is important to note that, due to their nascent stage, they may contain potential errors or vulnerabilities. Consequently, these vulnerabilities could pose fund loss issue to the whole users of their networks.

DeFi protocol risk

Each supported DeFi protocol of the Kiln DeFi product are developed and maintained independently to Kiln. They may contain potential errors or vulnerabilities which could impact user funds. It is important to highlight the risk of each protocol to the end users so they can take proper informed decisions.

Rewards variation risk

DeFi protocols rewards rate, especially for lending supplying and liquidity provisioning, is highly dependent of the protocol liquidity and usage (for example the fewer the borrowing demand the less the supply rewards rate), and may present a lot of variance over time. This is independent from Kiln or the protocol itself and is purely do to market conditions and usage. Users of Kiln DeFi might see their rewards increase in high volatility market phases and diminish when the volatility get lowers without any possible guarantee.