I would like to create an asset that can be traded for particular asset(s) only so I decided to take approach where I use a single account to manage customer balances by using federation server and memo, one of the two ways suggested in Stellar guide documents:

Use federation and the memo field in transactions to send and receive payments on behalf of your customers. In this approach, transactions intended for your customers are all made using your base account. The memo field of the transaction is used to identify the actual customer a payment is intended for.

Latter on in the same guide are explained flows for performing payments (send/receive) on behalf of customers but there is no exact explanation of how is memo field used to manage this payments. Should we use single memo for every customer and map publicKey > amount? What events should we listen for and how should we react on them?

Are there any guides out there? I have failed to find any.

  • Just a quick comment: memos are application specific, that's why there's no explanation on how to use them -- It's up to you and your app. Commented Dec 6, 2018 at 10:31
  • It clearly is general purpose field. But, if you look at the quoted text, they clearly state the it should be used for single specific purpose in this case. Commented Dec 7, 2018 at 13:04
  • It's still just a suggestion. For that use-case, I've seen people either use the memo for giving each user a unique memo, or for giving each transaction a unique memo. The latter being more private, since you can't correlate deposits sent to the same user from multiple addresses. Commented Dec 8, 2018 at 2:39

1 Answer 1


We implemented federated accounts for our users as follows:

  • All our users have one or more account codes that they can use together with our domain name to form a federated address of the form accountcode*inbot.io
  • We have implemented a federation endpoint in our API that responds with the appropriate stellar address and memo in response to a query for a federated address.
  • We have set up a compliance endpoint as well that allows people to check whether we will be able to process their transaction before they send it. We only accept our own InToken for our users and only for users that we have cleared for aml/kyc. Using this API is optional for users but it helps them prevent sending us wrong transactions.
  • The federation and compliance endpoints are advertised in our stellar.toml on our website. So people can figure out from just the federated address what endpoints to call.
  • We regularly check the stellar accounts for new payments that we have not yet processed and look up the correct user using the account code in the memo field.
  • Any incoming payments that we can't find a valid user for are simply added to special internal account so we can take appropriate action. We don't have automated refunds currently but we might add that in the future if there's a need.

If you are going to do this, ignore the demo servers advertised on stellar.org. They are nice as a demo but useless for product development. Most of their documentation is about how to configure them instead of how they actually work. Once you dive into that, you'll likely come to the same conclusion as me and others I've talked to: it's a greenfield project with its own databases and a bunch of implementation choices that may or may not be something you are comfortable with and that has no integration points with whatever else you are running. Fixing that has the same or larger complexity as merely implementing two very straightforward endpoints in your own API.

  • A bit off-topic question, can the asset managed this way be listed on some of exchanges or used by some wallets listed on stellar website? Did some kind of protocol emerged from this approach up till now? Commented Dec 13, 2018 at 16:53
  • 1
    We are listed on stellarx and a few other Stellar exchanges. StellarX is pretty easy if you meet their minimum requirements regarding liquidity and trust lines. They do have a policy of unlisting things that violate their terms of use (e.g. scam tokens). Commented Dec 13, 2018 at 20:18
  • It's me again! I really find it hard to wrap my head around this :/ I kind of guess how users by your tokens, they send, let's say, XLM to one of your addresses and than you assign respective amount of your tokens in your database, or not? How do you manage sending your tokens between two users? Some API call with prof that the user really owns the sending address? Probably not :) Commented Dec 27, 2018 at 17:52

Your Answer

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

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