Bifrost Relayer Release Analysis v1.0.4

:warning: The following report is a set of changes that deserves to be highlighted due to their impact on the Bifrost Network. Highlights are categorized into High Impact, Medium Impact, and Low Impact for ease of navigation.

For more information on setting up your relayer please follow our official documentations.


This report analyzes the recent updates to the Bifrost Network’s (CCCP) Relayer. The primary feature of this release is its improvements on state verifications, as well as resource optimization. The target client is (Rust) that has been updated to accommodate these changes.

Client Upgrade

  • V1.0.3 → V1.0.4

:warning: Please note that it is recommended to upgrade your Relayer client and configurations if you’re operating a Relayer on our Mainnet or Testnet.

:hammer_and_wrench: Medium Impact

Balance check before transaction executions

PR: CCCP-229, feature: balance check before sending transactions by dnjscksdn98 · Pull Request #90 · bifrost-platform/ · GitHub

Previously, the built-in TransactionManager didn’t have any existing business logic of remaining balance checks. Due to this issue, transactions has been executed even though the relayer’s account had insufficient funds to pay transaction fees, that occurred to unexpected system failures and wasting funds. To prevent the issue, the TransactionManager now verifies whether the relayer’s account has sufficient funds or not, before executing every single transaction. If it ends up into insufficient funds, the system will be gracefully shutdown to restrain further failures. In order to track system failures, we highly recommend to attach Sentry or any other alerting tools to your relayer system to properly respond to a matter or situation.

Provide customizable eth_getLogs batch size

PR: CCCP-247 feature, provide get logs batch size option by dnjscksdn98 · Pull Request #91 · bifrost-platform/ · GitHub

In default, the built-in BlockManager will periodically read every blocks whether it contains CCCP events. This process is worked through by utilizing the JSON RPC method, eth_getLogs. This method has the feature to search certain contract event logs that had been emitted among the given block range. In most cases, eth_getLogs will consume high resources of your running node, and this is not exceptional for node provider services. We now provide customizable eth_getLogs batch size to optimize and reduce your resource usages, instead of using a constant single block batch per request.

In order to setup your batch size, it’s required to update your configuration YAML file. First, add the get_logs_batch_size parameter with the batch size (in blocks) into the EVM provider that requires higher batch sizes as below (A system restart is required). The default batch size is 1.

- name: "base"
  id: 84531
  call_interval: 2000
  block_confirmations: 7
  is_relay_target: false
  eip1559: true
  get_logs_batch_size: 3
  socket_address: "0x9c8B701961C20d006cb7c4B5B91c6cb93EdB44Ac"
  vault_address: "0x6EeE91b7c69e3576C13cE7a9C7C0E305dF6996F9"
  authority_address: "0xb3f5C3a2237Df09F94dDAC32F63E5D962Ae66a42"

Please note that custom setups will lead to certain tradeoffs as below.

  • Higher batch size → Lower resource usage. However, longer delays required to process a single CCCP event.

Support compatibility between EIP-1559 and Legacy typed transactions

PR: [CCCP-224] error on switching legacy <-> eip1559 tx_handler by alstjd0921 · Pull Request #88 · bifrost-platform/ · GitHub

The TransactionManager is customizable whether transactions will be executed in an EIP-1559 or a legacy format. This option can be configured by providing the eip1559 parameter into your configuration YAML file. However, in a very low probability, we have reached to an unexpected issue when the executed transaction has been stuck to the memory pool. While the transaction stays in the memory pool and when the system has been restarted with a switched TransactionManager type (either from EIP-1559 to Legacy, or vice versa), the transaction replacement process will not work properly due to the type incompatibility (The TransactionManager tries to replace the stuck transaction on-start). The TransactionManager will now handle the incompatibility issue by converting the transaction to the correct format before the replacement.

:speech_balloon: Low Impact

Improve on-start verifications

PR: CCCP-228, feature: enhance bootstrap verifications by dnjscksdn98 · Pull Request #89 · bifrost-platform/ · GitHub

The on-start process has been improved by adding some verification logics. The following verifications are to prevent unexpected system behaviors. If any verification is unsuccessful, the system won’t start.

  • Compare the configured chain ID specified in your configuration YAML file with the actual response from your connected node by eth_chainId.
  • Check if the configured account has at least the specified minimum amount (=1 BFC).
  • Verifies whether the following numeric parameters exceeds the maximum limit.
    • evm_providers.call_interval: [0, 60000] → max 60 seconds
    • evm_providers.block_confirmations: [0, 100] → max 100 blocks
    • evm_providers.escalate_percentage: [0.0, 100.0] → max 100%
    • evm_providers.escalate_interval: [0, 60] → max 60 seconds
    • evm_providers.duplicate_confirm_delay: [0, 60000] → max 60 seconds
    • evm_providers.get_logs_batch_size: [1, 60 seconds / call_interval] → max to the number of blocks the target chain averagely mines per minute
    • bootstrap_config.round_offset: [0, 64] → max 64 rounds

Process to update client

Please follow the steps below to update your relayer client.

Step 1.

First, remove or backup the previous bifrost-relayer binary file.


Step 3.

Then, install the latest version of bifrost-relayer into the same directory and update permissions. (In case of directory changes, the Systemd configuration file should be modified as well)

wget ""
chmod +x bifrost-relayer

Step 4.

At last, restart the Systemd service.

sudo systemctl restart bifrost-relayer