Skip to content

Latest commit

 

History

History
57 lines (41 loc) · 3.72 KB

cap-0029.md

File metadata and controls

57 lines (41 loc) · 3.72 KB

Preamble

CAP: 0029
Title: AllowTrust when not AUTH_REQUIRED
Working Group:
    Owner: Tomer Weller <@tomerweller>
    Authors: Tomer Weller <@tomerweller>
    Consulted: Nicolas Barry <@MonsieurNicolas>, Jon Jove <@jonjove>, Eric Saunders <@ire-and-curses>, Leigh McCulloch <@leighmcculloch>
Status: Final
Created: 2019-12-13
Discussion: https://groups.google.com/d/msg/stellar-dev/igkJhpPUm-g/7k_3v6SKBQAJ
Protocol version: 16

Simple Summary

This CAP addresses the following authorization semantics requirements:

  • An issuer should always be able to authorize a trustline regardless of any issuer flags.
  • An issuer should always be able to revoke a trustline for an asset that is set as revocable.

Working Group

This protocol change was authored by Tomer Weller, with input from the consulted individuals mentioned at the top of this document.

Motivation

Trustline authorization is an important feature of the Stellar protocol. It allows issuers to handle various regulatory requirements. However, it's current behavior is not sensible with regards to configuration changes and revocable assets:

  • The authorize (ALLOW_TRUST, Authorize=AUTHORIZED_FLAG) operation fails if the issuer does not have any flags set, even when the trustline is unauthorized. This complicates asset configuration changes.
  • The revoke (ALLOW_TRUST, Authorize=0 or ALLOW_TRUST, Authorize=AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG when AUTHORIZED_FLAG is set) operation fails if the issuer does not have the AUTH_REQUIRED flag set. This defeats the purpose of having revocable assets that default to authorized trustlines ("Blacklist authorization").

Goals Alignment

This CAP is aligned with the following Stellar Network Goals:

  • The Stellar Network should make it easy for developers of Stellar projects to create highly usable products

Specification

This CAP introduces two changes to ALLOW_TRUST semantics:

  • Allow ALLOW_TRUST operations that upgrade authorization (Authorize=AUTHORIZED_FLAG or Authorize=AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG when the trustline is unauthorized) to be performed regardless of any issuer account flags.
  • Allow ALLOW_TRUST revoke (ALLOW_TRUST, Authorize=0 or ALLOW_TRUST, Authorize=AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG when AUTHORIZED_FLAG is set) operations to be performed on trustlines to assets that have the AUTH_REVOCABLE flag set, regardless of whether or not their AUTH_REQUIRED flag is set.

Backwards Incompatibilities

This change is backward compatible for sensible consumers. It is not backward compatible for consumers that rely on the above operations failing and returning the ALLOW_TRUST_TRUST_NOT_REQUIRED result code.

Design Rationale

CAP-0035 introduces the SET_TRUST_LINE_FLAGS operation, which provides a better way to interface with the trustline flags. This operation will allow the authorization transitions specified in this CAP that currently return ALLOW_TRUST_TRUST_NOT_REQUIRED. While we could just leave ALLOW_TRUST the way it is and use SET_TRUST_LINE_FLAGS to get the desired behavior, making sure the possible authorization transitions are the same between operations would make it easier for the ecosystem to continue using ALLOW_TRUST. They can choose which operation to use, instead of being forced to switch. Keeping the logic the same will also make it easier for everyone to reason about the possible authorization transitions.

Security Concerns

There are no security concerns here. This CAP just allows the issuer to perform more sensible authorization transitions for trustlines.

Test Cases

//TBD

Implementation

stellar/stellar-core#2988