0031 XLS-31d: Transaction type specific Signer Quorum values for Multi-Signing

[Cadey]

Currently on a Multi-Sign wallet the Signer Quorum is set on the wallet and applies to all transactions the wallet performs.

Why is this a problem

The XPRL is being expanded with NFT's and Triggers, transactions which did not exist on the ledger before. In the future more features and interactions with the ledger will follow. To clarify why having a single Signer Quorum on a wallet can be an issue we will focus on the XLS-20 NFT feature.

XLS-20 enables NFT's on the ledger and with it a raft of new use cases. One of which is the creation of Marketplaces, one primary function of a Marketplace will be to mint NFT's on behalf of a customer.

Minting an NFT into a wallet requires the transaction to be signed, in this scenario the marketplace would need access to the wallet in which to mint into.

Currently if a wallet is Multi-Sign enabled both parties would need to potentially sign this transaction to get the NFT to be minted, or the marketplace could be given a Signer Weight high enough to sign the transaction its self. Unfortunately because XRPL wallets have the Signer Quorum set on the entire wallet, the marketplace would also now be able to sign ALL transactions for this wallet.

My suggestion is that we enable some ledger transaction types to have there own Signer Quorum.

The same scenario with transaction type Signer Quorum values

To make the above scenario more convenient for both parties involved the wallet could be setup in the following way.

The Target wallet is the one which we want the NFT's minted into.

1. The Target wallet has the Marketplace wallet added to its SignerLists
2. The Target wallet has a global Signer Quorum set to 2
3. The Target has its Signer Weight set to 2
4. The Marketplace wallet has its Signer Weight set to 1

With that setup we can now apply a Signer Quorum on the transaction type NFTokenMint to 1. This will enable the Marketplace wallet to be able to mint new NFT's but stops it from being able to sign any other transaction from this wallet on its own,

The result is that we can control which signers can perform which transactions on the wallet with more granularity. This will become an increasingly more important feature as the XRPL evolves and more user cases are created.

[movitto]

This could also be beneficial to allow an account(s) to extend trust on behalf on token issuers who have the 'Authorized TrustLines' flag set. This way the issuer credentials do not have to be online and an operational hot wallet could authorize holders of the token on behalf of the issuer (such as after a KYC)

[Cadey]

Hi @movitto, indeed it could. You could add the 'hot wallet' so that it can single sign the auth trustlines on the main wallet and the main wallets credentials can be kept offline

[RichardAH]

Quick note:
I've assigned you xls31 due to a conflict over xls30. The other xls30 had a correctly formatted title (and yours didn't) so your xls was reassigned. Nothing bad happened/happens you're just xls31 now :)

[Cadey]

lol ok :)

[SFsourDoh]

Certainly something like this is needed. Currency issuers will want to separate admin/config functions such as account_set and authorize trustline, as mentioned, from payments.

To keep these functions distinct we might need signer list per transaction type.

[ximinez]

I think I'm missing a step. How does the wallet setup you described allow Marketplace to sign any transactions? How does it restrict them to only singing NFTMint?

[ckeshava]

I believe that intention is to allow fine-grained control over Signer Quorum for different transaction types.
We want the MarketPlace to be able to sign the Non-Fungible Token Mint transactions. We do not want the MarketPlace to be able to exert undue influence on any other type of transaction.

This cannot be achieved in the current set up of the XRP Ledger because all the transaction types have identical Signer Quorums.

[ckeshava]

This proposal would perhaps make the account set up more complex. The account needs to specify different signer lists and weights to all the different transaction types. Have you considered a "default" signer list, in case the account-creator does not want to explicitly specify the signer-list for all the transaction types?

This would also increase the memory footprint of every account on the XRP Ledger. Instead of having one copy per account, every transaction type will have it's own list of signers.

[ralphsa]

A default signer list might make sense, are you thinking that specific transaction signer lists would override the detault list if they are defined?

[ckeshava]

Yes, I'm hoping this would reduce the developer efforts.

[SFsourDoh]

Ideally the default for every transaction would be to work as the ledger does now. No action needed when the amendment gets activated unless you want to create a new signer list for a specific transaction type.

for each new signer list you pay the same reserve you do now for a singer list.

@ckeshava thank you for looking at this.