refine wording

BEPs/BEP322.md

@@ -12,7 +12,7 @@
     - [1. Summary](#1-summary)
     - [2. Motivation](#2-motivation)
     - [3. Specification](#3-specification)
-        - [3.1 Trust Model](#31-trust-model)
+        - [3.1 BSC Trust Model](#31-bsc-trust-model)
         - [3.2 Workflow](#32-workflow)
         - [3.3 Payment & Economic Considerations](#33-payment--economic-considerations)
         - [3.4 APIs](#34-apis)
@@ -39,25 +39,25 @@ However, on BNB Smart Chain, there is no such specification yet. By
 introducing such a specification, it will resolve some problems as well
 as bring new benefits for the ecosystem.
 
-- Firstly, currently validators are using different customized
+- Improve stability of network: currently validators are using different customized
   implementations for MEV with different levels of quality, which
   brings instability to the network. With a specification, it will
   provide guidelines and standards to follow, minimizing the
   instability issues.
 
-- Secondly, validators can only integrate with a single MEV provider
+- Improve MEV economy by building MEV market: validators can only integrate with a single MEV provider
   now, due to the lack of support on BSC clients. With this
   specification, validators can integrate with multiple builders at
   the same time.
 
-- Thirdly, this specification will also bring transparency to
+- Improve transparency: this specification will also bring transparency to
   different stakeholders, including BNB delegators. With the
   adoption of builders, it is probable that delegators can earn more
   because builders are supposed to submit more profitable blocks.
 
 ## 3. Specification
 
-### 3.1 Trust Model
+### 3.1 BSC Trust Model
 
 Before we move on to the design of Builder Specification, let's have an
 analysis of the BSC trust model and compare it to Ethereum, for it will
@@ -68,7 +68,7 @@ networks.
   validators should delegate a lot of BNB (more than 10 thousand in
   general) and maintain a high reputation. Misbehaviour will lead to
   reputation damage and un-delegations. Currently, there are about
-  40 validators with 20M BNB staked, including active and inactive
+  40 validators (more validators are coming) with 20M BNB staked, including active and inactive
   ones. In Ethereum, the barrier to becoming a validator is very
   low (i.e., 32 ETH), and there are more than [800 thousand Ethereum
   validators](https://www.nasdaq.com/articles/the-most-pressing-issue-on-ethereum-is-validator-size-growth).
@@ -130,7 +130,7 @@ Builder Specification here for the readers who are familiar with it.
   workable for builders to send transactions to validators after
   receiving the receipt signature. In case a builder finds a
   validator stealing transactions, it can 1) not submit bids to evil
-  validators anymore, 2) reveal evidence to the public channels for
+  validators anymore, 2) reveal evidence to the public channels (e.g., chatting groups, github, blogs) for
   social influence.
 
 - In Ethereum, the fee settlement between builders and validators is
@@ -240,11 +240,11 @@ implement the aforementioned workflows. The full specification of these
 APIs is defined in [a repo with swagger and smart
 contracts](https://github.com/bnb-chain/builder-specs).
 
-#### 3.1.1 Builder APIs
+#### 3.4.1 Builder APIs
 
 The following APIs should be implemented on Builder.
 
-##### 3.1.1.1 Register Validator
+##### 3.4.1.1 Register Validator
 
 A smart contract should be implemented on the builder side. Then a
 validator can call the smart contract to register itself. The contract
@@ -261,7 +261,7 @@ interface looks like this.
     function baseUrl() external view returns (string);
 ```
 
-##### 3.1.1.2 Retrieve Transactions
+##### 3.4.1.2 Retrieve Transactions
 
 This api is used by the validator to ask for full transactions once a
 builder's bid is chosen. The request body will be treated as a receipt
@@ -345,7 +345,7 @@ for payment settlement.
 </tr>
 </table>
 
-##### 3.1.1.3 Query Status
+##### 3.4.1.3 Query Status
 
 This api is used to check the status of a builder.
 
@@ -391,7 +391,7 @@ HTTP status code is 200
 </tr>
 </table>
 
-##### 3.1.1.4 Notify Issues
+##### 3.4.1.4 Notify Issues
 
 This api is used to report issues to a builder. For example, if a
 validator finds that a builder's transactions are invalid or the txs
@@ -450,11 +450,11 @@ HTTP status code is 200
 </tr>
 </table>
 
-#### 3.1.2 BSC Client APIs
+#### 3.4.2 BSC Client APIs
 
 The following APIs should be implemented on BSC clients.
 
-##### 3.1.2.1 Bid Block
+##### 3.4.2.1 Bid Block
 
 This api is used by the builder to submit its bid for the current block
 production. In general, a proposer will use the `gas_fee` and