stellar / go

Stellar's public monorepo of go code
https://stellar.org/developers
Apache License 2.0
1.3k stars 502 forks source link

Proposal: Develop an API Endpoint to View Unconfirmed Transactions in Stellar Core #4886

Open hot-bit-git opened 1 year ago

hot-bit-git commented 1 year ago

Description:

The Stellar network, while robust and efficient, has an aspect that allows for "frontrunning". Frontrunning is when an entity can see a transaction before it's confirmed and act on that information before others have a chance to.

Currently, skilled coders can read unconfirmed transactions from the Stellar Core transaction set / mempool. Access to unconfirmed transactions is not possible with Horizon and SDKs, but requires modification to Stellar Core code, which creates inequality in the access to information.

Presently, Stellar Classic is experiencing issues with several thousands of transactions daily exploiting frontrunning tactics. These accounts aren't participating as market makers; instead, they're executing taker offers, which detrimentally impact the order book and disrupt the operations of market makers. This problem is expected to create comparable, if not more severe, complications in the forthcoming Stellar Soroban. Implementing a new endpoint, designed to mitigate these issues, is imperative and should be integrated into both validator nodes and captive cores to ensure comprehensive coverage and effectiveness.

Proposal:

To level the playing field and enhance the network's transparency, I propose the development of an API endpoint that would allow users to view the transaction pool, which contains unconfirmed transactions. This would make the information about unconfirmed transactions accessible to all members of the Stellar network, not just those with advanced coding skills.

The API could be designed to allow users to query the transaction pool and return the unconfirmed transactions in a user-friendly format, accessible using SDKs like Python SDK, Javascript SDK etc.

MonsieurNicolas commented 1 year ago

Hello. Thanks for the report. Before diving into the more technical bits... Can you explain how this would reduce front running? At a glance it seems this would make the problem worst as trading bots would not even have to run in their own infra, so this would just increase the number of active bots (without actually increasing the odds of "winning" those arb trades)

hot-bit-git commented 1 year ago

@MonsieurNicolas Currently, we maintain two versions of our orderbook: the censored, or as some may refer to it, the classic orderbook, which is accessible via SDKs; and the full orderbook, which encompasses both confirmed and unconfirmed transactions (orders). We could further censor the public visibility of the orderbook by introducing a delay of three ledgers, but it's crucial to contemplate whether this would bear any benefit beyond potentially facilitating more frontrunning opportunities.

Consequently, the proposal on the table is to disclose the full orderbook, not just a section of it. As with the classic orderbook, all participants would then have equal opportunities. If Participant X proposes a price that fails to meet market expectations, their order will manifest in the classic orderbook in the ensuing ledger as a market-making order. This dynamic action would contribute to narrowing the spread and enhancing liquidity, rather than solely eroding liquidity, as is the case in the current setup.

This approach aims to foster a more transparent, equitable, and liquid market for all participants, underlining our commitment to creating a fair trading environment.