Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return estimatedExchangeRate for quotes #491

Open
1 task
mkurapov opened this issue Jul 17, 2024 · 1 comment · May be fixed by #498
Open
1 task

Return estimatedExchangeRate for quotes #491

mkurapov opened this issue Jul 17, 2024 · 1 comment · May be fixed by #498
Assignees
Labels
type: specification Changes to the specification

Comments

@mkurapov
Copy link
Contributor

Context

Originally from @raducristianpopa particularly in the WM context, there is no good way to determine what is the minimum debitAmount for a quote that will satisfy at least a minimum one unit of value for the receiving wallet address:

What would be the best way to check what is the minimum amount that can be sent in a cross-currency scenario - debitAmount?
When sending from USD to EUR, in most cases $0.01 is not going to equal 0.01EUR.
I thought about using receiveAmount but this will not work - the grant will need the limits in the receiver’s asset.
Probe through quoting - create quotes until one is created successfully? - For WM this will lead to some delays in the flow
Probe through quoting with an exponential increase for the amount?
If the sender’s asset is ZAR and the receiver’s asset is USD we will probably have to make around 16-18 quote requests (depends on the exchange rate as well):
0.01 ZAR = 0.00… USD
0.19 ZAR = 0.01 USD
In the example above, the extension will have to make 18 quote requests until it reaches an amount that can be represented in USD.

What we came up with in the Open Payments catch up call is to expose an estimatedExchangeRate on the quote POST & GET response.

Todos

  • Update the resource server spec to include an optional estimatedExchangeRate: number in the quote
@raducristianpopa
Copy link
Member

raducristianpopa commented Aug 22, 2024

Should the ILP specific fields be removed as well in this PR?

Related to: interledger/rafiki#2856.

Edit: I just noticed that these fields are not returned for Open Payments.

@raducristianpopa raducristianpopa self-assigned this Aug 22, 2024
@mkurapov mkurapov added the type: specification Changes to the specification label Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: specification Changes to the specification
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

2 participants