Breaking down Router’s Cross-chain Intent Framework (CCIF) Architecture

7 min readDec 29, 2023

Part Two: Adapter Registry Module (ARM) and Intent Solvers

Welcome back to our in-depth exploration of Router’s Cross-chain Intent Framework (CCIF)!

In the first part of the series, we introduced the important role of Intent Adapters in executing blockchain actions, such as swapping, bridging, and staking.

Now, in this second segment, we shift our focus to the remaining two components of the CCIF architecture: the Adapter Registry Module (ARM) and Intent Solvers.

What is an Adapter Registry Module (ARM)?

Just as the name suggests, the Adapter Registry Module functions as a repository for all intent adapters. It establishes uniform guidelines for declaring, managing, and utilising adapters within the framework.

This uniformity ensures smooth interactions among the framework’s various components and the consistent, reliable execution of user intents at any time. Developers can use this module to track and update their adapters’ functionalities and constraints at any given time, Intent solvers can refer to the ARM to find the most optimal path for executing any workflow.

So, what are the parameters that characterise an adapter within the ARM?

There are various specifications through which each adapter within the ARM is uniquely defined. While the name of each parameter or field explains itself, we will go through them one by one.

adapter_id: This is a unique identifier that acts as the primary means of identifying the adapter within the network.
adapter_description: This describes the function of the adapter and outlines how it interacts within the intent framework, which helps users and developers understand the adapter’s role in the overall execution flow.
adapter_function_selector: These are a collection of function identifiers, each uniquely created from the adapter_id and a specific function selector. This guarantees a collision-free way to identify each function in the adapter.
adapter_function_descriptors: This is a mapping that links adapter function selectors to their respective descriptions, offering a clear understanding of each function’s behaviour and purpose.
whitelisted_head_set: A group of approved adapter_ids permitted to come before an adapter, preserving the sequence and integrity of the execution flow.
whitelisted_tail_set: A collection of approved adapter_ids allowed to follow an adapter in the execution sequence, ensuring a secure and orderly execution process.
chain_id: Similar to adapter_id, this is the identifier for the blockchain network on which the adapter is deployed, crucial for enabling cross-chain functionality and identification.
inbound_asset_set: This is a list of assets that an adapter can accept, detailing its ability to handle various inputs.
outbound_asset_set: This is a list of assets that an adapter can send or transfer, defining the range of assets it can deliver.
adapter_type: Specifies whether the adapter is stateless or stateful. You can read about the stateless and stateful adapters here.
tags: A set of descriptive tags for the adapter, like ‘staking’, ‘lido’, ‘dex’, ‘swap’, etc., which help in categorising and quickly identifying it within the framework.

These parameters form the backbone of the Adapter Registry Module, and this attention to detail shows just how much thought has gone into making the framework not only technically sound but also intuitive and accessible for everyone involved.

With the Adapter Registry Module’s core parameters well-established, we now turn our focus to the Adapter Sync Module!

Adapter Sync Module

The Adapter Sync Module ensures the integrity and consistency of the Adapter Registry Module (ARM). Its main responsibilities include:

Verification Check: This involves verifying each adapter’s status on its respective blockchain to guarantee its authenticity.
ABI Synchronization: This process entails extracting and storing the adapter’s Application Binary Interface (ABI) from the blockchain to ensure a dependable interaction interface.
Function Selector Validation: This step involves matching the adapter’s listed function selectors with those in the ABI, confirming that the adapter’s functionalities are consistent with its on-chain implementation.
Default Function Handler Generation: This involves creating basic function handlers for each declared function selector, facilitating a smoother integration process.

In conclusion, this module is key to keeping the ARM system reliable and secure. It does this by thoroughly checking and syncing each adapter with its online version, making sure they’re genuine and work as intended. By focusing on the detailed tasks mentioned above, the system runs smoothly and meets high standards. This careful management makes the ARM system both trustworthy and efficient.

Now, it’s time for the next part of the blog, Intent Solver!

What are Intent Solvers?

Intent Solvers are automated entities or actors designed to figure out the best ways to actualise specific goals or “intents.” They assess multiple factors and identify the optimal sequence of actions needed to complete a given task–ensuring tasks are carried out in the most efficient and reliable manner possible.

They are an important part of Router’s Cross-chain Intent Framework Module–working like a smart planner for transactions. Here’s how it does it:

Finding Paths: It refers to the ARM to search for different ways to carry out a transaction or task.
Choosing the Best Path: Using advanced decision-making methods, it picks the most efficient and effective way to do the task.
Preparing Each Step: For each part of the chosen path, it prepares the necessary information and fine-tunes it to make sure everything goes smoothly.
Finalising and Sharing Calldata: Once it figures out the best way to do the task and gets everything ready, it returns the entry point and calldata for the execution flow.

Their ability to traverse multiple possibilities and pinpoint the best approach to streamline processes enhances the overall effectiveness of Router CCIF framework. Eventually, this helps the end-user to start the transaction, knowing they’re using the best possible method.

To achieve the aforementioned steps, the Intent Solver in the Router CCIF has three major components.

Intent Solver Components —

Pathfinder:

The Pathfinder is an algorithm that finds the best ways to carry out a user’s plans using the Adapter Registry Module. It looks at different options and picks the best one based on cost, speed, and potential benefits.

Simulator:

The Simulator’s main job is to simulate the transactions for each adapter (part) of the chosen path. It makes sure that every adapter works properly, in case it doesn’t happen, the Simulator rules out that path.

While checking if each adapter is working as intended it also helps improve the path by providing useful data–ensuring the chosen path is both functional and optimised.

Calldata Composer:

The Calldata Composer’s role is to create and combine the necessary calldata for each adapter in the selected path, forming a single, cohesive calldata payload/package. This package represents the plan or blueprint for carrying out the user’s intention based on the best path chosen by the Pathfinder. The user then uses this combined calldata to make their intent happen on the blockchain. In this way, the Calldata Composer is equally important in turning user intentions into real blockchain actions.

Now that we have gone through the different components and their functions, let’s make things clearer with a real-world example.

Intent Solver Workflow

Imagine we want to stake 100 USDC from the Polygon network to Stader on Ethereum.

Let’s break down this process and see how it actually happens in our system, step by step.

Step 1) Identifying Various Routes:

The Pathfinder scans the ARM for suitable adapters for executing the user intent and identifies all the potential paths.

Potential proposed paths:

funds → DEX (Polygon) → Bridge 1 → Stader (Ethereum)
funds → Bridge 1 → DEX (Ethereum) → Stader (Ethereum)
funds → DEX (Polygon) → Bridge 2 → Stader (Ethereum)

Step 2) Path Simulation:

This involves the Pathfinder activating the Simulator to evaluate all identified paths, considering factors like execution cost, transaction completion time, and the potential yield of each path.

For example, consider Path 2, which requires 230K gas for execution, takes 6 minutes, and is estimated to yield 0.13 ETHx.

A key function of the Simulator is to identify and discard nonviable paths. If, for instance, the Simulator detects a failure in the simulation of the DEX (Ethereum) adapter in Path 2, the Pathfinder immediately excludes this path from further consideration. This ensures that the analysis focuses solely on feasible paths.

Step 3) Selecting the Best Route(s):

This involves the Pathfinder utilising a custom A* algorithm to evaluate each potential path, taking into account execution cost, time, and estimated outcome. This process calculates a composite score for each path.

For instance, while Path 3, with its requirements of 180K gas, 10-minute duration, and a yield of 0.136 ETHx, is identified as the best for net yield, Path 2 becomes the preferred choice. Path 2, requiring 120K gas and just 2 minutes to complete, with an estimated yield of 0.134 ETHx, offers an optimal balance between speed, cost, and expected outcome.

Step 4) Composing the Calldata:

After deciding on one or more optimal routes, the Calldata Composer creates a unified calldata payload. This is done by assembling the calldata for each adapter involved in the chosen paths. Upon successful generation of the calldata, the Intent Solver returns this data to the user along with the address of the entry point contract.

Together, these components harmonise to create a seamless and optimised process, turning conceptual intents into tangible blockchain actions with precision and efficiency.

In this light, Router’s CCIF is more than just a framework; it’s a visionary blueprint for a future where blockchain technology becomes as ubiquitous and essential as the internet is today. Its potential is boundless, and its impact, immeasurable.

Read the whitepaper for further details of the framework here: https://www.routerprotocol.com/router-ccif-whitepaper.pdf

In the next blog, we will talk about the use cases of Router Cross-chain Intent Framework. Stay tuned!