Today, we are ecstatic to announce the launch of the Celer Inter-chain Message (Celer IM) Framework! Celer IM fundamentally changes how multi-blockchain dApps are built and used. Instead of deploying multiple isolated copies of smart contracts on different blockchains, developers can now build inter-chain-native dApps with efficient liquidity utilization, coherent application logic, and shared states. Users of Celer IM-enabled dApps will enjoy the benefits of a diverse multi-blockchain ecosystem with the simplicity of a single-transaction UX, without complicated manual interactions across multiple blockchains.
By making cross-chain composability possible, the Celer IM framework opens up an entire galaxy of opportunities for inter-chain-native applications.
Some examples:
- DEXes that allow users to swap tokens across multiple chains from just one chain and with only a single transaction (demo on testnet)
- Yield aggregators that allow users to manage multi-blockchain vaults from a single chain
- Lending protocols where collateral can be provided on one chain in order to borrow assets on a different chain
- DAO governance protocols that allow unified governance mechanisms without requiring governance tokens to be moved across different chains
- NFT marketplaces where a user from one chain can place bids on an auction taking place on a completely different chain
- Metaverse games where users can interact seamlessly in the game with virtual items from various chains
- New kinds of cross-chain asset transfer bridges with different liquidity models, validation models, or even privacy features that can be built and co-exist under the same framework. In fact, cBridge can be seen as an asset bridge built on Celer IM.
The list goes on and almost every dApp that is deployed on multiple blockchains can benefit from using the Celer IM framework.
The Celer IM framework is very easy-to-use and allows a “plug’n’play” upgrade that often requires no modifications with already deployed code. As an example, Uniswap and Sushiswap can be transformed into an inter-chain-native DEX with just a simple plug-in.
A demonstration of what it looks like in real-world and you can try here:
The demo above shows an example where a user of Sushiswap can swap their ETH on Arbitrum to BNB on Binance Smart Chain (BSC) with a single, simple transaction. Behind the scenes, the following has happened:
- ETH -> USDT on the Arbitrum-side via Sushiswap
- USDT on Arbitrum is bridged to BSC via cBridge as part of the Celer IM framework
- An inter-chain message to execute a USDT->BNB swap is sent to BSC via Celer IM
- USDT -> BNB swap on BSC-side Sushiswap is triggered by that remote call on Sushiswap
Celer IM is currently live on testnet with demo app, documentation, smart contract framework, and sample application code available. We are actively looking for developer partners to work together with us and create powerful, user-friendly inter-chain-native dApps. Reach out to us if you are interested in working together.
The New Paradigm of inter-chain-Native dApps
The current common practice of making a “multi-blockchain” dApp is done by simply replicating the same code on multiple chains where the liquidity, application logic and states of the same dApp on different chains are completely isolated from each other. In fact, except for the UI and the protocol token, nothing is shared between these instances.
This approach often suffers from low liquidity efficiency, disconnected states, and a degraded user experience. Celer IM allows dApps to tap into the true potential of the multi-blockchain world by enabling a single-click user experience that benefits from much higher liquidity efficiency and coherent application logic.
Let’s walk through some examples in more detail and then we can dive into a more technical flow walkthrough.
Decentralized Exchanges
Today a multi-blockchain DEX has to build liquidity pools for the same key asset pairs on every chain they are deployed on. As a result, a DEX has to spread out the farming incentives across all of these different chains for these pairs. Even though the total liquidity across all of the chains may be fairly high, the liquidity depth of each pool on each individual chain is actually spread thin. Unfortunately, this harms the overall trading experience by creating high slippage. In addition, for users who want to make a trade for a token where deep liquidity exists on a different chain, they have to manually swap on the originating chain, use a separate fund bridge app, and then switch to the other chain to finally make the final swap.
DEXes built using Celer IM have a significantly improved trader experience by automatically routing their trade to the deep liquidity pool with just a single transaction. With this innovation, a DEX project will be able to concentrate the farming incentives for a pair of tokens on a single pool, creating deeper liquidity with low-slippage.
Lending Protocols
Today, if a user provides collateral in a lending protocol on one chain, they can only borrow assets on that same chain. In order to borrow assets from a different chain, they have to withdraw their liquidity, manually move it to a different chain, then provide liquidity in the new chain’s collateral pool.
Celer IM enables a new kind of inter-chain lending where a user is able to seamlessly move their collateral from a liquidity pool on one chain to a pool on a different chain, all in a single transaction. Then, they can directly borrow assets on that new chain. With this functionality, users will have a simple and clean UX that lets them accomplish what they need to without having to leave the lending application!
NFT Marketplaces
Today, if a user wants to participate in an NFT auction, they must have funds on the blockchain where the NFT exists. It excludes people who would normally partake in the auction, but don’t have funds on that particular chain. When a marketplace like OpenSea is deployed on a chain like Ethereum, a good chunk of the audience that is on other chains are excluded due to the complicated bridging operations and high gas costs.
Celer IM can help to expand NFT marketplaces to reach a wider audience. An auction will have the ability to take bids across chains other than where the NFT was initially minted. On top of this, there isn’t a need to make any individual cross-chain fund transfers before the auction results are finalized. This significantly reduces the costs of participating in an NFT auction, decreasing the barriers to entry and enlarging the trader pool for the marketplace as a whole.
Celer IM Architecture and Design Patterns
So how are these inter-chain-native dApps made possible? What do developers need to build?
In this section, we introduce the architecture of Celer IM via a step-by-step walkthrough of common application design patterns.
Cross-chain logic execution with accompanying fund transfer
For many inter-chain-native applications, the core flow often involves the process of sending funds to one or more chains and using those bridged funds to do something on the destination chain(s). In fact, the DEX demo given above uses this exact pattern. Links to the demo code will be provided throughout this walkthrough.
While the above flow diagram seems complicated, we want to highlight that most of this flow is handled by Celer IM, and that developers will only need to work with two simple functions in the framework’s application template.
Step 1: User initiates a transaction to dApp
Instead of interfacing directly with the existing dApp smart contracts, a user now interacts (mark A) with a new dApp Plug-in contract to express their intention of cross-chain logic execution. This dApp plug-in becomes part of the overall dApp business logic and may interact with existing smart contracts on the source chain. This is usually the only transaction that a user sends to interact with this inter-chain dApp.
In the DEX example shown, the transferWithSwap function serves as this entry point that allows a user to express the intention of, “swap Token A to Token B on Chain X and use the resulting Token B to swap for Token C on Chain Y”.
Of course, users usually do not manually specify these intentions. dApps using this framework are expected to compose higher-level user intent to these kinds of function calls.
Step 2: dApp Plug-in sends a message and associated cross-chain fund transfer
After completing the necessary actions on the source chain, the dApp Plug-in sends the resulting funds and the associated message across to the destination chain (marked B, C). The message specifies the action that needs to be carried out on the destination chain. In the DEX’s example, it is “swap the bridged token B to token C and give token C to the user”. The message and the fund transfer are automatically associated together by simply calling sendMessageWithTransfer. The message is then sent to the Message Bus contract and the fund transfer is sent via an asset bridge, in this case, cBridge.
Note: Celer IM can utilize other asset bridges in this application pattern and cBridge is just the first asset bridge that is supported.
Step 3: State Guardian Network (SGN) routes the message and cross-chain fund transfer
To understand this step, we must first introduce a core component in Celer IM: the State Guardian Network (SGN). The SGN is a Proof-of-Stake (PoS) blockchain built on Tendermint that serves as the message router between different blockchains. Node providers have to stake CELR tokens to join the consensus process of the SGN as a validator. The SGN uses the same security mechanisms of L1 blockchains like the Cosmos and Polygon PoS chains. The SGN’s CELR staking and slashing mechanisms are all implemented on Ethereum L1 smart contracts.
The SGN staking nodes are continuously monitoring the transactions happening on all of the connected chains. When a transaction triggers a cross-chain message event with a predefined header-payload format in the Message Bus contract (marked D), validators will first reach a consensus on the existence of such message and concurrently generate a stake-weighed multi-signature attestation. This attestation then is stored on the SGN chain and waits to be relayed to the destination via an Executor subscribing to the message (marked H).
For the cross-chain asset transfer, the cBridge contract can be seen as a specialized message bus with built-in optimizations for this purpose. A similar consensus and attestation process takes place (marked E). Instead of relaying this built-in fund transfer attestation to an off-chain Executor, the SGN validators themselves send the on-chain transaction to the cBridge contract (marked F) and trigger the fund transfer to the destination chain’s dApp Plug-in contract (marked G). Again, Celer IM can be connected to any asset bridge but starts with Celer’s cBridge set as the default.
Step 4: Executor performs cross-chain application logic
The Executor’s task is to read the stake-weighted multi-signature attestation from the SGN blockchain and simply relay it to the Message Bus on the destination chain (marked I). An Executor can be run by anyone for any application as the functionality is simply relaying the message. Of course, dApps are expected to take Executor incentives into consideration as it is the entity that sends out the transaction and pays the gas fee on the destination chain.
The functionality of the Message Bus is to check the validity of the attested message and verify that the associated payment has been indeed received by the dApp Plug-in (mark J). After that, the message (logic execution instruction) is delivered to the dApp Plug-in contract, which hosts the dApp’s inter-chain business logic on the destination chain (marked K).
The dApp Plug-in only needs to implement the executeMessageWithTransfer interface. In the DEX example, this function will execute the “Token B to Token C swap” on the destination chain.
Cross-chain logic execution without fund transfer
Of course it is not mandatory to send cross-chain messages or logic execution instructions with a fund transfer. In the NFT marketplace for example, if a user participates in an auction that takes place on a different chain, they will only need to lock up their funds without actually transferring it to the destination chain in order to place a bid. It is only after they win the auction that a fund transfer will be required.
The flow for this would just be a simplified version of the first pattern. The dApp Plugin would only need to implement the logic to call sendMessage on the source chain and then implement the executeMessage function on the destination chain’s dApp Plug-in contract.
Failure Handling
Due to the asynchronous nature of the above inter-chain message patterns, failure handling should be considered as part of the application logic. In these application patterns, failures can happen in the following three steps and they should each be handled accordingly:
- Source chain dApp logic execution failure. This is not related to Celer IM and should be handled by the dApp business logic itself (e.g. deadline exceeded for a DEX swap).
- Fund transfer failed in the asset bridge. The source chain dApp will be notified via a common interface and handle the refunded asset transfer by either retrying the fund transfer or sending it back to the user.
- Destination chain dapp logic execution failure. When a user’s fund reaches the destination chain, the dApp logic execution can still fail at that point. The dApp developers should prepare for this and should implement fallback functions in order to handle such a failure. A common way to handle such a failure can be to stop the execution and send the funds to the user on the destination chain or transfer the funds back to the source chain, but it is entirely up to the dApp developer to implement the specific logic of the fallback functions.
We won’t go into the details about the failure handling flow in this high-level flow walkthrough and will provide detailed design patterns in developer docs.
Network Value Accrual and Fees
It is obvious that CELR token stakers and validators in the SGN are indispensable in the smooth operation of Celer IM, as explained in both of the above models.
As such, users of Celer IM are required to pay fees to the SGN in return for its services of reaching consensus and storing attestations of the source chain messages, as well as the fund transfer. This is very much like a fee being paid for any other PoS blockchain validators. These fees are distributed to the CELR stakers corresponding to the SGN nodes that generate the block.
Building with Celer IM is Easy
Expanding an existing dApp’s reach or building an entirely new dApp with Celer IM is very easy with these three simple steps.
First is to write the dApp plug-in smart contract code. You only need to implement the logic in the source-chain smart contract interfaces in a way that can express cross-chain execution intention, call sendMessage or sendMessageWithTransfer on the source chain. You would then implement the executeMessage or executeMessageWithTransfer function on the destination chain’s dApp Plug-in contract.
Second is to operate the Executor. There is no code to write for this and the dApp developer or any member of the community can operate an Executor that subscribes to the relevant message attestation generated on the SGN.
The last thing is to make the UI/UX modifications. Because the application now has cross-chain logic that may involve multiple transactions, it is important for users to understand the various statuses of an action. The exact UI is application-dependent of course, but Celer IM provides an easy to query gateway service to get the statuses of messages and fund transfers for dApp developers to construct the full lifecycle of a cross-chain transaction.
We are looking for dApp partners to build on Celer IM and will be able to provide hands-on technical support. We are also setting up grant programs with more details to come. If you are interested, please fill out the early partner onboarding form to reach out to us!
