3

Because we are exchange we use main account and we generate Id number as a memo that we send to the customer so we will know the transaction was from him. we want to force the customer to add the memo , so if he does not add it the transaction will fail. Is there a way to do it?

5
  • In ripple we can use the destination tag as a required before making the transacion. Can we do the same for stellar ? As we found that stellar destination tag is the memo ID. Jan 24, 2019 at 10:05
  • If you are using main account in exchange, Then exchange must send transaction on behalf of user by asking the usedId to whom user wants to send asset. So there is no way to validate memo in a transaction. Jan 26, 2019 at 11:46
  • Ohh, so that means that this is something that the exchange must do as a middleware right? Jan 27, 2019 at 7:55
  • 1
    Exacly, A user (front-end) makes a REST api call to your exchange by sending userId and then exchange must create transaction with memo as userId sent from REST api call and send this transaction to Horizon. Jan 27, 2019 at 8:03
  • Thanks a lot! I thought it should works like ripple with the destination tag which can be forced. Jan 27, 2019 at 8:06

2 Answers 2

1

You can use a Federation server to do most of what you're asking.

If you have user user_1 and your app is hosted at a site called my-site.com, then you can host your own federated server to work a little like a DNS server whereby the exchange can call the resolveAddress method to get the address for that persons account.

So, by calling resolveAddress('user_1*my-site.com'), the exchange can expect to get a response along the lines of:

{
  "stellar_address": "user_1*my-site.com",
  "account_id": "GAIGZHHWK3REZQPLQX5DNUN4A32CSEONTU6CMDBO7GDWLPSXZDSYA4BU",
  "memo_type": "text",
  "memo": "user_1"
}

Here the account_id can be a shared custodial account or a unique account for that user. By setting the memo we can, of course, tell who the transaction was by/for.

Note: The federation server is a very simple protocol, so you can easily send a dynamic response where the memo field is a generated token.

Take for example this response:

{
  "stellar_address": "user_1*my-site.com",
  "account_id": "GAIGZHHWK3REZQPLQX5DNUN4A32CSEONTU6CMDBO7GDWLPSXZDSYA4BU",
  "memo_type": "text",
  "memo": "ABC123XYZ"
}

This second method allows you to hide the identity of the user on the ledger, as the only identifiable thing that will be recorded is ABC123XYZ. Only your systems, and the exchange performing the transaction will know the identity of the user.

The only caveat is that someone can still send a trusted asset to your account_id with a random memo, or no memo at all. I don't believe you can prevent that.

0

Method using SEP-0007 to build a payment request using either Operation TX or Operation PAY.

I have used the Operation PAY method to build a URI with a randomly generated MEMO_ID included in the URI: web+stellar:pay?destination=<DESTINATION_ADDR>&amount=[AMOUNT_CURR]&memo=<CUSTOM_MEMO_ID>

This has the added benefit of forcing the use of MEMO_ID and functionality of paying wherever the customer feels most comfortable signing a transaction; the URI can be packaged into a QR-Code or create a link that should be read by a wallet that recognizes it (for example, Keybase on phone and/or PC).

Operation TX has more functionality by allowing a Transaction Envelope to be attached to the URI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.