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?
2 Answers
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.
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.
usedId
to whom user wants to sendasset
. So there is no way to validatememo
in a transaction.exchange
by sendinguserId
and thenexchange
must create transaction withmemo
asuserId
sent from REST api call and send this transaction toHorizon
.