Stellar Docs are great, but I feel they miss the content for bringing all the servers together.

If an entity is acting as a custodian on behalf of their users and uses a Hot/Cold wallet architecture to manage funds. What is the best way for this entity to allow payments to its users?

The current architecture I envision would include the entity using a federation and bridge server with its internal SQL Tables. They entity would make public the format for friendly IDs (phone number, fist_last), would then receive federation requests at something like "https://www.entity_org.com:8002/federation?q=friendly_id*entity_org.com". This request would return a JSON payload with the UUID of the user in the internal user table of the entity.

The payer would then send a payment to the entity's public key and include the UUID in the memo field.

Is this a proper architecture? Feedback is strongly welcomed.

2 Answers 2


The Federation server would return some value with the memo field that can be used by the service provider (you) to uniquely identify the receiving user. A database ID does match this requirement but you can use anything else that makes sense in your domain as long as it's unique (also in the future).

The bridge server does also help to participate with the compliance protocol when you want/ need to apply Anti Money Laundry rules before you receive a payment. Another important part is the "Know Your Customer" section that is handled by the bridge server when you need to know where the transfer comes from. (Works in the other direction as well, when you do the transfer).

When you only want to do the lookup part to resolve to an address, key derivation may be a good option as well. Then you don't need to rely on the memo field filled proper by the sender (or his wallet).


For just federation -- no compliance -- the above sounds correct. As outlined in the docs, which you mentioned you have read through, this is easily done via Stellar's prebuilt federation server which can hook into an existing database. Once it is connected, it

essentially translates a federation request into a SQL query. The server supports MySQL, PostgreSQL, and SQLite3.

To establish this connection, and ensure proper configuration, define a federation.cfg. There is an example of one here.

Note: for this service to be discoverable, you will need to update your Stellar.TOML with:

FEDERATION_SERVER = "https://www.your_org.com:8002/federation"

Once this is all setup, you would do exactly as you describe above to request info about a federated account. See here for all the supported federation endpoints.

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.