The Rainbow Way
The Rainbow Road is now live on Arbitrum Nova, Arbitrum One, Base, BNB Chain, Fantom, Kava, Optimism, Polygon and Telos EVM using Chainlink’s Cross-Chain Interoperability Protocol (CCIP), Axelar’s General Message Passing (GMP), and LayerZero. This article will only go over the Rainbow Road smart contracts and integration with Chainlink CCIP. There will be a separate article to discuss the Rainbow Road service layer.
With that out of the way, let’s dive in.
The Rainbow Road is live!!!
As mentioned above the Rainbow Road is live on Arbitrum Nova, Arbitrum One, Base, BNB Chain, Fantom, Kava, Optimism, Polygon, and Telos EVM. First, a quick review of the vision for Rainbow Road. At the core, the Rainbow Road allows seamless cross-chain experiences to be built on top of blockchains. This is done by providing a layer that integrates with the underlying chains and other infrastructure protocols, removing the need for every app (Web2 and Web3) to do the same. Instead projects and businesses can integrate with the Rainbow Road, allowing it to take care of the details needed to reliably and securely operate across multiple chains. Thus freeing them to use that time to build great applications for their users. By executing on this vision, the Rainbow Road empowers users, projects, and businesses to effortlessly do what they want, where they want, when they want on any chain.
A lay of the land . . .
The core of the Rainbow Road consists of the Rainbow Road, receivers, senders, and handlers.
- The Rainbow Road is the central component that orchestrates the work that needs to be done. The core responsibility of the Rainbow Road is to manage tokens onboarded to the Rainbow Road, senders, receivers, handlers, and configuration settings.
- Receivers unwrap incoming messages and sends the resulting payload to the Rainbow Road for processing. They serve as an entry point for actions to be performed by the Rainbow Road on the local chain where it resides.
- Senders wrap outgoing messages into the required format needed to interact with external protocols and contracts. The destination for an outgoing message can be on the local chain or a remote chain.
- Handlers do the heavy lifting for the Rainbow Road. The main purpose of handlers is to carry out actions needed to accomplish a task. This can be anything from transferring tokens in and out of a contract to facilitate cross-chain transfers or to burn veArc on one chain and mint the veArc on another chain. Handlers can even be configure to take actions like getting price data from a Chainlink Data Feed or random number from Chainlink’s VRF, bundling that data into a payload, sending that payload out to a chain that does not have Chainlink VRF or Data Feed support via other cross-chain messaging protocols, and making the random number or price data available for contracts to consume just like they would if the chain had native support for VRF and Data Feed. Stating this another way, Handlers are very powerful contracts that can be used to extend the reach of a chain’s resources to benefit other chains onboarded to the Rainbow Road.
These components are built in a way that is composable and configurable for carrying out any task on the local chain or on a remote chain. Each component is upgradable via hot swapping the contracts. This means that any contract in the Rainbow Road, including the Rainbow Road contract itself, can be replaced by a newer version enabling the Rainbow Road to evolve seamlessly over time. By stringing calls between Receivers, Senders, and Handlers with other contracts or protocols, we can now provide a uniform abstract layer that has redundancy, reliability, and security. It’s built to use the best-in-class products and services offered by partners like Chainlink, Axelar, CryptoLink, Elk Finance, and ChainPort to enable seamless experiences on any chain. Over time, the plan is to open up the Rainbow Road to third-party developers to build their components on top of the Rainbow Road. Allowing for them to build a diverse library of resources that can scale with the Rainbow Road to any chain.
Stepping into the Future
When we set out on this journey back in February, we set three goals (Laps) for ourselves. Expand Archly to multiple chains (Lap 1), enable Arc to be transferred between chains (Lap 2), and allow veArc and other assets to be moved between chains (Lap 3). As of today, Lap 2 is now finished and we are halfway through Lap 3. The ability to transfer Arc (or any ERC20 token) is possible on the Rainbow Road. Transferring veArc across chains will also be coming very soon, marking the end of Lap 3. This is not only a great achievement for Archly, but for our partner projects and users alike.
The world was a simpler place during the early stages of development for the Rainbow Road. There was traditional finance (TradFi) and decentralized finance (DeFi). And for the most part, those two realms were isolated from each other. Archly’s charter was firmly in the world of DeFi. There were also no major failures of central players that caused wide-spread devaluation of assets on multiple chains en masse. Things just seemingly worked and no one asked “What if?”. Well, except for us. We ran into a lot of raised eyebrows after explaining the purpose of the Rainbow Road. Luckily, we developed some great partnerships with a set of like-minded projects that understood our goals. Over the course of this year, some game changing events for the real world and the blockchain world occurred that caused us, and everyone else, to re-think the current state of affairs.
With the unfortunate collapse of Multichain, a lot of projects had to scramble to work around the void created when the infrastructure of Multichain stopped working. The primary cause of this was that projects, in an effort to go multi-chain, had taken a hard dependency on one entity. This led to projects having single point of failure which turned out to be fragile. Even before the failure of Multichain, there were only a few ways to integrate their token with Multichain’s platform. One was to use a generic anyToken, which was could be swapped back to the native token. But, this seemed to be a rare exception as projects started to use the anyToken instead of pooling their native tokens on the destination chain. The other option was to write their token contract with hooks for Multichain. This put the token at risk of running into a different issue. What if Multichain’s platform was compromised and these hooks were used to mint more tokens? Thankfully, we did not have to find out the answer to that question. The last issue is that projects that did pool tokens with Multichain have essentially lost those tokens, including Archly. For these reasons we designed our ERC20 Transfer Handler to allow token issuers to retain total control of their tokens no matter where they are deployed. More on this later.
The successful transfer of tokenized assets by Swift through Chainlink’s CCIP opened the door to an even more connected world. Let that sink in for a minute. With that, the lines between TradFi and DeFi began to disappear, opening up new opportunities for Archly. In this new world, the demand for seamless experience across any chain has only gotten bigger. Since we already built the Rainbow Road to utilize the best of Web2 and Web3 making it easier for any app or Dapp to have access to the data and infrastructure they need, why not expand our charter to include TradFi too! The work between Chainlink and Swift showcased a glimpse of this new world and provided further confirmation that Archly is on the right path. We are not far off from tokens like Arc and LINK can be paired against tokenized real-world assets (RWA) like corn and oil, traded on Archly’s DEX, while the Rainbow Road orchestrates the necessary actions to price and settle the transaction with products like CCIP, Automation, and Data Feeds from Chainlink to provide the best-in-class experience we are striving for on any chain. The best part is that the Rainbow Road has already integrated CCIP and can easily be expanded to integrate with other products and services thanks to its modular design. Also, thanks to CCIP’s design, the Rainbow Road can take advantage of CCIP’s built-in features, like the Risk Management Network that independently monitors transactions flowing through CCIP, to prepare Archly to deal with any regulatory needs such as anti-money laundering (AML) laws and know your customer (KYC) requirements that may arise in the future. Getting there is going to be just as complex and challenging as the vision first laid out for the Rainbow Road. Especially given the current regulatory environment in the United States. But Archly is ready to rise up to the challenge, again, to make sure that users of the Rainbow Road can seamlessly operate where and when they want on any chain or in the real world.
Back to the Present
Now that the foundations of the Rainbow Road are laid, the team at Archly has two new objectives. One is to continually enhance the Rainbow Road by integrating more features and expanding to more chains to meet the demands of an ever changing world. Secondly is the design and building of Archly DEX V2, which will bring features like concentrated liquidity (CL), cross-chain voting and bribing, and unified Arc emissions across all chains to push the ve(3,3) experience to a new level. These two goals will go hand-in-hand as they help to shape the future of the Archly ecosystem with the Arc token at the heart of it all. The Arc token will be used as a fee token to interact with the Rainbow Road. Meaning each time a call is made to send messages, tokens, or for any other messages that flow through the Rainbow Road, Arc will be collected. Whitelisting tokens on the Rainbow Road will also have a fee that will be paid in Arc. To keep the fee structure simple the fees for sending messages and whitelisting tokens will be charged at a flat rate, but can be adjusted to meet the current costs needed to sustain the Rainbow Road.
Our aim is to provide a consistent price in terms of USD for sending messages and whitelisting on the Rainbow Road, i.e. the amount of Arc required to cover the fees will be adjusted based on the USD value of Arc on all chains. Thanks to Chainlink’s Automation and Data Feeds, we can build processes into the Rainbow Road that keep these prices pegged to a USD value across all chains. The Arc collected as fees for sending and whitelisting will be split between being burned and the team. The fees sent to the team will be used to pay for expenses to help keep Archly running, like LINK tokens to fund our Chainlink CCIP, Automations, and Data Feeds contracts, and server costs for the website and the Rainbow Road service.
A word about the ERC20 Transfer Handler
The ERC20 Transfer Handler is the handler that works to ferry tokens back and forth between chains. It has native support for flat-rate and percentage based fee-on-transfer tokens too. One of the primary ideas for the Rainbow Road was to allow for projects to issue their own tokens free of any dependencies and restrictions. Java’s main premise was to Write Once Run Anywhere. Archly’s Rainbow Road aims to do the same for tokens via the ERC20 Transfer Handler. The need to tightly couple your tokens contract code to one (or many) cross-chain providers is now a thing of the past. We would like to introduce Write Once Deploy Anywhere. A single token contract can now be deployed on any chain by using the Rainbow Road’s ERC20 Transfer Handler to handle movement between chains. Just like the Archly DEX, we wanted the Rainbow Road’s token whitelisting process to be fully permissionless, and this extends to the ERC20 Transfer Handler too. So, there is no gatekeepers to go through to get your token onto the Rainbow Road or enabled for the ERC20 Transfer Handler. You don’t even need to talk to the Archly team, even though we (and the community) are here to help if needed.
Just:
- Deploy your token to the chains you want to be on.
- Whitelist your token through the Rainbow Road on each of the chains.
Note: This is a separate whitelisting than the Archly DEX. - Deposit liquidity into the ERC20 Transfer Handler on each of the chain.
That’s it! Now given that Archly was born with ve(3,3) mechanics, it only makes sense for us to carry that spirit forward into the Rainbow Road’s ERC20 Transfer Handler. Each transfer done through the ERC20 Transfer Handler will be charged a percentage based fee that will be split between Rainbow Road liquidity providers and bribes on the Archly DEX for veArc voters, which will both be paid out weekly after the epoch flip.
ERC20 Transfer Handler Fees
- Fee Range: 0% — 20%
- Initial Fee: 2.5%
- Liquidity Providers: 70% of ERC20 Transfer Fees
(1.75% of tokens transferred) - veArc voters: 30% of ERC20 Transfer Fees
(0.75% of tokens transferred)
After the upgrade to Archly DEX V2, the Rainbow Road liquidity provider’s portion of the ERC20 Transfer Handler fees will trend towards 0% and be replaced with Arc emissions. At that time, 100% of ERC20 transfer fees will be distributed as bribes to veArc voters on the Achly DEX to re-establish our current ve(3,3) model of distributing fees to veArc holders and using Arc to incentivize liquidity providers. With these fees in place, we will have another avenue to help spin the Archly Flywheel and grow the Archly ecosystem to provide more services and features now and into the future.
It is still early.
Do you want to join us on this journey? Then follow us on X (formerly known as Twitter), join our Telegram or Discord groups, or dive into our docs to find out more.
