# OFA Node
***Thought experiment*** : many fork geth to experiment with different L1s, can we create a similar stable starting point for OFAs that benefit from [Linus's law](https://en.wikipedia.org/wiki/Linus%27s_law)?
assumption 1 : many OFAs are coming ( along with the many that are here )
assumption 2 : OFA teams can be convinced of the mutual benefit
☯️ We must ensure balance between the ever looming urge towards engineering complexity here ☯️
## Intro
OFAs are here,

how do we make sure the motley of OFAs coming online all play "nicely"?
## Benefits?
What exactly are the benefits of something like this?
- enables quick experimentation w/ OFAs (i.e. uniswap forks) - maybe realistic
- encourages standardization of interfaces to support a competitive market - maybe realistic
## Design Goals
### Roles
- `users` aka initiator of swaps, most likely not bots
- `wallets`
- `dapps`
- `bundlers`
- `matchmakers`
- `builders`
- `sequencers` (?)
### OFA User Dimensions
Let's first consider all the potential affected parties:
1. `wallets` will be sending orderflow (txs) to `matchmakers`
2. `dapps` will be sending orderflow (meta-txns) to `matchmakers`
**Note: Dapps may be wallets in the case of uniswap**
3. Searchers will be receiving obfuscated orderflow
4. Builders will be receiving bundleflow from `matchmakers`
**Further into the future:**
5. `bundlers` will be sending orderflow (userops) to `matchmakers`
It's helpful to think through the best and worst case scenarios here for all roles
### Credibility
Generally we want the OFA node to be as little of a black box as possible. Can we create a data API for OFA nodes to show which searchers got access to the order flow? Which searchers sent back orderflow? Is this helpful?
#### Data API considerations
- Should it be possible to attribute the source of orderflow? read: is it useful, and are there concerns about the integrity of the data or of harm/disadvantage to its originator?
- Let's say we reveal all searcher orderflow : i.e. the hash of the txn they sent + the time of sending + the bundle layout they specify
- Does this reveal too much of the searchers strategy?
- There are less "wait till the end" games in OFAs since there isn't a strict deadline. Well actually is this correct? The bundle can't be included until the end of the slot, and the matchmaker will take some unknown time `t` to "match" the bundle and forward to a builder.
- If this is too much information, we can reveal the tuple ``(hash of all the data: tx + bundle preference, timestamp)`
-
- What data would a wallet be interested in?
- Time to first bundle forward? Generally I could see wallets running analysis such as "how long from wallet's receipt of tx to forwarding to builder"
- wallets and dapps are interested in profit, this would require monitoring all bundles landing onchain going through node which adds complexity but isnt too bad
- It could be argued that the wallet should just do the profit analysis on its own time, but another interesting angle is that having the profit easily available could attract more orderflow.
### OFA Design Dimensions
### OFA Components
