Merge pull request #19 from flashbots/sheak/renameToNode

Matchmaker -> MEV-Share Node

README.md

@@ -12,20 +12,22 @@ Today, orderflow originators like wallets and dapps do not actively participate
 
 Importantly, **MEV-Share is an open-source protocol, not a product or company**. MEV-share uses commitments and privacy to facilitate permissionless collaboration between orderflow originators and searchers, similarly to what MEV-Boost did for builders and validators. It is credibly neutral, permissionless for searchers, and does not enshrine a single block builder. Aggregating order flow to MEV-Share will greatly reduce proprietary order flow as a centralizing force on Ethereum while enabling orderflow originators to participate in the MEV supply chain.
 
+> Note: The MEV-Share Matchmaker was renamed to the MEV-Share Node. This change is reflected in the specifications after June 2023.
+
 ## Minimum standardizable interfaces
 
 There are many parties that may interact as part of the MEV-share protocol:
 1. Orderflow providers / sources (users, wallets, dapps)
 2. Searchers
-3. Matchmakers
+3. MEV-Share Nodes
 4. Blockspace providers / proxies (builders, sequencers, validators, bundlers)
 
 A minimum set of interfaces includes:
-1. How orderflow providers send orderflow and preferences (eg. privacy, redistribution) to matchmakers
-2. How matchmakers share information about orderflow with searchers
-3. How searchers send bids, orderflow, and preferences (eg. validity conditions) to matchmakers
-4. How matchmakers send orderflow and preferences to blockspace providers
-5. How value is redistributed to orderflow providers, blockspace providers, and matchmakers
+1. How orderflow providers send orderflow and preferences (eg. privacy, redistribution) to MEV-Share Nodes
+2. How MEV-Share Nodes share information about orderflow with searchers
+3. How searchers send bids, orderflow, and preferences (eg. validity conditions) to MEV-Share Nodes
+4. How MEV-Share Nodes send orderflow and preferences to blockspace providers
+5. How value is redistributed to orderflow providers, blockspace providers, and MEV-Share Nodes
 
 ## Current architecture and APIs
 

architecture.md

@@ -1,3 +1,3 @@
-![mev-share-architecture-diagram](https://user-images.githubusercontent.com/2029632/233164770-a00f1d14-3361-486d-9b80-2af8ed2ee90c.png)
+![mev-share architecture diagram](https://github.com/flashbots/mev-share/assets/2029632/35e0a2b9-6334-4cfd-94a4-679a788874dd)
 
-https://excalidraw.com/#json=elsgQaxoLJEizeh4iq-Wz,NsdOenLkg9gTy_CdMIWGgw
+https://excalidraw.com/#json=1l2qz7Dp_bbEnOtwb8Wk5,bFNry1-SY4W34J59xkiFzA

specs/bundles/refund-recipient.md

@@ -1,6 +1,6 @@
 # `eth_sendBundle`
 
-Matchmakers can use the `eth_sendBundle` method to send a bundle of transactions to a block builder. Specifically, the `refund-recipient` version of `eth_sendBundle` extends the [standard `eth_sendBundle` API](https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint#eth_sendbundle) to support two additional fields (`refundPercent` and `refundRecipient`) which can optionally be set to specify how refunds from MEV-Share should be distributed.
+MEV-Share Nodes can use the `eth_sendBundle` method to send a bundle of transactions to a block builder. Specifically, the `refund-recipient` version of `eth_sendBundle` extends the [standard `eth_sendBundle` API](https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint#eth_sendbundle) to support two additional fields (`refundPercent` and `refundRecipient`) which can optionally be set to specify how refunds from MEV-Share should be distributed.
 
 <!-- TOC -->
 * [`eth_sendBundle`](#eth_sendbundle)

specs/bundles/v0.1.md

@@ -1,6 +1,6 @@
 # `mev_sendBundle`
 
-Users and searchers can use `mev_sendBundle` to send a bundle of transactions [and transaction hashes] to a MEV-Share Matchmaker. Matchmakers can use `mev_sendBundle` to send a bundle of transactions to a block builder.
+Users and searchers can use `mev_sendBundle` to send a bundle of transactions [and transaction hashes] to a MEV-Share Node. Nodes can use `mev_sendBundle` to send a bundle of transactions to a block builder.
 
 <!-- TOC -->
 * [`mev_sendBundle`](#mev_sendbundle)
@@ -179,7 +179,7 @@ For example, refund (MEV kickback) parameters are considered as a post-inclusion
 
 The `refundConfig` is specified by the original party (eg. user) who sends an input to MEV-Share. Given some refund X, the `refundConfig` specifies what % of X should be paid to what address(es). The `refundConfig` is not aware of the precise refund amount X, because this is not known until after the input has been sent to MEV-Share.
 
-The `refund` is set by the matchmaker. It identifies what items in the bundle should be refunded -- ie. when a searcher submits a new bundle back to the Matchmaker, what indices contained hashes. The builder must simulate the bundle without these input transactions to determine what portion of the overall bundle payment came from searcher bids and should be redistributed. If bundles contain multiple input items then the Matchmaker is responsible for allocating the searcher bids across the other items in the bundle. The party who submits the input to the matchmaker could also use this field to specify their preference for what percentage of the searcher bid they receive. The matchmaker would use this information when producing the final `refund` field that is sent to a block builder.
+The `refund` is set by the MEV-Share Node. It identifies what items in the bundle should be refunded -- ie. when a searcher submits a new bundle back to the MEV-Share Node, what indices contained hashes. The builder must simulate the bundle without these input transactions to determine what portion of the overall bundle payment came from searcher bids and should be redistributed. If bundles contain multiple input items then the MEV-Share Node is responsible for allocating the searcher bids across the other items in the bundle. The party who submits the input to the MEV-Share Node could also use this field to specify their preference for what percentage of the searcher bid they receive. The MEV-Share Node would use this information when producing the final `refund` field that is sent to a block builder.
 
 ### `privacy`