BAP-710: Unified PropAMM Relayer

[asiawildboar]

https://github.com/asiawildboar/BEPs/blob/bap-propamm/BAPs/BAP-710.md

[hashdit-bot]

Pull Request Review

This PR adds a new draft BAP metadata file to reserve a future BAP number. The document contains placeholder values for the BAP number and title, along with draft status, application type, and creation date.

Sensitive Content

No sensitive content detected.

Security Issues

No serious security issues detected.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[hashdit-bot]

Pull Request Review

This PR adds BAP-710, a specification for a builder-neutral PropAMM relayer and standardized BNB Chain registry and pool interfaces. It defines signed priority quote updates, RPC and maker APIs, atomic multi-builder bundle execution, test cases, and operational security requirements.

Sensitive Content

No sensitive content detected.

Security Issues

🟠 [HIGH] Replayable signed updates permit rollback to stale pricing state

File: BAPs/BAP-710.md

Section 4.2.2 deliberately allows a previously signed update to be replayed until its maxBlockNumber expires and imposes no on-chain sequence or monotonicity check per lane. After a newer quote is installed, anyone who obtains an older still-valid signature—including from prior on-chain calldata—can overwrite the lane with the old price and atomically trade against it, potentially extracting funds from the pool. Relayer-side seq ordering does not protect against direct on-chain submission or a malicious builder/relayer.

Recommendation: Include a per-lane nonce or sequence number in the EIP-712 signed payload, store the latest accepted value on-chain, and reject updates whose sequence is not strictly greater. If replacement semantics are based on validity blocks, also prevent maxBlockNumber from decreasing; do not rely solely on relayer-side ordering.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[nash-takapu]

Thank you @asiawildboar for proposing BAP-710 and for putting together the Unified PropAMM Relayer design. The proposal provides a systematic approach to PropAMM quote updates, transaction simulation, and Builder execution, and attempts to improve quote inclusion efficiency.

After carefully reviewing the proposal, we have the following concerns.

Taker

• Reduced transaction composability: Transactions involving PropAMM must be sent through the designated Relayer for Bundle construction. They can no longer be freely combined with other transactions, external Bundles, or other Builders, which makes the design particularly difficult to use for searchers performing copy trading, arbitrage, and other strategies that require custom Bundle construction and submission.

Wallet

• The integration cost is underestimated: Although the transaction format and signing flow remain unchanged, Wallets still need custom development to distinguish PropAMM transactions from ordinary transactions and to handle different simulation, broadcasting, and failure paths.

• Existing RPC business relationships are difficult to replace: Wallets choose RPC providers based not only on APIs, but also on rebates, performance, reliability, multi-RPC availability, and existing commercial partnerships. Connecting to a single Relayer would affect existing RPC traffic and commercial arrangements, creating additional adoption barriers.

• Transaction stability may suffer during network congestion: PropAMM transactions sent directly to a Builder may fail because the corresponding Quote Update is missing. At the same time, larger Bundles assembled by the Relayer may be harder to order and include than existing single transactions during periods of congestion. This could affect Wallet transaction stability and create significant concerns about integration.

Aggregators / Solvers

• The main integration challenge is maintaining a low-latency in-memory pool state: Efficient routing and liquidity splitting require the latest quote state to be available directly in memory. Querying an RPC node for every quote is not viable.

• Both approaches require state adaptation, whether subscribing to State Override updates or running a Local Relayer: With State Override subscriptions, the Solver must receive updates in real time and convert and apply them to its own in-memory pool state. Running a Local Relayer only moves state distribution and aggregation locally; the Solver still needs to convert the effective state maintained by the Relayer into the representation used by its own in-memory pool. Therefore, neither approach eliminates the need for state-model adaptation; they only determine where that adaptation takes place.

Market Makers

• The incremental benefit may not justify the migration cost: There are already multiple PropAMMs on BSC, and major Makers and aggregators already support multi-route, many-to-many integrations. The existing ecosystem is broadly functional. The main incremental benefit of this proposal may be faster quote inclusion, but the expected improvement appears limited, while Makers would need to migrate to a unified contract and storage design that may restrict differentiation in contract and pricing logic.

• Quote execution becomes overly dependent on the Relayer: Makers would need to trust the Relayer to submit their quotes faithfully. The Relayer could incorrectly or maliciously submit already-signed quote updates, and software bugs could also result in wasted Gas.

• There may be insufficient migration incentives: It remains unclear whether existing PropAMMs would be willing to adapt and migrate. Without sufficient Maker liquidity, Wallets and Solvers would also have little incentive to integrate the system.

Builders

• Builders have no clear incentive to prioritize Relayer Bundles: Builders may not need to implement PropAMM-specific logic, but the proposal does not provide a clear additional incentive for them to prioritize Relayer Bundles. Compared with existing transactions, these Bundles may be more complex and larger, and may be harder to order and include during periods of congestion.

• The Relayer may affect fair competition among Builders: By controlling a significant amount of transaction flow and Bundle distribution, the Relayer may influence competition and traffic allocation among Builders.

Relayer

• Costs and responsibilities are highly concentrated: The Relayer must handle quote processing, state maintenance, transaction matching, Bundle construction, multi-Builder distribution, as well as the development, auditing, and long-term operation of highly available infrastructure.

• The revenue model is unclear: The proposal does not clearly explain how the Relayer can generate sustainable revenue sufficient to cover its infrastructure, development, and maintenance costs.

• The single point of failure is too significant: The Relayer occupies a highly centralized position. If it experiences an outage or serious degradation, all PropAMM transactions depending on it may be affected, potentially creating significant reputational and trust-related consequences.

Conclusion

We believe the current BSC PropAMM ecosystem is already broadly usable. The main need at this stage appears to be improving quote-update and transaction-inclusion efficiency, rather than introducing a highly centralized Unified Relayer.

This proposal requires Wallets, Solvers, Market Makers, Builders, and the Relayer to bear significant technical, commercial, and operational costs, while the expected benefits appear limited. As a result, adoption may be challenging.

There are already protocols in the ecosystem exploring innovations in contract design, quote mechanisms, and execution. We believe it would be more valuable to encourage open competition and diverse infrastructure, allowing different participants to continue innovating, rather than concentrating PropAMM transaction flow in a single operator.