diff --git a/BEPs/BEP-346.md b/BEPs/BEP-346.md
new file mode 100644
index 00000000..7c95f8c4
--- /dev/null
+++ b/BEPs/BEP-346.md
@@ -0,0 +1,69 @@
+<pre>
+  BEP: 346
+  Title: Streamline off-chain authentication on Greenfield
+  Status: Draft
+  Type: Standards
+  Created: 2024-03-14
+</pre>
+
+
+# BEP-346: Streamline off-chain authentication on Greenfield
+
+- [BEP-346: Streamline off-chain authentication on Greenfield](#bep-346-streamline-off-chain-authentication-on-greenfield)
+  - [1. Summary](#1-summary)
+  - [2. Motivation](#2-motivation)
+  - [3. Status](#3-status)
+  - [4. Specification](#4-specification)
+  - [5. License](#5-license)
+
+
+## 1. Summary
+This BEP introduces GNFD2-EDDSA, a simplified off-chain authentication signature verification method. It streamlines the authentication process, reducing developer integration complexity and improving user interaction.
+
+## 2. Motivation
+
+Greenfield is an object storage system with permission management. SP uses an off-chain authentication mechanism to authenticate users from the dApps. For more details, refer to [Greenfield Storage Provider Off-Chain Authentication](https://docs.bnbchain.org/greenfield-docs/docs/guide/storage-provider/modules/authenticator/#greenfield-storage-provider-off-chain-authentication). 
+
+In the previous design, users first needed to request a Metamask signature to derive an EdDSA private key. Subsequently, registering this EdDSA public key with various SPs required another Metamask signature. We strive to simplify the off-chain authentication procedure by consolidating the two signatures into a single one.
+
+
+## 3. Status
+This BEP is in progress.
+
+## 4. Specification
+
+When maintaining security integrity, we recommend streamlining the off-chain authentication process as follows:
+
+1. In a dApp frontend, a random EdDSA private key is generated without fetching a nonce from the service provider or requesting a user wallet signature, and this private key would be stored in the browser's local storage. The generation of a private EdDSA key is to use Ed25519 as the EdDSA curve. Here is the sample code:
+    ```
+    // use js lib at https://github.com/paulmillr/noble-ed25519 
+    const privateKeyBytes = ed.utils.randomPrivateKey();
+    ```
+
+2. To register the user’s current EdDSA public key with SPs, users are required to sign the message. This step ensures SPs can verify the user's identity. The simplified content for signing is as follows:
+
+    ```
+    https://www.yourwebsite.com wants you to sign in with your BNB Greenfield account:0xA4cFxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0af6
+    Register your identity public key 280e1a3f143215c010db9c4f1bbd0675b39356a8ee8b4b3b6f965b5c7a42d3aa
+    URI: https://www.yourwebsite.com
+    Version: 1
+    Chain ID: 1017
+    Issued At: 2024-03-02T07:24:24Z
+    Expiration Time: 2024-03-07T07:24:24Z
+    ```
+
+    After users register their EdDSA public keys with the SPs, they can sign requested messages using the private key. This allows the SP to verify their identity based on the registered public key. This off-chain authentication signature doesn't require block chain network operations, so users can verify signatures without switching to the Greenfield network.
+
+3. When a user initiates a request to the SP, they sign the request using the EdDSA private key generated in step one. The signature is then placed in the authorization field of the header. To ensure backward compatibility, this new signature verification method is labeled as GNFD2-EDDSA. While the previous signature verification method is no longer recommended, it is still supported. The new format is as follows:
+
+    ```
+    Authorization = auth_type + "," + Signature
+    string-to-sign = crypto.Keccak256(canonical)
+    Signature = ed25519.Sign(privateKey, string-to-sign)
+
+    Authorization: GNFD2-EDDSA, Signature=0a9d0e0c4778cdfbbc7d86f4aad2651d3c0140c15a80b4f80315dee58987c2a401877bfb05aef6f8a9c4137b8587a4f02536b3cb7e303c444edaacee476e7ad2
+    ```
+
+## 5. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/README.md b/README.md
index 4523862f..3ea29d8e 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@ BEP stands for BNB Evolution Proposal. Each BEP will be a proposal document prov
 Here is the list of subjects of BEPs:
 
 | Number                       | Title                                                         | Type      | Status    |
-|------------------------------|---------------------------------------------------------------|-----------|-----------|
+| ---------------------------- | ------------------------------------------------------------- | --------- | --------- |
 | [BEP-1](./BEPs/BEP1.md)      | Purpose and Guidelines of BEP                                 | Process   | Living    |
 | [BEP-2](./BEPs/BEP2.md)      | Tokens on BNB Beacon Chain                                    | Standards | Enabled   |
 | [BEP-3](./BEPs/BEP3.md)      | HTLC and Atomic Peg                                           | Standards | Enabled   |
@@ -56,6 +56,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-346](./BEPs/BEP-346.md) | Streamline off-chain authentication on Greenfield             | Standards | Draft     |
 
 
 # BNB Chain Upgrades