Introduction to the Biconomy Relayer Network (BRN)

Biconomy Relayer Network (BRN)
, ,
1

Biconomy has been running and perfecting our relayer infrastructure for almost 3 years. The relayer infrastructure pioneered meta-transactions and made massive strides in managing all aspects of a transaction on the user’s behalf.

This helped dApp developers scale their applications by removing gas-related complexities by either providing gas subsidies to their end users or by allowing their users to pay gas fee in any ERC20 tokens. Over time, we added cross-chain transaction execution as well, helping dApps become practically chainless by unifying liquidity and smart contract interaction across multiple chains. We will keep building new transaction-level innovations to abstract away UX complexities as part of our new SDK. For example, our relayer infrastructure will soon allow for automated transaction execution based on external or on-chain inputs.

We think it’s high time to take our relayer infrastructure to another groundbreaking level - a decentralized & trustless multi-chain relayer network where anyone in the world can participate and contribute to the transaction management & execution layer of web3. Thus, forms the idea of the Biconomy Relayer Network (BRN).

Biconomy Relayer Network is a collective term for a group of computers/nodes that are running the Biconomy Relayer Node Specification. The nodes will be rewarded for executing transactions that follow the rules of the network and penalized for any undesirable behavior.

We at Biconomy are a proponent of progressive decentralization. By staying true to our ethos, we have been running and optimizing the relayer node as a trusted entity to get to product market fit. While this approach has helped us scale phenomenally to serve over 25M transactions, a centralized system cannot help us realize the dream of onboarding the next billion users and making it accessible in a non-custodial manner. As a starting point, we have already open-sourced the relayer node, and anybody can run their own relayer setup by utilizing our code.

Decentralization is hard. There are a lot of moving parts and some pretty hard questions to tackle to make the system as trustless and robust as possible. To give you a flavor of what’s coming, here are a few questions that the team is dabbling with at this point:

  • How do we incentivize nodes to execute a transaction without destructive competition between themselves?
  • How does the system differentiate between a malicious node censoring transactions against a genuine node with a local power outage?
  • What are the different scenarios in which a node’s stake can get slashed?
  • How does the reward split happen between the node and the delegators?

We hope to build a robust, permissionless, and composable decentralized protocol. We want to create the hyperstructure on which many more protocols will be built and which can advance our mission of onboarding the next billion users.

Looking forward to building the most crucial infrastructure for scaling the user experience with all of you.

Onwards and Upwards!

PS: Read the team’s initial thoughts on the workings of the network here.

PPS: We will be creating more long-form posts on specific topics around the network. Keep an eye on this space for more updates.
Join the protocol forum on discord to stay updated and contribute to live conversations, where we will start posting weekly updates.

3 Likes
2

Fascinating news!

To get the convo started, I have a question on the following.

At Flashbots, we generally see competition between relayers as positive for the user, as it creates an incentive to drive down costs and improve user execution. Could you say more about the destructive effects of competition you are worried about?

3

How to prevent nodes from competing for the same transaction. If there are sufficient rewards, especially if they vary greatly across chains/operations, we may see nodes compete against each other to submit the transaction (i.e., racing conditions). However, as you suggest we do want nodes to compete on performance, as that would require nodes to continue to optimize their setups leading to more optimal user experience. As of now, we are looking to motivate competition by allocating a greater share of transactions to nodes with higher overall stake (bonded + delegated). A high performing node should accrue stake, as they are consistently earning more money for their delegators.

1 Like
4

Thanks, trevor. It sounds like the problem could also be solved by simulating competing transactions before broadcasting so that only the winning one ends up in a block. Flashbots or any other block builder can do that for free today, but you can also do it on your end by adding your own relayer into the mix that only simulates candidate transactions and forwards the winning one?

5

Hello Hasu, thanks for your question.
The competition arrives when a relayer sees a transaction submitted by another relayer and decides to submit the same transaction to the blockchain with higher gas to get the reward. Only one transaction will be included in a block, the other will fail meaning that there is one of the relayers that loses funds used to pay for the failed transaction. This is what we consider a destructive competition.

6

What benefits do you see for doing this? For further clarification, we haven’t finalized on a fee model, but as of now we are planning for a fixed premium of gas set by the network (i.e., 9% premium on gwei up to a cap).

7