specifications/transactions/README.md
The Diem Payment network supports transactions between VASPs (Virtual Asset Service Providers) and between VASPs and DDs (Designated Dealers). This document covers the end-to-end flow for these transactions derived from the DIPs.
Diem supports two methods for transacting on-chain:
In the case of subaddresses, a participant can directly provide a subaddress to one or more other participants, who can then submit transactions directly to that party on-chain. However, re-use of subaddresses creates on-chain linkage across transactions that may constitute publicly identifiable material. To address this, participants can also leverage the Off-Chain Protocol to produce a one-time use reference id for the on-chain payment. The Off-Chain Protocol also provides functionality for dual attestation of KYC (Know Your Customer) exchange per Diem's Travel Rule requirements.
A Diem transaction consists of a sender, a script or script function, and a set of arguments. Currency transfer transaction arguments include a recipient, an amount, a currency, and metadata. Diem leverages the metadata to provide context behind a transaction. The metadata itself is not validated by the Diem blockchain or Move standard library.
When a transaction is submitted to the blockchain it is evaluated many times both at the general transaction layer as well as at the peer-to-peer settlement layer. Successfully executed transaction are committed to the blockchain and debit the sender's account by the specified amount in addition to gas (network usage) costs and credit the recipient's account. Transactions that fail any general transaction layer validations are discarded as early as possible. Transactions that pass these validations but fail during execution, for example, the sending account has insufficient funds for the transfer, will be committed to the blockchain as an aborted transaction. Aborted transactions still charge the sending account gas fees.
Users do not have direct ability to send and receive payments on the Diem network and must do so through VASPs. One method to do so, is to store potentially personally identifiable information in a transaction metadata, Diem also supports an off-chain framework that can negotiate one-time use transaction identifiers called reference_ids. The off-chain framework is also used by support travel rule compliance.
Diem defines refunds as part of the transaction framework. The refund includes a pointer to the transaction that is being refunded and the reason for the refund, for example, an errant transaction to a non-existent destination as well as user-driven refunds. However, use of the refund type is optional.
Bob would like to send Alice 10 XUS:
In the case that Bob would send Alice an amount that exceeds the travel rule limit, the flow changes:
reference_id and Alice's VASP would have provided a signature for the transaction metadata that Bob's VASP will submit to the chainreference_id instead of the subaddressesThere are two cases for refunds, those initiated by the recipient and those that have no valid recipient. In practice, those initiated by a recipient can be sent back as a transfer to the originating VASP and subaddress. Diem also provides for native refunds that contain a reason for the refund, so that VASPs need not speculate or confer off-chain on the reason why funds were returned, e.g., a purchase refund or an invalid subaddress.
The rest of this specification contains the following components: