Skip to content

Concero V2 - Technical Overview

Published: at 10:00 AM

Introduction

A Word About Concero V1

Concero V1 is a fully decentralised cross-chain bridging solution built on top of Chainlink CCIP. The primary aim of V1 was to build an interoperability protocol that is resistant to manipulation and censorship, setting it apart from existing centralised solutions prone to such risks.

Traditionally, achieving high levels of security and decentralisation in cross-chain protocols has led to slower transaction times, often making fast transactions the domain of centralised systems with inherent trust assumptions and single points of failure.

Concero V1 was engineered to break this status quo. By leveraging Chainlink CCIP as a secure and truly decentralised settlement layer, and coupling it with the decentralised compute capabilities of Chainlink Functions, Concero V1 managed to achieve 25-second transfer speeds at competitive costs without compromising on security or decentralisation.

For a detailed technical overview, please consult the following resources:

Concero V2

Building upon the capabilities of Concero V1, which leveraged Chainlink CCIP and Chainlink Functions, we recognised the potential of extending the protocol’s reach to a wider array of networks. This motivated us to develop Concero V2—a cross-chain interoperability protocol capable of facilitating any-to-any network communication.

Unlimited network reach

While Concero V2 introduces significant advancements over V1, it leverages relayer nodes economically secured by Symbiotic restaking. Coupling them with Chainlink Functions, Concero V2 effectively expands its reach to any chain.

Modularity

Concero V2 provides developers with greater control over the modules required to confirm cross-chain messages. This modularity introduces an optional consensus-based approach to bridging and messaging, where multiple relayer nodes and existing networks can validate a message before it is confirmed and released. This added flexibility allows developers to fine-tune the speed, security, and cost of their cross-chain messages depending on their application requirements.

Unlimited transmitted data size

An important update of Concero V2 is that the transmitted data size limit is now as high as it can be – not limited by the protocol itself, but merely by the constraints of the networks the protocol is interacting with.

ProtocolData limits per message
Concero V1~650 bytes
Concero V21.875 MB

This example considers EVM chains only and their theoretical calldata size limit of 1.875 MB, given a 30M block gas limit (as per Ethereum network) and a non-zero calldata byte cost of 16 gas units. Other non-EVMs may vary.

Concero V2 Security

As with the V1, the highest priority for Concero V2 is security. Given the new architecture and the unique security challenges it brings, two main security pillars have been implemented to ensure a reliable and safe operation of the protocol:

Message types

Concero V2 supports three types of cross-chain messages, all of which are covered in detail in the Transaction Flows section below.

Message TypeFocusAdditional Relayer Requirements
Non-value bearing messagesSpeed, CostsNone
Value-bearing messagesSecurity, Speed, CostsNone (Relayer recommended)
Value transfersSecurityRelayer B

Each message type focuses on certain characteristics applicable to specific application use cases and is processed by a minimum of both of the following modules:

Architecture of Concero V2

Schematic overview

concero-v2-architecture.png The architecture of Concero v2 consists of the following modules, which are covered in detail below:

Router contracts

Router contracts are deployed to every supported network of Concero V2 and serve as the single entry point for end users interacting with the protocol.

The core functionality of router contracts includes:

Additional functionality of router contracts includes:

Chainlink Functions is chosen as a trust-minimised verifiable compute to enable essential operations of Concero V2. Computation is requested from a CLF-enabled network – Base – and takes place on four nodes in the Chainlink Functions Decentralised Oracle Network (DON).

The main purpose of Chainlink Functions in Concero V2 is to serve as a verifier of transaction presence on the source chain. After computation results are ready, a report is formed and posted back to the invoking contract. The report is then captured by Relayer A and sent to ConceroRouter on the destination chain.

The fact that the report is signed by at least 3 out of 4 DON nodes allows us to verify the following:

Schematic overview

concero-v2-clf-report.png The following operations take place during Chainlink Functions runtime:

Symbiotic contracts

As a restaking protocol, Symbiotic is responsible for the economic security of Concero v2 by ensuring genuine behaviour of node operators and penalising incorrect claims in case they occur.

As the Symbiotic core contracts are deployed on Ethereum network, their state changes are minimised to ensure cost-efficiency of the protocol. State changes occur only in the case of slashable events, whereas during normal operation only state reads take place. These reads are used to ensure the operator performing an action is both registered and has sufficient delegated stake required for the operation.

Operator rewards

Operator rewards are collected on ConceroRouter contracts at the time of successful transaction fulfilment and are withdrawn from every chain ConceroRouter is deployed on. This approach is chosen in line with minimising Ethereum state changes and maximising cost-efficiency of the infrastructure.

The parties receiving rewards are:

The operator reward rates are yet to be announced.

Operator slashing

Slashing is an essential restaking mechanism which allows protocols to fine relayer operators – the only slashable parties – for inaccurate claims.

Chainlink Functions is used to determine whether the transaction claim received from the relayer is accurate and therefore whether it is slashable. The order of operations outlined in Transaction Flows section set Chainlink Functions as the last party that confirms the transaction, enabling it to fetch published relayer results prior to sending the final report and therefore to simultaneously determine whether there is potential misalignment in consensus. If no consensus is reached, a report is posted to the slasher contract on the Ethereum network, which results in slashing of the operator(s) who posted the incorrect message, for at least 100% of the value that was being relayed.

Challenge period

The challenge period is a time window during which a transaction claims can be disputed before the transaction is considered final. In Concero V2, the challenge period allows for the penalisation of incorrect actions of relayer operators before the transaction is released.

One of the benefits of the restaking architecture of Concero v2 is a near-instant challenge period, which significantly increases delegated stake efficiency for operators. The role of Chainlink Functions in determining whether the operator is to be slashed makes the challenge period of roughly 10-20 seconds.

This efficiency of delegated stake plays a major role in reducing the barrier of entry for operators in Concero V2, as for every 1 ETH delegated an operator is able to relay 1 ETH worth of transactions within ~20 seconds. After the challenges of ongoing transactions are fulfilled, the limit is set back to 1 ETH, allowing the operator to send another 1 ETH worth of transactions.

Relayer nodes

There are two types of relayer nodes in Concero v2:

Relayer A (required)

Enables essential operations of Concero v2. Captures events from ConceroRouter contracts, triggering their confirmation via ConceroCLFRouter deployed on a CLF-Enabled chain in order to obtain the report. Listens for new reports emitted in ConceroCLFRouter, decodes and relays them to the corresponding destination chain ConceroRouter contracts.

Relayer B (optional)

Captures events from SRC chains, relays them to the DST chains as part of consensus with Chainlink Functions report and other networks. Developers are free to enable this optional relayer (as well as other networks) depending on their specific use case.

Existing protocols

On top of the mandatory confirmation modules (Relayer A and Chainlink Functions), Concero plans to implement existing interoperability protocols to work alongside relayers in order to provide additional confirmations for messages and value transfers. In case developers choose to enable optional protocols, destination chain consensus will be determined based on multiple responses of selected networks and relayers, before the transaction is released. Keeping in mind increased transaction completion time and costs, an option of enabling additional protocols allows developers to adjust their risks per transaction in accordance with their specific use case.

Transaction flows

Non-value bearing messages

The nature of non-value bearing messages aims to focus on low-cost, high-speed transactions. As these messages do not involve value, additional network verifications are unnecessary.

  1. End-user sends message to the source chain router contract
  2. Relayer A picks up an event emitted from the source chain router contract regarding the new message.
  3. Relayer A forwards the message to the Master Chain (Base) in order to request a report from Chainlink Functions.
  4. Chainlink Functions return the report to the CLF chain, which is picked up and decoded by Relayer A.
  5. Relayer A forwards the report and TX data to the destination chain router contract in accordance with the decoded report.
  6. Destination chain router contract decodes and verifies the report, ensuring it originated from Chainlink Functions node operators and has not been tampered with, in which case it releases the transaction.

Value-bearing messages & Value-transfers

Value-bearing messages

As there is no technical way for Concero to determine if the message will result in a value unlock for the integrator, we may only recommend developers to enable an additional relayer verification (Relayer B) on an optional basis, which will then be coupled with Chainlink Functions report in the destination chain router consensus.

Value transfers

Unlike value-bearing messages, value transfers utilise Concero’s liquidity pools to facilitate transactions in under 20 seconds. As this is the most sensitive type of transfer, a mandatory dual verification with Chainlink Functions & Relayer B is enforced.

The transaction flow remains the same for both types of transfers:

  1. End-user sends message to the source chain router contract
  2. Relayer A & Relayer B pick up an event emitted from the source chain router contract regarding the new message
  3. Relayer B forwards the message confirmation to the destination chain router.
  4. Relayer A forwards the message to the CLF-Enabled Master chain (Base) in order to request a report from Chainlink Functions.
  5. Chainlink Functions return the report to the CLF-enabled Mater chain, which is picked up and decoded by Relayer A.
  6. Relayer A forwards the report and TX data to the destination chain router contract in accordance with the decoded report.
  7. Destination chain router contract decodes and verifies the report, ensuring it originated from Chainlink Functions node operators and has not been tampered with. It ensures that all of the awaited confirmations have been received, ensures consensus on the message and releases the transaction.

Fees

Message fees

Fixed messages fees are yet to be announced

Value transfer fees

As with Concero V1, the fees on top of the operating costs will remain the same.

Fee TypePercentageCharged
Concero Fee0.1%Always
Liquidity Provider Fee0.1%Only for cross-chain value-transfers
Integrator Fee0% and aboveFor third-party integrations

Risk mitigation

Relayer node risks

In case a relayer posts an incorrect message, Concero V2 has several mechanisms to mitigate any associated risks:

In an unlikely event that the majority of Chainlink DON nodes produce an incorrect message on chain, the risk of value loss can be mitigated through enabling an additional verifier network or relayer (Concero Relayer B), in which case the consensus consisting of Chainlink Functions and an additional protocol will not be met, thereby not releasing the message on the destination chain.

Denial of service

The reliance on node operators for essential operations of the Concero V2 means that the protocol risks temporary pauses or delays in case not enough nodes are in operation. In order to mitigate such risk, an economic model which is attractive for both the operators of Concero V2 and users and integrators of the protocol.