ChainRunner Technical Report
What is ChainRunners?
ChainRunners was introduced to service a wider range of blockchain users and provide users a seamless experience in reaping its benefits in the multichain ecosystem.
Currently, the blockchain space still faces challenges in bringing mass adoption. Utilizing innovative DeFi or NFT services often times come with prerequisites such as financial knowledge, technical experience with crypto wallets or even coding skills in writing smart contracts. These blockchain jargons and platforms may all seem foreign and difficult.
Even though the new era of Money Legos in the DeFi world comes with many promises, users are still left on their own to overcome such hurdles across multiple protocols and strategies.
ChainRunner is the engine and system targeting this exact problem. ChainRunners equip users to effortlessly run complex blockchain services as well as to use those services in one platform. As the engine on top of services (e.g. BiFi, BiFi-X), ChainRunners focus on primarily enhancing service functionality and on performing as customized secretary with additional services like the wallet (e.g. Biport). Each and every one of these ChainRunner acknowledge each other and plays its part to make an orchestra of functions under the conductor “ChainRunners” that perfectly synchronize all performances. (i.e. ChainRunners is plural.)
The following technical document aims to elaborate on three distinct technical features of ChainRunners, our roadmap and vision.
1. ChainRunner Engine: A Hub for Users and Services
For services, ChainRunners interact in its compatible language “Taster,” (to be introduced in detail below) to improve scalability of use. Complex blockchain services that require multiple procedures can be executed at a high level with simple commands (e.g., “migrate assets pooled in a service to other assets”).
ChainRunner Engine breaks down each command into necessary steps and asks the users for confirmation prior to executing each step. Users can command specifics to their desired operations as long as they understand ChainRunner’s language — which is extremely straightforward.
As with any blockchain networks, ChainRunner Engine connects users via wallet to perform operations safely through user signature. It receives user signature from user wallets such as Biport and MetaMask upon request to proceed with the necessary actions.
Furthermore, ChainRunner Engine is also linked to external services, or off-chain services. For instance, to perform arbitrage deals, users can either link blockchain-specific Autotask services with external network Gelato or Defender or link with the to-be released ChainRunner service to execute commands when specific criteria are met. Even for token swaps, off-chain Oracle or exchange prices can act as safeguards. The opportunities are limitless with web-based automation. We can imagine a future where any Twitter or Instagram feed or post is processed through blockchain transactions by linking IFTTT or similar services.
2. The Lightweight Architecture Built With F#
The ChainRunner Engine’s structure consists of several modules (Figure 2). Taster’s high level of flexibility is the only method of communication deemed fit for ChainRunner Engine. Therefore, there are many modules that are associated/correlated to Taster. Taster Validator verifies that there are neither grammar mistakes nor miswritten content entered on Taster (e.g. incorrect operation to add the quantity of ETH and USDT). Taster Executor’s role is to interpret those commands and execute them. There are three modules are involved in the execution of Taster with the following functions:
- Blockchain Executor — communicates with blockchains to retrieve data (e.g. your Ethereum and Avalanche balance from your crypto-wallet)
- Wallet Connector — requests your permission and signature to connect to your wallet(s)
- Offchain Interactor — retrieves data anywhere but blockchains (e.g. Twitter feed, Instagram feed, weather information, etc.)
There are even times when Taster takes on the role of smart contracts when necessary. At this time, Transpiler will automatically convert some parts of the content into smart contracts. (This powerful feature will be further described in technical documents later). Lastly, the Blockchain Service Model represents a library for storage and easy use of various blockchain services. It will be described more in detail in the following Taster introduction below.
3. Taster: Language for Blockchain Services
How best to communicate human intentions for computers to interpret has always been the on-going challenge in the field of computer science. Commands such as “swap my Ether deposit to USDT deposit” or “short a 2x leverage on Ether for price protection” takes even a person to manually go through multiple steps across different platforms or protocols. As such, the number of scripts to code that would reasonably be extremely long.
For this exact reason, we created our own high-level language called “Taster” for ChainRunner to accurately and thoroughly express human intentions. “Taster” is an adapted form of programming language, maintaining its structure but going beyond ordinary programming languages to intuitively and immediately express the functions of blockchain. This is a type of Domain Specific Language (DSL), which has several advantages. First, service connectivity is significantly improved because DSL can be commanded with high-level functions. Also, DSL offers higher usability because it is easy for individuals to grasp.
All ChainRunner Engine has Blockchain Service model pre-scripted by Taster. You can think of it as a Standard library or a built-in library for popular and major DeFi services (e.g. Aave, and Compound) that enables you to easily specify desired blockchain operations when you input Taster scripts. Hence, you can use all of the DeFi services that the library supports right away as long as ChainRunner is present. (Please refer to the Reference page for a list of supported services.)
These steps that occur internally when using Taster. For example, there are four steps to one of the scenarios in ChainRunner Q — “Depositing BiFi-WETH LP token in BiFi Pooling.”
- Determine the quantity of ETH to be used for liquidity supply
- Buy a BiFi token from SushiSwap
- Supply liquidity to the BiFi-WETH Pool in SushiSwap
- Deposit LP (SLP) token into BiFi Pooling. (LP tokens are given to the user to prove ownership of providing liquidity)
The process above can be completed by ChainRunner with just three Taster codes. Blockchain Service Model allows you to use features, such as SushiSwap and BiFi, right away at a high-level. Now, what do you think happens internally? Let’s take a look at only swapEsactETHForTokens() as a representative, which is used in the process of purchasing BiFi tokens from the sushi swap. This script allows the exchange of tokens via SushiSwap.
Don’t be intimidated by its complicated appearance; ChainRunner takes care of these processes. Let’s examine each step below.
- You must import an account linked to a crypto wallet in order to make transactions. ChainRunner takes care of this Line 1.
accountvariable now has a crypto wallet account linked to a user.
- Next you must know the smart contract of the token before purchase. Line 2 retrieves smart contract of “BiFi” token from the blockchain network.
- Swap function family provided by the SushiSwap contract require a token smart contract list to swap in
Patharray. We combine smart contracts of WETH and BiFi into an array in order to swap the two tokens.
- Slippage value is crucial for blockchain-based DeFi swaps. Slippage refers to cases where there is a change in market price between the time of the swap request and when the actual swap is processed. This could lead to losses for the traders because the transactions might be processed at undesired prices. This line sets a slippage limit to set the amount of BiFi that could be traded for WETH (
- Import the
decimalsvalue of BiFi tokens from the blockchain network in order to calculate the transaction limit to prevent slippage.
- Obtain the base slippage rate in the same way. (0.5% for SushiSwap.)
- Based on the values obtained from steps 4~6, multiply the amount of WETH that could be traded with BiFi by the base slippage rate to set the transaction limit (
amountOutMin). This reverts the transaction if the amount of BiFi that the user receives is less than the
- This value sets a deadline to self-terminate a transaction if it is put on hold for too long without being mined. Most DeFi protocols set this value with sufficient room to process most transactions for better service usability.
- Retrieve the wallet balance before the transaction to show the amount of BiFi received after the swap.
- Call SushiSwap’s
swapExactETHForTokens()function (expressed as a function because it is a smart contract.) to swap WETH and BiFi.
- Retrieve the final balance after the transaction to check the amount of BiFi received.
- Return (current balance — balance before transaction).
As you can see, ChainRunner processes all these events for one user action. In fact, there may be few more steps involved in each step. Some procedures carry these micro-procedures to be able to execute them. For example, this one:
Even these micro-procedures are surrounded by more internal procedures to be executed within Taster. Towards the end of these procedures, Taster Evaluator flows to Blockchain Executor, which then communicates with the smart contract within the blockchain network and re-sends the data back to Taster Evaluator (e.g. the return value after swap
ChainRunner Q utilizes the functionalities of ChainRunner Engine as the first runner of ChainRunners. Think of Q as your faithful butler as well as an all-rounded executive chef for blockchain services. Within a few clicks of demanding a preferred scenario in the recipe book-like UX, all operations can be executed effortlessly. Whether it is DeFi’s complex functionality such as yield farming or scenarios that require multiple services such as arbitrage trading and migration, we’ve got it all in store for our users. For instance, Q can conduct operations such as “deposit LP tokens to BiFi-WETH Pooling” by a simple command (the amount of WETH to be supplied to WETH-BiFi Pool). With unlimited number of blockchain services, or we call it “ingredients”, our recipes will be periodically updated.
Although Q currently only acts to prove the limitless possibilities for ChainRunners, it has the potential to advance and expand on its own as well. The recipe book read by Q could actually be developed by anyone who can inject the Taster code to the widely available Markdown file. We envision the platform to grow into a public, profit-sharing recipe book for any contributors who is financially literate or willing to share unique strategies to disrupt the blockchain ecosystem. Contributors can secure both legacy and profits from BIFROST City with an extensive backup of the Taster code and strategy in Markdown.
Future of ChainRunners
All products in BIFROST City are built towards synergies with other products in mind. ChainRunners are built on top of Biport, BiFi and various services to link each of these individual services for improved ease of use. ChainRunner will employ a wider scope of activities as more services are released in later dates within the BIFROST ecosystem. Stay tuned for ChainRunner to unlock its full potential and as it accelerates both as a service and a platform!