Bitmatrix brings fairness among all end-users when transacting with the covenant —which results in a better overall user experience while mitigating external revenue extraction events such as front-running.
In an EVM environment, front-running is a special type of attack when someone seeing an upcoming trading transaction puts his own transaction ahead, making the prior transaction much less profitable. There are various types of front-running, but the most common type is “slippage-based front-running”. Price slippages occur because of the nature of AMM design — where the larger the deal becomes, the stronger impact it has on the price, and the more the opportunity it brings to the attacker. This is so that the slippage design in EVM environments is inherent to these types of attacks.
In today’s AMMs “slippage tolerance” indicates the minimum amount of tokens users can receive where anything below gets automatically canceled. For example, the default slippage tolerance on Uniswap is 0.5% where users can set their own target. The transaction ordering in a block ultimately decides which transactions to pay for more tolerance and which less. Essentially the more early-ordered the transaction ends up the less (or no) slippage it pays.
In contrast to this EVM-leading approach, Bitmatrix by its nature approaches a “slippage system” from a different angle.
Bitmatrix is based on the UTXO model and the way it processes concurrent swaps is done by aggregating them as partial transactions in one transaction — as outlined here. These partial transactions are ordered lexicographically and the order index does not affect which transaction to pay more for tolerance and which not. This is because the slippage tolerance is held “static” in contrast to being “dynamic”.
Bitmatrix users pay the exact slippage they offer and therefore receive the exact swap amount they see in the interface. This can be thought off the minimum swap amount in the “dynamic” model. While this may have seen as a bad design, because of the fair distribution of slippage among all partial transactions, the default slippage tolerance on Bitmatrix is set to 0.3%, in contrast to 0.5% on Uniswap. Essentially, one user's slippage contributes to the overall slippage pool. The remaining extra sats allocated to this overall slippage pool are paid extra to liquidity providers (in addition to base 0.25%). It’s impractical for malicious users to steal from this pool because the fourth rule of BIP-125 (which Bitmatrix relies on) requires that the replacement transaction must also pay for its own bandwidth at or above the rate set by the node’s minimum relay fee setting.
Overall, Bitmatrix users are certain to pay the default 0.3% slippage tolerance, no less or more. While Uniswap users may end up paying the whole 0.5% or maybe 0.3% or zero— as it depends on the block-ordering.
While 0.3% is the default slippage tolerance, users will be able to set their own tolerance via the settings page on the Bitmatrix interface.
In addition to the user-customizable slippage fee, Bitmatrix covenant is expected to be programmed to charge a minimum rate of 0.25% liquidity provider fee and a fixed rate of 0.05% service commission.
