CAP: 0030
Title: Remove NO_ISSUER Operation Results
Author: Siddharth Suresh
Status: Final
Created: 2020-01-14
Discussion: https://github.com/stellar/stellar-protocol/issues/497
Protocol version: 13
There are operations that unnecessarily load the issuer, and return an error result if the issuer of an asset was not found. These errors are not necessary, and this proposal aims to remove them.
The following operation results indicate that an operation failed because the issuer of an asset does not exist: PAYMENT_NO_ISSUER, PATH_PAYMENT_STRICT_RECEIVE_NO_ISSUER, PATH_PAYMENT_STRICT_SEND_NO_ISSUER, MANAGE_SELL_OFFER_SELL_NO_ISSUER, MANAGE_SELL_OFFER_BUY_NO_ISSUER, MANAGE_BUY_OFFER_SELL_NO_ISSUER, MANAGE_BUY_OFFER_BUY_NO_ISSUER, and CHANGE_TRUST_NO_ISSUER. Each of the operations that can produce these results other than ChangeTrustOp does not otherwise depend on the existence of the issuer. The issuer is only required when creating a trustline with ChangeTrustOp. Removing the issuer check from all other operations will standardize the protocol on not requiring the issuer outside of this one case.
Removing the issuer from the operations that produce the *_NO_ISSUER results will also prevent stellar-core developers from using the AUTH_REQUIRED flag incorrectly. If AUTH_REQUIRED is not set on the issuer, then the TrustLine will be authorized on it's creation. The name AUTH_REQUIRED, however, implies that the flag determines if authorization should be checked, which is not the actual logic.
This proposal will also make the CAP-0023 (Two-Part Payments) implementation simpler because we won't need to return the *_NO_ISSUER results there to maintain consistency.
The Stellar Network should facilitate simplicity and interoperability with other protocols and networks.
For every operation that can return a *_NO_ISSUER result except ChangeTrustOp, don't load the issuer or return the *_NO_ISSUER result.
The *_NO_ISSUER results will no longer be returned for the affected operations, so anyone relying on these results will need to modify their behavior. These error results aren't meaningful anyways because anyone can create the issuer account to bypass the issuer check.
None
None yet