rename user to bidder

Author: kant

README.md

@@ -1,5 +1,5 @@
 # mev-commit
-mev-commit is P2P software that creates a network of execution providers and users. Users can broadcast bids to providers and receive commitments from them. A high throughput POA EVM chain settles the bids at the end of a block slot.
+mev-commit is P2P software that creates a network of execution providers and bidders. Bidders can broadcast bids to providers and receive commitments from them. A high throughput POA EVM chain settles the bids at the end of a block slot.
 
 ![](node-architecture.png)
 
@@ -11,7 +11,7 @@ $ ./build.sh start localhost:8545 <DataDog-KEY>
 When prompted, read the values of where the Smart-contracts where deployed on the settlement layer and update the configurations in the integrationtest/config/...yml files.
 
 ## Quickstart
-- An ECDSA private key is required to create an ethereum address for the node as well as to use for the P2P network. Users can add an existing key or create a new key using the `create-key` command.
+- An ECDSA private key is required to create an ethereum address for the node as well as to use for the P2P network. Bidders can add an existing key or create a new key using the `create-key` command.
 ```
 NAME:
    mev-commit create-key - Create a new ECDSA private key and save it to a file
@@ -114,10 +114,10 @@ To simplify the deployment process, you may utilize Docker to create an isolated
   docker-compose down
   ```
 
-## APIs for Users & Execution Providers
-[Link to Documentation on User and Execution provider API](./pkg/rpc/README.md)
+## APIs for Bidders & Execution Providers
+[Link to Documentation on Bidder and Execution provider API](./pkg/rpc/README.md)
 - This includes: 
-   - the payload for the User API
+   - the payload for the Bidder API
    - The required setup for execution providers to process bids into commitments in their personal infra.
 
 

cmd/main.go

@@ -106,7 +106,7 @@ type config struct {
 	ExposeProviderAPI        bool     `yaml:"expose_provider_api" json:"expose_provider_api"`
 	PreconfContract          string   `yaml:"preconf_contract" json:"preconf_contract"`
 	ProviderRegistryContract string   `yaml:"provider_registry_contract" json:"provider_registry_contract"`
-	UserRegistryContract     string   `yaml:"user_registry_contract" json:"user_registry_contract"`
+	BidderRegistryContract   string   `yaml:"bidder_registry_contract" json:"bidder_registry_contract"`
 	RPCEndpoint              string   `yaml:"rpc_endpoint" json:"rpc_endpoint"`
 }
 
@@ -196,7 +196,7 @@ func start(c *cli.Context) error {
 		ExposeProviderAPI:        cfg.ExposeProviderAPI,
 		PreconfContract:          cfg.PreconfContract,
 		ProviderRegistryContract: cfg.ProviderRegistryContract,
-		UserRegistryContract:     cfg.UserRegistryContract,
+		BidderRegistryContract:   cfg.BidderRegistryContract,
 		RPCEndpoint:              cfg.RPCEndpoint,
 	})
 	if err != nil {

config/bootnode.yml

@@ -6,6 +6,6 @@ rpc_port: 13524
 secret: hello
 log_fmt: text
 log_level: debug
-user_registry_contract: 0x17855D7AB9B84cF2eddb8a7Db2df825c54a492aD
+bidder_registry_contract: 0x17855D7AB9B84cF2eddb8a7Db2df825c54a492aD
 provider_registry_contract: 0x11a315df6B4aCDbB6816B287a10F92F0C3a1BBc1
 rpc_endpoint: http://34.215.163.180:8545

config/provider.yml

@@ -9,7 +9,7 @@ log_level: debug
 expose_provider_api: true
 preconf_contract: 0xD11e7E017e22232912E2F8150751436c4E6ec606
 provider_registry_contract: 0x11a315df6B4aCDbB6816B287a10F92F0C3a1BBc1
-user_registry_contract: 0x17855D7AB9B84cF2eddb8a7Db2df825c54a492aD
+bidder_registry_contract: 0x17855D7AB9B84cF2eddb8a7Db2df825c54a492aD
 rpc_endpoint: http://34.215.163.180:8545
 bootnodes:
   - /ip4/<localhost>/tcp/13522/p2p/<p2p_ID>

config/user.yml

@@ -6,7 +6,7 @@ rpc_port: 13524
 secret: hello
 log_fmt: text
 log_level: debug
-user_registry_contract: 0x17855D7AB9B84cF2eddb8a7Db2df825c54a492aD
+bidder_registry_contract: 0x17855D7AB9B84cF2eddb8a7Db2df825c54a492aD
 provider_registry_contract: 0x11a315df6B4aCDbB6816B287a10F92F0C3a1BBc1
 rpc_endpoint: http://34.215.163.180:8545
 bootnodes:

docker-compose.yml

@@ -26,7 +26,7 @@ services:
     networks:
       - primev_net
 
-  user:
+  bidder:
     build:
       context: .
       dockerfile: Dockerfile
@@ -45,7 +45,7 @@ services:
 volumes:
   bootnode-keys:
   provider-keys:
-  user-keys:
+  bidder-keys:
 
 networks:
   primev_net:

docs/README.md

@@ -4,27 +4,27 @@
 Introducing mev-commit, a peer-to-peer (P2P) networking software that serves as a conduit for real-time communication with execution providers. mev-commit enables MEV actors to join and utilize a P2P network for the exchange of execution bids and commitments, enriching the transaction execution experience by allowing for granular specification of execution needs and receiving real-time commitments.
 
 ## Actors
-The roles of actors within this p2p ecosystem are defined with respect to other actors. A list of possible actors is given below. A good way to interpret them is to observe a given actors' relative placement in the diagram shown below. For example, an MEV Searcher (Transaction Originator) is a user to a Sequencer, and however, that same sequencer can be a user to a block builder. Thus, it's best to think of the roles of actors from the perspective of the MEV Supply Chain. To the left of the diagram are users who source MEV; and to the right of the diagram, are asset holders that help users actualize their MEV. These asset holders are providers in the p2p ecosystem. 
+The roles of actors within this p2p ecosystem are defined with respect to other actors. A list of possible actors is given below. A good way to interpret them is to observe a given actors' relative placement in the diagram shown below. For example, an MEV Searcher (Transaction Originator) is a bidder to a Sequencer, and however, that same sequencer can be a bidder to a block builder. Thus, it's best to think of the roles of actors from the perspective of the MEV Supply Chain. To the left of the diagram are bidders who source MEV; and to the right of the diagram, are asset holders that help bidders actualize their MEV. These asset holders are providers in the p2p ecosystem. 
 
-Traditionally, information only moved to the right in this supply chain, from users to providers. With our P2P network, we're allowing information about how the MEV is actualized to flow from providers back to users, along with cryptographic commitments that strengthen the value of information exchange.
+Traditionally, information only moved to the right in this supply chain, from bidders to providers. With our P2P network, we're allowing information about how the MEV is actualized to flow from providers back to bidders, along with cryptographic commitments that strengthen the value of information exchange.
 
 ![](mev-supply-chain.png)
 
 **Providers**
 
 Providers of execution services (**Block builders, Rollup Sequencers)**
 
-**Users**
+**Bidders**
 
-Users of execution services (**MEV searchers, AA bundlers, L2s, and other blockspace consumers)**
+Bidders of execution services (**MEV searchers, AA bundlers, L2s, and other blockspace consumers)**
 
 ## Network Topology
 
 The network topology we will be releasing is as follows:
 
 <img src="topology.png" alt="Topology" width="500" height="500"/>
 
-Users will connect to providers, each of these nodes will have access to a bootnode for network startup. Providers will also be able to run gateway nodes to allow users to send bids directly to an RPC endpoint under a provider URL.
+Bidders will connect to providers, each of these nodes will have access to a bootnode for network startup. Providers will also be able to run gateway nodes to allow bidders to send bids directly to an RPC endpoint under a provider URL.
 
 ## Bids and Privacy
 

docs/api-clients.md

@@ -1,16 +1,16 @@
 # API clients
 
-The mev-commit node provides two key APIs. The execution providers need to use the **Provider API** whereas the users need to use the **User API** based on their role in the network.
+The mev-commit node provides two key APIs. The execution providers need to use the **Provider API** whereas the bidders need to use the **Bidder API** based on their role in the network.
 
 ## Providers
 
-Execution providers will use the `provider` role of the mev-commit software to run their nodes. This will allow users to send bids to them to include in the blocks that they build. They will use the **Provider RPC API** to receive signed bids that are being propogated in the network. Once they get a bid, they need to communicate with the mev-commit node whether the bid has been **Accepted** or **Rejected**. If accepted, the mev-commit node will send a signed pre-confirmation to the users.
+Execution providers will use the `provider` role of the mev-commit software to run their nodes. This will allow bidders to send bids to them to include in the blocks that they build. They will use the **Provider RPC API** to receive signed bids that are being propogated in the network. Once they get a bid, they need to communicate with the mev-commit node whether the bid has been **Accepted** or **Rejected**. If accepted, the mev-commit node will send a signed pre-confirmation to the bidders.
 
 The API is implemented using gRPC framework. This allows two types of operations:
 
 ### RPC API
 
-Users can find the protobuf file in the [repository](https://github.com/primevprotocol/mev-commit/blob/main/rpc/providerapi/v1/providerapi.proto). This can be used to generate the client for the RPC in the language of your choice. The go client is already generated in the repository. For other languagues, please follow the instructions in the [grpc documentation](https://grpc.io/docs/languages/) to generate them.
+Bidders can find the protobuf file in the [repository](https://github.com/primevprotocol/mev-commit/blob/main/rpc/providerapi/v1/providerapi.proto). This can be used to generate the client for the RPC in the language of your choice. The go client is already generated in the repository. For other languagues, please follow the instructions in the [grpc documentation](https://grpc.io/docs/languages/) to generate them.
 
 There are two main APIs
 ```proto
@@ -49,15 +49,15 @@ The same API is also available on the HTTP port configured on the node. Please g
 
 An [example client](https://github.com/primevprotocol/mev-commit/tree/main/examples/provideremulator) is implemented in the repository. This is mainly to demostrate how to write the client integrated in the provider's environment. The client blindly accepts each bid that it receives, however the provider needs to implement custom logic here to make the decision.
 
-## Users
+## Bidders
 
-Users will use the `user` role of the mev-commit software to run their nodes. With this role, the node provides the **User API** to submit bids to the network. The mev-commit node will sign the bid before it sends it to different providers that are accepting bids. On the response, users will get pre-confirmations from the providers if the bid is accepted. This is a streaming response and users are expected to keep the connection alive till all the preconfirmations are received by the node.
+Bidders will use the `bidder` role of the mev-commit software to run their nodes. With this role, the node provides the **Bidder API** to submit bids to the network. The mev-commit node will sign the bid before it sends it to different providers that are accepting bids. On the response, bidders will get pre-confirmations from the providers if the bid is accepted. This is a streaming response and bidders are expected to keep the connection alive till all the preconfirmations are received by the node.
 
 The API is implemented using gRPC framework. This allows two types of operations:
 
 ### RPC API
 
-Users can find the protobuf file in the [repository](https://github.com/primevprotocol/mev-commit/blob/main/rpc/userapi/v1/userapi.proto). This can be used to generate the client for the RPC in the language of your choice. The go client is already generated in the repository. For other languagues, please follow the instructions in the [grpc documentation](https://grpc.io/docs/languages/) to generate them.
+Bidders can find the protobuf file in the [repository](https://github.com/primevprotocol/mev-commit/blob/main/rpc/bidderapi/v1/bidderapi.proto). This can be used to generate the client for the RPC in the language of your choice. The go client is already generated in the repository. For other languagues, please follow the instructions in the [grpc documentation](https://grpc.io/docs/languages/) to generate them.
 
 The API available is:
 ```proto
@@ -85,8 +85,8 @@ message PreConfirmation {
 
 ### HTTP API
 
-The same API is also available on the HTTP port configured on the node. Please go through the [API docs](https://mev-commit-docs.s3.amazonaws.com/user.html) to understand the usage.
+The same API is also available on the HTTP port configured on the node. Please go through the [API docs](https://mev-commit-docs.s3.amazonaws.com/bidder.html) to understand the usage.
 
-An [example CLI application](https://github.com/primevprotocol/mev-commit/tree/main/examples/usercli) is implemented in the repository. This is mainly to demostrate how to integrate with the RPC API.
+An [example CLI application](https://github.com/primevprotocol/mev-commit/tree/main/examples/biddercli) is implemented in the repository. This is mainly to demostrate how to integrate with the RPC API.
 
 

docs/debugging.md

@@ -1,6 +1,6 @@
 # Debugging
 
-The mev-commit node is still in active development. As a result there is some debugging instrumentation available on the node. In the normal use-cases, the users might not need this, but they can always use this to get more information on the inner-workings of the node. These tools can be accessed on the HTTP API endpoint.
+The mev-commit node is still in active development. As a result there is some debugging instrumentation available on the node. In the normal use-cases, the bidders might not need this, but they can always use this to get more information on the inner-workings of the node. These tools can be accessed on the HTTP API endpoint.
 
 ## Network topology
 
@@ -31,4 +31,4 @@ The node also emits a bunch of prometheus metrics. These can be potentially used
 
 ## Pprof endpoints
 
-The pprof endpoints are also accessible on the node on the `/debug/pprof` endpoint. These are mainly used to observe how the node is performing for eg. the memory, CPU usage on the nodes. These are useful only for users who already know how to use them. Explaining them is beyond the scope of this documentation.
+The pprof endpoints are also accessible on the node on the `/debug/pprof` endpoint. These are mainly used to observe how the node is performing for eg. the memory, CPU usage on the nodes. These are useful only for bidders who already know how to use them. Explaining them is beyond the scope of this documentation.

docs/quickstart.md

@@ -2,7 +2,7 @@
 
 ## Using the CLI
 
-mev-commit software is a CLI program that needs to be run by the users in their own environments. The CLI has two commands mainly. You can run the main command with `-h`/`--help` option to see the available commands.
+mev-commit software is a CLI program that needs to be run by the bidders in their own environments. The CLI has two commands mainly. You can run the main command with `-h`/`--help` option to see the available commands.
 
 ```
 ❯ mev-commit -h
@@ -25,7 +25,7 @@ GLOBAL OPTIONS:
    --version, -v  print the version
 ```
 
-Users can use any existing ECDSA private key or create one using the `create-key` command. This key is used to derive the ethereum address of the node taking part in the network.
+Bidders can use any existing ECDSA private key or create one using the `create-key` command. This key is used to derive the ethereum address of the node taking part in the network.
 
 ```
 ❯ mev-commit create-key -h
@@ -39,7 +39,7 @@ OPTIONS:
    --help, -h  show help
 ```
 
-In order to run a node, users need to create a configuration file in the YAML format. Example config files can be found in the [config](https://github.com/primevprotocol/mev-commit/tree/main/config) folder. The important options are defined below:
+In order to run a node, bidders need to create a configuration file in the YAML format. Example config files can be found in the [config](https://github.com/primevprotocol/mev-commit/tree/main/config) folder. The important options are defined below:
 
 ```yaml
 # Path to private key file.
@@ -74,7 +74,7 @@ bootnodes:
 expose_provider_api: false
 ```
 
-Place this config file in some folder. It is advised to create a new `.mev-commit` folder in the home directory and place it there. Once this is done, users can start the node using the `start` command.
+Place this config file in some folder. It is advised to create a new `.mev-commit` folder in the home directory and place it there. Once this is done, bidders can start the node using the `start` command.
 
 ```
 ❯ mev-commit start -h
@@ -91,4 +91,4 @@ OPTIONS:
 
 ## Docker
 
-Optionally users can use the docker images to run the client in their docker environment. You need to make sure the node is able to communicate with provider/user nodes.
+Optionally bidders can use the docker images to run the client in their docker environment. You need to make sure the node is able to communicate with provider/bidder nodes.