A worked example for XRPL Education Month
Payments and memos: a worked example.
Imagine a small service that takes a payment on the XRP Ledger. What would happen? This page follows one made-up payment from start to finish, so you can see what a memo is, what belongs in it, and what never should. It is an example, not an offer of anything.
One payment, a short note, and a lot of privacy.
Here is what would happen if a service took a payment on the XRP Ledger. The sender signs a Payment transaction from their wallet. The transaction carries a short reference number in its memo, so the service can match the payment to its own records. It never carries personal details. Once the ledger validates the payment, both sides can look it up by its hash.
Everything below is hypothetical. No real service or sign-up is involved, and nothing on this page takes a payment.
This is education, not financial advice. There are no price calls, and no investment talk.
A wallet signs the payment.
A payment starts in the sender's wallet. The wallet holds the secret key, and only the wallet can sign. For practice, people use a testnet wallet, because testnet XRP has no value.
- 1
The service shows its XRPL address and the amount it expects. In our example that is a made-up address and a made-up amount.
- 2
The sender opens a wallet app, checks the address and amount, and signs. The service never holds the sender's secret key, and no website needs it.
- 3
Never share a wallet seed or secret key with anyone, for any reason. A real wallet app will not ask a website for it.
The memo only gets a short reference number.
A memo is a short note attached to a transaction. It is public, and it is permanent. So in our example the memo holds one thing: a short reference number, like REF-184592, that the service can match to its own records later.
That is all that belongs there. Not a name. Not an email address. Not a birth date, birth time, or birth place. Memos are public and permanent, even on testnet.
A hard rule: never put a birth date, a birth time, a birth place, a name, or any other personal detail in a ledger memo, or in raw NFT metadata. Anything written to a ledger is public and permanent.
A destination tag sorts payments at one address.
A destination tag is an optional number on a Payment. A service that receives many payments at one address can use it to tell which payment is for what. It is only a number, so it should never be built from personal details.
- 1
Some accounts can be set to require a destination tag, so a payment without one is rejected. That protects people from forgetting it.
- 2
A tag and a memo do different jobs. The tag is a plain number in its own field. The memo is a free-form note.
- 3
Both are visible to anyone reading the ledger. A tag or memo is a label, not a secret.
Personal details stay off the ledger.
If a service ever needs details about a person, those details belong somewhere private, never on the ledger. They never go in a transaction, in a memo, or in NFT metadata.
- 1
A practice natal chart NFT only uses Sun and Moon signs, or a signs-only chart link. Raw birth date, time, and place are never written into the NFT metadata.
- 2
If a birth time is not being used, the chart can be labeled "time unknown." Planet signs can still be shown. Signs are public and can hint at a birth window, so only use signs you are comfortable sharing. Houses and the Ascendant are left off, and the Moon sign may be approximate.
- 3
You can preview a signs-only chart on the signs-only chart tool or the testnet viewer.
Validated means final.
When enough trusted validators agree on the ledger page that holds the payment, the transaction is validated. At that point the service can look it up by its hash, read the reference number, and match it to its own records. The ledger only records that the payment happened. It does not know or care what the payment was for.
Then comes the natal chart NFT.
As another example, an issuer can mint an NFT and create a 0 XRP offer to a wallet. The next lesson walks a real testnet offer, field by field.