diff --git a/BEPs/BEP-362.md b/BEPs/BEP-362.md
new file mode 100644
index 00000000..87048a93
--- /dev/null
+++ b/BEPs/BEP-362.md
@@ -0,0 +1,117 @@
+<pre>
+  BEP: 362
+  Title: Greenfield Storage Fee Paymaster
+  Status: Draft
+  Type: Standards
+  Created: 2024-03-14
+</pre>
+
+
+# BEP-362: Greenfield Storage Fee Paymaster
+
+- [BEP-362: Greenfield Storage Fee Paymaster](#bep-362-greenfield-storage-fee-paymaster)
+  - [1. Summary](#1-summary)
+  - [2. Motivation](#2-motivation)
+  - [3. Status](#3-status)
+  - [4. Specification](#4-specification)
+    - [4.1 Create and update bucket](#41-create-and-update-bucket)
+    - [4.2 Set the flow rate limit for a bucket](#42-set-the-flow-rate-limit-for-a-bucket)
+    - [4.3 Update bucket payment address](#43-update-bucket-payment-address)
+  - [5. License](#5-license)
+
+## 1. Summary
+The BEP introduces a storage fee paymaster solution for sponsors to cover storage costs on Greenfield, making it easier 
+for regular users to utilize the platform. Currently, users need to pay the storage fee for the buckets by themselves, 
+so they need to hold BNB in Greenfield and understand the charging mechanism. Allowing the sponsors to pay the storage 
+fee for the users will make it easier to use Greenfield.
+
+## 2. Motivation
+
+Objects stored on Greenfield incur storage fees, with additional data access incurring read traffic fees. 
+Greenfield employs stream payment to charge for storage and read traffic. For regular users, grasping the concept of 
+stream payment and knowing when to renew can be challenging. Users need to know what is the stream payment and they 
+need to calculate the cost of the BNB according to the price of storage which is confusing for normal users. 
+To address this, we aim to introduce the Paymaster approach, enabling sponsors to cover storage and read traffic costs for their users seamlessly.
+
+## 3. Status
+
+This BEP is in progress.
+
+## 4. Specification
+
+### 4.1 Create and update bucket
+
+When creating a bucket via `MsgCreateBucket`, users can specify a payment address for the bucket to make payments.
+
+```
+message MsgCreateBucket {  
+  string creator = 1;  
+  string bucket_name = 2;  
+  VisibilityType visibility = 3;  
+  string payment_address = 4;  
+  ...
+}
+```
+
+In previous implementations, this payment address had to be the bucket owner or be created by the bucket owner. 
+However, in the new design, we allow this payment address to be any address.
+
+Users can specify any payment address when creating the bucket. But if the payment address does not set a flow rate 
+limit(which you can refer to [below section](#42-set-the-flow-rate-limit-for-a-bucket)) for the bucket, they may not use the bucket normally.
+
+Users can also update the payment address for the bucket via the `MsgUpdateBucketInfo` by specifying the payment address 
+to be replaced if they want to use another payment address after creating the bucket.
+
+We recommend setting the bucket's payment address to the sponsor's payment address for optimal convenience and flexibility.
+
+### 4.2 Set the flow rate limit for a bucket
+
+When the payment account’s owner of a bucket is different from the bucket owner, it is necessary to check if the current 
+payment flow exceeds the flow rate limit when deducting charges for streaming payments.
+
+The payment account owner can use the `MsgSetBucketFlowRateLimit` transaction to set the maximum payment flow size for a 
+specific bucket. The default flow rate limit is 0, but if the payment account is owned by the bucket owner, the default 
+flow rate limit is unlimited. If the payment account owner hasn't set a flow rate limit for the bucket, users can't create 
+any objects in it or set read quota for the bucket.
+
+```
+message MsgSetBucketFlowRateLimit {  
+  // operator defines the account address of the operator, either the object owner or the updater with granted permission.  
+  string operator = 1;  
+  // bucket_name defines the name of the bucket  
+  string bucket_name = 2;  
+  // bucket_owner defines the account address of the bucket owner  
+  string bucket_owner = 3;  
+  // payment_address defines an account address to pay the fee for the bucket.  
+  string payment_address = 4;  
+  // flow_rate_limit defines the flow rate limit of the bucket  
+  string flow_rate_limit = 5;  
+}
+```
+
+The payment account owner can send a `MsgSetBucketFlowRateLimit` transaction on the Greenfield side to set the flow rate 
+limit for a bucket. However, this process requires maintaining a backend program to detect the creation of a qualifying 
+bucket and trigger the transaction for setting it up. A more recommended approach would be to wait for the implementation 
+of the GreenfieldExecutor contract in another BEP for improving  Greenfield cross-chain programming capability to enable 
+setting flow rate limits via smart contract. Once this is in place, users can directly create buckets on the BSC/opBNB 
+side and specify a payment address as a contract address. By doing so, users can simultaneously create a bucket and invoke 
+the payment contract address to set the flow rate limit, eliminating the need for backend transaction triggers and enabling 
+automatic flow rate limit configuration.
+
+
+The payment account owner can adjust the flow rate limit for the bucket. The rules for adjusting the limit are as follows:
+
+1. Setting the new flow rate limit to 0 indicates will stop the payment for the bucket, the bucket is rate-limited and the user can’t use the bucket as normal.
+2. Setting the new flow rate limit under the current flow rate of the bucket is the same as setting the new flow rate limit to 0.
+3. To resume payment for the bucket, the flow rate limit must be set to a value not lower than the current net flow rate of the bucket.
+4. The user’s operation will be rejected if the flow rate of the bucket exceeds the flow rate limit.
+
+### 4.3 Update bucket payment address
+
+When the payment account no longer pays for the bucket or the bucket is rate-limited by the current payment account, 
+the bucket owner can update the payment address to continue using the bucket. In this case, users will need to utilize 
+the new payment address for making payments.
+
+## 5. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/README.md b/README.md
index 6e62b6a6..7e2dc18f 100644
--- a/README.md
+++ b/README.md
@@ -57,6 +57,7 @@ Here is the list of subjects of BEPs:
 | [BEP-343](./BEPs/BEP-343.md) | Implement EIP-1153: Transient storage opcodes                 | Standards | Candidate |
 | [BEP-344](./BEPs/BEP-344.md) | Implement EIP-1153: Transient storage opcodes                 | Standards | Candidate |
 | [BEP-345](./BEPs/BEP-345.md) | Implement EIP-7516: BLOBBASEFEE opcode                        | Standards | Candidate |
+| [BEP-362](./BEPs/BEP-362.md) | Greenfield Storage Fee Paymaster                              | Standards | Candidate |
 | [BEP-346](./BEPs/BEP-346.md) | Streamline off-chain authentication on Greenfield             | Standards | Draft     |