📃Integration contract

Learn more about your integration contract along with the choice of receipt tokens available to you.

Introduction

The integration contract will be deployed by Kiln, but then owned and operated by our partner. This provides partners with complete control over the user experience and the staking product being distributed to their end users.

What can be configured in the contract?

Partners can do the following:

modify the end user fee

Also referred to as a commission. Programmatically deducted fee from total staking rewards only. The fee can be updated at any time by our partner.

modify commission split:

Specify the recipients (wallets) and their corresponding commission percentages. e.g. where the end-user fee is 15%, with a 60/40% commission split, Wallet1 gets 9%, and Wallet2 gets 6% as commission.

modify staking weighting across multiple node operators

When linked to multiple operator pools, tailor your staked ETH distribution per pool. Set ratios like 80/20 for Operator1/Operator2, and the smart contract self-adjusts with incoming deposits. Easily modify these ratios, and the contract rebalances as ETH is staked or exited.

pause deposits

Pause the contract to prevent further deposits being made.

modify admin roles

There are two admin roles required to operate the smart contracts. These roles are owned, and can be changed, by the partner at any time.

upgrade the contract

When upgrades become available, Kiln will provide instructions for the upgrade. Notably, the actual upgrade can only be executed by the partner, utilizing one of the configured admins.

Token definition

Users receive a receipt token representing their staked position. Partners must decide on the token type upfront (soulbound or liquid), as it cannot be set or changed later. Kiln deploys the correct integration contract based on this initial decision.

Token attributes

Partners can customise the below token attributes. Both attributes will be displayed on Etherscan and ERC20 compatible interfaces:

• token symbol: e.g. cbETH, cdcETH, psETH

• token name: e.g. Pooled Staked ETH, Coinbase Wallet ETH

Token types

Partners need to choose the token type they wish to include in the staking product being offered to their end users.

Below is a comparison and summary of token types, highlighting differences in integration approaches, capabilities, and end-user experiences.

NOTE: Commonly, start with Native20 (non-transferrable tokens). Consider an optional upgrade to Liquid20 later; connect with us for details on the upgrade path and associated considerations.

Feature	Native20	Liquid20A	Liquid20C
Stake any amount	✅	✅	✅
Commission taken onchain	✅	✅	✅
Multi commission recipients	✅	✅	✅
Users chooses pool	❌	❌	❌
Partner chooses pool (sets % distribution across pools)	✅	✅	✅
Transfers	❌	✅	✅
NOTES		aToken	cToken

Native20

• contract expose the exact same view methods as Liquid20C

• without the transfer and approve methods. It looks like a token, but cannot behave like one.

example view of Native20 token in Etherscan

Liquid20A

• an ERC20 rebase token.

• the quantity of tokens held in the users wallet will increase each time rewards are distributed. Rebase tokens maintain a fixed exchange rate but the quantity of tokens issued increases to reflect earned rewards.

Liquid20C

• standard ERC20 token

• The quantity of tokens held in the users wallet do not change, however their value increases each time rewards are distributed.

Contract Parameters

20 type Configuration

Parameter		Description
admin	address	Admin wallet address
pools	address[]	List of pool addresses
poolFees	uint256[]	List of fee for each pool in basis points
poolPercentages	uint256[]	Share of new stake to go to each pool, in basis points, must add up to 10 000
commissionRecipients	address[]	List of address of commission beneficiaries
commissionDistribution	uint256[]	Share of each beneficiary, in basis points, must add up to 10 000
name	string	ERC-20 style display name
symbol	string	ERC-20 style display symbol