SEP-24: add or update fee endpoint including FX rates #1273

JakeUrban · 2022-07-25T16:08:00Z

What problem does your feature solve?

SEP-24's GET /fee endpoint assumes the off-chain asset is exchanges 1-for-1 with the on-chain asset. But it is increasingly common for anchors to accept off-chain assets that are not exchanged 1-for-1 with the on-chain assets they support.

What would you like to see?

We either need to update the existing GET /fee endpoint or add a new endpoint for requesting the FX rate + any fees.

The endpoint we design will likely look very similar to SEP-38's GET /price or GET /prices (or we could add endpoints for both).

What alternatives are there?

We could recommend that SEP-24 anchors implement SEP-38, since the use case is so similar.

However, implementing the entire SEP-38 API may be overkill in the context of SEP-24, since users can commit to FX rates in the anchor's UI, which means there is no reason for SEP-24 anchors to expose the SEP-38 POST /quote endpoint.

The text was updated successfully, but these errors were encountered:

leighmcculloch · 2022-07-25T16:27:18Z

I think this is reasonable extension to SEP-24.

I agree implementing /quote may be overkill, unless the UI hopes to display more accurate estimate of an amount before sending the user down the UI. At the least we can leave /quote out on a first pass and introduce it if the need for it arises.

Do we see more use of /price or /prices for SEP-38?

Should we deprecate /fee in time?

JakeUrban · 2022-07-25T16:41:38Z

Do we see more use of /price or /prices for SEP-38?

I think so. We've had multiple wallets express desire for the functionality offered by these endpoints, primarily for monitoring FX rates out-of-band of the transaction initiation flow. For example, sending notifications to users when rates are favorable, or displaying an anchor's live rates on the wallet's website to entice downloads of their app.

Should we deprecate /fee in time?

I think so (again). The GET /price endpoint from SEP-38 can do everything SEP-24's GET /fee endpoint does, so we don't lose existing functionality, and GET /fee nowadays only works for a increasingly small subset of anchors.

leighmcculloch · 2022-07-25T16:43:22Z

Do we see more use of /price or /prices for SEP-38?

I think so. We've had multiple wallets express desire for the functionality offered by these endpoints

I was meaning do we see folks primarily using /price or /prices? Or do folks really need both?

JakeUrban · 2022-07-25T16:55:50Z

They serve different use cases.

GET /prices would likely be used most outside transaction flows for monitoring prices.

But GET /price includes information on any additional fees charged for processing transactions on top of the FX rates, so that endpoint would be used when the user is looking at a particular pair and about to initiate a transaction.

My inclination is that GET /prices would be used more in the context of SEP-24 anchors, since additional fees can be displayed in the anchor's UI when users initiate a transaction, but from the wallet's perspective I'm sure they would prefer to have both endpoints available.

leighmcculloch · 2022-07-25T17:47:33Z

Sounds reasonable to me to add both now.

github-actions · 2022-08-24T18:07:42Z