# Decentralized order flow distributer (DOFD)

**URL:** https://collective.flashbots.net/t/decentralized-order-flow-distributer-dofd/731
**Category:** Research
**Tags:** order-flow
**Created:** [November 13, 2022, 10:56am UTC](https://collective.flashbots.net/t/decentralized-order-flow-distributer-dofd/731 "2022-11-13T10:56:45Z")
**Posts on this page:** 1
**Showing post:** 14

<div class="post-metadata">

### Author: ![josojo](https://collective.flashbots.net/letter_avatar_proxy/v4/letter/j/779978/32.png) [@josojo](https://collective.flashbots.net/u/josojo)
#### Post date: [January 26, 2023, 8:05am UTC](https://collective.flashbots.net/t/decentralized-order-flow-distributer-dofd/731/14 "2023-01-26T08:05:49Z")

</div>

> [@Quintus](#):
>
> My main concerns are with latency, advantages drawn from being the first to decrypt and changing the committee (basically, everything DKG related), but I haven’t really looked into it much.

What kind of latency does the system require?  
I think latency will be good (likely good enough) as

- During the decryption process, only the parts of the private message-keys of transactions in the block need to be sent over the network - no bigger data junks. One DKG decryption should be pretty fast and lean and the specification requires “only” 1 DKG private key generate per tx included in the block. And since DKG works with thresholds, only a certain percentage of the network needs to act fast and publish their secrets on time, such that the decryption can start on time. (If there is a small percentage of malicious DKG nodes that want to delay something, they can’t, if the threshold is reached without them).
- the encyrpted orderflow can be continuously be published (the tx-sender can even encrypt the tx themselves with the public DKG key and send it to all builders. )

> [@llllvvuu](#):
>
> > [@josojo](#):
> >
> > Allowing builders to only see the transactions without the signatures prevents them from publishing the transactions to other builders.
> 
> This is the most important innovation here IMO. You cannot get the contents ratified without claiming accountability for them - very nice. We do need to be careful that this doesn’t create any liveness issues.

Yes, the DKG/DOFD nodes must ensure data availablity for the signatures. Otherwise, as you are saying, there would be a risk of liveness failure.

> [@llllvvuu](#):
>
> The reason is that if you add these slashing conditions then you get to a point where you must censor to win the most MEV without being slashed.

It could be that this is true for some transactions. But if someone pays a bigger eip1559 tip to be included, it’s very unlikely that the best solution would have to censor this person(assuming the tip is big enough). Or am I missing something?

---

_[View the full topic](https://collective.flashbots.net/t/decentralized-order-flow-distributer-dofd/731)._