Setting things up
XRP Ledger accounts
First XRPL interaction
Activate Existing XRPL Account on Test Network
Connecting and Interacting with XRP Ledger: account_info
Interacting with XRP Ledger using JSON-RPC
Error Handling and Best Practices
Basics of XRP and Issued Currency
Signing Payment Transaction
Assignment Solution
Verifying Signature
Submit Transaction Signature To XRP Ledger
Subscription Methods
Subscription Methods To Build Responsive App
Transaction Verification
Balance Detail
Transaction Cost
Measures to Avoid Ledger Spamming
Source And Destination Tags
AccountSet Transaction: Domain, Gravatar
AccountSet Transaction: SetFlag, ClearFlag
Deposit AuthorizationTokens, transactions
Issuing Token on XRPL
Token(IOU): Payment Transaction
Commands To Fetch TrustLine Information
Freeze a TrustLine
Issuer: Transfer Fees
More about TrustLine
Currency Code In Hex Format
Removing a TrustLine
Require authorization FlagLedger features
AccountDelete Transaction
Tickets: Theory
TicketCreate Transaction
Delete Ticket ObjectSetRegularKey
SetRegularKey: The Concept
Assigning RegularKey
Change RegularKey
Remove RegularKey
Blackhole An AccountMultiSigning
MultiSigning: The Concept
Replace SignerListSource And Destination Tags
Intro
Importance and use case of Source and Destination Tags.
Video
Topics covered
- How much reserve the exchanges pay?
- How exchanges attach meaning to destination and source tags.
- For the ledger source and destination tags are just an additional piece of information and it doesn’t hold any meaning.
- What happens if you send payment to an exchange account and forget to include destination tag.
- Making destination tag a required field.
References
- Source and Destination Tags
- AccountSet: RequireDest
Use-case
There are many use cases for Source and Destination tags, and I’ve talked about some of them in the video.
One another use case is for centralised systems(ex: exchanges): Centralised systems usually have 1 (or couple) address and it identifies its users with unique destination tag.
Problem: Now consider a scenario where one of your user wants to send funds to another user within your own system. i.e., Two of your users want to transaction.
In such a case, the transaction payload will have same address in both Account and Destination fields, the transaction(if submitted to network) fails with following error: temREDUNDANT. Clearly you are not supposed to have same address in both Account and Destination fields in a transaction.
Solution: Use source and destination tags.
Since the transactions will be happening with in your own centralised system, you can just check if both Account and Destination is same(and that the address belongs to you), then look up the source and destination tags in your own database to identify the sender and receiver, and change the balance of them directly in your database, instead of submitting the transaction to the ledger.
← Previous
Avoid Ledger Spamming
Next →
Domain and Gravatar
- Source And Destination Tags
- Intro
- Video
- Topics covered
- References
- Use-case
