Allow sending account to add trustline on receiving account

[tomquisel]

Currently, sending an airdrop or funding a new Stellar account with a non-XLM token is a messy, multistep process for both sender and receiver. Issuer and user experience can be improved by adding some mechanism for a sending account to add a trustline on a receiving account.

Deposit & Sending Requirements

Deposit with asset issuer (mandatory)

An issuer should be able to completely process a user’s deposit of an external asset without needing to wait on the user to take an intermediate step, such as adding a trustline.

An illustrative SEP-6 deposit flow (crypto asset example):

1. User wants to deposit an external crypto asset with an Issuer and receive the Issuer’s anchored asset on the Stellar network.
2. User makes a SEP-6 deposit request to the Issuer via the user’s Stellar wallet, communicating their Stellar account id (A) to the Issuer.
3. Issuer asks for any information they need (KYC info, bank acct, etc…).
4. User provides needed information.
5. Issuer sends deposit address to user.
6. The user sends their external crypto asset to the deposit address to initiate the deposit.
7. When the Issuer receives the external asset, they send a Stellar payment of the same amount (minus fees) to the user’s Stellar account, completing the deposit.

The Requirements

• When initiating a deposit, the user must not need to sign any transactions.
• The Issuer must not need to wait on any user action to complete the deposit, once the user has sent the external crypto asset to the Issuer. The single exception to this is if the user does not need any XLM to take the action and the information that the transaction has completed (on the issuer side) is present on the chain.
• The deposit must arrive at the user’s original account id A. Only at this point is the deposit complete.
• The user must not have to add extra XLM from some external source to their account to complete the deposit.
• The deposit process must complete successfully even in the case where the user spends XLM for some other purpose as soon as it hits their account.
• The deposit process must complete successfully even if the user’s account is not yet created, or if the user has no trustline for the deposit asset.

[tomerweller]

With the current base reserve model, it will allow you to force fees on other accounts. This should probably come with some form of trust-line sponsorship model or a complete revamp of storage fees.

Regarding airdrops, one possible solution is to setup a new account per drop along with the relevant trustline, and then transfer ownership using multisig. Essentially dropping an account on a signer rather than dropping an asset on an account. However, this requires more ecosystem support for multiple accounts per signer.

[antb123]

The issue is most clients who pay with ether or BTC do not have a stellar account. We were just going to send the private key via lockbin and phone call and or text (depending on purchase value) to provide the password/key.

…

On Sat., 6 Oct. 2018, 02:13 tomerweller, ***@***.***> wrote: With the current base reserve model, it will allow you to force fees on other accounts. This should probably come with some form of trust-line sponsorship model or a complete revamp of storage fees. Regarding airdrops, one possible solution is to setup a new account per drop along with the relevant trustline, and then transfer ownership using multisig. Essentially dropping an account on a signer rather than dropping an asset on an account. However, this requires more ecosystem support for multiple accounts per signer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQZFzjuPwUhuwNYEXvSy1sCrIvzy4Z6Yks5uh_XBgaJpZM4XK27B> .

[tomquisel]

@danrobinson has suggested this to achieve sender-created trustlines:

The Idea

Add a new operation that just adds a trustline to the destination account, and also moves minreserve from the source to the destination account.

If you want to send an asset to someone that doesn't have a trustline, the transaction will include one of those operations, as well as the send of the actual asset.

If the receiver actually does have the trustline, the new operation succeeds and does nothing.

The Question

Is there any point to recording whether each trustline was created via this new operation?

It may be useful to know if an account holder has consented to a particular asset they hold for compliance reasons, but I'm not sure if there's a real use case there. Thoughts?

[danrobinson]

It may be useful to know if an account holder has consented to a particular asset they hold for compliance reasons, but I'm not sure if there's a real use case there. Thoughts?

Good question—I don't really think it needs to, unless we think of a reason to treat them differently in the protocol. Presumably if you really needed to find this out for off-chain reasons, you could look at the ledger history.

I do think this change would push the already-stretched term "trustline" past its reasonable limits. See this language from the documentation:

When you hold an asset, you must trust the issuer to properly redeem its credit. Since users of Stellar will not want to trust just any issuer, accounts must explicitly trust an issuing account before they’re able to hold the issuer’s credit. In the example above, you must explicitly trust Scott before you can hold orange credits.

Since Stellar uses offers rather than trustlines for path payments, this notion seems outdated already, and allowing anyone to add a trustline for you would deal the killing blow.

With that in mind:

1. Is there any reason to keep the "Limit" field on trustlines? (We technically could retain a little meaning for this by preventing anyone else from raising your trustline's limit, but what's the real point of having that limit at all, particularly if anyone would be able to set an infinite limit for you to start?)
2. This seems like a pretty far-reaching change, but maybe we should rename "Trustlines" to "Balances", and essentially merge those two concepts in the account state?

[istrau2]

As I wrote in the google group, I think this issue is most elegantly solved by making the account sequence deterministic (perhaps starting at 1). This allows the presigning of a an change_trust operation prior to funding the account.

[skirsch]

@tomquisel @danrobinson @tomerweller As a provider of USD asset, I'm definitely a fan of @tomquisel 's approach. If it causes grief, you could add a account flag to accept/reject unsolicited trustlines. That keeps the notion of trustline alive. You could also have a third state like "ask me on unsolicited trustlines" but that's much more complicated to implement so I think having the two options should make everyone happy. Default value is accept. And if it gets abused, you can simply bump the XLM fee needed to send out an unsolicited trustline. So if the fee is bumped 5 XLM, the account still only receives enough XLM to establish the trustline... the remaining XLM is absorbed as a fee for he transaction. How about that?

[theaeolianmachine]

As an update on the efforts here: last year CAP-0013 and SEP-0016 were proposed, and we're currently coming up with additional requirements and analysis to move this forward.

Making a clean solution that's low-risk for attacks, respects explicit trust, and is a simple workflow is a challenging and nuanced problem, and we hope to have more updates here soon.

[skirsch]

@theaeolianmachine CAP-0013 is way better than SEP-0016. My only concern is on moving balances. As an issuer, I need to freeze an account if required to. Therefore this totally defeats my ability to do that (from the description): "This (unlike ChangeTrust) allows an account to successfully remove a balance even if the issuer has frozen it" Or am I reading this wrong?

[theaeolianmachine]

For sure; I think most of us prefer the workflow of CAP-0013, but enough concerns have been raised that we're actually going back to the drawing board (I placed our current list of requirements in the first comment), and CAP-0013 as it currently exists is unlikely to be implemented. If you have any feedback on the requirements, I'm all ears.

[jonjove]

Addressed by CAP-0023 and CAP-0033

[oriana13]

Hello @tomquisel,
May I ask you for your solution regarding the trust line? Because currently I have the same problem: I want to create a function that sends an NFT, the only problem is that the recipient does not have a trust line and when I create it in my function, I do not have the secret key of the recipient who must sign ...