Skip to content

Commit dd79f39

Browse files
mvadarimvadari
authored
Merge branch 'master' into discussion-management
2 parents e67265c + 871d35e commit dd79f39

File tree

70 files changed

+7984
-1138
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

70 files changed

+7984
-1138
lines changed

‎.github/workflows/deploy.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -20,15 +20,15 @@ jobs:
2020
runs-on: ubuntu-latest
2121
steps:
2222
- name: Checkout
23-
uses: actions/checkout@v5
23+
uses: actions/checkout@v6
2424

2525
- name: Setup Python
2626
uses: actions/setup-python@v6
2727
with:
2828
python-version: "3.11"
2929

3030
- name: Cache Python dependencies
31-
uses: actions/cache@v4
31+
uses: actions/cache@v5
3232
id: cache-deps
3333
with:
3434
path: ~/.cache/pip

‎.github/workflows/lint.yml‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -11,15 +11,15 @@ jobs:
1111
runs-on: ubuntu-latest
1212
steps:
1313
- name: Checkout code
14-
uses: actions/checkout@v5
14+
uses: actions/checkout@v6
1515

1616
- name: Set up Node.js
17-
uses: actions/setup-node@v5
17+
uses: actions/setup-node@v6
1818
with:
1919
node-version: "24"
2020

2121
- name: Install dependencies
22-
run: npm install -g prettier
22+
run: npm install -g prettier@3.6.2 # match version in pre-commit-config.yaml
2323

2424
- name: Run Prettier
25-
run: npx prettier --check .
25+
run: prettier --check .

‎.github/workflows/validate-xls.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ jobs:
1313

1414
steps:
1515
- name: Checkout repository
16-
uses: actions/checkout@v5
16+
uses: actions/checkout@v6
1717

1818
- name: Setup Python
1919
uses: actions/setup-python@v6
@@ -22,7 +22,7 @@ jobs:
2222

2323
- name: Cache Python dependencies
2424
id: cache-deps
25-
uses: actions/cache@v4
25+
uses: actions/cache@v5
2626
with:
2727
path: ~/.cache/pip
2828
key: ${{ runner.os }}-pip-${{ hashFiles('**/site/requirements.txt') }}

‎AMENDMENT_TEMPLATE.md‎

Lines changed: 302 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,302 @@
1+
## 1. SType: `[STypeName]`
2+
3+
> **Note:** Most specifications will not need this section, as the [existing types](https://xrpl.org/docs/references/protocol/binary-format#type-list) are generally sufficient. Only include this section if your specification introduces new serialized types (STypes).
4+
5+
_[If your specification introduces new serialized types, document each SType in its own numbered subsection below. Otherwise, delete this entire section.]_
6+
7+
### 1.1. SType Value
8+
9+
**Value:** `[Unique numeric value - see current values [here](https://github.com/XRPLF/rippled/blob/develop/include/xrpl/protocol/SField.h#L60)]`
10+
11+
_[Specify the unique numeric value for this SType]_
12+
13+
### 1.2. JSON Representation
14+
15+
_[Describe how instances of this SType are represented in JSON. For example: "Represented as a string in base64 format" or "Represented as an object with fields X, Y, Z"]_
16+
17+
### 1.3. Additional Accepted JSON Inputs _(Optional)_
18+
19+
_[If applicable, describe alternative JSON input formats that may be parsed. For example: "Can accept either a string or numeric format"]_
20+
21+
### 1.4. Binary Encoding
22+
23+
_[Describe how this SType is encoded in binary format, including byte order, length prefixes, etc.]_
24+
25+
### 1.5. Example JSON and Binary Encoding
26+
27+
**JSON Example:**
28+
29+
```json
30+
[Provide JSON example]
31+
```
32+
33+
**Binary Encoding Example:**
34+
35+
```
36+
[Provide hexadecimal representation of binary encoding]
37+
```
38+
39+
## 2. Ledger Entry: `[LedgerEntryName]`
40+
41+
_[If your specification introduces new ledger entry objects, document each entry in its own numbered section following this part of the template. Otherwise, do not include any sections with this title.]_
42+
43+
_[If your specification introduces new ledger entry common fields, you can have a section called `Transaction: Common Fields` before listing out any specific transactions.]_
44+
45+
### 2.1. Object Identifier
46+
47+
**Key Space:** `0x[XXXX]` _[Specify the 16-bit hex value for the key space]_
48+
49+
**ID Calculation Algorithm:**
50+
_[Describe the algorithm for calculating the unique object identifier. Include the parameters used in the tagged hashing and ensure no collisions are possible. Example: "The ID is calculated by hashing [specific parameters] with the key space prefix 0xXXXX"]_
51+
52+
### 2.2. Fields
53+
54+
| Field Name | Constant | Required | Internal Type | Default Value | Description |
55+
| ----------------- | ---------- | ---------------------- | ------------- | ------------------ | --------------------------------------------------------------------- |
56+
| LedgerEntryType | Yes | Yes | UINT16 | `[EntryTypeValue]` | Identifies this as a `[LedgerEntryName]` object. |
57+
| Account | No | Yes | ACCOUNT | N/A | The account that owns this object. |
58+
| `[CustomField1]` | `[Yes/No]` | `[Yes/No/Conditional]` | `[TYPE]` | `[Value/N/A]` | `[Description of field]` |
59+
| `[CustomField2]` | `[Yes/No]` | `[Yes/No/Conditional]` | `[TYPE]` | `[Value/N/A]` | `[Description of field]` |
60+
| OwnerNode | No | Yes | UINT64 | N/A | Hint for which page this object appears on in the owner directory. |
61+
| PreviousTxnID | No | Yes | HASH256 | N/A | Hash of the previous transaction that modified this object |
62+
| PreviousTxnLgrSeq | No | Yes | UINT32 | N/A | Ledger sequence of the previous transaction that modified this object |
63+
64+
_[Add more rows as needed for your specific fields. Remove example custom fields and replace with your actual fields.]_
65+
66+
**Field Details:** _[Include subsections below for any fields requiring detailed explanation]_
67+
68+
#### 2.2.1. `[FieldName]` _(If needed)_
69+
70+
_[Detailed explanation of field behavior, validation rules, etc.]_
71+
72+
### 2.3. Flags
73+
74+
\_[Describe any ledger entry-specific flags. The values must be powers of 2. If there are none, you can omit this section.]
75+
76+
| Flag Name | Flag Value | Description |
77+
| ---------------- | ------------ | ---------------- |
78+
| `[lsfFlagName1]` | `0x[Value1]` | `[Description1]` |
79+
80+
### 2.4. Ownership
81+
82+
_[Specify which AccountRoot object owns this ledger entry and how the ownership relationship is established.]_
83+
84+
**Owner:** `[Account field name or "No owner" if this is a global object like FeeSettings]`
85+
86+
**Directory Registration:** `[Describe how this object is registered in the owner's directory, or specify if it's a special case]`
87+
88+
### 2.5. Reserves
89+
90+
**Reserve Requirement:** `[Standard/Custom/None]`
91+
92+
_[If Standard]: This ledger entry requires the standard owner reserve increment (currently 0.2 XRP, subject to Fee Voting changes)._
93+
94+
_[If Custom]: This ledger entry requires `[X]` reserve units because `[reason]`._
95+
96+
_[If None]: This ledger entry does not require additional reserves because `[reason]`._
97+
98+
### 2.6. Deletion
99+
100+
**Deletion Transactions:** `[List transaction types that can delete this object]`
101+
102+
**Deletion Conditions:**
103+
104+
- `[Condition 1, e.g., "Object balance must be zero"]`
105+
- `[Condition 2, e.g., "No linked objects must exist"]`
106+
- `[Additional conditions as needed]`
107+
108+
**Account Deletion Blocker:** `[Yes/No]`
109+
_[If Yes]: This object must be deleted before its owner account can be deleted._
110+
_[If No]: This object does not prevent its owner account from being deleted._
111+
112+
### 2.7. Pseudo-Account _(Optional)_
113+
114+
_[Only include this section if your ledger entry uses a pseudo-account. Otherwise, delete this subsection.]_
115+
116+
**Uses Pseudo-Account:** `[Yes/No]`
117+
118+
_[If Yes]:_
119+
120+
- **Purpose:** `[Describe why a pseudo-account is needed, e.g., "To hold assets on behalf of users"]`
121+
- **AccountID Derivation:** `[Describe the algorithm for deriving the pseudo-account's AccountID]`
122+
- **Capabilities:** `[List what the pseudo-account can/cannot do]`
123+
124+
### 2.8. Freeze/Lock _(Optional)_
125+
126+
_[Only include this section if your ledger entry holds assets that can be frozen/locked. Otherwise, delete this subsection.]_
127+
128+
**Freeze Support:** `[Yes/No]`
129+
**Lock Support:** `[Yes/No]`
130+
131+
_[If applicable, describe how freeze/lock functionality is implemented for assets held by this object]_
132+
133+
### 2.9. Invariants
134+
135+
_[List logical statements that must always be true for this ledger entry. Use `<object>` for before-state and `<object>'` for after-state.]_
136+
137+
- `[Invariant 1, e.g., "<object>.Balance >= 0 AND <object>'.Balance >= 0"]`
138+
- `[Invariant 2, e.g., "IF <object>.Status == 'Active' THEN <object>.Account != NULL"]`
139+
- `[Additional invariants as needed]`
140+
141+
### 2.10. RPC Name
142+
143+
**RPC Type Name:** `[snake_case_name]`
144+
145+
_[This is the name used in `account_objects` and `ledger_data` RPC calls to filter for this object type]_
146+
147+
### 2.11. Example JSON
148+
149+
```json
150+
{
151+
"LedgerEntryType": "[EntryTypeName]",
152+
"Flags": 0,
153+
"PreviousTxnID": "[32-byte hex hash]",
154+
"PreviousTxnLgrSeq": 12345678,
155+
"OwnerNode": "0000000000000000",
156+
"Account": "[r-address]",
157+
"[CustomField1]": "[example value]",
158+
"[CustomField2]": "[example value]"
159+
}
160+
```
161+
162+
## 3. Transaction: `[TransactionName]`
163+
164+
_[If your specification introduces new transactions, document each transaction in its own numbered section following this part of the template. Otherwise, delete this entire section.]_
165+
166+
_[If your specification introduces new transaction common fields, you can have a section called `Transaction: Common Fields` before listing out any specific transactions.]_
167+
168+
> **Naming Convention:** Transaction names should follow the pattern `<LedgerEntryName><Verb>` (e.g., `ExampleSet`, `ExampleDelete`). Most specifications will need at least:
169+
>
170+
> - `[Object]Set` or `[Object]Create`: Creates or updates the object
171+
> - `[Object]Delete`: Deletes the object
172+
173+
### 3.1. Fields
174+
175+
| Field Name | Required? | JSON Type | Internal Type | Default Value | Description |
176+
| ---------------- | ---------------------- | ------------------------------ | ------------- | ------------------- | ---------------------------------------------------- |
177+
| TransactionType | Yes | string | UINT16 | `[TransactionName]` | Identifies this as a `[TransactionName]` transaction |
178+
| `[CustomField1]` | `[Yes/No/Conditional]` | `[string/number/object/array]` | `[TYPE]` | `[Value/N/A]` | `[Description of field]` |
179+
| `[CustomField2]` | `[Yes/No/Conditional]` | `[string/number/object/array]` | `[TYPE]` | `[Value/N/A]` | `[Description of field]` |
180+
181+
_[Add more rows as needed for your specific fields. Remove example custom fields and replace with your actual fields. Common fields like Account, Fee, Sequence, Flags, SigningPubKey, TxnSignature are assumed.]_
182+
183+
**Field Details:** _[Include subsections below for any fields requiring detailed explanation]_
184+
185+
#### 3.1.1. `[FieldName]` _(If needed)_
186+
187+
_[Detailed explanation of field behavior, validation rules, etc.]_
188+
189+
### 3.2. Flags
190+
191+
\_[Describe any transaction-specific flags. The values must be powers of 2. If there are none, you can omit this section.]
192+
193+
| Flag Name | Flag Value | Description |
194+
| --------------- | ------------ | ---------------- |
195+
| `[tfFlagName1]` | `0x[Value1]` | `[Description1]` |
196+
197+
### 3.3. Transaction Fee
198+
199+
**Fee Structure:** `[Standard/Custom]`
200+
201+
_[If Standard]: This transaction uses the standard transaction fee (currently 10 drops, subject to Fee Voting changes)._
202+
203+
_[If Custom]: This transaction requires `[X]` drops because `[reason]`._
204+
205+
### 3.4. Failure Conditions
206+
207+
_[List all conditions that cause the transaction to fail, with corresponding error codes]_
208+
209+
- `[Description of failure condition]` (`[ERROR_CODE]`)
210+
- `[Description of failure condition]` (`[ERROR_CODE]`)
211+
- `[Description of failure condition]` (`[ERROR_CODE]`)
212+
213+
_[For new error codes, provide justification for why existing codes are insufficient]_
214+
215+
### 3.5. State Changes
216+
217+
_[Describe the ledger state changes when the transaction executes successfully. Omit standard changes like fee processing and sequence increment.]_
218+
219+
**On Success (`tesSUCCESS`):**
220+
221+
- `[State change 1, e.g., "Create new [ObjectName] ledger entry"]`
222+
- `[State change 2, e.g., "Update Account's OwnerCount"]`
223+
- `[Additional changes as needed]`
224+
225+
### 3.6. Metadata Fields _(Optional)_
226+
227+
_[Only include this section if the transaction adds or modifies metadata fields. Otherwise, delete this subsection.]_
228+
229+
| Field Name | Validated | Always Present? | Type | Description |
230+
| -------------- | ---------- | ---------------------- | ------------------------------ | --------------- |
231+
| `[field_name]` | `[Yes/No]` | `[Yes/No/Conditional]` | `[string/number/object/array]` | `[Description]` |
232+
233+
### 3.7. Example JSON
234+
235+
```json
236+
{
237+
"TransactionType": "[TransactionName]",
238+
"Account": "[r-address]",
239+
"Fee": "10",
240+
"Sequence": 12345,
241+
"[CustomField1]": "[example value]",
242+
"[CustomField2]": "[example value]"
243+
}
244+
```
245+
246+
## 4. Permission: `[PermissionName]`
247+
248+
_[If your specification introduces new permissions, document each permission in its own numbered section following this part of the template. Otherwise, do not include any sections with this title.]_
249+
250+
### 4.1. Transaction Types Affected
251+
252+
_[List transaction types that this permission applies to]_
253+
254+
### 4.2. Permission Scope
255+
256+
_[Describe what the granular permission controls]_
257+
258+
### 4.3. Permission Description
259+
260+
_[Describe how this permission interacts with existing permissions and what it allows/restricts]_
261+
262+
## 5. RPC: `[rpc_method_name]`
263+
264+
_[If your specification introduces new APIs or modifies existing ones, document each API in its own numbered section following this part of the template. Otherwise, do not include any sections with this title.]_
265+
266+
### 5.1. Request Fields
267+
268+
| Field Name | Required? | JSON Type | Description |
269+
| -------------- | ---------------------- | ------------------------------ | ----------------------------- |
270+
| command | Yes | string | Must be `"[api_method_name]"` |
271+
| `[field_name]` | `[Yes/No/Conditional]` | `[string/number/object/array]` | `[Description of field]` |
272+
273+
### 5.2. Response Fields
274+
275+
| Field Name | Always Present? | JSON Type | Description |
276+
| ----------------- | ---------------------- | ------------------------------ | ------------------------------------ |
277+
| status | Yes | string | `"success"` if the request succeeded |
278+
| `[ResponseField]` | `[Yes/No/Conditional]` | `[string/number/object/array]` | `[Description of field]` |
279+
280+
### 5.3. Failure Conditions
281+
282+
- `[Description of failure condition]` (`[ERROR_CODE]`)
283+
- `[Description of failure condition]` (`[ERROR_CODE]`)
284+
- `[Description of failure condition]` (`[ERROR_CODE]`)
285+
286+
### 5.4. Example Request
287+
288+
```json
289+
{
290+
"command": "[api_method_name]",
291+
"[field_name]": "[example value]"
292+
}
293+
```
294+
295+
### 5.5. Example Response
296+
297+
```json
298+
{
299+
"status": "success",
300+
"[ResponseField]": "[example value]"
301+
}
302+
```

‎CONTRIBUTING.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,8 @@
11
# CONTRIBUTING
22

3+
> [!IMPORTANT]
4+
> This process is in a state of flux right now, and this document is still referring to the old process. Please refer to https://github.com/XRPLF/XRPL-Standards/discussions/340 instead.
5+
36
The work of the [XRP Ledger](https://xrpl.org) community is open, collaborative, and welcoming of all contributors participating in good faith. Part of that effort involves standardization, and this document outlines how anyone can contribute to that process.
47

58
## Licensing

0 commit comments

Comments
 (0)