WebSockets SDK
A simple-to-integrate API that provides dApps with front-run protected transaction flow for their users.
Frontrunning is now a major UX issue across Ethereum and EVM-based chains, with an average of over 10,000 sandwich attacks each day. Users are increasingly seeking out services and solutions to protect their transactions from unwanted sandwiching, frontrunning, or other forms of exploitation.
Flashbots provides a proven solution against frontrunning and other negative externality MEV by sending transactions directly to miners, avoiding the public mempool. Currently, more than 92% of miner hashrate participates in the Flashbots network.
However, for Web3 dApps, integrating directly with Flashbots to route transaction flow is often not practical for a number of reasons, including backend overhead and the need to maintain a reputation score.
The WebSockets SDK is a simple-to-integrate API that provides dApps with front-run protected transaction flow for their users. The SDK bundles transactions and submits them to the Flashbots network. This gives Web3 dApp users a range of benefits such as free transaction cancellations and protection against negative-externality MEV.

How it works

The WebSockets SDK transaction flow works as follows:

    1.
    The client opens a WebSocket connection with the WebSockets SDK Relay directly from the frontend web application in browser
    2.
    The client publishes the serialized transaction signed (via eth_sign or eth_signTransaction) by the user to our backend using the WebSockets SDK.
    3.
    Our backend repeatedly publishes the transaction, each block, to the Flashbots miner network. The backend analyses and validates the response, providing real-time feedback to the frontend Web application - for example: “block passed without inclusion”, “insufficient fee for competitive inclusion”, “transaction reverted - not included in block”, “transaction successfully included in block”
    4.
    A user can cancel an unconfirmed transaction at any time for free, and reverted transactions cost no gas
    5.
    Once the transaction is successful, details of the tx hash and containing block are returned

Why not integrate directly?

While integrating a Web3 dApp directly to Flashbots without the SDK is possible, it is not practical for the majority of projects for several reasons:
    1.
    Transaction delivery through Flashbots has a lot of architecture overhead and requires distributed backend infrastructure. This is a burden for projects which aim to deliver a lightweight single-page application to their users
    2.
    All Flashbots bundles require signing with a bundle key, which maintains a reputation score. A high reputation score is essential for timely inclusion in blocks during periods of high network traffic
    3.
    Flashbots has a competitive bidding system, and careful attention is required to analyze in advance for reverts or errors and maintain a high success rate for transaction inclusion. Failing to maintain a high reputation drastically decreases successful inclusion
    4.
    Submitting reverting transactions lowers your reputation on Flashbots and future inclusion rate. The WebSockets SDK performs in-house simulation to ensure a high delivery rate
The WebSockets SDK handles all of this overhead for dApps, freeing your development resources to focus on your product and other things your users care about.

Fees

We work with teams to come up with a pricing plan.

Advanced Integration

For more advanced integration, mistX provides a router contract which offers gasless transactions and protection against uncle bandit attacks.
Since providing gasless transactions is no longer riskless after eip1559, MistX will charge a small fee on every transaction in order to cover the execution risk.

FAQ

What are the infrastructure requirements?

The integration can be handled on the frontend through a WebSocket connection with the relay. It does not require the app party to maintain any backend services

Who currently uses the WebSockets SDK?

The mistX exchange aggregator built the SDK and uses it to provide over $150m per month in Flashbots-protected transactions.

Are pending transactions visible on Etherscan?

No, since transactions are never sent to the public mempool they will not be visible on Etherscan until they are successfully included in a block. Information about the pending transaction state is communicated to the frontend via the SDK.

Can the frontend client use MetaMask to sign transactions?

Yes, while MetaMask does not currently support eth_signTransaction, eth_sign can be used without broadcasting the transaction. Any wallet can be used that supports eth_signTransaction or eth_sign. However, for a better user experience, we recommend wallets that support eth_signTransaction.

How does EIP1559 affect the WebSockets SDK?

EIP1559 has no effect on the WebSockets SDK as the user pays the EIP1559 base fee in the same manner as a regular transaction.
Last modified 17d ago