Cross-Chain Communication Protocol (CCCP)


Bifrost's Cross-Chain Communication Protocol (CCCP) realizes cross-chain communication through interactions between socket contracts and relayers. The CCCP enables users on one blockchain to utilize DApps provided on other blockchains.

A socket contract is a system contract installed on the Bifrost Network and all other external chains such as Ethereum. A socket contract emits a CCC-event when triggered by a CCC-request from another socket contract, and this CCC-event is delivered to another socket contract by a relayer. A user’s request goes around different socket contracts in the form of a CCC-event and terminates when all the necessary logic has been executed.

In particular, multiple relayers deliver the socket-events to ensure the protocol’s continuity even if a certain number of relayers fail or are compromised, and the “timeout rollback” function is in place to prevent the users’ assets from being locked in socket contracts even if the entire relayer group fails. Additionally, the total operational cost of the relayer group is significantly cut down by minimizing the number of transactions delivered to other blockchains that have relatively high costs.


  • CCC Protocol (CCCP): Cross-Chain Communication Protocol

  • VS Protocol (VSP): Validator Synchronization Protocol

  • Validator: the consensus validation node of the Bifrost Network

  • Relayer: the CCC protocol-worker node of the Bifrost Network

  • CCC-request: is requested by a user which calls an f(x) installed on other blockchains

  • CCC-event: a CCCP message containing the CCC-request details (socket contract’s event)

  • External chain: any blockchain other than the Bifrost Network (e.g. Ethereum, BNB chain, Polygon, etc.)

  • f(x): a pre-defined function to be executed in other blockchains. (smart contract)

  • Positive status: the CCC-status indicating “success” (REQUESTED, EXECUTED, ACCEPTED, COMMITTED)

  • Negative status: the CCC-status indicating “failure”; the positive and negative statuses have been accordingly paired (FAILED, REVERTED, REJECTED, ROLLBACKED)


A user sends a CCC-request to the socket contract, which calls a f(x) under another blockchain. As a f(x) requires cryptocurrency payment, the socket contract collects the user’s cryptocurrency.

Relayers deliver the following data to the socket contract:

  • Latest validator (relayer) list: relayers deliver the latest validator list to all external chains; all blockchains utilize the latest validator list for access control

  • Off-chain data: off-chain data such as certain assets’ prices or Bitcoin blockchain’s block hash are delivered to the Socket contract of the Bifrost Network; the oracle manager contract receives this data from the socket contract and provides oracle services

  • CCC-events: a relayer detects CCC-events from all supported blockchain networks and relays the detected event to its corresponding socket contract; the corresponding socket contract information can be derived from the CCC-event

System Contracts - The Bifrost Network supports the three system contracts:

  • The socket contract generates CCC-events which are to be treated by other socket contracts, or receives CCC-events emitted by other socket contracts and treats them. In particular, it executes request-indicated actions (e.g. mint, lending, leveraged investment) according to the protocol specifications.

  • The Built-in DeFi Suite - The DeFi Suite functions are abstracted and expressed as f(x).

  • The oracle manager contract collects the designated off-chain data and provides on-chain oracle services.

Protocol Design

The following design factors are applied to the CCCP to overcome the limitations of the smart contracts' execution environment.

Design Factors

  • As smart contracts do not provide sufficient data storage space, we only store the data’s hash instead of the entire data in smart contracts. If we need to reuse the data, we re-send it. We use this strategy because comparing the hash value is cheaper than initially storing the data.

  • A transaction may fail due to its atomic property. In this case, another transaction indicating this “failure” must be re-transmitted to leave its failed status on the smart contract.

  • Smart contracts do not provide built-in functions such as sorting array or mapping keys/values return, and implementing such functions is inefficient transaction fee-wise. Thus, the transaction sender may have to send an already sorted array data so that the smart contract does not have to do the sorting.

  • We minimize the number of transactions directed to external chains which impose relatively high fees. When a relayer group relays a CCC-event to an external chain, the CCC-event is first submitted with a signature to the Bifrost Network. Then, the primary relayer aggregates all signatures and delivers them to the external chain at once.

VSP is the sub-protocol of CCCP, which synchronizes the latest validator list of the Bifrost Network to all external chains. The validator list must stay up to date as the validators of the network can change periodically and socket contracts use information about validators for access control.


  • Relayers monitor every CCC-event.

  • Relayers possess sufficient amounts of native coins (e.g. BFC, ETH, BNB) for transaction fees.

  • Relayers are penalized for request forgeries. (Relayers do not harm the protocol for minor gains.)

  • The majority of relayers faithfully execute the protocol. (The number of relayers in shut down status or conducting request forgery attacks is always less than the majority.)

  • The preceding CCC-event accumulation will not cause the failure of the following CCC-event production.

  • Relayers process all events generated during their delegated time, even if they are un-delegated for any reason.

    • Relayers process all requests that occur during their term.

    • The Bifrost Network relays the next validator set.

    • Otherwise, relayers are penalized.

Inbound CCCP

The inbound protocol indicates the delivery method of the CCC-request from an external chain to the Bifrost Network. The figure below represents the CCC-event flow of the inbound protocol. The “relay type” marked for each relay is further explained in the section "Two-Types of Relay Vote".

Each user request delivered to the socket contract of an external chain sequentially goes through “REQUESTED”, “EXECUTED”, and “ACCEPTED” and finally ends in “COMMITTED” status. However, if the Phase 1 f(x) fails to execute, a request goes through “REQUESTED”, “REVERTED”, and “REJECTED” and ends in “ROLLBACKED” status. Requests completed as “ROLLBACKED” return the collected tokens during the user’s transaction.

Outbound CCCP

The outbound protocol indicates the delivery method of the user request from the Bifrost Network to an external chain. The figure below represents the CCC-event flow of the outbound protocol. The “relay type” marked for each relay is further explained in the section "Two-Types of Relay Vote".

Each user request delivered to the socket contract of an external chain sequentially goes through “REQUESTED”, “EXECUTED”, “ACCEPTED” and finally ends in “COMMITTED” status. However, if the Phase2 f(x) fails to execute, a request goes through “REQUESTED”, “REVERTED”, “REJECTED” and ends in “ROLLBACKED” status. Requests completed as “ROLLBACKED” return the collected tokens during the user’s transaction.'

Validator Synchronization Protocol

VSP delivers the updated information on the Bifrost Network’s validator(=relayer) set to all socket contracts on all supported external chains. Socket contracts update their access permission list with the delivered validator set.

Two Types of Relay Vote

A CCC-request is delivered by several relayers for a low risk of data falsification. On the other hand, if a valid CCC-event is concurrently delivered to two different blockchains, user assets can increase or decrease on both sides. For example, when there are five relayers, the quorum is three. There can be a case where two relayers succeed and three fail in transmitting a CCC-event transaction that mints in Ethereum. In such a case, the “failed relayers” transmit a CCC-event transaction to the Bifrost Network, and the user is refunded in Ethereum. However, if one of the “failed relayers” re-sends the mint transaction and succeeds, the user’s asset in the Bifrost Network increases and results in “double payment.” This example shows how one malicious relayer can cause protocol failure.

Situations like the above can occur as the socket contract did not clearly finalize the CCC-event process result before proceeding to the next phase. Thus, a CCC-request must be finalized as one status in each phase before emitting an event. The relayer must proceed to the next phase only when a CCC-event of the next status is detected.

Each phase of the protocol delivers relay votes to the socket contract through one of the type methods described below. Moreover, for phases executing f(x) as a result of the relay vote, the “Self Transition Rule” additionally applies.

Self Transition Rule (if fails)

For phases in which f(x) is executed, such as Inbound Phase1 or Outbound Phase2, the transaction may fail due to the logic of f(x) even if the relayers deliver valid CCC-events. However, as a failed transaction due to its atomic property cannot affect the socket contract, an “execution failure” CCC-event cannot be emitted. Thus, relayers set the CCC-event status to negative and transfer it to the socket contract. When the socket contract receives negative CCC-events from a majority of relayers, it emits the “execution failure” CCC-event and forces the process onto the next phase. (A negative status can never be restored to positive status.)

Furthermore, due to the transaction’s asynchronous property, we cannot know when the next status CCC-event is going to be emitted. There can be a situation where two out of five relayers emit a positive CCC-event, and the other two emit a negative CCC-event. If the remaining relayer does not act, this CCC-event can never be processed. This example shows how the protocol can fail due to one relayer.

Thus, relayers that have voted for positive status verify if the request has been finalized as a positive status after t seconds. If not finalized, the relayers change the original CCC-event to negative status and resend it. As a result, the CCC-event will always be processed in t seconds. (In the example case above, the status would ultimately be settled as negative.)

Figure Description

  1. Each relayer delivers the event of the detected positive status to the next socket contract.

    1. transaction success → set timer

    2. transaction failure → change event to negative status and resend it

  2. timeout → change event to negative status and resend it

For each status, the socket contract executes f(x) at the n-th relay vote transaction that reaches the majority and emits the next CCC-event.

Type 1: General Relay

In the case of a phase with no f(x) in its resulting logic, each relayer simply delivers the CCC-event through a transaction.

Figure Description

  1. All relayers deliver the detected event to the next socket contract.

The socket contract emits the next CCC-event at the n-th relay vote transaction that reaches the majority.

Type 1-1: General Relay with signature

The relayer additionally attaches its signature to execute “Type 1: General Relay”. The socket contract saves the attached signatures, which can later be inquired en bloc by the socket contract.

Type 2: Aggregated Relay

Instead of having all the relayers deliver the CCC-event to an external chain with a relatively high fee, one primary relayer aggregates all relayers’ signatures and emits a CCC-event. (Once the primary relayer is designated, other relayers are automatically considered secondary relayers.)

To ensure that the failure of the primary relayer does not lead to the failure of the protocol, secondary relayers verify whether or not the CCC-event has been successfully emitted after t seconds. If not emitted, all secondary relayers take on the role of the primary relayer and emit the CCC-event.

Figure Description

  1. Calculate the primary relayer index: (the height of the block containing the event) % (the total number of validators). The relayer with the calculated primary relayer index is designated as the primary relayer. (The rest become secondary relayers.)

  2. Primary relayer

    1. Inquires the socket contract for the relayers’ signature values submitted in the preceding phase.

    2. Attaches the majority number of signatures and delivers it to the next socket contract.

  3. Secondary relayers

    1. If the primary relayer’s successful event delivery cannot be verified after t seconds, execute the primary relayer process instead.

The socket contract emits the next CCC-event upon verifying the majority of the signatures received.


CCCP allows external chain users to use Bifrost Network DApp services. For example, let us say that f(x) is “Lending::Deposit” installed in the Bifrost Network. In this case, an Ethereum user can simply deposit tokens to the Ethereum socket contract, and this action will automatically deposit tokens to the lending service on the Bifrost Network. To give another example, let us say that f(x) is “Swap” in the Bifrost Network. In this case, a user can acquire some Bifrost Network’s token B by depositing some Ethereum’s token A through the inbound protocol, and then withdraw Avalanche’s token B through the outbound protocol. This implements a cross-chain swap.

Ultimately, the CCCP of the Bifrost Network allows users to enjoy DeFi services with relatively low fees and fast speed, and easily transfer assets between chains.

Last updated