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:

  1. Remove the create_new option from /deposit
  2. If the account sent to /deposit doesn't have a trustline to the anchor return an error
  3. 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:

      1. New Stellar user downloads XyzWallet and wants to deposit some BTC
      2. XyzWallet generates a new address for the user and makes a call to ExampleAnchor/deposit
      3. 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?
      4. User sends the correct amount of BTC to the address returned by how
      5. 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.
      6. 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.

          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. "

          @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?

            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.

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

            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 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 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.

              Ok I dropped the /trusted endpoint.

              12 days later

              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