Skip to content

Latest commit

 

History

History
322 lines (270 loc) · 14.4 KB

sep-0016.md

File metadata and controls

322 lines (270 loc) · 14.4 KB
Raw

Preamble

SEP: 0016
Title: Account Transfer Permissionless Payment Protocol (atp3)
Author: Jeremy Rubin
Status: Draft
Created: 2018-11-07

Simple Summary

Account Transfer Permissionless Payment Protocol (atp3) is used to make a payment to another party by effectively creating a non-custodial temporary account on their behalf. It can be used in contexts where the recipient does not yet have an account or must take some action in order to finalize their payment.

Abstract

Atp3 introduces an asynchronous protocol which allows senders to trustlessly transfer funds to a recipient. In contrast to other proposals to accomplish this goal, it does not require a core protocol change.

Motivation

Currently, it is impossible to make a payment to a user who does not yet have an account, or has not set up the requisite trust lines. Because setting up a trustlines requires the approval and online-ness of the recipient, this makes it difficult to push payments. Atp3 is a suite of techniques that can be used to address this issue without requiring any core protocol changes.

Atp3 can also be used in the future with Deterministic Accounts (CAP-0007) to great effect.

Atp3 also makes conditional transfers possible, which are demonstrated as a call-option contract.

Specification

The general setup of atp3 is a sender (Sarah) wanting to make a payment to a specific recipient (Robert).

We consider a few cases:

  1. Where Sarah wishes to create an account for Robert
  2. Where Sarah does not wish to create an account for Robert
  3. Where Sarah wishes to impose an additional constraint (e.g., Call Option) on the payment.

In all of the following designs, we discuss trustlines with limits to make it clear how much is expected to show up. However, because limits prevent contracts from proceeding, all should be set to be unlimited. If it is critical for the counterparty to know the size of the trustline (e.g., for a covered option) it may be included as metadata in the MEMO_TEXT field.

The process is described as a list of actions Robert and Sarah must take. Often times, these action may be aggregated into a single transaction in implementation, but aggregation must not change the behavior of the un-aggregated version.

With Deterministic Accounts (a la CAP-0007/CAP-0008)

Case 1: Create Account

In this case, Sarah creates an account for Robert which has 10 FunBucks in it.

  1. Robert has a specified set of signers, {R}. For simplicity, assume all of {R} are EDDSA25519 keys.
  2. Sarah wants to pay Robert 10 FunBucks.
  3. Sarah does a transaction which:
    • creates an deterministic account C with sufficient reserve for the signers {R} and one trust-line.
    • Adds a trustline for 10 FunBucks to account C
    • If Auth is required, Sarah includes an AllowTrust C (Sarah must also get FunBucks Issuer to sign this transaction)
    • Sends 10 FunBucks to C.
    • Adds the signers {R} specified by Robert.
  4. Robert queries horizon for accounts with the signers {R}, and notices C.

Robert then does whatever Robert wants with the account. Notably, Sarah has paid Robert the required reserve for {R} and a trustline. Perhaps Sarah deducts this from the amount of FunBucks paid, from a future transaction, or Robert pays Sarah back at some point in the future if reimbursement is required.

Case 2: No Create Account

In this case, Sarah does not wish to pay reserve for Robert, but wants to transfer custody of 10 FunBucks to Robert (and be guaranteed to have her reserve returned).

  1. Robert has a specified set of signers, {R}. For simplicity, assume all of {R} are EDDSA25519 keys. Robert also specifies an account ID Ra which may or may not exist.
  2. Sarah wants to pay Robert 10 FunBucks.
  3. Sarah checks to see if Ra exists and has a trustline which can receive 10 FunBucks.
  4. If such an account exists, Sarah transfers 10 FunBucks to Robert and finishes.
  5. If such an account did not exist, Sarah continues.
  6. Sarah does a transaction with memo Ra which:
    • creates an deterministic account C with sufficient reserve for 2 signers and one trust-line.
    • Adds a trustline for 10 FunBucks to account C
    • If Auth is required, Sarah includes an AllowTrust C (Sarah must also get FunBucks Issuer to sign this transaction)
    • Sends 10 FunBucks to C.
    • Adds a preauth at sequence 1 that
      • Adds Sarah's key to the account
    • Adds a preauth at sequence 0 that
      • Optionally, pays transaction fees sufficient for the setup from Ra to C
      • Sends 10 FunBucks from C to Ra
      • BumpSequence 0 Ra (to require Robert's signature)
      • Adds Sarah's key to the account
      • Removes the preauth at sequence 1
  7. Robert queries horizon for recent transactions with memo Ra, and notices account C.
  8. Robert derives the preauth transaction (it is deterministic).
  9. Robert ensures that Ra is created and has a trustline that can support FunBucks.
  10. Robert plays the transaction to the network to move the FunBucks to his account. Note he must sign with Ra for it to succeed.
  11. Sarah reclaims the account automatically if Robert succeeded. If he didn't, Sarah uses the next preauth transaction to reclaim.

Sarah may reuse this account for another transfer, or may merge it to reclaim reserve if desired.

Case 3: Covered Option

In this case, Sarah wishes to receive 100 BoringBucks in exchange for 10 FunBucks by time T, or get her 10 FunBucks back.

  1. Robert has a specified set of signers, {R}. For simplicity, assume all of {R} are EDDSA25519 keys.
  2. Sarah does a transaction with memo (Ra, 100) which:
    • creates an deterministic account C with sufficient reserve for 3 signers and one trust-line.
    • Adds a trustline for 10 FunBucks to account C
    • Adds a trustline for unlimited BoringBucks to account C
    • If Auth is required, Sarah includes an AllowTrust C (Sarah must also get FunBucks/BoringBucks Issuer to sign this transaction)
    • Sends 10 FunBucks to C.
    • Adds a preauth at sequence 0 that is valid until time T which:
      • Optionally, pays transaction fees sufficient for the setup from Ra to C
      • Sends 10 FunBucks from C to Ra
      • pays 100 BoringBucks from Ra to C
      • BumpSequence 0 Ra (to require Robert's signature)
      • Adds Sarah's key to the account
      • Removes the other preauth at sequence 0
      • Removes the preauth at sequence 1
    • Adds a preauth at sequence 0 valid after time T which
      • Adds Sarah's key to the account
      • Removes the preauth at sequence 1
    • Adds a preauth at sequence 1 that
      • Adds Sarah's key to the account
  3. Robert queries horizon for recent transactions with memo (Ra, *) and notices account Ra.
  4. Robert derives the preauth transactions (it is deterministic).
  5. Robert ensures that Ra is created and has a trustline that can support FunBucks and has a trustline with 100 BoringBucks.
  6. Robert plays the transaction to the network to move the FunBucks to his account and the BoringBucks out. Note he must sign with Ra for it to succeed.
  7. Sarah reclaims the account automatically if Robert succeeded. If he didn't, Sarah uses the next preauth transaction to reclaim.

If Robert fails any of his constraints, his exercise of the option will fail. His constraints are:

  1. Having an account Ra
  2. Ra having a trustline for 10 FunBucks
  3. Ra having a trustline for at least 100 BoringBucks with at least 100 BoringBucks

Note that because the payment of BoringBucks to C is atomic with the exercise, this prevents Sarah from getting the BoringBucks and Robert not getting the FunBucks.

Without Deterministic Accounts

Case 1: Create Account

In this case, Sarah creates an account for Robert which has 10 FunBucks in it.

  1. Robert has a specified set of signers, {R}. For simplicity, assume all of {R} are EDDSA25519 keys.
  2. Sarah wants to pay Robert 10 FunBucks.
  3. Sarah creates an account C with a random PkC and sufficient reserve for the signers {R} and one trust-line.
  4. Sarah checks that the account was instantiated correctly -- otherwise Sarah adds or removes XLM from the account.
    • This step is required because of non-determinism in account creation.
  5. Sarah does a transaction which adds a trustline for 10 FunBucks to account C.
    • If Auth is required, Sarah must request that FunBucks Issuer AllowTrusts C.
  6. Sarah sends 10 FunBucks to C.
  7. Sarah does a transaction which sets masterWeight=0 and adds the signers {R} specified by Robert.
  8. Robert queries horizon for accounts with the signers {R}, and notices C.

Robert then does whatever Robert wants with the account. Notably, Sarah has paid Robert the required reserve for {R} and a trustline. Perhaps Sarah deducts this from the amount of FunBucks paid, from a future transaction, or Robert pays Sarah back at some point in the future if reimbursement is required.

Case 2: No Create Account

In this case, Sarah does not wish to pay reserve for Robert, but wants to transfer custody of 10 FunBucks to Robert (and be guaranteed to have her reserve returned).

  1. Robert has a specified set of signers, {R}. For simplicity, assume all of {R} are EDDSA25519 keys. Robert also specifies an account ID Ra which may or may not exist.
  2. Sarah wants to pay Robert 10 FunBucks.
  3. Sarah checks to see if Ra exists and has a trustline which can receive 10 FunBucks.
  4. If such an account exists, Sarah transfers 10 FunBucks to Robert and finishes.
  5. If such an account did not exist, Sarah continues.
  6. Sarah creates an account C with a random PkC and sufficient reserve for the signers {R} and one trust-line.
  7. Sarah checks that the account was instantiated correctly -- otherwise Sarah adds or removes XLM from the account.
    • This step is required because of non-determinism in account creation.
  8. Sarah does a transaction which adds a trustline for 10 FunBucks to account C.
    • If Auth is required, Sarah must request that FunBucks Issuer AllowTrusts C.
  9. Sarah sends 10 FunBucks to C.
  10. Sarah does a transaction with memo Ra which sets masterWeight=0 and adds a preauth transaction at the next sequence (n) for C which
    • pays 10 FunBucks to Ra
    • pays transaction fees sufficient for the setup from Ra to C
    • BumpSequence 0 Ra
    • set masterWeight=1
    • removes the next preauth and a preauth transaction at sequence (n+1) which
    • set masterWeight=1
  11. Robert queries horizon for recent transactions with memo Ra, and notices account Ra.
  12. Robert derives the preauth transaction (it is deterministic).
  13. Robert ensures that Ra is created and has a trustline that can support FunBucks.
  14. Robert plays the transaction to the network to move the FunBucks to his account. Note he must sign with Ra for it to succeed.
  15. Sarah reclaims the account automatically if Robert succeeded. If he didn't, Sarah uses the next preauth transaction to reclaim.

Sarah may reuse this account for another transfer, or may merge it to reclaim reserve if desired.

Case 3: Covered Option

In this case, Sarah wishes to receive 100 BoringBucks in exchange for 10 FunBucks by time T, or get her 10 FunBucks back.

  1. Robert has a specified set of signers, {R}. For simplicity, assume all of {R} are EDDSA25519 keys.
  2. Sarah creates an account C with a random PkC and sufficient reserve for the signers {R} and one trust-line.
  3. Sarah checks that the account was instantiated correctly -- otherwise Sarah adds or removes XLM from the account.
    • This step is required because of non-determinism in account creation.
  4. Sarah does a transaction which adds a trustline for 10 FunBucks to account C.
    • If Auth is required, Sarah must request that FunBucks Issuer AllowTrusts C.
  5. Sarah sends 10 FunBucks to C.
  6. Sarah does a transaction which adds a trustline for 100 BoringBucks to account C.
    • If Auth is required, Sarah must request that BoringBucks Issuer AllowTrusts C.
  7. Sarah does a transaction with memo Ra which sets masterWeight=0 and adds a preauth transaction at the next sequence (n) valid until time T for C which
    • pays 10 FunBucks to Ra
    • pays 100 BoringBucks from Ra to C
    • pays transaction fees sufficient for the setup from Ra to C (if required by Sarah)
    • set masterWeight=1
    • removes the other preauths and a preauth transaction at sequence (n+1) which
    • set masterWeight=1 and a preauth transactions at sequence (n), valid after time T which
    • set masterWeight=1
    • removes next preauth
  8. Robert queries horizon for recent transactions with memo Ra, and notices account Ra.
  9. Robert derives the preauth transaction (it is deterministic).
  10. Robert ensures that Ra is created and has a trustline that can support FunBucks and has a trustline with 100 BoringBucks.
  11. Robert plays the transaction to the network to move the FunBucks to his account and the BoringBucks out. Note he must sign with Ra for it to succeed.
  12. Sarah reclaims the account automatically if Robert succeeded. If he didn't, Sarah uses the next preauth transaction to reclaim.

If Robert fails any of his constraints, his exercise of the option will fail. His constraints are:

  1. Having an account Ra
  2. Ra having a trustline for 10 FunBucks
  3. Ra having a trustline for 100 BoringBucks with 100 BoringBucks

Note that because the payment of BoringBucks to C is atomic with the exercise, this prevents Sarah from getting the BoringBucks and Robert not getting the FunBucks.

Rationale

The atp3 design is proposed as an alternative to the Balance's proposal offered by Jed McCaleb on the Stellar-Dev mailing list on October 24th, 2018 and in issue 188.

In contrast to 188, atp3 does not require any changes to the core consensus protocol. This ensures that it is fully backwards and forwards compatible and does not break or change any existing behavior.

It is also a more flexible foundation for future protocols as it supports new contracts like covered options.

If a proposal similar to CAP-7 is finalized, a atp3 like protocol can be made much more efficient as the steps Sarah has to take could be collapsed into a single step. Furthermore, with CAP-7, O(n) outbound payments from Sarah could be confirmed in a single transaction of constant size, and redeemed later. This type of 'multicast payment' is very useful for large scale issuers.

Backwards Compatibility

This is fully backwards compatible with Core.

Horizon must support two new types of query (query by signer and query by memo).

Implementation

No implementation.