# Minimal viable Decentarlized Orderflow Distributer (DOFD)

**Main Objective:** This write-up tries to define a minimal viable DOFD with the lowest level of complexity that enables the decentralization of the order flow, and is useful to all involved parties at the same time:

- Why do blockchain users want to use the DOFD?:

- transaction revert protection (hence it allows users to set tight slippages and be better protected against sandwiching)
- fast mining time (faster compared to the situation where users just integrating with one block builder)

- Why block builders should integrate with DOFD?
- Additional order flow allows them to win more frequently in MEV-Boost

- Why ethereum fans should support it:
- It creates a fair builder market and hence decentralizes the builder infrastructure.

- Why this is not SUAVE:
- Suave's scope is much broader (e.g.intends to give MEV back to users). Suave's scope is much more challenging and could be done in later iterations(Non-MVP) of the DOFD.

## Specifications:

#### Privacy options:

Privacy of order flow is a very important concept for trading and hence the MVP will support 3 models of privacy from the start:
1. **Hidden order flow:** Here, only the tx-hash, and transaction meta information like gas limit, and max-gas-price + tip are shared. The real transaction will only be shared with block-builders after they included the tx into their block.
1. **Signature-Hidden order flow:** This order flow will be shared with everyone, but the signatures are cut out. The signature will only be shared later if the block was produced according to a set of rules from listed block-builders. This means that this information can not be shared with any malicious block-builder, as the DOFD would not share the signature and the block will not receive enough signatures, due to data unavailability.
1. **Open order flow:** Orders shared in this mode will be part of the public mempool visible to everyone.

### Single node specification
First, we will only describe the infrastructure with one single node to avoid many complexities. Later on, we will describe it as a fully decentralized network.

**Single DOFD node infrastructure**
- The single DOFD node will receive unencrypted transaction messages with an encryption intention (hidden, signature-hidden, open).
- The order flow received by the single DOFD node is shared minus the private data(for hidden orders, only the transaction hashes are shared, for signature-hidden the whole payload minus the signature is shared)
- Each builder has to register themselves permissionless on the ethereum blockchain in a 'register-contract'. To prevent misuse, a registration fee/bond might be charged. During the registration, builders share their public builder key.
- Block builders compete to build the best blocks according to the MEV boost specification, but they are constrained by the following rule:
- They are not allowed to have any reversion of any signature-hidden transactions in their block.
- Any violation of the rule will result in a delisting of the builders from the official builders' list, first via governance, later maybe via zk-proofs. Hence these builders would not get the order flow in the future - unless they register again under a different name and pay the listing fees/bonds again.
- Block builders continuously build new blocks and provide their best solutions to the MEV relays. The MEV relay will double-check with the single DOFD node, whether the data is available for the proposed block and only then relay the block to validators.

Properties of the system:
- Private transactions require trust in the relayer and the DOFD node that their transaction are not leaked (as is the case today).
- Users that wanna use the DOFD could just integrate with the DOFD similar to Metamask allows integrating `flashbots protect` today. For each different encryption level, they would talk to the node with a different URL
- For delisting the system needs a minimal form of governance: Initially, this could just be a multi-sig of high-reputable people in the blockchain space
- Since in theory, there could be several DOFD systems - as there are several relayers today, the censorship resistance will not be hampered with. Only, if DOFDs decide that one of their rules for builders is to not include non-public order flow - to make the market fairer for all builders - then the censorship-resistance will be influenced.

### Network specification

The actual implementation will likely vary a little bit according to which PBS implementation is chosen by the ethereum community.
For the following, we assume that PBS has implemented a similar to this [2-slot PBS](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980) proposal.

- The DOFD nodes will select per block a committee of 256 members.
- A trader erasure-codes the hidden payload of their transaction into 256 chunks (85 needed to recover), encrypts the i’th chunk to the public key of the i’th committee member, and sends this info to the DOFD nodes. Additionally, the trader needs to generate a zk-proof verifying that the signatures are valid and certain meta information - like transaction gas limit and transaction gas price and tip - are valid.
- The DOFD nodes share the order flow - minus the hidden part - to everyone and the committee signs off the data availability of the hidden part
- Builders are again - as described above - permissionless register themselves. Though there might be some registration fee/bond, to prevent misuse of order flow
- The block-builders are building their blocks and participating in the MEV-Boost auction
- The proposer accepts the highest-bid header for which they found at least 170 signatures
- During the MEV-Boost auction, the proposer asks for the winning block and then sign it off, and sends the proposal to the committee according to their risk preference
- The committee will evaluate the chosen block according to a set of rules. Initially, these rules will be:
- there are no reverted transactions from the open and signature-hidden order flow in the block
- no private order flow is included. The order flow should be seen by the majority of the nodes and at least 80 committee signatures should be available.
- After successful validation, the committee will decrypt and publish the whole block - liveness is given if 85 of the 256 nodes are publishing their erasure code
- If a block is proposed by a non-registered builder, and this builder is using hidden or signature/hidden order flow of the DOFD network, the committee will not publish the data necessary to finalize the block. This is done to enforce the rules - e.g. no reverted transaction - over the registered builders.

Properties of the system:

- order flow stays private, if not 85 of 256 of the nodes collude
- data availability is given if 85 of 256 nodes are online and share their secrets
- revert protection and privacy are on the same level as we have today with flashbots protect