Closed accordeiro closed 5 years ago
What does this mean
(maybe via a path payment to itself)
why not send via a path payment to the withdraw anchor
Is exchange rate fluctuation an issue in any normal (non-cross-border) withdrawal? If something is very volatile, the exchange rate could change between the portion of the kyc flow where rate was calculated and when the payment actually gets processed on the network.
Are you suggesting that anchors will have a flexible input for a fixed output?
I think it might help to wireframe this out. I wonder if we can move the USDZ/BRZ exchange rate to the end of the flow. In the confirm payment page, the user will be sending USDZ, ie the user goes through a normal BRZ withdraw flow, and at the end the wallet can say "You need to get 400BRZ to this account, you can do so via a path payment of 101.4USDZ" or something
My understanding was that the user could adjust (or the app would adjust automatically, based on the price rate difference) the final value after the KYC check, so this would be the final value to be withdrawn. The idea of asking for the value before the KYC would be related to anchors requiring different KYC info or allowing different permissions depending on the requested withdrawal value, is that correct?
we've been moving away from that idea of different kycs based on inital value, if you're an anchor that requires that, do it all in the webapp.
The more i think about this the better it seems to just start by saying “Withdraw BRZ” even if you don’t have any, and the confirm transaction screen lets you withdraw BRZ via path payment from any of your other assets
Following up:
<@msfeldstein> What does this mean (maybe via a path payment to itself) why not send via a path payment to the withdraw anchor
I think you're right: sending the path payment to the withdraw anchor makes more sense.
<@msfeldstein> Is exchange rate fluctuation an issue in any normal (non-cross-border) withdrawal? If something is very volatile, the exchange rate could change between the portion of the kyc flow where rate was calculated and when the payment actually gets processed on the network.
You're right – but the exchange would happen prior to the payment processing part, so we wouldn't need to worry about this for withdrawal. But this is indeed a concern for deposit.
<@msfeldstein> Are you suggesting that anchors will have a flexible input for a fixed output?
Not exactly, I think they should have a flexible input to accommodate fluctuations, but they should of course adjust the output accordingly. In the described case, the anchor would deposit 398 BRL - fees
to a 398 BRLZ
deposit, even though the user initially requested a 400 BRL
deposit.
<@msfeldstein> I wonder if we can move the USDZ/BRZ exchange rate to the end of the flow. In the confirm payment page, the user will be sending USDZ, ie the user goes through a normal BRZ withdraw flow, and at the end the wallet can say "You need to get 400BRZ to this account, you can do so via a path payment of 101.4USDZ" or something
Yep, but we need to understand whether that's feasible in the first place, considering the current USDZ
balance the User holds. This is why we need the check prior to the interactive flow. Does that make sense?
<@brunomuler> The idea of asking for the value before the KYC would be related to anchors requiring different KYC info or allowing different permissions depending on the requested withdrawal value, is that correct?
I think Michael already answered this, but I also wanted to add that asking for an amount pre-KYC is a validation step to ensure the user has enough funds to perform that operation later on.
<@msfeldstein> The more i think about this the better it seems to just start by saying “Withdraw BRZ” even if you don’t have any, and the confirm transaction screen lets you withdraw BRZ via path payment from any of your other assets
I think my previous two answers apply here too – we need to have a ballpark estimate of what the user aims to withdraw to check if we should move forward with the KYC/withdrawal flow.
we need to have a ballpark estimate of what the user aims to withdraw to check if we should move forward with the KYC/withdrawal flow.
Yeah i think this will catch people a lot in the case where they're a dollar short, i see why you are considering the flexibility and that seems like a good idea.
This "max amount available to withdraw" seems like something we could add to the spec as a hint that wouldn't break anything already existing.
I think this is a bit of a bigger topic.
Multi-currency deposit/withdraws are problematic (deposits more so than withdraws) due to the inability to lock a conversion rate . I believe the root cause of this is that they are non-idiomatic to the way that the stellar protocol along with the ecosystem protocols view cross border payments.
In theory, an idiomatic cross border payment should look like (approach 1):
An alternative approach, is to move currency conversions off-chain (approach 2):
The implied approach in this specific issue is a bit of a mish-mash of both of the above. It uses multiple assets and the dex for conversions, without the destination wallet actually holding a balance of BRLZ. I assume this is because this specific wallet only allows a USDZ balance?
As a stop-gap, maybe the wallet should just convert the USDZ to BRLZ immediately in the beginning of the withdraw process. That will essentially lock the conversion rate.
I really like the idea of being able to do approach 2 – I remember we discussed this a while ago. The only tricky bit is it'd require anchors to be able to make international payments and/or have a legal entity in different countries. Does that seem to reflect real-life scenarios?
I assume this is because this specific wallet only allows a USDZ balance?
You're right, this specific Wallet only allows a USDZ
balance.
As a stop-gap, maybe the wallet should just convert the USDZ to BRLZ immediately in the beginning of the withdraw process. That will essentially lock the conversion rate.
Yeah, we've thought about this approach. However, what if the user converts to BRLZ
early in the process, then their KYC gets rejected afterwards? I guess we'd be able to convert back, but the User might lose some of their balance in the process due to fees / conversion rates.
The only tricky bit is it'd require anchors to be able to make international payments and/or have a legal entity in different countries. Does that seem to reflect real-life scenarios?
It's not necessarily that complicated. It just entails a relationship between the BRL off-ramp and the USD Anchor. So, let's say that you @accordeiro provide an AnchorUSD off-ramp in Brazil. You're going to end up with a bunch of AnchorUSD dollars on Stellar. If you have an American bank account you can use their ACH off-ramp to turn this to dollars in your american bank account. Or, you can use their wire service to off-ramp through swift to anywhere in the world. I'm no lawyer but I don't think you'll need an American legal entity for that.
However, what if the user converts to BRLZ early in the process, then their KYC gets rejected afterwards? I guess we'd be able to convert back, but the User might lose some of their balance in the process due to fees / conversion rates.
Let's optimize the experience for the people who pass KYC ;)
@tomerweller I love the idea of allowing multiple offramps for the same asset.
It's also worth asking if a longer-term goal of this project is to make the forex happen on the DEX. I thought it was, which means approach 2 would improve the user experience but would not be a step towards our larger goals.
My take is that if we do the following:
then the flow will work out nicely.
It's also worth asking if a longer-term goal of this project is to make the forex happen on the DEX. I thought it was
I agree having the forex happen on the DEX helps us achieve our goals in a more holistic way.
@tomerweller created a separate issue (#397) for us to discuss the decoupling of deposit/withdraw flows from asset issuers altogether, including off-chain withdraw/deposit currency conversions.
Based on our discussions, these are my suggestions for tweaking SEP-6 to solve the problems listed in this issue:
On the Basic Anchor Implementation, emphasize the importance of accepting an amount
value as a parameter to both /withdraw
and the interactive flow URL. This partially solves P1. We might still have some issues with users changing amounts in the interactive flow, which is a minor edge case we probably shouldn't focus on for now.
On the Withdraw Specs, point out that anchors need to be flexible about the informed amount vs. what is actually transferred to their Stellar accounts (a 10% margin might be a good start). This should solve P2 completely.
Do these sound right, or am I missing something?
To capture some other details discussed offline, we should also instruct anchors to watch for pathPayment
operations (vs. only payment
ops) in the Withdraw specs.
we should also instruct anchors to watch for
pathPayment
operations
Good point. They should listen to all form of payments that the horizon payments
endpoint supports. Even though it can be a bit challenging sometimes.
Cool, that makes sense. I'll issue a PR to reflect our conclusions here.
This issue describes a use case for Wallets that support cross-border payments, and a few issues that have been encountered while trying to lay out the correct withdrawal flow.
Use case
USDZ
BRLZ
User / Wallet / Anchor interaction flow
In order to accomplish that use case, we could use the following flow:
USDZ
balance in their native currencyUSDZ
it would cost for the user to withdraw a certain amount of BRL (the Wallet can use the Stellar Ticker API to calculate the conversion rate). In this example, let's say at the given time the Wallet informs the user that they would have to use100 USDZ
of their balance to withdraw400 BRL
.400 BRL
), the Wallet hits theBRLZ
anchor's/withdraw
endpoint, passingamount=400
as a parameter./withdraw
request would be a403 (Forbidden)
with a URL pointing to the interactive flowBRLZ
Anchor's UI, informing their bank account info, etc.BRLZ
transfer (viapostMessage
) before it fulfills the external deposit100 USDZ
toBRLZ
, then sends the newly acquiredBRLZ
to the given Stellar address, and polls the/transaction
to get status updates about the withdrawal, until the transaction's status is marked ascomplete
.Problems
There are a few issues with this approach.
P1: Double input of amount
The user has to input a
BRL
amount early in the process, in step 2. However, as we're suggesting anchors to collect most info through the interactive flow, that user will likely be presented with an "amount" input again in the interactive flow. Even if the amount is pre-populated, giving the user the ability to change that amount might lead to an inconsistent state in the later steps.Suggested solution
One solution for that is to provide some kind of
amount_readonly=true
parameter to the interactive popup URL, and either skip the amount input or display it as read-only during the interactive withdrawal flow.P2: Exchange rate fluctuation
On step
2
, the Wallet uses an exchange rate (ER_1
) to calculate how manyUSDZ
are needed to withdraw400 BRL
. However, this exchange rate might have changed toER_2
when the actual exchange happens, which is only on step7
. Wallets could ask the user if they would like to update theUSDZ
amount to reflect the exchange rate, but we should have a solution in case the user doesn't want to do that (or can't, in case100 USDZ
is their full balance andER_2
is more expensive thanER_1
).Suggested solution
In order to provide a smooth user experience in this scenario, we could recommend/require anchors to be flexible to accept
398 BRLZ
or402 BRLZ
, as long as the correctmemo
is provided in the transaction.Questions
@morleyzhi @brunomuler please let me know if this flow correctly describes what we've discussed last Friday @tomquisel @msfeldstein @tomerweller looking forward to getting your thoughts on this :)