Skip to content
Permalink
master
Switch branches/tags
Go to file
 
 
Cannot retrieve contributors at this time

Preamble

SEP: 0029
Title: Account Memo Requirements
Author: OrbitLens, Tomer Weller, Leigh McCulloch, David Mazières
Status: Active
Created: 2019-12-27
Updated: 2020-05-04
Version: 0.5.0

Simple Summary

This SEP describes a standard way to define transaction memo requirements for incoming payments.

Motivation

Custodial wallets often use a single Stellar account for all deposits/withdrawals, relying on the transaction memo to disambiguate incoming payments. Users frequently forget to fill in a memo in their deposit transactions. Dealing with missing memos may result in lost funds and requires manual actions from the custodial support staff.

We introduce a basic convention that allows defining memo requirements at the account level.

Although this interoperability standard aims to deal with a missing memo problem in the first place, it can also be utilized by a wider class of Stellar-based applications to designate additional interaction or prerequisites.

Abstract

An account owner configures memo requirements by adding a data entry that specifies whether a transaction memo is required when transferring funds to the account. A payment sender ensures that a memo is attached before submitting the transaction to the network.

Specification

To set up memo prerequisites for an account, the owner submits a transaction with a MANAGE_DATA operation that adds a data entry with the name config.memo_required (in lower case following SEP-18 notation) and value 1 (a single character string "1" - ASCII code 49 or Unicode U+0031).

When a payment sender submits a transaction containing a PAYMENT, PATH_PAYMENT_STRICT_SEND, PATH_PAYMENT_STRICT_RECEIVE, or MERGE_ACCOUNT operation to a destination account which is not a multiplexed account they:

  • Load details about the destination account.
  • Check if the destination account has the config.memo_required data entry set. If so:
    • Verify that the transaction memo field is set.
    • If memo is not set, show a notification and prevent the transaction from submission.
  • For transactions containing more than one operation, perform the same checks for each operation.

Rationale

The proposal First-class multiplexed accounts (CAP-27) is a more advanced and comprehensive solution for the problem described above, but its adoption by the whole ecosystem and custodial exchanges will require much more time, as well as development efforts. Specifying memo requirements in the form of a data entry attached to an account introduces a simple way of enforcing transaction memo requirements without changing the underlying protocol.

The name of the data entry follows the namespaces format proposed in SEP-18.

Memo type verification routines are intentionally omitted from this SEP in favor of a separate standard with extended definition of more granular memo constraints via separate data entries in the future, if such need arises. For example, config.memo_required_type for memo type validation.

Security Concerns

N/A

Implementations