BEP-559: Encrypted Mempool for BNB Smart Chain

[Smokyish]

Proposal for an Encrypted Mempool for Binance Smart Chain.

[zzzckck]

hi @Smokyish , thank you for your proposal, but I wonder if BSC really need the EncryptedMempool.
There is a discussion thread: https://forum.bnbchain.org/t/call-for-feedbacks-bsc-short-block-interval-validator-dedicated-network-and-direct-mempool/3348, lots of reply are against the PrivateTxPool concept.

[pepae]

hi @Smokyish , thank you for your proposal, but I wonder if BSC really need the EncryptedMempool. There is a discussion thread: https://forum.bnbchain.org/t/call-for-feedbacks-bsc-short-block-interval-validator-dedicated-network-and-direct-mempool/3348, lots of reply are against the PrivateTxPool concept.

Hey! I think those are two different things and I agree, that a private mempool is not a good choice:

Private mempool: Exclusive, non-public mempool which someone needs to control. Transactions are simply hidden for everyone except for the validator or centralized mempool operator. This is basically how most rollups work. It requires massive trust in whoever operates that mempool not to front-run/censor and is generally considered to be a force for centralization.

Threshold encrypted mempool: Transactions are encrypted in a decentralized fashion (using threshold encryption) until the order and inclusion is finalized/committed to by validators. So no one can see the transactions before they're fixed to go into the block, making it very hard to front-run in general.
This doesn't prevent the back-running/general arbitrage type MEV, which can still be extracted/distributed and lead to higher market efficiency.

More on this: https://ethresear.ch/t/the-road-towards-a-distributed-encrypted-mempool-on-ethereum/21717

Happy to explain more/answer any questions!

[zzzckck]

hi @Smokyish , thank you for your proposal, but I wonder if BSC really need the EncryptedMempool. There is a discussion thread: https://forum.bnbchain.org/t/call-for-feedbacks-bsc-short-block-interval-validator-dedicated-network-and-direct-mempool/3348, lots of reply are against the PrivateTxPool concept.

Hey! I think those are two different things and I agree, that a private mempool is not a good choice:

Private mempool: Exclusive, non-public mempool which someone needs to control. Transactions are simply hidden for everyone except for the validator or centralized mempool operator. This is basically how most rollups work. It requires massive trust in whoever operates that mempool not to front-run/censor and is generally considered to be a force for centralization.

Threshold encrypted mempool: Transactions are encrypted in a decentralized fashion (using threshold encryption) until the order and inclusion is finalized/committed to by validators. So no one can see the transactions before they're fixed to go into the block, making it very hard to front-run in general. This doesn't prevent the back-running/general arbitrage type MEV, which can still be extracted/distributed and lead to higher market efficiency.

More on this: https://ethresear.ch/t/the-road-towards-a-distributed-encrypted-mempool-on-ethereum/21717

Happy to explain more/answer any questions!

Hi @pepae , I have read the post, it is a very good idea, but:

• 1.most of the front run can be avoided by protected-RPC service, it is much simple
• 2.concerns of "EncryptedMempool": its complexity and performance downgrade

[pepae]

hi @Smokyish , thank you for your proposal, but I wonder if BSC really need the EncryptedMempool. There is a discussion thread: https://forum.bnbchain.org/t/call-for-feedbacks-bsc-short-block-interval-validator-dedicated-network-and-direct-mempool/3348, lots of reply are against the PrivateTxPool concept.

Hey! I think those are two different things and I agree, that a private mempool is not a good choice:
Private mempool: Exclusive, non-public mempool which someone needs to control. Transactions are simply hidden for everyone except for the validator or centralized mempool operator. This is basically how most rollups work. It requires massive trust in whoever operates that mempool not to front-run/censor and is generally considered to be a force for centralization.
Threshold encrypted mempool: Transactions are encrypted in a decentralized fashion (using threshold encryption) until the order and inclusion is finalized/committed to by validators. So no one can see the transactions before they're fixed to go into the block, making it very hard to front-run in general. This doesn't prevent the back-running/general arbitrage type MEV, which can still be extracted/distributed and lead to higher market efficiency.
More on this: https://ethresear.ch/t/the-road-towards-a-distributed-encrypted-mempool-on-ethereum/21717
Happy to explain more/answer any questions!

Hi @pepae , I have read the post, it is a very good idea, but:

• 1.most of the front run can be avoided by protected-RPC service, it is much simple
• 2.concerns of "EncryptedMempool": its complexity and performance downgrade

Good points! Let me address:

1. While being a good quick fix for some of the MEV related issues, conceptually, a protected RPC comes with similar centralization vectors and trust assumptions as a private mempool. In this case you'll need to trust the relay and the group of validators not to front-run. A lot of the comments in your mentioned thread are arguing against centralized control of the mempool and I'm afraid protected RPCs have that same issue.

More detail: protected RPCs still hinge on an off‑chain relay, and that relay is a single choke‑point you have to trust completely. It sees your raw tx before inclusion and could leak or reorder it.

So while protected RPCs hide you from public frontrunners, they hand the same power to an even smaller cartel of relay operators (probably 1 or 2). Until we eliminate the relay entirely with in‑protocol threshold encryption or enshrined PBS, protected‑RPCs carry the same centralization risk as a private mempool (plus one extra hop of trust).

2. There is some implementation complexity, but that work is already done on Gnosis Chain and Nethermind and Erigon clients support this already (Gnosis Chain is a "99%" Ethereum-like chain in terms of that client software, similar to BNB).

On performance: 2 separate concerns 1) throughput and 2) latency: if correctly implemented, there should be close to no impact to throughput (because the encryption/decryption scales well and is extremely light).
As for latency, if there's full buy in from the validators, the decryption adds only a small amount of latency (on the order of a couple 100 miliseconds, depending on network topology of the threshold committee nodes). Would think this is acceptable for a decentralized chain which has e.g. 4 second block time.

In any case, the having an encrypted mempool does not eliminate the option to send through non-encrypted transactions. It's just an option that is offered to users/wallets/dapps. Many transactions shouldn't go through encryption (e.g. if it's a simple token transfer which cannot be front-run).

[BlockRazorinc]

We believe encrypted mempool introduces additional costs, primarily in the following aspects:

Additional system complexity and computational overhead from transaction encryption:

• A key question is who performs the transaction encryption—wallets, RPC providers, or others? Currently, none of these options seem ideal.Decryption also burdens validators, especially considering BSC's push toward millisecond-level block times.
• Reduced revenue for validators and users : Encrypted mempool negatively impacts the efficiency and profitability of backrun strategies and other MEV strategies, ultimately leading to lower validator earnings.

On the other hand, encrypted mempool offers two advantages:

• Frontrunning prevention
• Stronger censorship resistance

To achieve these goals, alternative solutions like execution ticket / pre-confirmation mechanisms might be more effective.

[pepae]

We believe encrypted mempool introduces additional costs, primarily in the following aspects:

Additional system complexity and computational overhead from transaction encryption:

• A key question is who performs the transaction encryption—wallets, RPC providers, or others? Currently, none of these options seem ideal.Decryption also burdens validators, especially considering BSC's push toward millisecond-level block times.
• Reduced revenue for validators and users : Encrypted mempool negatively impacts the efficiency and profitability of backrun strategies and other MEV strategies, ultimately leading to lower validator earnings.

On the other hand, encrypted mempool offers two advantages:

• Frontrunning prevention
• Stronger censorship resistance

To achieve these goals, alternative solutions like execution ticket / pre-confirmation mechanisms might be more effective.

Great questions, let me try to answer:

1. so on who performs the transaction encryption, the nice thing is, both of your options can work alongside each other, plus we can also encrypt within the dapp frontend.
   On Gnosis Chain, there's an encrypting RPC: https://github.com/shutter-network/encrypting-rpc-server (you can try this out for yourself here: https://blog.shutter.network/shielded-trading/#get-protected-on-gnosis-chain )
   And here's an example of encryption within the dapp frontend: https://shutter.gnosischain.com/
   Also, keep in mind, using the encrypted mempool is optional for users/wallets/dapps, so this won't impede any existing applications or applications which aren't interested in benefiting from transaction encryption.

2. As for reduced revenue for validators: This is true in the sense that it reduces the front-running types of MEV. But that's exactly the value that's currently lost by users. So we think this is a good thing (users will get better prices).
   If implemented correctly, back-running and general arbitrage should not be affected. Longer term, we'd expect that if we can build a fair marketplace that is a more level playing field and thus open to more mainstream users, we think overall (benign/positive) MEV rewards for validators then might even increase.

3. In regards to pre-confirmation/execution ticket, this can be very complementary with an encrypted mempool. Please check out our roadmap for how to integrate Shutter with proposer commitments (which are the basis of pre-confs): https://ethresear.ch/t/the-road-towards-a-distributed-encrypted-mempool-on-ethereum/21717
   Tengentially related: we also think it's very complementary with ePBS and we'll publish a post on this very soon.

[BlockRazorinc]

We believe encrypted mempool introduces additional costs, primarily in the following aspects:
Additional system complexity and computational overhead from transaction encryption:

• A key question is who performs the transaction encryption—wallets, RPC providers, or others? Currently, none of these options seem ideal.Decryption also burdens validators, especially considering BSC's push toward millisecond-level block times.
• Reduced revenue for validators and users : Encrypted mempool negatively impacts the efficiency and profitability of backrun strategies and other MEV strategies, ultimately leading to lower validator earnings.

On the other hand, encrypted mempool offers two advantages:

• Frontrunning prevention
• Stronger censorship resistance

To achieve these goals, alternative solutions like execution ticket / pre-confirmation mechanisms might be more effective.

Great questions, let me try to answer:

1. so on who performs the transaction encryption, the nice thing is, both of your options can work alongside each other, plus we can also encrypt within the dapp frontend.
   On Gnosis Chain, there's an encrypting RPC: https://github.com/shutter-network/encrypting-rpc-server (you can try this out for yourself here: https://blog.shutter.network/shielded-trading/#get-protected-on-gnosis-chain )
   And here's an example of encryption within the dapp frontend: https://shutter.gnosischain.com/
   Also, keep in mind, using the encrypted mempool is optional for users/wallets/dapps, so this won't impede any existing applications or applications which aren't interested in benefiting from transaction encryption.
2. As for reduced revenue for validators: This is true in the sense that it reduces the front-running types of MEV. But that's exactly the value that's currently lost by users. So we think this is a good thing (users will get better prices).
   If implemented correctly, back-running and general arbitrage should not be affected. Longer term, we'd expect that if we can build a fair marketplace that is a more level playing field and thus open to more mainstream users, we think overall (benign/positive) MEV rewards for validators then might even increase.
3. In regards to pre-confirmation/execution ticket, this can be very complementary with an encrypted mempool. Please check out our roadmap for how to integrate Shutter with proposer commitments (which are the basis of pre-confs): https://ethresear.ch/t/the-road-towards-a-distributed-encrypted-mempool-on-ethereum/21717
   Tengentially related: we also think it's very complementary with ePBS and we'll publish a post on this very soon.

I think encrypting RPC has same problem as protected RPCs, and we believe we need more comments from wallet and front end Dapp provider for this case.

Could you explain why back-running and arbitrage will not be affected and at what user case the overall MEV will increase?

[pepae]

I think encrypting RPC has same problem as protected RPCs, and we believe we need more comments from wallet and front end Dapp provider for this case.

Agreed that an encrypting RPC in this context isn't the ideal end goal and introduces another trust assumption. For Gnosis Chain, it's seen as a stop gap solution towards the end goal, which is encryption by the users themselves, either in the wallet or dapp. Here again the example of this (on the dapp level) running in production: https://shutter.gnosischain.com/
But in general, a validator level encrypted mempool with multiple avenues to encrypt, including the RPC is very different from a protected mempool which hinges fully on the RPC alone.

Btw, we think that the UX paradigm might be changing anyway, towards a more agentic UX. This could be a good opportunity also to implement encryption on the user side. Example: https://x.com/bezzenberger/status/1895137585414160393

Also note that today already, anyone can run their own RPC, so users can already today be end-to-end protected, if they wish to do so.

Could you explain why back-running and arbitrage will not be affected and at what user case the overall MEV will increase?

Short answer is that the validator can still insert transactions immediately after the shielded transactions, just not before. So they can still back-run, and solutions like flashbots could be used to extract/distribute this type of back-running MEV.

We think overall MEV could increase over the long term, because we believe that by creating a fair marketplace that prioritizes accessibility and inclusion (i.e. making DEFI available not just to sophisticated traders, who know about MEV, but to an even bigger, broader, more mainstream audience, which is currently side-lined) we’ll draw in more users, which could actually contribute to an increase in overall transaction volume and thus validators’ back-running related MEV rewards.

[48ClubIan]

go to opbnb is you want this

[WTDuck2255]

I don't understand i touchtouchtouch everything i can

[MRHUNG369]

ok

[fallonp]

How will this proposal avoid BNB chain just being clogged up with spam MEV txs as described here?
https://writings.flashbots.net/mev-and-the-limits-of-scaling

[MRHUNG369]

**### _

Đề xuất BEP-559 (về cơ bản là BEP-547) áp dụng phương pháp mempool được mã hóa ngưỡng. Các giao dịch được gửi đến mempool sẽ được mã hóa, vì vậy trình xác thực, trình tạo hoặc bot MEV không thể xem nội dung ở front-run/sandwich. Khi đơn đặt hàng trong khối bị "khóa", giao dịch sẽ được giải mã và thực hiện. Do đó, các giao dịch "mùn thải MEV" (ví dụ: chạy trước, bánh sandwich) không thể bị gián đoạn, giúp mạng tránh tắc nghẽn do MEV txs.@>FALLONP /### _txs. ###**

[MRHUNG369]

phê duyệt

[Smokyish]

How will this proposal avoid BNB chain just being clogged up with spam MEV txs as described here? https://writings.flashbots.net/mev-and-the-limits-of-scaling

An encrypted mempool would remove malicious MEV like front-running and sandwich attacks. Arbitrage, liquidations and backrunning would still be possible, but it could alleviate some of the spam related to those.

[fallonp]

An encrypted mempool would remove malicious MEV like front-running and sandwich attacks. Arbitrage, liquidations and backrunning would still be possible, but it could alleviate some of the spam related to those.

Agreed that a private mempool would end malicious MEV. But that article makes clear that private mempools on Base and other chains have caused a massive explosion of spam MEV transactions, see -

Searchers will write bots which check Pool reserves and action Arbs if the reserves create an opportunity, These spam txs will only work less than 1% of the time but are a 'rational' approach in a world of private mempools. Result on Base are that 50% of Gas is spent by spam bots in this way, seems HIGHLY LIKELY that this will be repeated on BNB Chain if this proposal goes through.

We need to eliminate Sandwich attacks but in a way that allows searchers some access to pending txs to avoid this 'private mempool created MEV spam'. Ideas are discussed in the article in this section

[MRHUNG369]

How will this proposal avoid BNB chain just being clogged up with spam MEV txs as described here? https://writings.flashbots.net/mev-and-the-limits-of-scaling

An encrypted mempool would remove malicious MEV like front-running and sandwich attacks. Arbitrage, liquidations and backrunning would still be possible, but it could alleviate some of the spam related to those.

Thank you for raising this important question.
While BEP-559 may not completely eliminate all forms of MEV, it provides a substantial improvement in limiting harmful activities like front-running, back-running, and MEV-driven spam attacks.

By encrypting the mempool, this proposal effectively hides transaction content during the critical propagation window, making it significantly harder for MEV bots to exploit pending transactions. This helps to reduce network congestion, protect user intent, and preserve fairness in transaction ordering.

Arbitrage and liquidation may still occur post-block inclusion, but those are structurally different from pre-execution attacks.

Overall, I believe BEP-559 is a valuable step forward for the BNB ecosystem and should be supported.

[pepae]

How will this proposal avoid BNB chain just being clogged up with spam MEV txs as described here? https://writings.flashbots.net/mev-and-the-limits-of-scaling

Good question! Flashbot's proposal in the link you provided to auction off the backrunning slot would be a good way to achieve this, while maintaining front-running resistance. So this and the encrypted mempool should be complementary.

[octavio12345300]

List

[MRHUNG369]

Ok

[pepae]

Hey @MRHUNG369 @octavio12345300 @davesmail1401-sudo @hailuu01041990-lab how do we move forward with getting this BIP approved to be in the list of potentially to be adopted EIPs? Who can approve it?

As I understand, this stage wouldn't mean actual adoption/implementation but rather just it being part of the list of potential candidates, so imho should be ready to approve. Thanks!

[caravello00]

Hey all, it looks like some sandwich attacks have returned. Could be a good time to revisit the encrypted mempool BEP as a potential longterm solution.

Sharing some screenshots of charts from the Dune dashboard below. But perhaps someone else has a better data source.
https://dune.com/hildobby/sandwiches?Blockchain=bnb