diff --git a/BEPs/BEP322.md b/BEPs/BEP322.md
index 8db073f6..de1f47f8 100644
--- a/BEPs/BEP322.md
+++ b/BEPs/BEP322.md
@@ -30,8 +30,8 @@ economic considerations for real adoptions.
 
 ## 2. Motivation
 
-The specification is defined in [Ethereum Builder API
-Specification](https://github.com/ethereum/builder-specs), and it has been supported by almost all the mainstream
+The [Ethereum Builder API
+Specification](https://github.com/ethereum/builder-specs) has been supported by almost all the mainstream
 Ethereum consensus clients. Nowadays, the inclusion rate of blocks from builders
 is [about 90%](https://dune.com/ChainsightAnalytics/mev-after-ethereum-merge) (based on the statistics of October 2023).
 
@@ -60,9 +60,8 @@ as bring new benefits for the ecosystem.
 ### 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
-affect how the design works and differentiate the designs in these two
-networks.
+analysis of the BSC trust model and compare it to Ethereum. It will
+lead to different designs for these two networks.
 
 - Validators are more trustworthy in BNB Smart Chain. In BSC, the
   validators should delegate a lot of BNB (more than 10 thousand in
@@ -116,6 +115,10 @@ The overall workflow is as follows:
     timeout to retrieve transitions from the builder, or the proposed
     block is invalid).
 
+For step 4, a builder can also submit a bid with transactions, then at step 7 a proposer
+does not need to ask for transactions and can send the receipt in an asynchronous way.
+This option is also supported in this specification.
+
 Here, we would like to highlight some main differences between Ethereum
 Builder Specification here for the readers who are familiar with it.
 
@@ -137,7 +140,7 @@ Builder Specification here for the readers who are familiar with it.
   conducted using coinbase reward (for reward to builders) and token
   transfer (for fee to validators). In BSC, the coinbase reward will
   be transferred to the system contract for later distribution to
-  all delegators. A different way is proposed in this proposal, a
+  all delegators. A different way is proposed in this proposal; a
   validator and a builder can do the payment settlement via the
   receipts which contain the validator's signatures through
   off-chain or on-chain (e.g., smart contracts). It will be further
@@ -171,8 +174,8 @@ timeout to retrieve transactions from the winning builder.
 
 ![block timing](./assets/bep-322/block_timing.png)
 
-Secondly, a validator can choose to participate in or not. The
-implementation should support a validator to turn on/off the feature
+Secondly, a validator can choose to run a node with or without support for builder.
+The implementation should support a validator to turn on/off the feature
 based on its choice.
 
 ### 3.3 Payment & Economic Considerations
@@ -196,7 +199,7 @@ For the payment between builders and validators, a builder can settle
 with validators via the receipts (when asking for full transactions from
 a builder, a receipt with a validator's signature must be disclosed to
 the builder) off-chain or on-chain (e.g., smart contracts). Because the
-builder fee is paid by validators (not all the delegators), validators
+builder fee is paid by validators (not all the delegators), so validators
 can evaluate and increase the commission rate if needed.
 
 For the payment, we propose the following smart contract interfaces if
@@ -293,7 +296,8 @@ for payment settlement.
     "builder_address": "builder address",
     "consensus_address": "validator consensus address",
   },
-  "signature": "signature of the message"
+  "signature": "signature of the message",
+  "return_transactions": "the builder should transactions back or not"
 }
 </code>
 </pre>
@@ -401,7 +405,7 @@ api is timeout-ed, a validator can notify the builder.
 <table>
 <tr>
 <td>Path</td> 
-<td>/bsc/v1/builder/issues</td>
+<td>/bsc/v1/builder/issue</td>
 </tr>
 
 <tr>
@@ -487,7 +491,12 @@ find the most profitable bid.
       "transaction_merkle_root": "merkle root of transactions",
       "transaction_count": "total count of transactions"
   },
-  "signature": "signature of the message"
+  "signature": "signature of the message",
+  "transactions": [ //optional
+      {},
+      {},
+      {}
+    ]
 }
 </code>
 </pre>