Amendment Idea: Optimized Accounts and Trustlines

[mvadari]

  title: Optimized Accounts and Trustlines
  description: Improve accounts and trustlines to store the same data but take up less on-ledger space
  author: Mayukha Vadari , Nik Bougalis (@nbougalis), Rome Reginelli 
  created: 2025-09-11

Originally posted by Nik Bougalis in #56 (comment) and Rome Reginelli in XRPLF/rippled#3866

Amendment Idea: Optimized Accounts and Trustlines

1. Overview

This alternative proposal makes several minor changes to the way accounts are structured and by which reserves are calculated.

Unlike XLS-23d, this proposal does not impose any limitations on an account, does not require a flag to signify that an account should be charged a reduced reserve and does not mandate complicated conversion procedures from 'lite' to 'full' accounts. Additionally, it makes it possible for accounts to to only be charged for the resources they use at any given time, which the existing proposal does not allow: once an account has been converted into a full account, it is always charged a full reserve.

These changes will require an amendment, tentatively named EfficientObjects.

1.1. Historical Background

The original intention behind the account reserve was to act as as a deterrent to the creation of new accounts with the intention of spamming the ledger, since at the time accounts could not be deleted and the entire reserve was, therefore, unrecoverable.

Accounts are now deletable, and users can retrieve most of their account reserve if they delete their account (0.8 out of 1 XRP).

As XLS-23d makes clear, several participants in the ecosystem have expressed concerns that the cost of creating an account represents a barrier to entry for new users and remains a major impediment to the expansion of the ecosystem. While this barrier has reduced now that reserves are only 1 XRP for an account, this is still a nontrivial amount in some parts of the world.

1.2. Background: Field Types

3 types of types: Required/Optional/Default

• Required: the field must be there
• Optional: the field does not have to be there
• Default: the field does not have to be there, and is assumed to have a value (the 0 value of the type) if it is not present
  • e.g. if you have an STUInt32 field with type "default", it is assumed to be 0 if it's not present. So using default fields can save a lot of space if the field often has the default value.

1.3. The Current AccountRoot Object

Accounts on the XRP Ledger are stored inside AccountRoot ledger object, which groups together the many fields that, together, comprise the state of an account on the XRP Ledger.

Specifically, as of the time of this writing an AccountRoot consists of the following fields:

Field	Required	Type	Bytes
sfLedgerEntryType	✔️	UInt16	3
sfFlags	✔️	UInt32	5
sfAccount	✔️	AccountID	22
sfSequence	✔️	UInt32	5
sfBalance	✔️	Amount	9
sfOwnerCount	✔️	UInt32	5
sfPreviousTxnID	✔️	UInt256	33
sfPreviousTxnLgrSeq	✔️	UInt32	5
sfAccountTxnID		UInt256	33
sfAMMID		UInt256	33
sfRegularKey		AccountID	22
sfEmailHash		UInt128	17
sfWalletLocator		UInt256	33
sfWalletSize		UInt32	5
sfMessageKey		Blob	33
sfTransferRate		UInt32	5
sfDomain		Blob	<= 256
sfTickSize		UInt8	3
sfBurnedNFTokens		UInt32	5
sfFirstNFTokenSequence		UInt32	5
sfMintedNFTokens		UInt32	5
sfNFTokenMinter		AccountID	22

Thus, an account with all the bells and whistles enabled may exceed 500 bytes, although most accounts will be much smaller - a minimal account is only 110 bytes.

2. On-Ledger Object: AccountRoot

Defaulting Fields

This proposal recommends that modifying the definitions of the Flags and OwnerCount fields, changing them from REQUIRED to DEFAULT, which essentially makes the fields OPTIONAL and avoids storing them if their value is 0, marginally reducing the size of an account with no owner directory. Note that the Flags field is currently a common field; changing this could reduce the size of other object types as well, but many objects have at least one flag set.

Net gains

Assuming an account with no optional fields, the size of the AccountRoot will go down by 10 bytes, which represents a reduction of greater than 10% for a minimal account. This may not seem like a lot, but it is a measurable amount - and combined with further improvements on trust lines, this might result in significant savings.

As of ledger 95079427 (3/28/2025, 4:30:00 PM UTC), there were:

• 6,326,193 total accounts.
• 6,148,404 accounts with a Flag value of 0.
• 5,112,517 accounts with an OwnerCount value of 0.

This change would result in 56.3 MB of savings, or about 0.8% of the total size of the ledger (which is about 6,600 MB), or about 512k accounts of minimal size.

Deprecating Fields

In the interest of reducing the possibility of account bloat and to eliminate legacy and fields which have no clear purpose, this proposals recommends that we disable support for the WalletLocator and WalletSize fields. Since existing accounts use these fields, they must remain part of the object, but it should not be possible to set these fields going forward and attempts to do so must fail.

As of ledger 95079427 (3/28/2025, 4:30:00 PM UTC), there were:

• 3 accounts with a WalletLocator set.
• 0 accounts with a WalletSize set.

Given the small amount of objects with these fields set, no provision is made to allow them to be cleared.

3. On-Ledger Object: RippleState

XRPLF/rippled#3866

3.1. Current State

Field	Required	Type	Bytes
sfLedgerEntryType	✔️	UInt16	3
sfFlags	✔️	UInt32	5
sfBalance	✔️	Amount	49
sfLowLimit	✔️	Amount	49
sfHighLimit	✔️	Amount	49
sfPreviousTxnID	✔️	UInt256	33
sfPreviousTxnLgrSeq	✔️	UInt32	5
sfLowNode	✔️	UInt64	9
sfHighNode	✔️	UInt64	9
sfLowQualityIn		UInt32	5
sfLowQualityOut		UInt32	5
sfHighQualityIn		UInt32	5
sfHighQualityOut		UInt32	5

3.1.1. sfBalance

Always has an issuer of rrrrrrrrrrrrrrrrrrrrBZbvji - wasted space

3.1.2. HighLimit and LowLimit

Currency code is repeated from Balance

3.1.3. HighNode and LowNode

Often have values of 0

3.2. Proposal

Field	Required	Type	Bytes
sfLedgerEntryType	✔️	UInt16	3
sfFlags	Default	UInt32	5
sfBalanceAmount	Default	Number	13
sfCurrency	✔️	Currency	21
sfLowAccount	✔️	AccountID	22
sfLowLimitAmount	Default	Number	13
sfHighAccount	✔️	AccountID	22
sfHighLimitAmount	Default	Number	13
sfPreviousTxnID	✔️	UInt256	33
sfPreviousTxnLgrSeq	✔️	UInt32	5
sfLowNode	Default	UInt64	9
sfHighNode	Default	UInt64	9
sfLowQualityIn		UInt32	5
sfLowQualityOut		UInt32	5
sfHighQualityIn		UInt32	5
sfHighQualityOut		UInt32	5

3.2.1. Proposal in English

For all trustlines:

• Replace sfBalance with sfCurrency/sfBalanceAmount, since the issuer is not needed for the balance
• Replace sfLowLimit with sfLowAccount/sfLowLimitAmount, since the Currency is already stored above
• Replace sfHighLimit with sfHighAccount/sfHighLimitAmount, since the Currency is already stored above

For some trustlines:

• sfFlags is soeDEFAULT, like with AccountRoot
• sfBalanceAmount is soeDEFAULT, which saves some bytes for trustlines with 0 balance
• sfLowLimitAmount/sfHighLimitAmount is soeDEFAULT, which saves some bytes for unidirectional trustlines (the vast majority of them
• Makes LowNode and HighNode are optional fields, to be omitted when their value is 0.

3.3. Savings

3.3.1. Savings for All Trustlines

• sfBalance -> sfCurrency/sfBalanceAmount - 15 bytes saved
• sfLowLimit -> sfLowAccount/sfLowLimitAmount -> 14 bytes saved
• sfHighLimit -> sfHighAccount/sfHighLimitAmount -> 14 bytes saved

A total of 43 bytes saved per trustline.

3.3.2. Savings for Some Trustlines

• sfFlags is soeDEFAULT - 5 bytes saved for trustlines with no flags (rare - you get this from the account savings)
• sfBalanceAmount is soeDEFAULT - 9 bytes saved for trustlines with 0 balance
• sfLowLimitAmount/sfHighLimitAmount is soeDEFAULT - 9 bytes saved for one-directional trustlines (the vast majority of them)
• sfLowNode is soeDEFAULT - 9 bytes saved for most trustlines
• sfHighNode is soeDEFAULT - 9 bytes saved for most trustlines

3.3.3. Total Savings Based on Latest Data

As of ledger 95079166 (3/28/2025, 4:13:01 PM UTC), there were:

• 6,548,846 total trustlines
• 22 trustlines with a Flags value of 0
• 2,457,133 trustlines with a HighNode value of "0"
• 1,687,693 trustlines with a LowNode value of "0"
• 2,807,114 trustlines with a balance of 0
• 2,264 bidirectional trustlines (neither the LowLimit nor the HighLimit is 0)

Resulting savings:

Type	Count	Savings Each (bytes)	Total Savings (MB)
Total	6,548,846	43	281.60
Empty Flags	22	5	0.00011
Empty HighNode	2,457,133	9	22.11
Empty LowNode	1,687,693	9	15.19
0 Balance	2,807,114	9	25.26
Unidirectional	6,546,582	9	58.92

The total savings would be 403 MB, or 6.1% of the whole ledger (which is about 6,600 MB). These savings would be equivalent to 3.7 million accounts of minimal size, or 3.3 million trustlines of minimal size.

Note: these savings may not translate directly to this number of accounts/trustlines, as there will likely be other side effects of having an additional 3-4 million accounts/trustlines, such as with the size of the SHAMap.

4. Transaction: LedgerStateFix

The LedgerStateFix transaction is intended to be used for one-time fixes. It could be used for converting AccountRoots and RippleStates from the old format to the new one, on top of lazily converting them whenever a transaction interacts with them.

5. Out of Scope

This proposal avoids the topic of account sponsorship, which XLS-23 and XLS-68 discuss at length. While the topic is important, it does not need to be combined with this proposal; it should instead be discussed separately, especially since there is no way to enable "sponsorship" without actually increasing the size of the AccountRoot by at least 20 bytes (to track the sponsor).

This proposal also avoids the topic of "better token standards", which XLS-33 discusses at length.