Anchor Quote API

[JakeUrban]

We've recently seen an increased demand for a standardized API specification to facilitate off-chain liquidity in Anchor flows. We'd love to hear your thoughts about this.

Currently, our deposit/withdraw (sep6/24) and cross-border payments (sep31) standards assume that off-chain assets being deposited/withdrawn are the same as those pegged on-chain. For example, when you withdraw BRLT (by nTokens) using nTokens, you get BRL in your bank account.

However, there's nothing stopping an anchor from converting currencies during deposits and withdrawals, as long as they can provide the FX. For example, nTokens could also, theoretically, offer a withdrawal from USDC (by Circle) directly to BRL in a bank account in Brazil.

The missing part of this puzzle is that nTokens doesn't have an interoperable way to provide quotes for their users and, presumably, users will not initiate a withdrawal without knowing how much they're going to get in the end.

What would this standard API be good for? Some anchors are able to provide FX and prefer to skip asset issuance due to operational and/or regulatory complexity.

cc. @tomerweller

This issue serves as a place for discussion and TODO

[erasmus]

Great initiative! We'd love to get involved with this SEP. I think developing USDC (or some other high-trust asset) as bridge asset makes a lot of sense, especially considering the widespread use of USD as settlement currency in international trade.

Some initial thoughts:

1. Perhaps there's some insights gained in looking at 0x's RFQ API specs?
2. It would make sense for the quote API to take as input asset pair, volume, expiry time (optional?). Perhaps the request could also state whether it's an indicative quote request or a transaction that is expected to be executed soon.

[JakeUrban]

@erasmus thanks for the thoughts. I think having an indicative /price endpoint and firm /quote endpoint in the style of 0x makes a lot of sense, they serve different use cases.

Maybe this is what you meant, but expiration time needs to be specified by the quote provider, since they're the entity taking on the risk, and the client will need to deliver funds before the provided expiration.

I'm collecting context and requirements internally and from our interested partners at the moment, and will submit a PR for the API soon.

[erasmus]

I was thinking that the quote requester should be able to specify a desired expiration and get a quote from provider based on that time horizon. As a requester I may want to pay more for a longer expiry time.

[JakeUrban]

@erasmus The PR is ready to be merged, do you have any remaining comments / concerns?