Amendment XLS: DisallowIncomingCredentials

[tequdev]

  title: Disallow Incoming Credentials
  description: This amendment allows accounts to opt out of receiving on-ledger credentials created by third parties.
  
  author: tequ 
  status: Draft
  category: Amendment
  created: 2025-09-21

Disallow Incoming Credentials

Abstract

Some accounts may wish to opt out of receiving on-ledger credentials created by third parties. This document proposes a new account-level flag that, when enabled, causes CredentialCreate transactions targeting the account to be rejected unless the credential is self-issued by the account itself.

1. Motivation

In XLS-70: On-Chain Credentials, an issuer can create a credential for any subject (CredentialCreate). Some subjects may not want unsolicited credentials to be created for them. This proposal provides a simple, opt-in mechanism to prevent third-party issuance to an account while preserving the ability to self-issue.

2. Specification

This feature requires a new amendment, tentatively titled DisallowIncomingCredentials.

2.1. Ledger Object: AccountRoot

Introduce a new AccountSet flag on AccountRoot:

Flag Name	Flag Value	Description
lsfDisallowIncomingCredential	0x00008000	If set on an account, third-party credential issuance to this account is disallowed.

• Default: Disabled.

2.2. Transaction: AccountSet

This proposal adds a new flag to AccountSet:

Flag Name	Flag Value	Description
asfDisallowIncomingCredential	18	If this flag is set on AccountSet transaction, the lsfDisallowIncomingCredential flag on the AccountRoot will be set.

• Applies to: SetFlag / ClearFlag.

2.3. Transaction: CredentialCreate

This proposal adds a new failure condition to CredentialCreate (as defined in XLS-70):

• If the Subject account has asfDisallowIncomingCredentials enabled and Issuer ≠ Subject, the transaction MUST fail with a tecNO_PERMISSION error code.
• If Issuer = Subject (self-issued credential), the transaction proceeds under the normal rules, regardless of the flag.
• If the flag is not enabled on the Subject, behavior is unchanged.

No other transactions are affected by this proposal.

3. Backwards Compatibility

• The flag is disabled by default; existing behavior is unchanged unless an account opts in.

4. Test Cases (Illustrative)

• Subject has asfDisallowIncomingCredentials enabled, Issuer ≠ Subject → CredentialCreate MUST return tecNO_PERMISSION error code.
• Subject has asfDisallowIncomingCredentials enabled, Issuer = Subject → CredentialCreate MUST succeed if otherwise valid.
• Subject does not have the flag enabled → behavior unchanged from XLS-70.

5. References

• XLS-70: On-Chain Credentials

[mvadari]

@tequdev note the new process where XLS numbers are assigned on PR, not Discussion: #340

Please just use Amendment XLS: instead and leave out the number.

[mvadari]

What do you think about just having one DisallowIncoming flag for all incoming objects (we can leave the existing ones as-is to be backwards-compatible)? Having a flag for each incoming object type feels like a waste of account root flags, especially since that's the object most pressed for space.

[tequdev]

We could add a new sfDisallowIncomingFlags to ltAccountRoot for those flags.

[mvadari]

That seems fine with me.

How many accounts use these flags? Could we lazily convert the old flags to the new method and/or use LedgerStateFix to convert them? By my rough calculations (console.xrpscan.com) it's only a few hundred.