You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: XLS-0025-enhanced-secret-numbers/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
xls: 25
3
3
title: Enhanced Secret Numbers
4
4
description: Enhances XLS-12 secret number format by introducing an additional block for encoding ancillary information, and supporingt for longer secrets.
Copy file name to clipboardExpand all lines: XLS-0041-xpop/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
<pre>
2
2
xls: 41
3
3
title: XRPL Proof of Payment Standard (XPOP)
4
-
author: Richard Holland (RichardAH)
4
+
author: Richard Holland (@RichardAH)
5
5
description: An offline non-interactive cryptographic proof that a transaction was successfully submitted to the XRP Ledger and what its impact (metadata) was
Copy file name to clipboardExpand all lines: XLS-0064-pseudo-account/README.md
+26-26Lines changed: 26 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,11 +11,11 @@ updated: 2025-08-29
11
11
12
12
### Abstract
13
13
14
-
This document proposes a standard for a *pseudo-account*, an `AccountRoot` ledger entry that can be associated with one or more other ledger entries. A pseudo-account is designed to hold and/or issue assets on behalf of its associated entries, enabling protocol-level functionality that requires an on-ledger entity to manage funds.
14
+
This document proposes a standard for a _pseudo-account_, an `AccountRoot` ledger entry that can be associated with one or more other ledger entries. A pseudo-account is designed to hold and/or issue assets on behalf of its associated entries, enabling protocol-level functionality that requires an on-ledger entity to manage funds.
15
15
16
16
### Motivation
17
17
18
-
The XRP Ledger is an account-based system where assets (XRP, IOUs, etc.) can only be held by an `AccountRoot` entry. However, several advanced protocols, such as Automated Market Makers (AMMs), lending pools, and vaults, require a ledger *object* itself to hold and manage assets.
18
+
The XRP Ledger is an account-based system where assets (XRP, IOUs, etc.) can only be held by an `AccountRoot` entry. However, several advanced protocols, such as Automated Market Makers (AMMs), lending pools, and vaults, require a ledger _object_ itself to hold and manage assets.
19
19
20
20
The [XLS-30 (AMM)](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0030-automated-market-maker#readme) specification pioneered this concept by introducing a pseudo-account linked to each `AMM` instance. This allows the AMM to track its token balances and issue Liquidity Provider Tokens (`LPTokens`).
21
21
@@ -43,30 +43,30 @@ A nonce-based approach is used to generate the unique `AccountRoot` ID:
43
43
44
44
###### **Fields**
45
45
46
-
| Field Name | Constant | Required | Internal Type | Default Value | Description |
47
-
| :--- | :---: | :---: | :---: | :---: | :--- |
48
-
|`<Object>ID`| Yes |Yes |`HASH256`|N/A | The unique identifier of the ledger object this pseudo-account is associated with. |
49
-
|`Flags`|Yes |Yes |`UINT32`|N/A | A set of flags that must be set for a pseudo-account. |
50
-
|`Sequence`|Yes |Yes |`UINT32`|`0`| The sequence number, which must be `0`. |
51
-
|`RegularKey`| Yes |No |`ACCOUNT`|N/A | A regular key, which must not be set for a pseudo-account. |
46
+
| Field Name | Constant | Required | Internal Type | Default Value | Description|
|`<Object>ID`|Yes |Yes |`HASH256`|N/A| The unique identifier of the ledger object this pseudo-account is associated with. |
49
+
|`Flags`|Yes |Yes |`UINT32`|N/A | A set of flags that must be set for a pseudo-account.|
50
+
|`Sequence`|Yes |Yes |`UINT32`|`0`| The sequence number, which must be `0`.|
51
+
|`RegularKey`|Yes |No |`ACCOUNT`|N/A | A regular key, which must not be set for a pseudo-account.|
52
52
53
53
A detailed description of these fields follows:
54
54
55
55
**`<Object>ID`**
56
56
57
57
This field links the pseudo-account to its parent ledger object. Any protocol introducing a pseudo-account must define a new, optional field on the `AccountRoot` object to store this ID. The field name must follow this convention:
58
58
59
-
*`<Object>` is the name of the associated ledger object (e.g., `AMM`, `Vault`). Names that are acronyms should be fully capitalized (`AMMID`). Otherwise, use PascalCase (`VaultID`).
60
-
* The suffix `ID` must always be appended.
59
+
-`<Object>` is the name of the associated ledger object (e.g., `AMM`, `Vault`). Names that are acronyms should be fully capitalized (`AMMID`). Otherwise, use PascalCase (`VaultID`).
60
+
- The suffix `ID` must always be appended.
61
61
62
62
**`Flags`**
63
63
64
64
The following flags must be set on a pseudo-account's `AccountRoot` and must be immutable:
65
65
66
-
| Flag Name |Hex Value | Description |
67
-
| :--- | :---: | :--- |
68
-
|`lsfDisableMaster`|`0x00040000`| Disables the master key pair, ensuring no entity can sign transactions directly for this account. Control is ceded entirely to protocol rules. |
69
-
|`lsfDepositAuth`|`0x01000000`| Requires authorization for deposits, typically meaning that funds can only be sent to this account via specific protocol transactions rather than standard `Payment` transactions. |
|`lsfDisableMaster`|`0x00040000`| Disables the master key pair, ensuring no entity can sign transactions directly for this account. Control is ceded entirely to protocol rules. |
69
+
|`lsfDepositAuth`|`0x01000000`| Requires authorization for deposits, typically meaning that funds can only be sent to this account via specific protocol transactions rather than standard `Payment` transactions. |
70
70
71
71
**`Sequence`**
72
72
@@ -80,9 +80,9 @@ A `RegularKey` must not be set on a pseudo-account.
80
80
81
81
The cost of creating a pseudo-account depends on whether it is owned and controlled by another account.
82
82
83
-
***Owned Pseudo-Accounts:** For objects like a `Vault` where a single account owns and controls the associated pseudo-account, the transaction must increase the owner's XRP reserve by one increment. This is in addition to any other reserve requirements of the transaction (e.g., for the `Vault` object itself). The transaction fee is the standard network fee.
83
+
-**Owned Pseudo-Accounts:** For objects like a `Vault` where a single account owns and controls the associated pseudo-account, the transaction must increase the owner's XRP reserve by one increment. This is in addition to any other reserve requirements of the transaction (e.g., for the `Vault` object itself). The transaction fee is the standard network fee.
84
84
85
-
***Unowned Pseudo-Accounts:** For objects like an `AMM` that are not owned by any account, the creation transaction must charge a special, higher-than-normal transaction fee. This fee must be at least the value of one incremental owner reserve (currently **2 XRP**, subject to change via Fee Voting). This amount is burned, compensating for the permanent ledger space without tying the reserve to a specific owner.
85
+
-**Unowned Pseudo-Accounts:** For objects like an `AMM` that are not owned by any account, the creation transaction must charge a special, higher-than-normal transaction fee. This fee must be at least the value of one incremental owner reserve (currently **2 XRP**, subject to change via Fee Voting). This amount is burned, compensating for the permanent ledger space without tying the reserve to a specific owner.
86
86
87
87
###### **Deletion**
88
88
@@ -92,18 +92,18 @@ A pseudo-account must be deleted together with the associated object.
92
92
93
93
The following invariants must hold true for any `AccountRoot` entry functioning as a pseudo-account:
94
94
95
-
* The ledger object identified by the `<Object>ID` field must exist.
96
-
* Exactly one `<Object>ID` field must be present on the `AccountRoot` (e.g., an account cannot be linked to both an `AMMID` and a `VaultID`).
97
-
* The `lsfDisableMaster` and `lsfDepositAuth` flags must always be set.
98
-
* The `Sequence` number must always be `0`, and must never change.
99
-
* AMM pseudo-accounts created under old rules will have a sequence number set to the index of the ledger they were created in. They still must never change.
100
-
* A `RegularKey` must not be set.
95
+
- The ledger object identified by the `<Object>ID` field must exist.
96
+
- Exactly one `<Object>ID` field must be present on the `AccountRoot` (e.g., an account cannot be linked to both an `AMMID` and a `VaultID`).
97
+
- The `lsfDisableMaster` and `lsfDepositAuth` flags must always be set.
98
+
- The `Sequence` number must always be `0`, and must never change.
99
+
- AMM pseudo-accounts created under old rules will have a sequence number set to the index of the ledger they were created in. They still must never change.
100
+
- A `RegularKey` must not be set.
101
101
102
102
### Security Considerations
103
103
104
104
The design of pseudo-accounts includes several critical security features:
105
105
106
-
***No Direct Control:** The mandatory `lsfDisableMaster` flag and the absence of a `RegularKey` ensure that no user can directly control the pseudo-account or its assets. All fund movements are governed exclusively by the rules of the associated protocol.
107
-
***Transaction Prevention:** A `Sequence` of `0` makes it impossible for the account to submit transactions, preventing any misuse of the account itself.
108
-
***Address Front-running Prevention:** The deterministic but unpredictable method for generating the account address prevents attackers from guessing the address and sending funds to it before it is officially created by the protocol.
109
-
***Controlled Deposits:** The `lsfDepositAuth` flag prevents arbitrary `Payment` transactions from being sent to the account, ensuring that its balances can only be modified through legitimate protocol transactions.
106
+
-**No Direct Control:** The mandatory `lsfDisableMaster` flag and the absence of a `RegularKey` ensure that no user can directly control the pseudo-account or its assets. All fund movements are governed exclusively by the rules of the associated protocol.
107
+
-**Transaction Prevention:** A `Sequence` of `0` makes it impossible for the account to submit transactions, preventing any misuse of the account itself.
108
+
-**Address Front-running Prevention:** The deterministic but unpredictable method for generating the account address prevents attackers from guessing the address and sending funds to it before it is officially created by the protocol.
109
+
-**Controlled Deposits:** The `lsfDepositAuth` flag prevents arbitrary `Payment` transactions from being sent to the account, ensuring that its balances can only be modified through legitimate protocol transactions.
0 commit comments