Smart Contracts
Last updated
Was this helpful?
Last updated
Was this helpful?
You are referring to the Legacy
version of KyberSwap docs.
For the most updated information, please refer to:
This guide will walk you through on how you can interact with our protocol implementation at a smart contract level. The most common group of users that can benefit from this guide are Dapps.
We break the guide into 2 sections:
- The section covers what contract interfaces to import, and functions to call to fetch rates and perform a simple trade.
- This section covers the reserve routing feature to include / exclude reserves, or to split trades amongst multiple reserves.
If possible, minimise the use of msg.sender
within your smart contract. If you were to call a function within the wrapper contract, msg.sender
instead of your wallet address.
If the source token is not ETH (ie. an ERC20 token), the user is required to first call the ERC20 approve
function to give an allowance to the smart contract executing the transferFrom
function.
To prevent front running, the contract limits the gas price trade transactions can have. The transaction will be reverted if the limit is exceeded. To query for the maximum gas limit, check the public variable maxGasPrice
.
We will use Solidity compiler version 0.6.6 for deploying our sample contract. The following interfaces are imported for these functionalities:
The network proxy contract can be instantiated as such:
Call the getExpectedRateAfterFee
function of the network proxy contract. The input parameters are explained below.
src
IERC20
source ERC20 token contract address
dest
IERC20
destination ERC20 token contract address
srcQty
uint256
src
token wei amount
platformFeeBps
uint256
hint
bytes
Returns\ Expected rate for a trade after deducting network and platform fees. To get a 'readable' rate, divide it by 10**18. Refer to the example below.
Get the conversion rate of 1 WBTC -> KNC, with a platform fee of 0.25%.
Call the tradeWithHintAndFee
function of the network proxy contract. The input parameters are explained below.
src
IERC20
source ERC20 token contract address
srcAmount
uint256
src
token wei amount
dest
IERC20
destination ERC20 token contract address
destAddress
address
recipient address of dest
tokens
maxDestAmount
uint256
limit on maximum dest
token wei receivable
minConversionRate
uint256
minimal conversion rate. If actual rate is lower, trade reverts
platformWallet
address
wallet address for receiving platform fees.
-->
platformFeeBps
uint256
platform fee to be charged, in basis points.
-->
hint
bytes
hint for reserve routing.
-->
Returns\ Actual dest
token wei amount sent to destAddress
Convert 1 ETH to KNC, specifying 0.25% platform fee.
Note: The following code is not audited and should not be used in production. If so, it is done at your own risk.
In previous network versions, the hint
parameter was used to filter permissionless reserves. With Katalyst, we utilise this parameter for routing trades to specific reserves.
There are 4 optional routing rules:
BestOfAll
- This is the default routing rule when no hint is provided, and is the classic reserve matching algorithm used by the Kyber smart contracts since the beginning.
MaskIn
(Whitelist) - Specify a list of reserves to be included and perform the BestOfAll
routing on them
MaskOut
(Blacklist) - Specify a list of reserves to be excluded and perform the BestOfAll
routing on the remaining reserves
Split
- Specify a list of reserves and their respective percentages of the total srcQty
that will be routed to each reserve.
For token -> token trades, you can specify a routing rule for each half. For example, a MaskIn
route can be used for the token -> ether side, while a Split
route can be used for the ether -> token side.
We will use Solidity compiler version 0.6.6 for deploying our sample contract. The following interfaces are imported for these functionalities:
The kyberStorage and kyberHintHandler contracts can be instantiated as such:
For the token -> ether side of the trade, call getReserveIdsPerTokenSrc
of the kyberStorage contract. For the ether -> token side of the trade, call getReserveIdsPerTokenDest
of the kyberStorage contract.
Get reserve IDs for WBTC -> ETH
Get reserve IDs for ETH -> KNC
For token -> ether trades, call the buildTokenToEthHint
function
For ether -> token trades, call the buildTokenToEthHint
function
For token -> token trades, call the buildTokenToTokenHint
function
Their input parameters are explained below:
tokenSrc
IERC20
source ERC20 token contract address
tokenToEthType
TradeType
BestOfAll
, MaskIn
, MaskOut
or Split
tokenToEthReserveIds
bytes32[]
list of reserve IDs for token -> ether trade
tokenToEthSplits
uint256[]
percentages (in basis points) for Split
trade
tokenDest
IERC20
source ERC20 token contract address
ethToTokenType
TradeType
BestOfAll
, MaskIn
, MaskOut
or Split
ethToTokenReserveIds
bytes32[]
list of reserve IDs for token -> ether trade
ethToTokenSplits
uint256[]
percentages (in basis points) for Split
trade
The correct builder hint function must be used for the correct trade type. Otherwise, the hint will not be built correctly, and will result in transaction failure.
For token -> token trades, a combination of TradeTypes are allowed. For example, the token -> eth trade can be BestOfAll
, while the eth -> token trade can be Split
.
Note that the splits parameter must be empty.
Select the first reserve for a WBTC -> ETH trade.
Note that the splits parameter must be empty.
Exclude the first reserve from a WBTC -> ETH trade.
Note that the splits values must add up to 10000
(100%).
Split evenly among 2 reserves for a ETH -> KNC trade.
The BestOfAll
TradeType is primarily for specifying the BestOfAll
behaviour for one side of token -> token trades. It is not needed for token -> ether and ether -> token trades.
The reserveIds and splits parameters must be empty.
For a WBTC -> KNC trade, do a MaskIn
route for WBTC -> ETH, and BestOfAll
route for ETH -> KNC.
: Token approvals and transfers. We recommend the usage of for these purposes.
: Fetch rates and execute trades
platform fee to be charged, in basis points. Read more about platform fees
hint for reserve routing. hint for reserve routing. Refer to
Example
<!-- Read more about platform fees
<!-- Read more about platform fees
<!-- Refer to
Example
We strongly recommend for the building of hints to be performed off-chain to save gas costs, and we have not discovered a use case for it to be done on-chain yet. You can do so using or the . Nevertheless, this guide explains how you may do the building of hints on-chain.
: Fetching reserve IDs. For more information about reserve IDs, refer to .
: Building and parsing of hints
: The IERC20
input parameter of building / parsing hints
Examples
Notes
Example
Example
Example
Example