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. Below is the dynamic service fee approach for sharing the profits:
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
)
REQUEST
Method: blxr_submit_bundle
Parameters
transaction
A list of raw transaction bytes without a 0x prefix, seperated by a comma.
blockchain_network
Blockchain network name. Must be BSC-Mainnet.
block_number
Block number of a future block to include this bundle in, in hex value.
min_timestamp
[Optional] The minimum timestamp that the bundle is valid on, an integer in unix epoch format. Default value is None.
max_timestamp
[Optional] The maximum timestamp that the bundle is valid on, an integer in unix epoch format. Default value is None.
reverting_hashes
[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.
dropping_hashes
[Optional] A list of transaction hashes within the bundle that can be removed from the bundle if it's deemed useful (but not revert). For example, when transaction is invalid. Default is empty list: the whole bundle would be excluded if any transaction fails.
blocks_count
[Optional, default: 1] An integer that specifies the number of subsequent blocks that the bundle is valid for. The maximum value allowed for this parameter is 20. For example, when block_number
parameter is 1000, and blocks_count
is 3, then the current bundle would be processed with block numbers 1000, 1001, 1002.
mev_builders
[Optional, default: all
builder] A dictionary of MEV builders that should receive the bundle. For each MEV builder, a signature (which can be an empty string) is required.
Possible MEV builders are:
bloxroute
: bloXroute internal builder (always enabled for all MEV bundle submission requests)all
: all builders
avoid_mixed_bundles
[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
Ultra
Unlimited
Enterprise-Elite
Unlimited
Enterprise
12 bundle requests every block number
4 bundle requests every second
Professional
4 bundle requests every block number
2 bundle requests every second
Introductory
2 bundle requests every block number
1 bundle request every second
Last updated