Introduction to the SignerList

The SignerList is an object type on the XRP Ledger that represents a list of parties that are authorized to sign a transaction on behalf of an individual account. The SignerList can be created, replaced, or removed using a SignerListSet transaction.

Structure of the SignerList

The SignerList consists of a list of Signer Entry objects, representing the parties that are part of the signer list. Each Signer Entry has an Account field, which is an XRP Ledger address whose signature contributes to the multi-signature, and a SignerWeight field, which is the weight of a signature from this signer. The SignerList also has a SignerQuorum field, which is the target number for signer weights needed to produce a valid signature for the owner of the SignerList. A multi-signature is only considered valid if the sum weight of the signatures provided meets or exceeds the SignerQuorum value.

In addition to the Signer Entry fields, the SignerList object also has a Flags field, which is a bit-map of Boolean flags enabled for this signer list, a LedgerEntryType field indicating that this object is a SignerList object, an OwnerNode field that is a hint for which page of the owner directory links to this object, a PreviousTxnID field that is the identifying hash of the transaction that most recently modified this object, and a PreviousTxnLgrSeq field that is the index of the ledger that contains the transaction that most recently modified this object.

ESL Amendment Changes to the SignerList

The ExpandedSignerList (ESL) amendment added an optional WalletLocator field to the Signer Entry object, which allows for the inclusion of arbitrary hexadecimal data. It also increased the maximum SignerList size from 8 to 32 entries.

Multi-Signed Transaction Processing

When processing a multi-signed transaction, the server looks up the Account values with respect to the ledger at the time of transaction execution. If the address does not exist or is not funded, the server treats the Account field as a zero-weight entry. The server also checks that the SignerWeight is less than or equal to the SignerQuorum value. If these conditions are not met, the server rejects the transaction as invalid.

Funded and Unfunded Addresses in Signer Lists

Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. Multi-signed transactions have the same permissions as transactions signed with a regular key.

Disabling and Removing Keys

An address with a SignerList can disable the master key even if a regular key is not defined. An address with a SignerList can also remove a regular key even if the master key is disabled.

Benefits of the XRPL ExpandedSignerList Amendment

The XRPL ExpandedSignerList (ESL) amendment is a protocol change that expands the capabilities of the XRP Ledger’s multi-signing feature. It increases the maximum signer list size from 8 to 32 entries and allows for the inclusion of optional data with each signer. This additional data can be used to identify the signer and may be useful for smart contracts or for identifying who controls a key in a large organization.

The main benefit of the ESL amendment is its ability to increase the scalability of the XRP Ledger by allowing a subset of signer nodes to handle the majority of the transaction validation process. This helps to distribute the workload more evenly among the nodes, leading to faster transaction processing times. The amendment also enhances the security of the XRP Ledger by requiring signer nodes to meet certain criteria before they are allowed to validate transactions, helping to ensure that only reputable and reliable nodes are involved in the process. As a result, the risk of fraud or tampering is reduced.

In addition to increasing scalability and enhancing security, the ESL amendment can also help to reduce the costs associated with running the XRP Ledger. By requiring fewer resources to process transactions, the cost of operating the network will be lower. The amendment can also improve the user experience by providing faster transaction processing times, which is especially important for applications that require real-time processing.