0023 XLS-23d: Lite Accounts (lower reserve, less features)

[WietseWind]

LiteAccounts Amendment

By @RichardAH, @WietseWind

Introduction

The XRP Ledger is a fast consensus-based blockchain which, unlike competing chains, maintains its user's balances as persistent state rather than as a graph of unspent transaction outputs. This imposes unique per-account storage costs on the network. These costs are passed on to the user.

The cost of creating an account on the ledger is, at time of writing, 5 XRP with an additional lockup of 15 XRP (which is redeemable if the account is later deleted). Collectively this is known as the Account Reserve. It has been argued the Account Reserve acts as a barrier to entry for new users and remains a major impedement to the expansion of the ecosystem.

The AccountRoot ledger object represents the authoritative state of an XRPL account.

It contains the following fields:

Field	Type	Bytes	Required	Lite Account
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
sfRegularKey	AccountID	22
sfEmailHash	UInt128	17
sfWalletLocator	UInt256	33
sfWalletSize	UInt32	5
sfMessageKey	Blob	33
sfTransferRate	UInt32	5
sfDomain	Blob	at most 256
sfTickSize	UInt8	4
sfTicketCount	UInt32	6
sfSponsor^^	AccountID	22		✅

^^ Part of this proposal

An XRPL Account which owns no on-ledger objects (i.e: does not have any trustlines, escrows, offers, etc.), does not specify a regular key and does not set any of its other optional fields has a serialized size of 87 bytes (excluding storage overhead.)

We propose that any such minimal account root imposes such a small burden on the ledger that it should be able to be treated differently to full account roots.

Lite Accounts

We propose that a lite account is an XRPL Account with:

• a minimal account root
• the new asfLiteAccount account flag set, and,
• (optionally) the new sfSponsor field set.

Lite accounts have an Account Reserve of 1/5th the ledger's object reserve (i.e. 1 XRP at time of writing.)

⚠️ Restrictions

A lite account cannot:

• Own on-ledger objects, and thus cannot:
  • Hold or create Trustline balances
  • Have non-default limits on incoming trustlines
  • Create Offers
  • Create Escrows
  • Create Checks
  • Create Payment Channels
  • Create or install Hooks (pending amendment)
  • Set or use a Signer List
  • Create Tickets
  • Require or use Deposit Authorizations
  • Set or use a Regular Key
• Become a sponsor for another lite account
• Perform AccountSet on any fields except sfSponsor and sfFlags

New Fields and Flags

The following changes are made to fields and flags.

1. sfSponsor — a new optional AccountID field on the acount root which indicates that another account owns the reserve for the account root.
2. tfSponsor — a new transaction flag that indicates the intent of the sender to create and sponsor a new lite account.
3. asfLiteAccount — a new account flag that can be set and unset subject to certain conditions, which indicates that the account is a lite account and subject to the restrictions of a lite account.

These are explained in further detail below.

Sponsorship

Lite accounts may be sponsored. Sponsorship provides that another account pays the account reserve and, subject to conditions, is entitled to recover the entire account reserve should the lite account be later deleted. Full accounts cannot be sponsored, only accounts with asfLiteAccount flag can be sponsored.

To sponsor a new account creation:
A ttPAYMENT transaction is created and successfully submitted, which:

1. Specifies an unfunded destination account,
2. Specifies the (new) tfSponsor flag, and
3. Sends at least as much XRP as the lite account reserve.

There is no way for an already established XRPL account (full or lite) to subsequently become a sponsored account. Sponsorship can only occur through account creation.

Reclamation

A sponsor is entitled to reclaim the Account Reserve on a lite account (for which they are the sponsor) subject to certain conditions:

Scenario 1: AccountDelete

If a sponsored lite account:

• contains less than two times the lite account reserve, and
• does not sign and submit any transaction that results in a tesSUCCESS on a validated ledger for more than 1 million ledgers,

Then the account's sponsor may recover the Account Reserve via an AccountDelete transaction. The spsonsor also receives the remaining balance in the lite account.

The AccountDelete transaction specifies the lite account as the sfAccount field but is signed by the sponsor.

Scenario 2: AccountSet

If a sponsored lite account, at any time:

• contains at least two times the lite account reserve

Then the account's sponsor may recover the Account Reserve via an AccountSet transaction that clears the sfSponsor field.

The AccountSet transaction specifies the lite account as the sfAccount field but is signed by the sponsor and can only be used to delete the sfSponsor field.

Doing so results in a balance mutation on both the lite account and the sponsor account to reflect the return of the lite Account Reserve.

Upgrading

The owner of a lite account can upgrade their account twice:

Scenario 1: Removal of Sponsor

The owner of a lite account may unilaterally unsponsor his or her own account by:

• ensuring the account contains at least twice the lite Account Reserve, and
• creating and successfully submitting an AccountSet transaction that clears the sfSponsor field.

Doing so results in a balance mutation on both the lite account and the sponsor account to reflect the return of the lite Account Reserve.

Scenario 2: Full Account

The owner of an unsponsored lite account may upgrade the account to a full account by:

• ensuring the account contains at least the Full Account Reserve (at time of writing 20 XRP)
• creating and successfully submitting an AccountSet transaction that clears the asfLiteAccount flag.

Downgrading

The owner of a full account may opt to downgrade their account to a lite account by:

• creating and successfully submitting an AccountSet transaction that sets the asfLiteAccount flag. This action frees up the difference between the full Account Reserve and the lite Account Reserve.

Deletion of Lite Accounts

The owner of a lite account may delete their account subject to certain conditions:

Scenario 1: Send all to Sponsor

If the lite account is sponsored then the owner of the lite account may:

• create and successfully submit an AccountDelete transaction, which
• specifies the account sponsor as the Destination field

Scenario 2: Upgrade and Delete

If the lite account is sponsored then the owner of the lite account may upgrade their account to an unsponsored account.
Once the lite account is unspsonsored, the user may proceed with a normal AccountDelete operation (with the proceeds going to any desired Destination).

[ximinez]

Very cool proposal. I have a couple of questions:

1. In reclamation scenario 1, where the sponsor deletes the account, will that AccountDelete transaction still require the 5 XRP (one increment) fee? Who pays the fee? If it's the sponsor, they're going to net lose a few XRP. If it's the sponsored account, they won't have sufficient balance to pay the fee?
2. When upgrading, will it be possible to do both steps in one AccountSet transaction (removing the sponsor and the flag in one tx)?

[RichardAH]

1. We're intending to roll in a reduction of AccountDelete fee to 1 XRP as to avoid incentivising people downgrading rather than deleting accounts they don't want. And in this way the sponsor would pay 1 XRP deletion fee and get the balance of the lite account back which would typically be >= 1 XRP.
2. Afaik AccountSet allows only one ClearFlag to be set per transaction. We did toss around ways to do it for a while but in the end decided it should be two seperate txns. Input welcome on this and (1) of course :)

[ximinez]

1. That may be controversial. Probably should mention it in the proposal. It does make more economic sense for the sponsor.
2. Yes, AccountSet can only clear one flag at a time, but sfSponsor is not a flag. Removing it might be implemented as clearing a flag, since sfSponsor can't be set arbitrarily... or can it?

[RichardAH]

This proposal text is slightly out of date. There is indeed an asfSponsored flag to shadow the current state of the sfSponsor field because it can’t be set arbitrarily. An AccountSet which clears this flag upgrades from a sponsored lite account to an unsponsored lite account. A second txn which clears asfLiteAccount upgrades to a full account. But they must be done in that order.

Iwill update the proposal to reflect this and the reduction in DeleteAccount fee. Good suggestions.

Preliminary code is here, still being debugged. https://github.com/richardah/rippled/tree/liteaccounts

We had originally also put in some only loosely unrelated trustline restriction features, however those will probably be going into their own amendment now. If you find something in code related to trustlines that’s why :)

[ximinez]

Thanks for the update

[Silkjaer]

Very interesting suggestion for a solution to a commonly discussed topics: whether to lower reserves or not.

It could be solved with hooks and destination tags as has been suggested earlier, with a hook keeping score of who owns what. A “native” solution like this is definitely easier.

Some questions for further discussion:

• how often is the base reserve an issue for users – is it much requested in support tickets with the various XRPL wallet providers?
• the whole base/owner reserve appear to be tricky to understand for many people. Lite accounts add a new level of complexity, and opens doors to a multitude of new “support tickets” based on the lite account limitations
• If the lite accounts are restricted in terms of what they can do, maybe the easy solution would be to lower the base reserve altogether, making the total reserve dynamic according to how many features are used (which it already is qua owner reserves). This way there is no difference between lite and full accounts and the only amendment would be to make sponsored base reserves?

[NetScr1be]

Xumm Support has closed/resolved over 3,200 tickets since 2020-01-01.

There is no tracking by issue topic but, as someone who averages several tickets per day, this is one of the most common pain points.

Most are satisfied about the why once it is explained but there are still a non-trivial amount whose response ranges from indignation to anger with some actually accusing us of scamming them.

Reducing the reserve requirements will certainly turn down the volume on the issue but, as long as people are expressing surprise, we are not doing a good enough job of communicating on this topic.

Agree with the second point re; additional complexity triggering new forms of confusion (and support tickets) but that is the burden of innovation.

"making the total reserve dynamic according to how many features are used"

Brilliant if done natively.

[nbougalis]

So, on a first, quick skim, it looks like the size of a "lite account" is no smaller than the size of a regular account, so these are lite in name only. I think that if we're going to implement lite accounts we should, instead, try to reduce the minimum size of such accounts.

Unfortunately, with the exception of making the sfOwnerCount field optional (since lite accounts don't own objects and so they'll never need that field) which is a tiny, tiny, tiny win, there's not much else you can cut out.

I've given this issue a lot of thought because I tried to draft a standard for "lite accounts" in the past, and my conclusion was that any effort to overload the existing ltACCOUNT_ROOT to make lite accounts doesn't buy much.

So here's what I would do:

• Make the sfOwnerCount field optional (for subtle technical reasons it's not easy to default this field, unfortunately).
• Keep the asfLiteAccount flag.
• Introduce an asfNoTrustlines flag for accounts.

All accounts, lite or not, require an account reserve. We keep the current code for that, and the network can decide on what that reserve should be by voting). I think it should be reduced to at most 10 XRP.

An account with the asfLiteAccount flag obeys the restrictions that you specify in your proposal and, additionally, it may not have trustlines opened to it. This flag takes priority over other flags.

An account with the asfNoTrustlines flag does not allow others to create trustlines to it, but can, itself, create trustlines. This flag is superseded by asfLiteAccount.

One alternative here might be do away with "lite account" flag entirely and eliminate the "account reserve", using only the "incremental reserve" (this can be done by simply voting to set the account and incremental reserves to the same value). An account that owns any object is charged a reserve for actually having an owner directory. This would require a bit of extra work: a new flag which determines whether the existing sfOwnerCount counts the owner directory reserve or not. If the flag was unset and the sfOwnerCount field was non-zero, the code would set the flag and increment sfOwnerCount by 1. The net result of this, assuming the current incremental reserve, is that a lite account ends up with a 5 XRP reserve and an account that owns N objects ends up with a reserve that's 10 + (N * 5).

Sponsored accounts are a great idea, but the proposed implementations has some weird corner cases. Maybe they're a problem and maybe they aren't. The primary concern is that the requirement to store the sponsor's address bloats the object: a sponsored lite account, as defined in this spec is 23 bytes larger than a "normal" account.

I don't have a good solution to this, but I'd appreciate thoughts on it because I think sponsored wallets are a neat idea.

[bharathchari]

Sponsored accounts have use cases that span both commercial and specific groups (need based) that could benefit from them. The lower account reserves do make them viable from the context of economies where the wallet reserve (even if lowered) still pose a barrier to entry.

[nbougalis]

Oh, I agree. I have no problem with making it possible for accounts to be sponsored; I just think that there are a lot of corner cases with the proposed implementation, in addition to the bloating I described. We should think those through carefully and investigate other options.

[yxxyun]

https://developers.stellar.org/docs/glossary/sponsored-reserves/ I think this is similar , but your proposal limited to activate account only.

[nbougalis]

An alternative proposal for "Lite Accounts"

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.

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 impedement to the expansion of the ecosystem.

Introduction

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	Type	Bytes	Required
sfLedgerEntryType	UInt16	3	✔️
sfFlags	UInt32	5	✔️
sfAccount	AccountID	22	✔️
sfSequence	UInt32	5	✔️
sfBalance	Amount	9	✔️
sfOwnerCount	UInt32	5	✔️
sfPreviousTxnID	UInt256	33	:heavy_check_mark:
sfPreviousTxnLgrSeq	UInt32	5	✔️
sfAccountTxnID	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

Thus, an account with all the bells and whistles enabled may exceed 500 bytes, although most accounts will be much smaller and likely under 100 bytes.

Lite Accounts

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

Specifically, this proposal recommends that the base and incremental reserves are replaced by a single value. However, to ensure maximum future flexibility and limit code changes, this proposal recommends that this change be affectuated by validator operators using the existing reserve voting mechanism to collaboratively set the base and incremental reserves to the same value. This proposal recommends 1 XRP.

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.

Modifications to ltACCOUNT_ROOT

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 (i.e. a "lite" account). 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% which is significant. Assuming that there are 1,000,000 accounts that could take advantage of these changes, the net reduction in the size of the state map (i.e. the "ledger") would be 10MB with minimal changes. This may not seem like a lot, but it is a measurable amount and combined with further improvements on trust lines might result in significant savings.

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. Given the small amount of objects with these fields set, no provision is made to allow them to be cleared.

A Word About Account Sponsorship

This proposal avoids the topic of account sponsorship which XLS-23d discusses at length. While the topic is important, it need not 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.

[WietseWind]

Thank you @nbougalis!

I feel the the proposed modifications could (should) be implemented, not as part of Lite accounts, but simply to optimize XRPL ledger size. With the proposed changes (summary below) I believe most reasons to propose Lite Accounts do no longer apply. Sponsorship then could be another discussion (I agree), although at the mentioned 1 XRP per account (reserve) I doubt if sponsorship is required any time soon based on use cases requiring sponsorship. Something to possibly revisit later.

• Proposal: validators: vote for 1 XRP owner reserve, 1 XRP incremental reserve
• Change Flags & OwnerCount fields
• Removing WalletLocator & WalletSize fields

The one thing not covered (makes sense, we're talking about lite accounts) is the size of Trust Lines, at 1 XRP per account & 1 XRP per trust line, I feel both should be optimized. Trust Lines even consume more ledger space than Accounts.

❗ One thought about base & incremental reserve at 1 XRP: an AccountDelete currently returns [base] - [incremental] XRP. At 1 - 1 there is no incentive for users to delete unused accounts anymore. Also, it would kill the incentive to keep an account (as an on ledge ridentity) instead of activating & using a new one every time. So my proposal would be 2 / 1 or 1 / 0.5, but not equal.

[nbougalis]

I agree re: both the reserve and the comment about trust lines. Unfortunately, tackling trust lines in a way that makes sense is more difficult than this change and must require a bit of hoop-jumping.

[wojake]

This is a great proposal to resolve the "account reserve acting as a barrier of entry to new users" issue.

This is debatable, but don't you think lite accounts' account reserve is too low? (0.1 XRP as of now 1/5 owner reserve).

I propose the account reserve for lite accounts to be 1/2 of a full account's owner reserve.

Reasoning: As the network grows in terms of users, the account reserve for full accounts will gradually be lowered. Adding to this, the network will increase in load as the result of the increase of new users utilizing the network. Not to mention, the ledger's resources is finite, this is not cost effective because only a small amount of XRP will be burnt/froze compared to the resources and load used in the network which is not worth while.

If I'm not wrong, the network profits economically by burning a fair amount of XRP.

Hence in order to minimize the poor use of the ledger's resources in the future, it would be best that we keep a stable yet economically affordable for the global use of the ledger.

[mvadari]

@WietseWind should this spec be moved into PR and kept in the repo or should it be closed? Note that this does not mean that the spec has been accepted/implemented/finalized.

I will move it to PR by copy-pasting the existing draft if there is no response in the next week.

[WietseWind]

For future reference/inspiration: some record, but I don't think that keeping this open is needed.