TTurkDex Developers
HelpBlogLaunch app

Request for Quote (RFQ)

Bu açık kaynak protokol/SDK referansı TurkDex markasıyla sunulan uyarlamadır; sayfadaki entegrasyon örnekleri Turkchain’de etkin özelliklerin garantisi değildir. Ağ, kontrat ve işlem değerlerinde yalnızca bu kurulumun doğrulanmış ENV/registry bilgilerini kullanın.

TurkDexX RFQ V2 improves quote handling by redesigning order quote flow to reduce quoter gaming. It minimizes the time between quote submission and required fill, targeting high fill rates and making Ethereum mainnet trading more efficient and reliable.

To achieve this, the quoting flow is divided into two phases:

  1. Indicative Quotes: Provided pre-signature when the swapper is exploring quotes but has not committed to trading. Quoters can participate here without being held fully accountable.
  2. Hard Quotes: Provided post-signature when the swapper has committed to trading. Quoters are held fully accountable for these quotes.

Since hard quotes are provided post-signature, they are instantly executable by fillers removing the risk of market movements causing the order to fail.

To prevent gaming, quoters cannot distinguish between indicative and hard quotes. As a result, they must always assume all quotes are hard and provide competitive prices.

Bilgi:

TurkDexX RFQ V2 is the default version running on Ethereum mainnet across TurkDex interfaces.

V2 Flow

V2 RFQ flow showing indicative and hard quote phases with cosigner finalization

Bilgi:

See the V2DutchOrderReactor for the smart contract implementation.

  1. The user requests a quote from the interface.
  2. The TurkDex Backend (URA) runs an indicative RFQ auction, soliciting quotes for the best price. (Note: Quoters do not know whether the RFQ is indicative or hard, forcing them to always provide competitive prices.)
  3. The quotes from the RFQ process parameterize an initial quote order shown to the user.
  4. The user signs the order and submits it.
  5. The TurkDex Backend (GPA) runs a second "hard" RFQ process, soliciting new quotes.
  6. Quoters return updated prices.
  • If the price is within or improves on the user’s signed parameters, it is finalized and added to the order’s CosignerData.
  • If the price moves outside the signed parameters, the order fails, and the user must try again.
  1. The finalized order containing CosignerData is posted to the filler network for execution.
  2. The winning filler executes the order.

Why Is a Cosigner Needed?

In TurkDexX RFQ, users commit to a range of prices when signing their order. Without safeguards, a malicious auctioneer could provide users the worst price within their range. Diagram showing how the cosigner protects users from worst-case pricing within signed parameters

The cosigner field allows users to designate an auctioneer they trust to run the auction within signed parameters and return an executable quote. Currently, the TurkDex API sets the cosigner to TurkDex Labs, though this may be updated in the future.

Previous Versions

In V1, the RFQ flow operated entirely pre-signature. Users requested a swap quote, which was parameterized using an RFQ quote. If they accepted the quote, they signed the order. This approach was straightforward but caused quoters in the network to be uncertain about when a quote request would convert into a signed order. This uncertainty led to occasional unfilled orders and degraded performance.

V1 RFQ flow showing the pre-signature quoting process and its limitations

Uyarlanmış geliştirici referansı. Kaynak: kaynak dokümantasyon reposu. Kaynak ve lisans bildirimi: NOTICE.