bloXroute’s Value Model (from Milliseconds to $): The Uniswap Case
By bloXroute Co-Founder and Chief Architect Professor Aleksandar Kuzmanovic
bloXroute recently launched our DeFi tool kit. One of the tools we offer is fast propagation. Here we estimate the value in USD that bloXroute’s fast propagation of transactions brings to bloXroute’s users. We will focus on a single popular DeFi application — Uniswap, though a similar model might be applicable to other DeFi applications.
Takeway: bloXroute is currently sending transactions 150–900ms faster (depending on the node infrastructure used) and this can translate to 2–12% improvement in one’s trading strategy.
Uniswap Background
Uniswap is an Ethereum-based exchange that allows anyone to swap ERC20 tokens. Traditionally token swaps require buyers and sellers to create liquidity, while Uniswap creates markets automatically.
A Uniswap Pool consists of two ERC20 tokens, deposited by liquidity providers, which get a fee whenever someone trades at the pool.
The price at which one can buy or sell tokens at the pool is determined using a price curve defined by x*y=k, as illustrated in the above Figure. This has several important effects:
- The larger a transaction one wants to make, the worse the price she gets. Hence, users are advised to make a larger number of smaller-value transactions.
- If a trade is “contested,” i.e., a larger number of users want to trade at the same contract at the same time, then those who execute sooner, i.e., in a prior block, get a better price than those who execute in a latter block.
- If a user sets a slippage parameter (which determines the floor of “low” she will still accept) too conservatively, yet others manage to trade on that contract before the user, then it is possible that the user’s transaction simply won’t execute. In such a scenario the user still loses the Ethereum fee for the transaction.
Architecturally, Uniswap looks as follows:
Model Parameters
In terms of our model which we will present next, important parameters are:
Uniswap Daily Transaction Volume: Currently (8/20/20 at 2:00PM) at $287M daily (CoinGecko). The distribution of Uniswap Pairs is highly biased, i.e., the top 10 Unsiwap Pairs approximately account for 50% of the entire transaction volume. Such pairs are thus highly “contested,” i.e., if a transaction is not executed in a block, executing it in the next block will come with a loss.
Value Loss due to Trading Loss: We want to quantify the amount of loss a user has once she fails to execute her transaction or executes at a level that is still within her slippage parameter, but below the one executed by those who acted faster. Oftentimes, a failed transaction can never be executed again, and sometimes it can be executed at much worse conditions.
Model
bloXroute deploys a Blockchain Distribution Network that reduces the latency for a transaction to reach mining pools. Below, we aim to quantify how this latency reduction, expressed in milliseconds, can be quantified in terms of $, in the context of the Uniswap application.
Consider the following parameters.
Delta: The amount of time, in milliseconds, by which bloXroute transmits a transaction faster than the p2p network. In other words, it is defined as Delta = Latency_p2p — Latency_BLXR, for a transaction. While this value is variable in reality, in our model we use a constant value for simplicity.
Probability that a Uniswap user is supported by bloXroute: For bloXroute to be effective, a Uniswap transaction needs to be bloXroute-supported.
Critical Delta. In order to compute the probability that a bloXroute-supported transaction is generated during a critical period when bloXroute provides a competitive advantage to its users, we define the Critical Delta period.
Assuming the next block will be mined by a pool, consider a moment (t1 in the Figure) as the deadline for the mining pool, to decide on the contents of the block. If a bloXroute-supported transaction is sent prior to t1-Latency_BLXR, it will reach the mining pool before the deadline, hence it will be eligible to be included in the next block. At the same time, if a non-bloXroute supported transaction is generated during the CRITICAL DELTA, it will not be possible for it to be included in the next block, because it will not reach the mining pool prior to the t1 deadline.
To better understand this, consider an example shown in the next figure.
The first transaction, 1, is generated before the CRITICAL DELTA period (before t1-Latency_p2p). Thus, irrespectively if it is supported by bloXroute or not, it will arrive to the mining pool “on time,” before the next block is started to be mined. Hence, bloXroute provides no competitive advantage in this case.
The second transaction, 2, is generated during the CRITICAL DELTA, i.e., [t1-Latency_p2p, t1-Latency_BLXR]. Thus, if the transaction is bloXroute-supported, it will reach the mining pool before the deadline, hence it will be possible to include it in the next block (we assume that the mining fees and slippage parameters are set to enable this). On the other hand, if transaction 2 is not bloXroute-supported, it will arrive to the mining pool after the deadline, hence it will not be possible to include it in the next block. This is where bloXroute provides a competitive advantage.
The third transaction, 3, is generated after the CRITICAL DELTA period, i.e., after t1-Latency_BLXR. Hence, it will not make it to the mining pool on time either if it is supported by bloXroute or not. Thus, we conclude that bloXroute does not provide a competitive advantage in this scenario.
Probability that a transaction is generated during the Critical Delta for a block
Here, we want to compute the probability that a bloXroute-supported transaction is generated during the CRITICAL DELTA. We approximate this probability by CRITICAL DELTA / inter-block-time. For a fixed Delta, the shorter the inter-block time is, the larger the probability that the transaction is generated during the Critical Delta, and vice versa.
To compute this probability, we rely on a real-world distribution of inter-block times, shown below. The y-axis shows the number of inter-block events as a function of the inter-block intervals in seconds (x-axis).
In particular, we compute the probability that the transaction is generated during the Critical Delta for a block as follows.
P = Sum (Delta / inter-block-time) * Prob of the inter-block-time
The results of this computation for various values of Delta are shown in the Table below.
The results in the Table show that, for example, if the DELTA, i.e., the latency improvement of bloXroute over p2p, is 600 ms, this leads to 8% of scenarios where bloXroute will deterministically help the transaction reach the mining pool before the deadline. A 8% improvement in one’s trading strategy can lead to huge returns and savings on fees that would have otherwise been wasted on failed transactions.
bloXroute is currently sending transactions 150–900ms faster depending on the node infrastructure used.
Conclusion
Traders can take advantage of bloXroute’s high speed network to boost their trading strategies and unlock additional value. Uniswap is just one example of this. Anyone can unlock the power of faster, smarter trading today with the bloXroute BDN.
Get Started Today.
There are two ways to connect to bloXroute’s Blockchain Distribution Network (BDN).
1. Gateway
For those that run full nodes, the Gateway offers an entry point to the BDN. Your full node peers with a Gateway, which is connected to the rest of the bloXroute Blockchain Distribution Network. The Gateway then sends and receives transactions and blocks to your node.
You can also bypass your node and speak directly to the Gateway-API, which supports receiving commands that can be invoked directly from users application or via the bloXroute-cli utility. The Gateway-API is based on RPC.
2. Cloud-API
The bloXroute Cloud-API is a set of endpoints that allow users to send and receive data from the BDN. This option is perfect for Users who do not run a full node. Transactions can be sent from the bloXroute-cli or directly using a curl / https request and received from the BDN by subscribing to the Transaction Stream (below).
Subscribing to Transaction Stream
Once connected to the BDN, users can subscribe to the bloXroute Transaction Stream (Tx Stream) to receive new pending transactions in the Ethereum network.
The Tx Stream currently supports two subscription feeds: pendingTxs and newTxs .
- pendingTxs is the stream of all new transactions as they enter the Ethereum TxPool.
- newTxs is the stream of all new transactions as they propagate in the BDN.
To Begin:
- Register an account.
- Select a paid tier plan (all plans come with a 14-day free trial). Note that the introductory plan will not work. All plans can be paid for in cryptocurrency, including DAI, ETH, BCH, and BTC.
- After downloading the artifacts, unzip the content of the archive to a folder. The archive contains the certificate and the key file in a pem format. (The files are stored in the sub folder external_gateway\registration_only. You should not change these folder names.)
Use blxr_tx to send transactions fast via the Cloud-API or Gateway-API
- Method: blxr_tx
- Params: a json that consists of the mandatory transaction string and optional synchronous flag, detailed below.
- Transaction: (mandatory) the raw transaction in string hex format.
- Synchronous: (optional, default: true) a boolean flag indicating if the caller waits for a complete answer from BDN.
Cloud-API blxr_tx
To use the Cloud-API, prepare the authorization header using the secret hash from the account registration.
For Example: base64.b64encode(f”{account_id}:{secret_hash}”.encode(“utf-8”)).decode(“utf-8”)
Call the blxr_tx method using the authorization header you created above.
Subscribe to the Transaction Stream
To subscribe to the Transaction Stream, use the certificate and private key you saved from the artifacts. Follow the instructions here for more information.
Have a problem? Email our team at support@bloxroute.com or post your question in our Technical Support channel on Discord.
