It will be easier for users if wallets and other clients can interact with anchors directly without the user having to leave the wallet to go to the anchor's site. Here is a draft proposal https://github.com/stellar/stellar-protocol/blob/master/drafts/draft-0002.md intended to create a standard way that anchors allow this to be done. Any feedback would be great.

Yes, great idea. Papaya anchor already supports that implemented in my own way, but it's very useful to make it a standard. /deposit endpoint needs memo_type and memo parameters to be usable by wallets / exchanges with 1 account for all users. That's the reason why I had to create Papaya anchor in a first place, naobtc doesn't have that. not sure I understood how create_new works, does it create new stellar account? Why then you need trusted notification? it can setup trustlines too. Or does it mean wallet will create new account and anchor must wait for it? I can see how /trusted endpoint is useful regardless of create_new parameter. /federation endpoint might need an extra field too dest_extra for currencies like Ripple (destination tag), Monero (payment id) or some other public stellar network (memo) /federation endpoint could also return eta ? I'll think if I can come up with something else

I think it would be easier if this workflow required that a trustline was already established: Remove the create_new option from /deposit If the account sent to /deposit doesn't have a trustline to the anchor return an error I think this would also let you remove the /trusted endpoint since once the user adds the trustline it'll appear as a transaction on the network and both the wallet and anchor can verify that it exists This would make it the responsibility of the wallet (or whatever's calling this API) to ensure that trustlines are established, the account has the correct minimum balance, etc. I think that would be the right place to do it since the wallet most likely also has a UI to manage trust lines.

zcc I like the simplicity of that, apay currently does it for BTC, BCH and LTC, but for Ethereum we don't because the same address is used for all ERC20 tokens, we don't know what asset we're going to receive before we receive it. Of course separate Ethereum addresses could be used for each token, but it has some downsides too. Apart from that I guess Jed's use case implies that Stellar account is only created when currency has been received. Wallet can't create accounts for everyone and set up all trustlines and then they will decide not to deposit anything, it will be a waste of resources.

/deposit endpoint needs memo_type and memo" hmm seems sketchy but I guess it should be added not sure I understood how create_new works, does it create new stellar account? yes I'll add more to the docs. The anchor doesn't have the secret key so it can't create the trust line. I think it would be easier if this workflow required that a trustline Sure that is easier and if the client account already exists it should do this. But a lot of people haven't used stellar and don't have an account. We need to make the process of on boarding them as easy as possible. This is often by trading some of their existing crypto to lumens. This proposal makes it easy for them. I updated the doc

jed I just read your update to the draft and think it could still work transparently to the user: New Stellar user downloads XyzWallet and wants to deposit some BTC XyzWallet generates a new address for the user and makes a call to ExampleAnchor/deposit ExampleAnchor sees that this is a new account, so it adds some extra BTC to fee_fixed since it will have to fund the new account and add enough for the user to establish a trustline. This could be an additional fee_create_account field? User sends the correct amount of BTC to the address returned by how ExampleAnchor confirms the BTC deposit, funds the account with XLM, and credits the account with BTC (minus the fee). If necessary, the BTC balance could be tracked internally until the anchor sees a transaction on the network that adds a trustline to the account. XyzWallet sees that the account is now funded and prompts the user to add the trustline (or does it automatically) At this point, the user has a funded Stellar account with BTC and a trustline to ExampleAnchor

zcc you need lumens to create an account and create a trust line

jed I'm thinking about this from the perspective of an anchor that's issuing a new ICO or running an exchange, so they have an incentive to easily onboard new users to Stellar. They'd also have a decent supply of Lumens since they'd need them to transact on the network anyway. As another concrete example, say Bittrex was an anchor. They could immediately convert the fee they charged in BTC to XLM by exchanging it on their market and then use that to fund the new account. What kind of use cases did you have in mind? I think being able to download a wallet and fund a Stellar account with your existing crypto is a great idea and want to understand how you see it working.

I have some questions: /deposit : Request Why use currency_code parameter name as opposed to asset_code parameter name? This protocol could potentially be used to inform clients who would like to deposit assets other than currency. Why include the create_new parameter at all? The anchor could check if the account exists and act accordingly... Response I think the how parameter should contain all instructions for depositing (not just an address in the case of a cryptocurrency). This way, the client application could just display the message to the user and it would be the user's job to follow the instructions outlined (i.e. sent BTC to some address). /trusted Why have this endpoint? The anchor is already listening to the network for withdrawals of its asset, it could just listen for trustlines as well and act accordingly (i.e. send the remaining asset to the newly created account).

yeah I'll switch to asset_code the client might not want them to create the new account. But yeah maybe not worth the complexity. the /trusted is there since it will be annoying for the anchor to have to monitor for trustlines. Seems better to just make the client tell it.

Anchor/Client interoperability

zain

We may need to expand how into: deposit_address and an optional deposit_identifier, because currencies like Monero require a transaction ID to figure out who it came from.

Also, I think we should change the following from suggested, to stipulating it:

"It is suggested that the anchor take some of the asset that is sent in to pay for these lumens. " becomes "The anchor should take some of the asset that is sent in to pay for these lumens. "

istrau2

@zain @jed That is why I suggested not restricting the how field on the /deposit response. Instead, the anchor should just state in words how the currency should be deposited. In any case, 99% of client applications that are requesting this information are not going to be doing anything with it (other than displaying it to the user). What is a use case where the client application hits the /deposit endpoint and then actually performs the deposit?

umbrel

istrau2 Why have this endpoint? The anchor is already listening to the network for withdrawals of its asset, it could just listen for trustlines as well and act accordingly (i.e. send the remaining asset to the newly created account).

I think this is a very good point. I am for simplicity.
It's not much harder for anchor to listen to these events, and I assume there will be more clients than anchors, so it must be easy for them to get started

istrau2 What is a use case where the client application hits the /deposit endpoint and then actually performs the deposit?

It could be Stellar aware online/mobile wallet. You just click send, and it takes care of getting an address for you and depositing funds.

zain

I guess extra_info may accomplish getting extra identifiers for currencies like Monero which require a transaction ID to assess where it came from.

jed

umbrel: you are running an anchor, so you don't mind just listening for when accounts trust you?

re: how it is just a string so if you need to put more stuff in it than you can. There is also this extra_info object that you can put stuff in.

istrau2: Ideally you could make a "deposit" tab in your wallet that would display the deposit addresses of other currencies like polo or kraken have. Check out the deposit tab here: http://wallet.stellar.chat/

umbrel

jed I don't mind, in fact even if there is an endpoint I will be listening anyway just for cases when client failed to call it. Anything to minimize potential support queries.

istrau2

@umbrel After thinking about it, I decided that eliminating the /trust endpoint actually doesn't really make things easier for the client. I mean, regardless, the client needs to:
1) hit the anchor's /deposit endpoint
2) deposit the asset in the real world
3) add the trustline for the anchor's asset
the only difference is that the client needs to add a step 4) hit the anchor's /trusted endpoint after the trustline has successfully been added, not very difficult. I mean, it simply means sending out one extra network request. As a developer who plans on making use of this protocol, I don't think its much of an issue at all.

@jed Yes, I would like to. In fact onboarding is my next big todo item for lupoex. This includes:
1) A proper landing page including video tutorials etc.
2) A smooth account creation/deposit process (i.e. generate a sellar address and deposit any asset a user would like to create the account on the network all in one smooth process)
3) Expanded/Updated docs
In fact, I have been waiting for this kind of thread for a while (I was thinking of starting something like this myself minus the actual proposal). Putting this kind of protocol in place is the only way to properly integrate clients and anchors and provide the users a smooth account creation process.
Once I have the onboarding in place, I think deposit/withdrawal tab will be a natural extension.

jed

Ok I dropped the /trusted endpoint.

jed

https://github.com/stellar/stellar-protocol/pull/67 <- accepting soon unless there are further comments

umbrel

if both fee_fixed and fee_percent are specified how is it supposed to work?
max(fee_fixed, amount*fee_percent) or sum(fee_fixed, amount*fee_percent) ?
These two scenarios are both very common: fee 1%, but no less than 10 USD or fee 0.3% + 0.2 USD

jed

Hmm really there are a lot of ways the fee could be calculated. would be cool to have a fee_formula field but unless there is some standard for that it would be gross to parse on the client side. Example "fee_formula" : "min(A*.01,1)" <- that would be the lower of 1% of the amount or $1.

umbrel

jed i believe it should be max and I agree that formula would be even better, but probably not necessary right now.
My wild guess would be that 80% of cases can be covered by making it sum() by default:
so just state in proposal that it's calculated as total_fee = fee_fixed + amount*fee_percent, since both fee_fixed and fee_percent are optional (default 0), you can have total_fee = 0 or total_fee = fee_fixed (if fee_percent not present) or total_fee = fee_percent * amount (if fee_fixed not present) or both

99% of all cases can be covered by making it possible to choose between sum() and max()
And we can add formula later when we better understand needs and ecosystem supports at least simple options.

istrau2

@umbrel @jed what about:
fee_min - minimum possible fee
fee_max - maximum possible fee
fee_percent - percentage of amount
fee_fixed - starting fee

so formula would be:
Math.min( fee_max || Infinity, Math.max( fee_min || 0, (fee_fixed || 0) + amount * (fee_percent || 0) ) )

umbrel

istrau2 Yup, that actually looks like a proper formula to start with.
I tried to avoid adding more parameters like fee_min and fee_max, but there is no real reason to do that. It looks much more clear that way

liangran

The desktop client support the deposit part since v3.3. You can download it from http://wallet.stellar.chat

I have some other opinion for the withdraw part. The withdraw process is two step flow. 1, get fields from anchor. 2, after user fill the fields, anchor return the amount with a memo or an error message.

SEP-0006 make step 1 from the toml file. But I think we can reuse the federation api. Add some extra fields in the response when type=name. You can check the sample here https://github.com/stellarchat/desktop-client/blob/master/docs/federation.md#step-1-stand-response-with-extra_fields-and-assets

The extra_fields is an array of html controller which could generate a dynamic form like user name with bank account, or a crypto address with a memo. It is dynamic and more flexible than put these thing in toml file.

Step 2 is also easy, add another type 'quote' to federation api. It contains account_id(alipay, eth etc), address, asset_code, asset_issuer, amount and all fields from step 1. Once user fill the form, the client can fire a quote event and get the response from anchor.

If we reuse the federation protocol api, it will be a very flexible and powerful tool for user withdraw their fund. You can take it a sample. The toml file could keep tiny and clean. The withdraw part just tell user which federation address to use. For example, BTC btc_withdrawnaobtc.com, bank bankripplefox.com.

The desktop already implement the enhanced federation protocol, you can try btc_withdrawnaobtc.com and bankripplefox.com in the send menu.

« Previous Page