BSC Bundle Submission
Submit a BSC bundle to the Cloud-API, which validates and forwards the bundle to MEV Relays directly connected to BSC validators participating in our MEV solution program.
Implementation
The MEV Relay builds blocks based on MEV bundles and mempool transactions with the highest possible validator reward. It then sends these blocks to the current proposer.
Assuming one of the proposed blocks has a higher reward than any other block the validator has (i.e. a locally produced block or a block received from another MEV Relay), the validator will seal and commit the proposed block including the MEV bundles.
Payout/Profit Sharing
The mechanism described works well when all parties benefit. Hence, you are expected to share profit both with the validator and with bloXroute. There are two approaches of sharing the profits:
Approach 1 β fixed service fee [payment to validator with gas price, payment to bloXroute with BNB transfer]:
Payment to the validator must be done through the gas fee of one of the transactions in the bundle, which, in BSC, is how validators collect their reward. Since you are submitting your transaction in a bundle, you can have a high gas price transaction after a low gas price which allows for backrunning or sandwich bundles.
bloXroute fixed service fee must be paid as part of the bundle, sent to the bloXroute wallet address. Most users use an internal transaction for this fee payment. The bloXroute address should be taken from the blxr_info endpoint (currently
0x965Df5Ff6116C395187E288e5C87fb96CfB8141c
). The bloXroute fixed service fee structure is documented in the table below.
Profit sharing summary table - fixed service fee approach
Stakeholders | Comment |
---|---|
Searcher | You can decide how much to keep for yourself based on the competition |
Validator | You can decide how much to pay the validator based on the competition. If others offer higher reward to the validator competing over the same opportunity, your bundle will not be selected |
bloXroute | Bundle prices can be queried with |
Approach 2 β dynamic service fee [payment to validator and bloXroute with a single BNB transfer]:
Payment to both validator and bloXroute can be done through a single transfer of BNB to address 0x74c5F8C6ffe41AD4789602BDB9a48E6Cad623520
. The transfer can be either an internal transaction transfer (which may require a custom smart contract), or an extra regular transaction added to the bundle. When using this approach, searchers donβt need to send additional bundle service fee to bloXroute address (currently 0x965Df5Ff6116C395187E288e5C87fb96CfB8141c
)
Fixed Service Fee and Dynamic Service Fee Comparison
Searchers can select either approach 1 or approach 2. With approach 2, searchers can easily bid on low margin opportunities below the fixed bundle service fee; plus, searchers can protect their bundles from potential blockchain reorgs by using custom smart contract such that the payment would be executed only if transaction is successful, instead of paying high gas price when reverted transaction lands on chain in a forked block.
For example, in an arbitrage opportunity with profit 0.1 BNB that involves a 3-tx bundle sent by an introductory plan searcher. With approach 1, the searcher needs to pay 0.004 BNB as fixed amount service fee to bloXroute address 0x965Df5Ff6116C395187E288e5C87fb96CfB8141c
, then the rest of the profit (0.1 BNB - 0.004 BNB = 0.096 BNB) will mostly be paid to validator via gas price. With approach 2, the searcher can simply transfer the 0.097 BNB (in this scenario, searcher pays 97% of the profit and keeps the rest) profit to address 0x74c5F8C6ffe41AD4789602BDB9a48E6Cad623520
without using high gas price to pay the validator.
REQUEST
Method: blxr_submit_bundle
Parameters
Parameters | Descriptions |
---|---|
| A list of raw transaction bytes without a 0x prefix, seperated by a comma. |
| Blockchain network name. Must be BSC-Mainnet. |
| Block number of a future block to include this bundle in, in hex value. |
| [Optional] The minimum timestamp that the bundle is valid on, an integer in unix epoch format. Default value is None. |
| [Optional] The maximum timestamp that the bundle is valid on, an integer in unix epoch format. Default value is None. |
| [Optional] A list of transaction hashes within the bundle that are allowed to revert. Default is empty list: the whole bundle would be excluded if any transaction reverts. |
| [Optional, default:
|
| [Optional, default: False] A boolean indicating whether it is okay to mix the bundle with other bundles and transactions. If false, then there might be other transactions inserted into the bundle assuming the original transactions in the bundle don't revert. |
Examples (Cloud API)
Rate Limit and Restriction
Plan | Submission and Simulation Rate Limit | Transaction Count Restriction and Bundle Price in Fixed Service Fee Approach |
---|---|---|
Ultra | Unlimited |
|
Enterprise-Elite | Unlimited |
|
Enterprise |
|
|
Professional |
|
|
Introductory |
|
|
Last updated