Amendment Idea: DEX Broker

[tequdev]

  
  title: DEX Broker
  description: This amendment allows accounts to earn revenue proportional to the traded volume of DEX orders.
  
  author: tequ <@tequdev>
  status: Idea
  category: Amendment
  created: 2025-09-26

DEX Broker

Abstract

Within the ecosystem, mechanisms such as XLS-56 (Batch) and XLS-67 (Charge) have been discussed for project monetization. Batch enables platforms to monetize by atomically executing a user’s intended transaction together with a payment to the platform. While Batch can impose a fee at the time an Offer is created, that is independent of whether the Offer is actually executed or matched on the DEX.

This proposal introduces the DEXBroker amendment, which enables platforms to earn revenue proportional to the traded volume of DEX orders. When an Offer is created and directly executed via an OfferCreate transaction, or when an Offer is executed via OfferCreate or Payment, a payment is made from the Offer owner to a Broker Destination according to a specified fee rate.

Amendment

The amendment changes the following:

• the Offer ledger object
• the OfferCreate transaction
• the Payment transaction

Specification

OfferCreate Transaction

Add a new field to the OfferCreate transaction.

Field Name	Required?	JSON Type	Internal Type	Description
Broker		object	STObject	The broker object. (Refer to Broker object below)

The fee paid to the Broker Destination always matches the token the Offer owner receives (TakerPays). If, at execution time, the Destination account does not exist or does not meet the required trust line conditions for the token, the transfer to the Destination is skipped and the transaction behaves exactly as if the Broker field were not provided.

The Destination must have an appropriate trust line to receive the fee when the token is an issued currency.

Amount paid to Broker Destination = Amount the Offer owner receives × BrokerRate / 100000

New Failure Conditions

For Create Offer with Broker

• Broker.Destination is the same as Account.
• Broker.Destination is not an activated account.
• Broker.BrokerRate is not a valid rate. (Should be 1 ~ 50000 / 0.001% ~ 50.000%)
• if TakerPays is not XRP
  • Broker.Destination does not have a valid Trustline (Frozen, Auth) for TakerPays token.

For Execute Offer with Broker

• No new failure conditions. If any of the above checks fail, the transaction does not fail; only the payment to the Broker Destination is omitted.

Example OfferCreate Transaction JSON

{
   "Account" : "rBY2yswbwwkDizQXwbMHM8jf6XZzB5KkMz",
   "Fee" : "10",
   "Broker" : {
      "Destination" : "r4Gxp2J3nq9kNjWo3hBmC8h7f3naG8ksVZ",
      "BrokerRate" : 1000
   },
   "Sequence" : 6,
   "SigningPubKey" : "02991B0AC5958B02244FB13FAE8A81FA6B8FC253C721EE87FBFDCB964F07E918F3",
   "TakerGets" : {
      "currency" : "USD",
      "issuer" : "r9cZ5oHbdL4Z9Maj6TdnfAos35nVzYuNds",
      "value" : "100"
   },
   "TakerPays" : "100000000",
   "TransactionType" : "OfferCreate",
   "TxnSignature" : "3045022100F64A40B091879FD9EAA031E557EF03CE4FED3C01D95A0EDF1AE6C99768B732F5022058E68579CCACAEC8C09E778696AC213238718E0F996C12C24895E96E681D3604",
   "hash" : "6C732FCC8E9A0A9532E5E10DC5750756AA124295BE7DC1DAC5AC0A83C73A07D2"
}

Payment Transaction

No new field to the Payment transaction.

When Offers are executed as part of a cross-currency payment or a token swap routed via the DEX, a broker is charged from the Offer owner to the Broker Destination under the same conditions as for OfferCreate.

Offer Ledger Object

Add a new field to the Offer ledger object.

Field Name	Required?	JSON Type	Internal Type	Description
Broker		object	STObject	The broker object. (Refer to Broker object below)

The presence or absence of the Broker field does not affect the Order Book Directory where the Offer is listed, and it does not worsen the execution quality for third parties who execute the Offer.

Example Offer Ledger Object JSON

{
   "Account" : "rBY2yswbwwkDizQXwbMHM8jf6XZzB5KkMz",
   "BookDirectory" : "5C763DE15534A062C34EC8D98F53C5E6D449CCCB9D5BD9495B038D7EA4C68000",
   "BookNode" : "0",
   "Flags" : 0,
   "LedgerEntryType" : "Offer",
   "OwnerNode" : "0",
   "PreviousTxnID" : "6C732FCC8E9A0A9532E5E10DC5750756AA124295BE7DC1DAC5AC0A83C73A07D2",
   "PreviousTxnLgrSeq" : 6,
   "Broker" : {
      "Destination" : "r4Gxp2J3nq9kNjWo3hBmC8h7f3naG8ksVZ",
      "BrokerRate" : 1000
   },
   "Sequence" : 6,
   "TakerGets" : {
      "currency" : "USD",
      "issuer" : "r9cZ5oHbdL4Z9Maj6TdnfAos35nVzYuNds",
      "value" : "100"
   },
   "TakerPays" : "100000000",
   "index" : "62861A460A36A5FD76D9368A7078184A6BB8060A1576138C9EC85FE2A34DA4E5"
}

Broker object

Field Name	Required?	JSON Type	Internal Type	Description
Destination	Yes	string	AccountID	The destination account to receive the broker.
BrokerRate	Yes	number	UINT16	The broker rate. (1 ~ 50000 / 0.001% ~ 50.000%)

Example flow

1. Create Offer with Broker

1. Alice creates an Offer (Sell 100 XRP for 100 USD) with Broker (Destination: John, BrokerRate: 1000(1%)).
   • Offer ledger object has created.
2. Bob creates an Offer (Buy 100 XRP for 100 USD).
   • Alice's Offer is executed.
   • Alice receives 99 USD.
   • John receives 1 USD as Broker Destination.
   • Bob receives 100 XRP.

2. Execute Offer with Broker

1. Alice creates an Offer (Sell 100 XRP for 100 USD).
   • Offer ledger object has created.
2. Bob creates an Offer (Buy 100 XRP for 100 USD) with Broker (Destination: John, BrokerRate: 100(0.1%))
   • Alice's Offer is executed.
   • Alice receives 100 USD.
   • Bob receives 99.9 XRP.
   • John receives 0.1 XRP as Broker Destination.

[xVet]

That's a very cool idea! It reminds me of the broker mode of NFTokenOffers

[CarloDotGG]

Marketplace Operator. I feel this is a huge catalyst for adoption by major players! Endless opportunities to apply this in B2B2B and B2B2C business models.

[EnchStyle]

I fully support this idea. Absolutely brilliant and very much needed.

Some questions I have on my mind this will stack up with pool AMM fees, as well as the behaviours and logic when one order is placed on xpmarket and another on a different DEX UI... But so far it seems there might be no conflicting?

[nguyenvanhoang26041994]

IMO. This appears to represent another Market Maker model. As an end-user (Alice), my primary goal is always to secure the best possible rate. This necessitates involving any broker who can offer the cheapest broker fee. Consequently, a single order fulfillment may involve multiple brokers and require a Central Limit Order Book (CLOB). This inherently increases the complexity of the execution system.
So i have few questions:

• A single Offer can be fulfill by multiple broker + AMM + CLOB orders?