Compare commits

..

108 Commits

Author SHA1 Message Date
Mayukha Vadari
ac623ef506 Add request parameters to server definitions
Updated server_definitions.md to include request parameters.
2025-12-03 10:50:37 -05:00
Rome Reginelli
d48698531c Merge pull request #3371 from XRPLF/fix_src_links_admin_apis_etc
Update source links in admin api refs & elsewhere
2025-12-02 12:32:08 -08:00
Maria Shodunke
6dce88c4f8 Merge pull request #3396 from XRPLF/dependabot/go_modules/_code-samples/issue-a-token/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/issue-a-token/go
2025-11-28 04:50:13 -08:00
dependabot[bot]
724c61c9e3 Bump golang.org/x/crypto in /_code-samples/issue-a-token/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-28 11:16:30 +00:00
Maria Shodunke
50f2f35b0b Merge pull request #3394 from XRPLF/dependabot/go_modules/_code-samples/get-started/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/get-started/go
2025-11-28 03:15:46 -08:00
Maria Shodunke
d4cfcee8ea Merge pull request #3395 from XRPLF/dependabot/go_modules/_code-samples/paths/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/paths/go
2025-11-28 03:15:29 -08:00
dependabot[bot]
e9709335a9 Bump golang.org/x/crypto in /_code-samples/paths/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-27 11:33:04 +00:00
dependabot[bot]
45f25acc3e Bump golang.org/x/crypto in /_code-samples/get-started/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-27 11:32:06 +00:00
Maria Shodunke
61bc24b7dc Merge pull request #3390 from XRPLF/dependabot/go_modules/_code-samples/clawback/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/clawback/go
2025-11-27 03:31:11 -08:00
oeggert
7cf6dccdd2 Merge pull request #3391 from XRPLF/ws-hydration-error
Fix WebSocket API Tool errors
2025-11-25 11:00:34 -08:00
Oliver Eggert
f44370009c fix hydration and browser navigation errors 2025-11-24 22:46:41 -08:00
dependabot[bot]
3a1bb9a70b Bump golang.org/x/crypto in /_code-samples/clawback/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-24 12:21:34 +00:00
Maria Shodunke
78fc4f49e6 Merge pull request #3388 from XRPLF/dependabot/go_modules/_code-samples/deposit-preauth/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/deposit-preauth/go
2025-11-24 02:37:52 -08:00
oeggert
adb09928cc Merge pull request #3387 from XRPLF/remove-rbac
Remove unused rbac configuration.
2025-11-21 10:24:40 -08:00
dependabot[bot]
36cd69821b Bump golang.org/x/crypto in /_code-samples/deposit-preauth/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-21 13:53:04 +00:00
Maria Shodunke
1e91335f83 Merge pull request #3384 from XRPLF/dependabot/go_modules/_code-samples/send-xrp/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/send-xrp/go
2025-11-21 05:51:50 -08:00
Maria Shodunke
1ff667bb21 Merge pull request #3383 from XRPLF/dependabot/go_modules/_code-samples/multisigning/go/golang.org/x/crypto-0.45.0
Bump golang.org/x/crypto from 0.35.0 to 0.45.0 in /_code-samples/multisigning/go
2025-11-21 05:51:36 -08:00
Oliver Eggert
d1969d3919 remove rbac to enable anonymous mcp connections 2025-11-20 14:46:57 -08:00
oeggert
92230d702c Merge pull request #3385 from XRPLF/rippled-2.6.2
Rippled 2.6.2
2025-11-20 10:48:05 -08:00
oeggert
30c6a42519 Update blog/2025/rippled-2.6.2.md
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
2025-11-20 07:26:04 -08:00
oeggert
24a374e2bf Update blog/2025/rippled-2.6.2.md
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
2025-11-20 07:25:49 -08:00
Maria Shodunke
cac56c37f6 Merge pull request #3372 from XRPLF/batch-transactions-tutorial
Javascript: Batch transactions tutorial
2025-11-20 03:58:58 -08:00
Oliver Eggert
bd06feb49c remove sha512half script 2025-11-19 21:04:49 -08:00
Oliver Eggert
815df642e0 add commit message and download links 2025-11-19 21:02:28 -08:00
dependabot[bot]
46ed7fc569 Bump golang.org/x/crypto in /_code-samples/send-xrp/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-20 01:39:20 +00:00
dependabot[bot]
f99277b841 Bump golang.org/x/crypto in /_code-samples/multisigning/go
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.35.0 to 0.45.0.
- [Commits](https://github.com/golang/crypto/compare/v0.35.0...v0.45.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.45.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-11-20 01:38:04 +00:00
Oliver Eggert
6c64a1e449 update tecdir_full error messages 2025-11-19 15:44:05 -08:00
Oliver Eggert
9e343558cc update tec codes and release notes 2025-11-19 15:16:42 -08:00
Maria Shodunke
fb33561a98 Address review comments 2025-11-19 12:22:32 +00:00
Oliver Eggert
567d980713 update known amendments with fixdirectorylimit 2025-11-17 15:32:44 -08:00
Maria Shodunke
7f16532b07 Calculate inner transaction hash to verify success 2025-11-17 19:13:57 +00:00
Oliver Eggert
62759ec261 add 2.6.2 release notes 2025-11-14 13:21:30 -08:00
Rome Reginelli
003927517f Merge pull request #3379 from XRPLF/rr-mpt-dupe-flag
Remove duplicate flags field in sample JSON
2025-11-14 12:19:31 -08:00
Rome Reginelli
9c8c231900 Remove duplicate flags field in sample JSON 2025-11-11 15:53:25 -08:00
Maria Shodunke
382a10bda9 Add temARRAY_EMPTY error for Batch transaction 2025-11-06 16:52:31 +00:00
Maria Shodunke
d2cf306ec6 Mention minimum number of transactions required in a Batch 2025-11-06 12:15:58 +00:00
Maria Shodunke
3e41224ef0 Add Batch transactions tutorials 2025-11-06 10:28:01 +00:00
Maria Shodunke
01ed3055ec Merge pull request #3299 from XRPLF/python-get-started-code-walkthrough
Add Get Started Walkthrough for Python
2025-11-06 10:17:26 +00:00
Maria Shodunke
eb174b8700 Add review comments 2025-11-06 09:57:51 +00:00
Maria Shodunke
9e96d40799 Add Get Started Walkthrough for Python 2025-11-06 09:57:51 +00:00
Maria Shodunke
d6b55ab177 Merge pull request #3375 from XRPLF/build-fix
Fix for build failure
2025-11-06 09:31:21 +00:00
Maria Shodunke
d8b216bdd7 Fix for build failure 2025-11-05 14:43:17 +00:00
mDuo13
e3ee7bf32f Update source links in admin api refs & elsewhere 2025-10-30 14:15:03 -07:00
Rome Reginelli
1e095599fd Merge pull request #3345 from XRPLF/dependabot/npm_and_yarn/multi-fa24b26d6e
Bump hono and @redocly/realm
2025-10-30 13:47:27 -07:00
Rome Reginelli
d27888182c Merge pull request #3370 from XRPLF/fix_src_links_public_apis
Update source links in public API methods
2025-10-30 13:42:22 -07:00
mDuo13
7dd37e6b19 Clean up path_find formatting 2025-10-30 13:38:04 -07:00
mDuo13
3347fc965d Remove note about MultiSign amendment (unconditionalized) 2025-10-30 11:55:09 -07:00
mDuo13
30c8e22eeb Fix source links in public API method pages 2025-10-30 01:52:48 -07:00
Rome Reginelli
8d2d3850ec Merge pull request #3368 from XRPLF/rwa-updates
Refactor RWA tokenization buttons
2025-10-29 12:20:26 -07:00
akcodez
c7961f692e use Link component for link 2025-10-29 12:17:21 -07:00
akcodez
dbcdb508aa add arrow to get started now 2025-10-29 12:15:59 -07:00
akcodez
982386d0f6 Update CompanyLogo component to use anchor tag for external links, enhancing accessibility and security with target and rel attributes. 2025-10-29 07:36:34 -07:00
akcodez
9dde1114ca remove arrow from internal link 2025-10-29 07:32:47 -07:00
akcodez
4ee47a63dc fix css build issues 2025-10-29 07:29:41 -07:00
Rome Reginelli
41b07a458e Merge pull request #3364 from XRPLF/fix_links_from_concepts
Fix source links in concepts and infrastructure sections
2025-10-28 14:12:58 -07:00
Rome Reginelli
e6765094a9 Merge pull request #3365 from XRPLF/fix_links_from_protocol_refs
Update links in protocol references
2025-10-28 13:56:23 -07:00
Maria Shodunke
fdcbc6c747 Merge pull request #3367 from XRPLF/kennyzlei/lending-protocol-faucet
Add new faucet configuration for Lending-Devnet
2025-10-28 16:07:44 +00:00
akcodez
5f3dc85e5b Refactor tokenization page layout and styles; update button structure and link behavior for improved responsiveness and user experience. 2025-10-27 12:11:40 -07:00
Kenny Lei
ea0c186fa0 Add new faucet configuration for Lending-Devnet 2025-10-27 09:30:51 -07:00
Maria Shodunke
31ff09c093 Merge pull request #3359 from XRPLF/mpt-metadata-schema
Add MPT Metadata Schema section to concept docs
2025-10-23 17:09:42 +01:00
mDuo13
3fa6394b09 Update links in protocol references 2025-10-22 16:03:12 -07:00
Rome Reginelli
4319594cf1 Merge pull request #3346 from XRPLF/contrib_titles_and_markdoc_tags
Update contributor documentation w/ more info
2025-10-22 15:03:45 -07:00
Rome Reginelli
7d9b9f7c17 Merge pull request #3360 from XRPLF/consistent_tx_examples
Add mainnet AMMCreate and OracleSet transaction examples
2025-10-22 15:03:18 -07:00
mDuo13
483c7c55e2 Adjust rate limiting log message example 2025-10-22 15:01:57 -07:00
Rome Reginelli
0d73d6d851 Merge pull request #3341 from XRPLF/fix_lsfammnode
Fix lsfAMMNode docs
2025-10-22 09:25:49 -07:00
mDuo13
408c0f27e8 Fix source links in concepts and infrastructure sections 2025-10-21 18:08:31 -07:00
oeggert
e7cb03a88d Merge pull request #3355 from XRPLF/remove-sidechain-devnet
remove mentions of Sidechain-Devnet
2025-10-21 14:29:05 -07:00
Rome Reginelli
18985ad7e5 Merge pull request #3356 from XRPLF/events-updates-2025-10-16
add xrpl hackathon, update image for italy hackathon
2025-10-21 14:12:27 -07:00
akcodez
09708e58de update event images 2025-10-21 08:57:03 -07:00
mDuo13
6e6247952f Revise contrib documentation per review 2025-10-20 17:56:06 -07:00
mDuo13
d7ca624269 Update translation contribution docs (fix #3239) 2025-10-20 17:53:19 -07:00
Rome Reginelli
d07d6dae6d Reword flags reminder per suggestion
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
2025-10-17 11:47:55 -07:00
Maria Shodunke
bc0c698692 Add MPT Metadata Schema section to concept docs
- Updates MPT Concept docs with metadata schema
- Updates issue-mpt-with-metdata example code with new schema changes.
2025-10-17 18:34:36 +01:00
Mayukha Vadari
878f1ba77c change URLs 2025-10-17 10:50:58 -04:00
Maria Shodunke
c83fc47941 Merge pull request #3328 from XRPLF/mptoken-authorize-transaction-sample
Add example JSON for MPTokenAuthorize transaction
2025-10-17 08:23:27 +01:00
akcodez
588da44a2e add xrpl hackathon, update image for italy hackathon 2025-10-16 09:12:14 -07:00
Maria Shodunke
f511a23ea2 Additional changes for other MPToken transactions 2025-10-16 12:08:25 +01:00
Maria Shodunke
20225b5f62 Update JSON + add Mainnet transaction 2025-10-16 11:36:10 +01:00
Mayukha Vadari
10c974249f remove mentions of Sidechain-Devnet 2025-10-15 18:03:36 -04:00
mDuo13
5d45562fc6 Add mainnet AMMCreate and OracleSet transaction examples 2025-10-15 11:40:05 -07:00
oeggert
befd012ffa Merge pull request #3350 from XRPLF/update-nft_history
Update nft_history command
2025-10-15 09:58:13 -07:00
Maria Shodunke
4481320636 Add example JSON for MPTokenAuthorize transaction 2025-10-14 17:03:15 +01:00
Maria Shodunke
62c1d31660 Merge pull request #3336 from XRPLF/token-escrow-amendment
Token escrow amendment updates/fixes
2025-10-14 09:38:10 +01:00
Rome Reginelli
522bf43aef Merge pull request #3352 from XRPLF/xrpl-events-updates-10-13-2025
feat: add new events and update existing event details
2025-10-13 12:59:18 -07:00
akcodez
b237a6a2f1 feat: add new events and update existing event details
- Introduced new events: XRPL Town Hall Meeting #5 and XRPL Aquarium Residency Demo Day #7 with relevant details.
- Updated the date format for the existing hackathon event.
- Replaced images for the hackathon event with the new Italy Hackathon image.
- Added new images for the Town Hall Meeting and Aquarium Residency events.
2025-10-13 12:13:56 -07:00
Maria Shodunke
3136af79a3 Remove Escrow amendment + fix admonition 2025-10-13 11:28:36 +01:00
Oliver Eggert
f248b92d0d update nft_history command with actual responses and notes about api_version 2 2025-10-10 15:51:51 -07:00
Maria Shodunke
9b9d186af1 Remove wrong fields 2025-10-10 22:39:22 +01:00
Rome Reginelli
e1b97f7dba Merge pull request #3349 from XRPLF/hackathon-descr-update
update vegas house hackathon description
2025-10-10 13:44:09 -07:00
akcodez
d46d04f7d8 update vegas house hackathon description 2025-10-10 12:16:11 -07:00
Maria Shodunke
e646e10537 Further updates for review 2025-10-10 17:47:25 +01:00
Maria Shodunke
f9df5652e4 Update docs/concepts/payment-types/escrow.md
Co-authored-by: Rome Reginelli <rome@ripple.com>
2025-10-10 12:21:10 +01:00
Maria Shodunke
ecec4b4833 Update docs/references/http-websocket-apis/public-api-methods/account-methods/account_channels.md
Co-authored-by: Rome Reginelli <rome@ripple.com>
2025-10-10 12:19:34 +01:00
Maria Shodunke
b93691a4c4 Update docs/references/http-websocket-apis/public-api-methods/account-methods/account_channels.md
Co-authored-by: Rome Reginelli <rome@ripple.com>
2025-10-10 12:19:19 +01:00
Maria Shodunke
26713099cf Update docs/references/protocol/ledger-data/ledger-entry-types/escrow.md
Co-authored-by: Rome Reginelli <rome@ripple.com>
2025-10-10 12:18:50 +01:00
Maria Shodunke
6154d7a9bd Update docs/references/protocol/transactions/types/accountset.md
Co-authored-by: Rome Reginelli <rome@ripple.com>
2025-10-10 12:18:20 +01:00
Maria Shodunke
7cdf35f032 Update escrow documentation 2025-10-09 18:57:53 +01:00
Rome Reginelli
904761dc51 Merge pull request #3348 from nzicko/fix/custom-plugins-imports
Fix broken imports in custom plugins for `@redocly/realm@0.126.0`
2025-10-09 10:47:49 -07:00
Nazarii Mykhailets
b2f345edd5 fix: imports in custom plugins 2025-10-09 13:01:08 +03:00
mDuo13
b1c8a33de9 Fix display of child pages in contributor documentation 2025-10-08 17:58:10 -07:00
mDuo13
755b15383b Update contributor documentation w/ more info
- Clarify frontmatter, especially titles
- Document more markdoc tags
2025-10-08 17:53:13 -07:00
Rome Reginelli
9b1878c512 Merge pull request #3344 from XRPLF/events-updates-2025-10-08
feat: add 2 new hackathons
2025-10-08 12:15:02 -07:00
dependabot[bot]
9e40756dd1 Bump hono and @redocly/realm
Bumps [hono](https://github.com/honojs/hono) to 4.9.7 and updates ancestor dependency @redocly/realm. These dependencies need to be updated together.


Updates `hono` from 4.6.5 to 4.9.7
- [Release notes](https://github.com/honojs/hono/releases)
- [Commits](https://github.com/honojs/hono/compare/v4.6.5...v4.9.7)

Updates `@redocly/realm` from 0.122.3 to 0.126.0

---
updated-dependencies:
- dependency-name: hono
  dependency-version: 4.9.7
  dependency-type: indirect
- dependency-name: "@redocly/realm"
  dependency-version: 0.126.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-10-08 19:13:43 +00:00
Rome Reginelli
b08d7f085f Merge pull request #3329 from XRPLF/update_desktop_wallet_js_tutorial
Update Desktop Wallet (JS) tutorial
2025-10-08 12:11:57 -07:00
Rome Reginelli
56ac023098 Apply suggestions from @maria-robobug review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
2025-10-07 14:49:48 -07:00
mDuo13
b2aa96e283 Fix lsfAMMNode docs 2025-10-07 12:21:26 -07:00
mDuo13
fd82a05ca1 Fix links in desktop wallet tutorial & update some details 2025-10-02 13:01:26 -07:00
mDuo13
929a4cbced Update Desktop Wallet (JS) tutorial dependencies, copy edits 2025-10-01 13:37:04 -07:00
196 changed files with 5414 additions and 3443 deletions

View File

@@ -17,8 +17,6 @@ Para ayudar a miembros de la comunidad del XRP Ledger a interactuar con la tecno
| Mainnet | Lanzamientos estables | _El_ [XRP Ledger](/about/), un libro contable criptográfico descentralizado impulsado por una red de servidores peer-to-peer y el hogar de [XRP](../../introduction/what-is-xrp.md). |
| Testnet | Lanzamientos estables | Una red de "universo alternativo" que actua como un campo de pruebas para el software construido en el XRP Ledger, sin impactar a los usuarios del XRP Ledger de producción y sin arriesgar dinero real. El [estado de enmienda](/resources/known-amendments.md) de Testnet está destinado a reflejar de cerca el de la Mainnet, aunque pueden ocurrir ligeras variaciones en el tiempo debido a la naturaleza impredecible de los sistemas descentralizados. |
| Devnet | Lanzamientos Beta | Una vista previa de las próximas atracciones, donde cambios inestables en el software principal de XRP Ledger se pueden probar. Los desarrolladores pueden utilizar esta altnet para interactuar y aprender sobre funcionalidades nuevas planficiadas para el XRP Ledger y enmiendas que no están habilitadas en la Mainnet. |
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Servidor Hooks](https://github.com/XRPL-Labs/xrpld-hooks) | Una vista previa de la funcionalidad de smart contract en la cadena utilizando [hooks](https://xrpl-hooks.readme.io/). |
| Sidechain-Devnet | Lanzamientos Beta | Una sidechain para probar funcionalidades en puentes cross-chain. Devnet se trata como la cadena de bloqueo y esta sidechain es la cadena de emisión.<br>Soporte a la librería:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**Nota**: También puedes usar la herramienta de línea de comandos [`xbridge-cli`](https://github.com/XRPLF/xbridge-cli) para configurar un puente entre cadenas en tu máquina local. |
Cada altnet tiene su propia distribución separada de XRP de prueba, que se [regala gratis](/resources/dev-tools/xrp-faucets) a partes interesadas en experimentar con el XRP Ledger y desarrollar aplicaciones e integraciones. El XRP test no tiene valor en el mundo real y se pierde cuando la red se reinicia.

View File

@@ -17,8 +17,6 @@ XRP Ledgerコミュニティのメンバーが、メインネットに影響を
| Mainnet | 安定版リリース | ピアツーピアサーバのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](../../introduction/what-is-xrp.md)の土台となる[XRP Ledger](/about/)です。 |
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワークです。本番環境のXRP Ledgerユーザに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](/resources/known-amendments.md)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
| Devnet | ベータ版リリース | 次期リリースのプレビューネットワークです。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Hooksサーバ](https://github.com/XRPL-Labs/xrpld-hooks) | [Hooks](https://xrpl-hooks.readme.io/)を使用したオンチェーン・スマートコントラクト機能のプレビューネットワークです。 |
| Sidechain-Devnet | ベータ版リリース | クロスチェーンブリッジ機能をテストするためのサイドチェーンです。<br>ライブラリのサポート:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**注記**: また、[`xbridge-cli`](https://github.com/XRPLF/xbridge-cli)コマンドラインツールを使用して、ローカルマシンにクロスチェーンブリッジをセットアップすることもできます。 |
テスト用XRPは、XRP Ledgerの実験やアプリケーションの開発、統合に興味のある人々に[無償で提供](/resources/dev-tools/xrp-faucets)されています。テスト用のXRPは実際には価値を持たず、ネットワークがリセットされると失われます。

View File

@@ -43,11 +43,6 @@ labels:
# No [ips] stanza. Use the default hubs to connect to Mainnet.
```
```{% label="Sidechain-Devnet" %}
[ips]
sidechain-net2.devnet.rippletest.net 51235
```
{% /tabs %}
2. 以前の `[ips]`があれば、コメントアウトしてください。
@@ -78,11 +73,6 @@ labels:
main
```
```{% label="Sidechain-Devnet" %}
[network_id]
262
```
{% /tabs %}
カスタムネットワークの場合、そのネットワークに接続する全員が、そのネットワークに固有の値を使用する必要があります。新しいネットワークを作成するときは、ネットワークIDを11から4,294,967,295までの整数からランダムに選択します。
@@ -121,14 +111,6 @@ labels:
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
```
```{% label="Sidechain-Devnet" %}
[validator_list_sites]
https://vlsidechain-net2.devnet.rippletest.net
[validator_list_keys]
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
```
{% /tabs %}
{% admonition type="success" name="ヒント" %}プレビュー版パッケージには必要な項目があらかじめ設定されている場合がありますが、念のため確認してください。{% /admonition %}
@@ -182,13 +164,6 @@ labels:
```
{% /tab %}
{% tab label="Sidechain-Devnet" %}
```
[features]
XChainBridge
```
{% /tab %}
{% /tabs %}
{% admonition type="danger" name="警告" %}メインネットまたはテストネットに接続するときは、`[features]`を使用しないでください。他のネットワークと異なる機能を強制的に有効にすると、サーバがネットワークから分断される可能性があります。{% /admonition %}

View File

@@ -26,7 +26,6 @@ labels:
| Ripple[¹][] | Testnet (Clio) | `https://clio.altnet.rippletest.net:51234/` | `wss://clio.altnet.rippletest.net:51233/` | Clioを使用したTestnet公開サーバ |
| Ripple[¹][] | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net:51233/` | Devnet 公開サーバ |
| Ripple[¹][] | Devnet (Clio) | `https://clio.devnet.rippletest.net:51234/` | `wss://clio.devnet.rippletest.net:51233/` | Clioを使用したDevnet公開サーバ |
| Ripple[¹][] | Sidechain-Devnet | `https://sidechain-net2.devnet.rippletest.net:51234/` | `wss://sidechain-net2.devnet.rippletest.net:51233/` | クロスチェーンブリッジ機能をテストするためのサイドチェーンDevnet。Devnetはロックチェーンとして機能し、このサイドチェーンは発行チェーンとして機能します。 |
| XRPL Labs | Xahau Testnet | `https://xahau-test.net/` | `wss://xahau-test.net/` | [Hooksが有効](https://hooks.xrpl.org/)なXahau Testnet |
[ネットワーク]: ../concepts/networks-and-servers/parallel-networks.md

View File

@@ -326,7 +326,7 @@ export function AmendmentDisclaimer(props: {
) : (
<>
{translate("component.amendment-status.updates.1", "The ")}{link()}
{translate("component.amendment-status.updates.2", "updates this.")}
{translate("component.amendment-status.updates.2", " updates this.")}
{" "}
<AmendmentBadge amendment={amendmentStatus} />
</>

View File

@@ -1,6 +1,6 @@
// @ts-check
import { getInnerText } from '@redocly/realm/dist/shared/markdoc.js';
import { getInnerText } from '@redocly/realm/dist/server/plugins/markdown/markdoc/helpers/get-inner-text.js';
import { dirname, relative, join as joinPath } from 'path';
import markdoc from '@markdoc/markdoc';
@@ -47,6 +47,7 @@ export function blogPosts() {
actions.createSharedData('blog-posts', { blogPosts: sortedPosts });
actions.addRouteSharedData('/blog/', 'blog-posts', 'blog-posts');
actions.addRouteSharedData('/ja/blog/', 'blog-posts', 'blog-posts');
actions.addRouteSharedData('/es-es/blog/', 'blog-posts', 'blog-posts');
} catch (e) {
console.log(e);
}

View File

@@ -1,6 +1,6 @@
// @ts-check
import { getInnerText } from '@redocly/realm/dist/shared/markdoc.js';
import { getInnerText } from '@redocly/realm/dist/server/plugins/markdown/markdoc/helpers/get-inner-text.js';
import { dirname, relative, join as joinPath } from 'path';
@@ -44,6 +44,7 @@ export function codeSamples() {
});
actions.addRouteSharedData('/resources/code-samples/', 'code-samples', 'code-samples');
actions.addRouteSharedData('/ja/resources/code-samples/', 'code-samples', 'code-samples');
actions.addRouteSharedData('/es-es/resources/code-samples/', 'code-samples', 'code-samples');
} catch (e) {
console.log(e);
}

View File

@@ -0,0 +1,15 @@
{
"alternatives": [
// ... paths omitted from this example; same format as the initial response ...
],
"destination_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"destination_amount": {
"currency": "USD",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"value": "0.001"
},
"full_reply": true,
"id": 8,
"source_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"type": "path_find"
}

View File

@@ -0,0 +1,75 @@
{
"id": 8,
"result": {
"alternatives": [
{
"paths_computed": [
[
{
"currency": "USD",
"issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
"type": 48
},
{
"account": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
"type": 1
},
{
"account": "rLzpfEnrB2Ro2LtaGd6Af7znRqGxULc4rW",
"type": 1
}
],
[
{
"currency": "USD",
"issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
"type": 48
},
{
"account": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
"type": 1
},
{
"account": "rQhbp2h133vD3TJGWkNY5zePHKQUq6vSVm",
"type": 1
}
],
[
{
"currency": "USD",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"type": 48
}
],
[
{
"currency": "USD",
"issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
"type": 48
},
{
"account": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
"type": 1
},
{
"account": "r4cjaKtZqP2GDjwK3eT9qua4Hqk9Zk2kSy",
"type": 1
}
]
],
"source_amount": "390"
}
],
"destination_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"destination_amount": {
"currency": "USD",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"value": "0.001"
},
"full_reply": false,
"id": 8,
"source_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
},
"status": "success",
"type": "response"
}

View File

@@ -1,4 +1,5 @@
# Batch
Code samples showing how to create and submit a [Batch transaction](../../docs/concepts/transactions/batch-transactions.md).
Both for simple and multi account batch transactions.
Code samples showing how to create and submit a [Batch transaction](https://xrpl.org/docs/concepts/transactions/batch-transactions).
Both for single and multi-account batch transactions.

View File

@@ -0,0 +1,301 @@
# Send a Batch Transaction
Code samples showing how to create and submit a [Batch transaction](https://xrpl.org/docs/concepts/transactions/batch-transactions) with Javascript.
Both for single and multi-account batch transactions.
## Single Account Batch Transaction
Quick setup and usage:
```sh
npm install xrpl
node singleAccountBatch.js
```
The script should output the following:
```sh
=== Funding new wallets from faucet... ===
Sender: rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim, Balance: 100 XRP
Wallet1: rGx6SACvYEvX8SRrvTPD91UhBmJ16pxL94, Balance: 100 XRP
Wallet2: r3qetgSfAtyCpGc4rvKNz4LX3F3urMSJJy, Balance: 100 XRP
=== Creating Batch transaction... ===
{
"TransactionType": "Batch",
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Flags": 65536,
"RawTransactions": [
{
"RawTransaction": {
"TransactionType": "Payment",
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Destination": "rGx6SACvYEvX8SRrvTPD91UhBmJ16pxL94",
"Amount": "2000000",
"Flags": 1073741824
}
},
{
"RawTransaction": {
"TransactionType": "Payment",
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Destination": "r3qetgSfAtyCpGc4rvKNz4LX3F3urMSJJy",
"Amount": "5000000",
"Flags": 1073741824
}
}
]
}
=== Submitting Batch transaction... ===
Batch transaction submitted successfully!
Result:
{
"close_time_iso": "2025-11-17T12:04:50Z",
"ctid": "C013313800030002",
"hash": "AE118213B0A183528418ABC5F14E3BFD6524020C5DB1C060157A0D3FDE15B900",
"ledger_hash": "621183809B68A794371C5EC6522105FF04E502C48EBDC8171B80224991E33394",
"ledger_index": 1257784,
"meta": {
"AffectedNodes": [
{
"ModifiedNode": {
"FinalFields": {
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Balance": "99999996",
"Flags": 0,
"OwnerCount": 0,
"Sequence": 1257779
},
"LedgerEntryType": "AccountRoot",
"LedgerIndex": "42CC98AF0A28EDDDC7E359B5622CC5748BDE2A93E124AF5C32647ECA8F68D480",
"PreviousFields": {
"Balance": "100000000",
"Sequence": 1257778
},
"PreviousTxnID": "081C42DAE12001735AC4E9A7F027636DF612DB17B4BFA2333F4DB8EA0C9D1E9F",
"PreviousTxnLgrSeq": 1257778
}
}
],
"TransactionIndex": 3,
"TransactionResult": "tesSUCCESS"
},
"tx_json": {
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Fee": "4",
"Flags": 65536,
"LastLedgerSequence": 1257802,
"RawTransactions": [
{
"RawTransaction": {
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Amount": "2000000",
"Destination": "rGx6SACvYEvX8SRrvTPD91UhBmJ16pxL94",
"Fee": "0",
"Flags": 1073741824,
"Sequence": 1257779,
"SigningPubKey": "",
"TransactionType": "Payment"
}
},
{
"RawTransaction": {
"Account": "rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim",
"Amount": "5000000",
"Destination": "r3qetgSfAtyCpGc4rvKNz4LX3F3urMSJJy",
"Fee": "0",
"Flags": 1073741824,
"Sequence": 1257780,
"SigningPubKey": "",
"TransactionType": "Payment"
}
}
],
"Sequence": 1257778,
"SigningPubKey": "ED7031CA5BA4EC745610AB495F5053F318C119E87567BE485A494773AD8ED4FBCE",
"TransactionType": "Batch",
"TxnSignature": "0610A277086943BC462C1A5F85BEB667B62B4BDA59525138B6014101C08297897A73D3D2D247CB37A06E1EA36267C53A51C0FDF32F3D8E974029BEDC41105B07",
"ctid": "C013313800030002",
"date": 816696290,
"ledger_index": 1257784
},
"validated": true
}
Batch transaction URL:
https://devnet.xrpl.org/transactions/AE118213B0A183528418ABC5F14E3BFD6524020C5DB1C060157A0D3FDE15B900
=== Verifying inner transactions... ===
Transaction 1 hash: D18EA54D5653BBB5C87F116978822EAB7A26EDFB1D6C41910F36D7484D4890E3
- Status: tesSUCCESS (Ledger 1257784)
- Transaction URL: https://devnet.xrpl.org/transactions/D18EA54D5653BBB5C87F116978822EAB7A26EDFB1D6C41910F36D7484D4890E3
Transaction 2 hash: 5660DB400F08EE5543C54D4D65824A2142F9D5AC17294A4ABF654260F129B44E
- Status: tesSUCCESS (Ledger 1257784)
- Transaction URL: https://devnet.xrpl.org/transactions/5660DB400F08EE5543C54D4D65824A2142F9D5AC17294A4ABF654260F129B44E
=== Final balances ===
Sender: rP9EsVosrmx2HyrmLgWJpJacX5ZrVVQsim, Balance: 92.999996 XRP
Wallet1: rGx6SACvYEvX8SRrvTPD91UhBmJ16pxL94, Balance: 102 XRP
Wallet2: r3qetgSfAtyCpGc4rvKNz4LX3F3urMSJJy, Balance: 105 XRP
```
## Multi-Account Batch Transaction
```sh
npm install xrpl
node multiAccountBatch.js
```
The script should output the following:
```sh
=== Funding new wallets from faucet... ===
Alice: rHpve1GL2ZXUs3NB5iU91BrXBSwb5PbBrG, Balance: 100 XRP
Bob: r3ruQ92bqXwWxcR2w4cC1tW35og9h3UbBq, Balance: 100 XRP
Charlie: rsi5D9bkczpbGykPxoGNBVVmFFFXGwm3QA, Balance: 100 XRP
Third-party wallet: rfUpGXTzU3siTr4UovV6Wt86Vw3gQU4ttA, Balance: 100 XRP
=== Creating Batch transaction... ===
{
"TransactionType": "Batch",
"Account": "rfUpGXTzU3siTr4UovV6Wt86Vw3gQU4ttA",
"Flags": 65536,
"RawTransactions": [
{
"RawTransaction": {
"TransactionType": "Payment",
"Account": "rsi5D9bkczpbGykPxoGNBVVmFFFXGwm3QA",
"Destination": "rHpve1GL2ZXUs3NB5iU91BrXBSwb5PbBrG",
"Amount": "50000000",
"Flags": 1073741824
}
},
{
"RawTransaction": {
"TransactionType": "Payment",
"Account": "r3ruQ92bqXwWxcR2w4cC1tW35og9h3UbBq",
"Destination": "rHpve1GL2ZXUs3NB5iU91BrXBSwb5PbBrG",
"Amount": "50000000",
"Flags": 1073741824
}
}
]
}
=== Submitting Batch transaction... ===
Batch transaction submitted successfully!
Result:
{
"close_time_iso": "2025-11-17T12:08:31Z",
"ctid": "C013317600000002",
"hash": "1299D20C6B489DA5C632AE4DBE49475DBF42D9444C7E9C109CC9B8DD0FD55FEC",
"ledger_hash": "E45ECF69057084CD02BA49A17E4D0C9154D33A98BB3C95A11B2EB9BE18F32C9B",
"ledger_index": 1257846,
"meta": {
"AffectedNodes": [
{
"ModifiedNode": {
"FinalFields": {
"Account": "rfUpGXTzU3siTr4UovV6Wt86Vw3gQU4ttA",
"Balance": "99999994",
"Flags": 0,
"OwnerCount": 0,
"Sequence": 1257845
},
"LedgerEntryType": "AccountRoot",
"LedgerIndex": "2D9E0A02007241C38A8DF679E7E62AA0B273E8B12A5430B7B9D99300424F0E1F",
"PreviousFields": {
"Balance": "100000000",
"Sequence": 1257844
},
"PreviousTxnID": "3153DE8DE922538A6BE54AA8F783CAD4B848A321AFF028D3E6DD0E80C4B9C237",
"PreviousTxnLgrSeq": 1257844
}
}
],
"TransactionIndex": 0,
"TransactionResult": "tesSUCCESS"
},
"tx_json": {
"Account": "rfUpGXTzU3siTr4UovV6Wt86Vw3gQU4ttA",
"BatchSigners": [
{
"BatchSigner": {
"Account": "rsi5D9bkczpbGykPxoGNBVVmFFFXGwm3QA",
"SigningPubKey": "EDEB88C2868BD25BF03DB26050E16579FA6F8F9E3FF3172E0DC3DCBDA5408572EB",
"TxnSignature": "9508568084596147CFDCFC18A62DC298A78AD1148BA4B0EB99BEE1CD37E5555FE3930810790D5708F9739B0E3F79772012C154CA33C2280BDD5B72473C17A607"
}
},
{
"BatchSigner": {
"Account": "r3ruQ92bqXwWxcR2w4cC1tW35og9h3UbBq",
"SigningPubKey": "ED82F98DA6A3FC3E88D2EE3A5469D92C7070513BEF4DEE75CAB0BDAA81E8AE378D",
"TxnSignature": "A482C8747F79857530474F1677599766C0BE283CB7E2A05AACF76E61BECCA16DCE3802D2D8244FBF4546A1C0E5EB70691255E3EFD2F8AC80B55357BDAB9ACD05"
}
}
],
"Fee": "6",
"Flags": 65536,
"LastLedgerSequence": 1257864,
"RawTransactions": [
{
"RawTransaction": {
"Account": "rsi5D9bkczpbGykPxoGNBVVmFFFXGwm3QA",
"Amount": "50000000",
"Destination": "rHpve1GL2ZXUs3NB5iU91BrXBSwb5PbBrG",
"Fee": "0",
"Flags": 1073741824,
"Sequence": 1257842,
"SigningPubKey": "",
"TransactionType": "Payment"
}
},
{
"RawTransaction": {
"Account": "r3ruQ92bqXwWxcR2w4cC1tW35og9h3UbBq",
"Amount": "50000000",
"Destination": "rHpve1GL2ZXUs3NB5iU91BrXBSwb5PbBrG",
"Fee": "0",
"Flags": 1073741824,
"Sequence": 1257841,
"SigningPubKey": "",
"TransactionType": "Payment"
}
}
],
"Sequence": 1257844,
"SigningPubKey": "ED22A32B61EDF083315515831723BC18F8311F03886BBA375DFF46335BB7A75F0B",
"TransactionType": "Batch",
"TxnSignature": "156791D2DBFAEFC9B0AC29F2D8D0CDB25E13F92E70E6D5414FE31BD8573CA23D3F62F8B34FC1F117BD556B25E4F748095A24C4342108AB32F1B2BAFBF1443501",
"ctid": "C013317600000002",
"date": 816696511,
"ledger_index": 1257846
},
"validated": true
}
Batch transaction URL:
https://devnet.xrpl.org/transactions/1299D20C6B489DA5C632AE4DBE49475DBF42D9444C7E9C109CC9B8DD0FD55FEC
=== Verifying inner transactions ===
Transaction 1 hash: 0F71979E3F641C980929F926640DCA886C30236ED0CD7C94B6CB36F0D42948AC
- Status: tesSUCCESS (Ledger 1257846)
- Transaction URL: https://devnet.xrpl.org/transactions/0F71979E3F641C980929F926640DCA886C30236ED0CD7C94B6CB36F0D42948AC
Transaction 2 hash: BC124CB29334AA1079139A9BE186B69A0AC467797F147754E2406714854D2A50
- Status: tesSUCCESS (Ledger 1257846)
- Transaction URL: https://devnet.xrpl.org/transactions/BC124CB29334AA1079139A9BE186B69A0AC467797F147754E2406714854D2A50
=== Final balances ===
Alice: rHpve1GL2ZXUs3NB5iU91BrXBSwb5PbBrG, Balance: 200 XRP
Bob: r3ruQ92bqXwWxcR2w4cC1tW35og9h3UbBq, Balance: 50 XRP
Charlie: rsi5D9bkczpbGykPxoGNBVVmFFFXGwm3QA, Balance: 50 XRP
Third-party wallet: rfUpGXTzU3siTr4UovV6Wt86Vw3gQU4ttA, Balance: 99.999994 XRP
```

View File

@@ -0,0 +1,143 @@
/**
* XRP Ledger Batch Transactions Tutorial
*
* This tutorial demonstrates how to use the Batch transaction feature (XLS-56)
* to perform a multi-account batch transaction.
* Concept doc: https://xrpl.org/docs/concepts/transactions/batch-transactions
* Reference doc: https://xrpl.org/docs/references/protocol/transactions/types/batch
*/
import xrpl from "xrpl"
const client = new xrpl.Client("wss://s.devnet.rippletest.net:51233/")
await client.connect()
// Create and fund wallets
console.log("=== Funding new wallets from faucet... ===");
const [
{ wallet: alice },
{ wallet: bob },
{ wallet: charlie },
{ wallet: thirdPartyWallet },
] = await Promise.all([
client.fundWallet(),
client.fundWallet(),
client.fundWallet(),
client.fundWallet(),
]);
console.log(`Alice: ${alice.address}, Balance: ${await client.getXrpBalance(alice.address)} XRP`)
console.log(`Bob: ${bob.address}, Balance: ${await client.getXrpBalance(bob.address)} XRP`)
console.log(`Charlie: ${charlie.address}, Balance: ${await client.getXrpBalance(charlie.address)} XRP`)
console.log(`Third-party wallet: ${thirdPartyWallet.address}, Balance: ${await client.getXrpBalance(thirdPartyWallet.address)} XRP`)
// Create inner transactions --------------------------------------------
// REQUIRED: Inner transactions MUST have the tfInnerBatchTxn flag (0x40000000).
// This marks them as part of a batch (requires Fee: 0 and empty SigningPubKey).
// Transaction 1: Charlie pays Alice
const charliePayment = {
TransactionType: "Payment",
Account: charlie.address,
Destination: alice.address,
Amount: xrpl.xrpToDrops(50),
Flags: xrpl.GlobalFlags.tfInnerBatchTxn // THIS IS REQUIRED
}
// Transaction 2: Bob pays Alice
const bobPayment = {
TransactionType: "Payment",
Account: bob.address,
Destination: alice.address,
Amount: xrpl.xrpToDrops(50),
Flags: xrpl.GlobalFlags.tfInnerBatchTxn // THIS IS REQUIRED
}
// Send Batch transaction --------------------------------------------
console.log("\n=== Creating Batch transaction... ===")
const batchTx = {
TransactionType: "Batch",
Account: thirdPartyWallet.address,
Flags: xrpl.BatchFlags.tfAllOrNothing, // tfAllOrNothing: All inner transactions must succeed
// Must include a minimum of 2 transactions and a maximum of 8 transactions.
RawTransactions: [
{ RawTransaction: charliePayment },
{ RawTransaction: bobPayment },
]
}
console.log(JSON.stringify(batchTx, null, 2))
// Validate the transaction structure
xrpl.validate(batchTx)
// Set the expected number of signers, which is 2 (Bob and Charlie) in this case, for this transaction.
// "autofill" will automatically add Fee: "0" and SigningPubKey: "" to inner transactions.
const autofilledBatchTx = await client.autofill(batchTx, 2)
// Gather batch signatures --------------------------------
// Each signer needs their own tx copy because signMultiBatch modifies the object.
// Charlie signs the Batch transaction
const charlieBatch = { ...autofilledBatchTx }
xrpl.signMultiBatch(charlie, charlieBatch)
// Bob signs the Batch transaction
const bobBatch = { ...autofilledBatchTx }
xrpl.signMultiBatch(bob, bobBatch)
// Combine inner transaction signatures.
// This returns a signed transaction blob (hex string) ready for submission.
const combinedSignedTx = xrpl.combineBatchSigners([charlieBatch, bobBatch])
// Submit the signed blob with the third-party's wallet
console.log("\n=== Submitting Batch transaction... ===")
const submitResponse = await client.submitAndWait(combinedSignedTx,
{ wallet: thirdPartyWallet }
)
// Check Batch transaction result --------------------------------
if (submitResponse.result.meta.TransactionResult !== "tesSUCCESS") {
const resultCode = submitResponse.result.meta.TransactionResult
console.warn(`\nTransaction failed with result code ${resultCode}`)
await client.disconnect()
process.exit(1)
}
console.log("\nBatch transaction submitted successfully!")
console.log("Result:\n", JSON.stringify(submitResponse.result, null, 2))
// View the transaction on the XRPL Explorer
console.log(`\nBatch transaction URL:\nhttps://devnet.xrpl.org/transactions/${submitResponse.result.hash}`)
// Calculate and verify inner transaction hashes --------------------------------------------
console.log("\n=== Verifying inner transactions ===")
const rawTransactions = submitResponse.result.tx_json.RawTransactions
let hasFailure = false
for (let i = 0; i < rawTransactions.length; i++) {
const innerTx = rawTransactions[i].RawTransaction
const hash = xrpl.hashes.hashSignedTx(innerTx)
console.log(`\nTransaction ${i + 1} hash: ${hash}`)
try {
const tx = await client.request({ command: 'tx', transaction: hash })
const status = tx.result.meta?.TransactionResult
console.log(` - Status: ${status} (Ledger ${tx.result.ledger_index})`)
console.log(` - Transaction URL: https://devnet.xrpl.org/transactions/${hash}`)
} catch (error) {
hasFailure = true
console.log(` - Transaction not found: ${error}`)
}
}
if (hasFailure) {
console.error("\n--- Error: One or more inner transactions failed. ---")
await client.disconnect()
process.exit(1)
}
// Verify balances after transaction
console.log("\n=== Final balances ===")
console.log(`Alice: ${alice.address}, Balance: ${await client.getXrpBalance(alice.address)} XRP`)
console.log(`Bob: ${bob.address}, Balance: ${await client.getXrpBalance(bob.address)} XRP`)
console.log(`Charlie: ${charlie.address}, Balance: ${await client.getXrpBalance(charlie.address)} XRP`)
console.log(`Third-party wallet: ${thirdPartyWallet.address}, Balance: ${await client.getXrpBalance(thirdPartyWallet.address)} XRP`)
await client.disconnect()

View File

@@ -0,0 +1,6 @@
{
"dependencies": {
"xrpl": "^4.4.3"
},
"type": "module"
}

View File

@@ -0,0 +1,120 @@
/**
* Single Account Batch Transaction Example
*
* This example demonstrates how to use the Batch transactions feature (XLS-56)
* to create a single-account batch transaction that sends payments
* to multiple destinations in one atomic operation.
* Concept doc: https://xrpl.org/docs/concepts/transactions/batch-transactions
* Reference doc: https://xrpl.org/docs/references/protocol/transactions/types/batch
*/
import xrpl from "xrpl"
const client = new xrpl.Client("wss://s.devnet.rippletest.net:51233/")
await client.connect()
// Create and fund wallets
console.log("=== Funding new wallets from faucet... ===");
const [{ wallet: sender }, { wallet: wallet1 }, { wallet: wallet2 }] =
await Promise.all([
client.fundWallet(),
client.fundWallet(),
client.fundWallet(),
]);
console.log(`Sender: ${sender.address}, Balance: ${await client.getXrpBalance(sender.address)} XRP`)
console.log(`Wallet1: ${wallet1.address}, Balance: ${await client.getXrpBalance(wallet1.address)} XRP`)
console.log(`Wallet2: ${wallet2.address}, Balance: ${await client.getXrpBalance(wallet2.address)} XRP`)
// Create inner transactions --------------------------------------------
// REQUIRED: Inner transactions MUST have the tfInnerBatchTxn flag (0x40000000).
// This marks them as part of a batch (requires Fee: 0 and empty SigningPubKey).
// Transaction 1
const payment1 = {
TransactionType: "Payment",
Account: sender.address,
Destination: wallet1.address,
Amount: xrpl.xrpToDrops(2),
Flags: xrpl.GlobalFlags.tfInnerBatchTxn // THIS IS REQUIRED
}
// Transaction 2
const payment2 = {
TransactionType: "Payment",
Account: sender.address,
Destination: wallet2.address,
Amount: xrpl.xrpToDrops(5),
Flags: xrpl.GlobalFlags.tfInnerBatchTxn // THIS IS REQUIRED
}
// Send Batch transaction --------------------------------------------
console.log("\n=== Creating Batch transaction... ===")
const batchTx = {
TransactionType: "Batch",
Account: sender.address,
Flags: xrpl.BatchFlags.tfAllOrNothing, // tfAllOrNothing: All inner transactions must succeed
// Must include a minimum of 2 transactions and a maximum of 8 transactions.
RawTransactions: [
{ RawTransaction: payment1 },
{ RawTransaction: payment2 }
]
}
console.log(JSON.stringify(batchTx, null, 2))
// Validate the transaction structure before submitting
xrpl.validate(batchTx)
// Submit and wait for validation
console.log("\n=== Submitting Batch transaction... ===")
const submitResponse = await client.submitAndWait(batchTx, {
wallet: sender,
// "autofill" will automatically add Fee: "0" and SigningPubKey: "" to inner transactions.
autofill: true
})
// Check Batch transaction result --------------------------------
if (submitResponse.result.meta.TransactionResult !== "tesSUCCESS") {
const resultCode = submitResponse.result.meta.TransactionResult
console.warn(`\nTransaction failed with result code ${resultCode}`)
await client.disconnect()
process.exit(1)
}
console.log("\nBatch transaction submitted successfully!")
console.log("Result:\n", JSON.stringify(submitResponse.result, null, 2))
// View the batch transaction on the XRPL Explorer
console.log(`\nBatch transaction URL:\nhttps://devnet.xrpl.org/transactions/${submitResponse.result.hash}`)
// Calculate and verify inner transaction hashes --------------------------------------------
console.log("\n=== Verifying inner transactions... ===")
const rawTransactions = submitResponse.result.tx_json.RawTransactions
let hasFailure = false
for (let i = 0; i < rawTransactions.length; i++) {
const innerTx = rawTransactions[i].RawTransaction
const hash = xrpl.hashes.hashSignedTx(innerTx)
console.log(`\nTransaction ${i + 1} hash: ${hash}`)
try {
const tx = await client.request({ command: 'tx', transaction: hash })
const status = tx.result.meta?.TransactionResult
console.log(` - Status: ${status} (Ledger ${tx.result.ledger_index})`)
console.log(` - Transaction URL: https://devnet.xrpl.org/transactions/${hash}`)
} catch (error) {
hasFailure = true
console.log(` - Transaction not found: ${error}`)
}
}
if (hasFailure) {
console.error("\n--- Error: One or more inner transactions failed. ---")
await client.disconnect()
process.exit(1)
}
// Verify balances after transaction
console.log("\n=== Final balances ===")
console.log(`Sender: ${sender.address}, Balance: ${await client.getXrpBalance(sender.address)} XRP`)
console.log(`Wallet1: ${wallet1.address}, Balance: ${await client.getXrpBalance(wallet1.address)} XRP`)
console.log(`Wallet2: ${wallet2.address}, Balance: ${await client.getXrpBalance(wallet2.address)} XRP`)
await client.disconnect()

View File

@@ -3,20 +3,19 @@ const { app, BrowserWindow } = require('electron')
const path = require('path')
/**
* This is our main function, it creates our application window, preloads the code we will need to communicate
* between the renderer Process and the main Process, loads a layout and performs the main logic
* Main function: create application window, preload the code to communicate
* between the renderer Process and the main Process, load a layout,
* and perform the main logic.
*/
const createWindow = () => {
// Creates the application window
// Create the application window
const appWindow = new BrowserWindow({
width: 1024,
height: 768
})
// Loads a layout
// Load a layout
appWindow.loadFile(path.join(__dirname, 'view', 'template.html'))
return appWindow
}

View File

@@ -1,40 +1,37 @@
const { app, BrowserWindow } = require('electron')
const path = require('path')
const xrpl = require("xrpl")
// Ledger index code additions - start
const xrpl = require('xrpl')
const TESTNET_URL = "wss://s.altnet.rippletest.net:51233"
const TESTNET_URL = 'wss://s.altnet.rippletest.net:51233'
/**
* This function creates a WebService client, which connects to the XRPL and fetches the latest ledger index.
* Create a WebSocket client, connect to the XRPL, and fetch the latest ledger index.
*
* @returns {Promise<number>}
*/
const getValidatedLedgerIndex = async () => {
const client = new xrpl.Client(TESTNET_URL)
await client.connect()
// Reference: https://xrpl.org/ledger.html#ledger
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger
const ledgerRequest = {
"command": "ledger",
"ledger_index": "validated"
}
const ledgerResponse = await client.request(ledgerRequest)
await client.disconnect()
return ledgerResponse.result.ledger_index
}
// Ledger index code additions - end
/**
* This is our main function, it creates our application window, preloads the code we will need to communicate
* between the renderer Process and the main Process, loads a layout and performs the main logic
* Main function: create application window, preload the code to communicate
* between the renderer Process and the main Process, load a layout,
* and perform the main logic.
*/
const createWindow = () => {
// Creates the application window
// Create the application window
const appWindow = new BrowserWindow({
width: 1024,
height: 768,
@@ -43,9 +40,8 @@ const createWindow = () => {
},
})
// Loads a layout
// Load a layout
appWindow.loadFile(path.join(__dirname, 'view', 'template.html'))
return appWindow
}

View File

@@ -24,9 +24,10 @@ const createWindow = () => {
return appWindow
}
// Step 2 changes - main whenReady function - start
/**
* This function creates a XRPL client, subscribes to 'ledger' events from the XRPL and broadcasts those by
* dispatching the 'update-ledger-data' event which will be picked up by the frontend
* Create an XRPL client, subscribe to 'ledger' events, and broadcast those by
* dispatching an 'update-ledger-data' event to the frontend.
*
* @returns {Promise<void>}
*/
@@ -38,7 +39,7 @@ const main = async () => {
await client.connect()
// Subscribe client to 'ledger' events
// Reference: https://xrpl.org/subscribe.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe
await client.request({
"command": "subscribe",
"streams": ["ledger"]
@@ -51,3 +52,4 @@ const main = async () => {
}
app.whenReady().then(main)
// Step 2 changes - main whenReady function - end

View File

@@ -29,30 +29,30 @@ const main = async () => {
await client.connect()
// Reference: https://xrpl.org/subscribe.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe
await client.request({
"command": "subscribe",
"streams": ["ledger"],
"accounts": [address]
})
// Reference: https://xrpl.org/subscribe.html#ledger-stream
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe#ledger-stream
client.on("ledgerClosed", async (rawLedgerData) => {
const ledger = prepareLedgerData(rawLedgerData)
appWindow.webContents.send('update-ledger-data', ledger)
})
// Initial Ledger Request -> Get account details on startup
// Reference: https://xrpl.org/ledger.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger
const ledgerResponse = await client.request({
"command": "ledger"
})
const initialLedgerData = prepareLedgerData(ledgerResponse.result.closed.ledger)
appWindow.webContents.send('update-ledger-data', initialLedgerData)
// Reference: https://xrpl.org/subscribe.html#transaction-streams
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe#transaction-streams
client.on("transaction", async (transaction) => {
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const accountInfoRequest = {
"command": "account_info",
"account": address,
@@ -64,7 +64,7 @@ const main = async () => {
})
// Initial Account Request -> Get account details on startup
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const accountInfoResponse = await client.request({
"command": "account_info",
"account": address,

View File

@@ -30,14 +30,14 @@ const main = async () => {
await client.connect()
// Reference: https://xrpl.org/subscribe.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe
await client.request({
"command": "subscribe",
"streams": ["ledger"],
"accounts": [address]
})
// Reference: https://xrpl.org/subscribe.html#ledger-stream
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe#ledger-stream
client.on("ledgerClosed", async (rawLedgerData) => {
const ledger = prepareLedgerData(rawLedgerData)
appWindow.webContents.send('update-ledger-data', ledger)
@@ -45,7 +45,7 @@ const main = async () => {
// Wait for transaction on subscribed account and re-request account data
client.on("transaction", async (transaction) => {
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const accountInfoRequest = {
"command": "account_info",
"account": address,
@@ -61,7 +61,7 @@ const main = async () => {
})
// Initial Account Request -> Get account details on startup
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const accountInfoResponse = await client.request({
"command": "account_info",
"account": address,
@@ -71,7 +71,7 @@ const main = async () => {
appWindow.webContents.send('update-account-data', accountData)
// Initial Transaction Request -> List account transactions on startup
// Reference: https://xrpl.org/account_tx.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_tx
const txResponse = await client.request({
"command": "account_tx",
"account": address

View File

@@ -23,6 +23,7 @@ const createWindow = () => {
return appWindow
}
// Step 5 - new main function - start
const main = async () => {
const appWindow = createWindow()
@@ -51,6 +52,9 @@ const main = async () => {
}
const wallet = xrpl.Wallet.fromSeed(seed)
// For compatibility with seeds generated using secp256k1
// (the old default algorithm), use the following instead:
// const wallet = xrpl.Wallet.fromSeed(seed, {algorithm: "secp256k1"})
const client = new xrpl.Client(TESTNET_URL)
@@ -80,5 +84,6 @@ const main = async () => {
}
})
}
// Step 5 - new main function - end
app.whenReady().then(main)

View File

@@ -2,7 +2,7 @@
Build a non-custodial XRP Ledger wallet application in JavaScript that runs on the desktop using Electron.
For the full documentation, refer to the [Build a Wallet in JavaScript tutorial](https://xrpl.org/build-a-wallet-in-javascript.html).
For the full documentation, refer to the [Build a Desktop Wallet in JavaScript tutorial](https://xrpl.org/docs/tutorials/javascript/build-apps/build-a-desktop-wallet-in-javascript).
## TL;DR

View File

@@ -3,7 +3,7 @@ const xrpl = require("xrpl");
// The rippled server and its APIs represent time as an unsigned integer.
// This number measures the number of seconds since the "Ripple Epoch" of
// January 1, 2000 (00:00 UTC). This is like the way the Unix epoch works,
// Reference: https://xrpl.org/basic-data-types.html
// Reference: https://xrpl.org/docs/references/protocol/data-types/basic-data-types#specifying-time
const RIPPLE_EPOCH = 946684800;
const prepareAccountData = (rawAccountData) => {

View File

@@ -14,7 +14,7 @@ const fernet = require("fernet");
* @returns {Promise<void>}
*/
const initialize = async (client, wallet, appWindow) => {
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const accountInfoResponse = await client.request({
"command": "account_info",
"account": wallet.address,
@@ -23,7 +23,7 @@ const initialize = async (client, wallet, appWindow) => {
const accountData = prepareAccountData(accountInfoResponse.result.account_data)
appWindow.webContents.send('update-account-data', accountData)
// Reference: https://xrpl.org/account_tx.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_tx
const txResponse = await client.request({
"command": "account_tx",
"account": wallet.address
@@ -42,14 +42,14 @@ const initialize = async (client, wallet, appWindow) => {
*/
const subscribe = async (client, wallet, appWindow) => {
// Reference: https://xrpl.org/subscribe.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe
await client.request({
"command": "subscribe",
"streams": ["ledger"],
"accounts": [wallet.address]
})
// Reference: https://xrpl.org/subscribe.html#ledger-stream
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe#ledger-stream
client.on("ledgerClosed", async (rawLedgerData) => {
const ledger = prepareLedgerData(rawLedgerData)
appWindow.webContents.send('update-ledger-data', ledger)
@@ -57,7 +57,7 @@ const subscribe = async (client, wallet, appWindow) => {
// Wait for transaction on subscribed account and re-request account data
client.on("transaction", async (transaction) => {
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const accountInfoRequest = {
"command": "account_info",
"account": wallet.address,

View File

@@ -9,7 +9,7 @@ const xrpl = require("xrpl");
* @returns {Promise<*>}
*/
const sendXrp = async (paymentData, client, wallet) => {
// Reference: https://xrpl.org/submit.html#request-format-1
// Reference: https://xrpl.org/docs/references/protocol/transactions/types/payment
const paymentTx = {
"TransactionType": "Payment",
"Account": wallet.address,

View File

@@ -39,7 +39,7 @@ async function checkDestination(accountData) {
/**
* Verify an account using a xrp-ledger.toml file.
* https://xrpl.org/xrp-ledger-toml.html#xrp-ledgertoml-file
* https://xrpl.org/docs/references/xrp-ledger-toml
*
* @param accountData
* @returns {Promise<{domain: string, verified: boolean}>}
@@ -89,7 +89,7 @@ async function verifyAccountDomain(accountData) {
* @returns {Promise<{domain: string, verified: boolean}>}
*/
async function verify(accountAddress, client) {
// Reference: https://xrpl.org/account_info.html
// Reference: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info
const request = {
"command": "account_info",
"account": accountAddress,

View File

@@ -1,6 +1,6 @@
{
"name": "xrpl-javascript-desktop-wallet",
"version": "1.0.0",
"version": "1.1.0",
"license": "MIT",
"scripts": {
"hello": "electron 0-hello/index.js",
@@ -14,15 +14,15 @@
"domain-verification": "electron 8-domain-verification/index.js"
},
"dependencies": {
"async": "^3.2.4",
"async": "^3.2.6",
"fernet": "=0.3.3",
"node-fetch": "^2.6.9",
"pbkdf2-hmac": "^1.1.0",
"node-fetch": "^2.7.0",
"pbkdf2-hmac": "^1.2.1",
"open": "^8.4.0",
"toml": "^3.0.0",
"xrpl": "^4.3.0"
"xrpl": "^4.4.2"
},
"devDependencies": {
"electron": "28.3.2"
"electron": "38.2.0"
}
}

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -0,0 +1,62 @@
# Get Started Using Python Library
Connects to the XRP Ledger and gets account information using Python.
To download the source code, see [Get Started Using Python Library](http://xrpl.org/docs/tutorials/python/build-apps/get-started).
## Run the Code
Quick setup and usage:
```sh
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python ./get-acct-info.py
```
You should see output similar to the following:
```sh
Creating a new wallet and funding it with Testnet XRP...
Attempting to fund address ravbHNootpSNQkxyEFCWevSkHsFGDHfyop
Faucet fund successful.
Wallet: ravbHNootpSNQkxyEFCWevSkHsFGDHfyop
Account Testnet Explorer URL:
https://testnet.xrpl.org/accounts/ravbHNootpSNQkxyEFCWevSkHsFGDHfyop
Getting account info...
Response Status: ResponseStatus.SUCCESS
{
"account_data": {
"Account": "ravbHNootpSNQkxyEFCWevSkHsFGDHfyop",
"Balance": "100000000",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 0,
"PreviousTxnID": "3DACF2438AD39F294C4EFF6132D5D88BCB65D2F2261C7650F40AC1F6A54C83EA",
"PreviousTxnLgrSeq": 12039759,
"Sequence": 12039759,
"index": "148E6F4B8E4C14018D679A2526200C292BDBC5AB77611BC3AE0CB97CD2FB84E5"
},
"account_flags": {
"allowTrustLineClawback": false,
"defaultRipple": false,
"depositAuth": false,
"disableMasterKey": false,
"disallowIncomingCheck": false,
"disallowIncomingNFTokenOffer": false,
"disallowIncomingPayChan": false,
"disallowIncomingTrustline": false,
"disallowIncomingXRP": false,
"globalFreeze": false,
"noFreeze": false,
"passwordSpent": false,
"requireAuthorization": false,
"requireDestinationTag": false
},
"ledger_hash": "CA624D717C4FCDD03BAD8C193F374A77A14F7D2566354A4E9617A8DAD896DE71",
"ledger_index": 12039759,
"validated": true
}
```

View File

@@ -1,34 +1,39 @@
# @chunk {"steps": ["connect-tag"]}
# Define the network client
from xrpl.clients import JsonRpcClient
from xrpl.wallet import generate_faucet_wallet
from xrpl.core import addresscodec
from xrpl.models.requests.account_info import AccountInfo
import json
JSON_RPC_URL = "https://s.altnet.rippletest.net:51234/"
client = JsonRpcClient(JSON_RPC_URL)
# @chunk-end
# Create a wallet using the testnet faucet:
# @chunk {"steps": ["get-account-create-wallet-tag"]}
# Create a wallet using the Testnet faucet:
# https://xrpl.org/xrp-testnet-faucet.html
from xrpl.wallet import generate_faucet_wallet
print("\nCreating a new wallet and funding it with Testnet XRP...")
test_wallet = generate_faucet_wallet(client, debug=True)
# Create an account str from the wallet
test_account = test_wallet.address
# Derive an x-address from the classic address:
# https://xrpaddress.info/
from xrpl.core import addresscodec
test_xaddress = addresscodec.classic_address_to_xaddress(test_account, tag=12345, is_test_network=True)
print("\nClassic address:\n\n", test_account)
print("X-address:\n\n", test_xaddress)
test_account = test_wallet.classic_address
print(f"Wallet: {test_account}")
print(f"Account Testnet Explorer URL: ")
print(f" https://testnet.xrpl.org/accounts/{test_account}")
# @chunk-end
# @chunk {"steps": ["query-xrpl-tag"]}
# Look up info about your account
from xrpl.models.requests.account_info import AccountInfo
print("\nGetting account info...")
acct_info = AccountInfo(
account=test_account,
ledger_index="validated",
strict=True,
)
response = client.request(acct_info)
result = response.result
print("response.status: ", response.status)
import json
print("Response Status: ", response.status)
print(json.dumps(response.result, indent=4, sort_keys=True))
# @chunk-end

View File

@@ -0,0 +1 @@
xrpl-py==4.3.0

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -10,26 +10,26 @@ const { wallet } = await client.fundWallet()
// Define metadata as JSON
const mpt_metadata = {
ticker: 'TBILL',
name: 'T-Bill Yield Token',
desc: 'A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.',
icon: 'https://example.org/tbill-icon.png',
asset_class: 'rwa',
asset_subclass: 'treasury',
issuer_name: 'Example Yield Co.',
urls: [
t: 'TBILL',
n: 'T-Bill Yield Token',
d: 'A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.',
i: 'https://example.org/tbill-icon.png',
ac: 'rwa',
as: 'treasury',
in: 'Example Yield Co.',
us: [
{
url: 'https://exampleyield.co/tbill',
type: 'website',
title: 'Product Page'
u: 'https://exampleyield.co/tbill',
c: 'website',
t: 'Product Page'
},
{
url: 'https://exampleyield.co/docs',
type: 'docs',
title: 'Yield Token Docs'
u: 'https://exampleyield.co/docs',
c: 'docs',
t: 'Yield Token Docs'
}
],
additional_info: {
ai: {
interest_rate: '5.00%',
interest_type: 'variable',
yield_source: 'U.S. Treasury Bills',

View File

@@ -12,26 +12,26 @@ wallet = generate_faucet_wallet(client, debug=True)
# Define metadata as JSON
mpt_metadata = {
"ticker": "TBILL",
"name": "T-Bill Yield Token",
"desc": "A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.",
"icon": "https://example.org/tbill-icon.png",
"asset_class": "rwa",
"asset_subclass": "treasury",
"issuer_name": "Example Yield Co.",
"urls": [
"t": "TBILL",
"n": "T-Bill Yield Token",
"d": "A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.",
"i": "example.org/tbill-icon.png",
"ac": "rwa",
"as": "treasury",
"in": "Example Yield Co.",
"us": [
{
"url": "https://exampleyield.co/tbill",
"type": "website",
"title": "Product Page"
"u": "exampleyield.co/tbill",
"c": "website",
"t": "Product Page"
},
{
"url": "https://exampleyield.co/docs",
"type": "docs",
"title": "Yield Token Docs"
"u": "exampleyield.co/docs",
"c": "docs",
"t": "Yield Token Docs"
}
],
"additional_info": {
"ai": {
"interest_rate": "5.00%",
"interest_type": "variable",
"yield_source": "U.S. Treasury Bills",

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -1,8 +1,6 @@
module github.com/XRPLF
go 1.23.0
toolchain go1.23.10
go 1.24.0
require github.com/Peersyst/xrpl-go v0.1.11
@@ -20,5 +18,5 @@ require (
github.com/tyler-smith/go-bip32 v1.0.0 // indirect
github.com/tyler-smith/go-bip39 v1.1.0 // indirect
github.com/ugorji/go/codec v1.2.11 // indirect
golang.org/x/crypto v0.35.0 // indirect
golang.org/x/crypto v0.45.0 // indirect
)

View File

@@ -46,8 +46,8 @@ github.com/ugorji/go/codec v1.2.11/go.mod h1:UNopzCgEMSXjBc6AOMqYvWC1ktqTAfzJZUZ
golang.org/x/crypto v0.0.0-20170613210332-850760c427c5/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.35.0 h1:b15kiHdrGCHrP6LvwaQ3c03kgNhhiMgvlhxHQhmg2Xs=
golang.org/x/crypto v0.35.0/go.mod h1:dy7dXNW32cAb/6/PRuTNsix8T+vJAqvuIy5Bli/x0YQ=
golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

View File

@@ -0,0 +1,70 @@
---
category: 2025
date: "2025-11-19"
template: '../../@theme/templates/blogpost'
seo:
title: Introducing XRP Ledger version 2.6.2
description: rippled version 2.6.2 is now available. This version contains a new amendment and a critical bug fix.
labels:
- rippled Release Notes
markdown:
editPage:
hide: true
---
# Introducing XRP Ledger version 2.6.2
Version 2.6.2 of `rippled`, the reference server implementation of the XRP Ledger protocol, is now available. This release adds a new `fixDirectoryLimit` amendment and a critical bug fix.
## Action Required
If you run an XRP Ledger server, upgrade to version 2.6.2 as soon as possible to ensure service continuity.
## Install / Upgrade
On supported platforms, see the [instructions on installing or updating `rippled`](../../docs/infrastructure/installation/index.md).
| Package | SHA-256 |
|:--------|:--------|
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-2.6.2-1.el9.x86_64.rpm) | `e3b041906a75c3c52cc6423219d7ba9c199a5d736d2e3978a5ce0ac5ef693fdf` |
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_2.6.2-1_amd64.deb) | `0887b5a77c43c362ea7680b83df40b955a5748b712924acf2212b2de29e3373b` |
For other platforms, please [build from source](https://github.com/XRPLF/rippled/blob/master/BUILD.md). The most recent commit in the git log should be the change setting the version:
```text
commit df24ee077438e03673a9c6661c41e8f070b90cd9
Author: Vladislav Vysokikh <vvysokikh@gmail.com>
Date: Tue Nov 18 09:28:59 2025 +0000
Version 2.6.2
```
## Full Changelog
### Amendments
The following amendment is open for voting with this release:
- **fixDirectoryLimit** - Removes directory page limits. Object reserve requirements provide enough incentive to avoid creating unnecessary objects on the XRP Ledger. ([#5935](https://github.com/XRPLF/rippled/pull/5935))
### Bug Fixes
- Fixed an assertion failure when all the inner transactions of a `Batch` transaction were invalid. ([#5670](https://github.com/XRPLF/rippled/pull/5670))
## Credits
The following GitHub users contributed to this release:
- RippleX Engineering
- RippleX Docs
- RippleX Product
## Bug Bounties and Responsible Disclosures
We welcome reviews of the `rippled` code and urge researchers to responsibly disclose any issues they may find.
To report a bug, please send a detailed report to: <bugs@xrpl.org>

View File

@@ -10,6 +10,7 @@
- group: '2025'
expanded: false
items:
- page: 2025/rippled-2.6.2.md
- page: 2025/rippled-2.6.1.md
- page: 2025/vulnerabilitydisclosurereport-bug-sep2025.md
- page: 2025/devnet-reset-oct.md

View File

@@ -17,6 +17,7 @@ const infoSession4 = require("../static/img/events/xrpl-builder-office-hours-04.
const decarb = require('../static/img/events/xrpl-decarb.png')
const townHall = require('../static/img/events/town-hall-meetup.png')
const devBootcamp = require('../static/img/events/dev-bootcamp.png')
const italyHackathon = require("../static/img/events/italy-hackathon.png");
export const frontmatter = {
seo: {
title: "Events",
@@ -26,8 +27,8 @@ export const frontmatter = {
};
export const sortEvents = (arr, asc = true) => {
return arr.sort((a, b) => {
const dateA = moment(a.date, "MMMM D, YYYY");
const dateB = moment(b.date, "MMMM D, YYYY");
const dateA = moment(a.end_date, "MMMM D, YYYY");
const dateB = moment(b.end_date, "MMMM D, YYYY");
return asc ? dateB.diff(dateA) : dateA.diff(dateB); // Returns a negative value if dateA is before dateB, positive if after, and 0 if the same
});
};
@@ -1269,20 +1270,53 @@ const events = [
link: "https://luma.com/llwjrmcx",
location: "Rome, Italy",
date: "November 07, 2025",
image: hackathon,
image: italyHackathon,
end_date: "November 08, 2025",
},
{
name: "Vega House Hackathon",
description:
"The Vega House XRPL Hackathon is calling all developers, designers, and innovators to create incredible solutions on the XRP Ledger (XRPL).",
"Vega House Hackathon: Compete in two XRPL tracks—Ledger Track to build MVP financial services using payments, tokenization, RLUSD, or AMM/DEX flows, and Exploration Track to create innovative apps leveraging XRPL features and upcoming amendments. Prizes total $25,000, including track awards and bounties for best use of new XRPL features.",
type: "hackathon",
link: "https://xrpl.vegahacks.xyz/",
location: "Virtual",
date: "October 01, 2025",
image: hackathon,
date: "Oct 01 - Nov 14, 2025",
image: italyHackathon,
end_date: "November 14, 2025",
},
{
name: "XRPL Town Hall Meeting #5",
description:
"Join Us for the 5th XRPL Town Hall Meeting!",
type: "info",
link: "https://luma.com/wo0g0fpv",
location: "Virtual",
date: "October 16, 2025",
image: require("../static/img/events/townhall-5.png"),
end_date: "October 16, 2025",
},
{
name: "XRPL Aquarium Residency Demo Day #7",
description:
"The Aquarium Residency is a 12-week program for entrepreneurs & developers building on the XRP Ledger blockchain. Join us at our Paris HQ to connect with our 11 residents, discover their projects focused on DeFi II, and engage with the XRPL community.",
type: "meetup",
link: "https://luma.com/mnby11vr",
location: "Paris, France",
image: require("../static/img/events/aquarium-residency.png"),
date: "December 10, 2025",
end_date: "December 10, 2025",
},
{
name: "XRPL Hackathon @ Blockchain Kaigi 2025",
description:
"This is a 3-week online hackathon culminating in demos and an awards ceremony to be held in conjunction with Blockchain Kaigi 2025 in Mumbai, India.",
type: "hackathon",
link: "https://luma.com/ypj8ecj0",
location: "Online (with demos at IIT Bombay)",
date: "Nov 14 - Dec 06, 2025",
image: require("../static/img/events/hackathon-kaigi.png"),
end_date: "December 06, 2025",
},
];

View File

@@ -20,6 +20,7 @@ const brazil = require("../static/img/events/event-meetup-brazil.png");
const infoSession2 = require("../static/img/events/xrpl-builder-office-hours-02.png");
const infoSession3 = require("../static/img/events/xrpl-builder-office-hours-03.png");
const infoSession4 = require("../static/img/events/xrpl-builder-office-hours-04.png");
const italyHackathon = require("../static/img/events/italy-hackathon.png");
const events = [
{
name: "New Horizon: Innovate Without Limits: New Horizons Await",
@@ -377,22 +378,34 @@ const events = [
link: "https://luma.com/llwjrmcx",
location: "Rome, Italy",
date: "November 07, 2025",
image: hackathon,
image: italyHackathon,
end_date: "November 08, 2025",
start_date: "November 07, 2025",
},
{
name: "Vega House Hackathon",
description:
"The Vega House XRPL Hackathon is calling all developers, designers, and innovators to create incredible solutions on the XRP Ledger (XRPL).",
"Vega House Hackathon: Compete in two XRPL tracks—Ledger Track to build MVP financial services using payments, tokenization, RLUSD, or AMM/DEX flows, and Exploration Track to create innovative apps leveraging XRPL features and upcoming amendments. Prizes total $25,000, including track awards and bounties for best use of new XRPL features.",
type: "hackathon",
link: "https://xrpl.vegahacks.xyz/",
location: "Virtual",
date: "October 01, 2025",
image: hackathon,
date: "October 01 - November 14, 2025",
image: italyHackathon,
end_date: "November 14, 2025",
start_date: "October 01, 2025",
},
{
name: "XRPL Hackathon @ Blockchain Kaigi 2025",
description:
"This is a 3-week online hackathon culminating in demos and an awards ceremony to be held in conjunction with Blockchain Kaigi 2025 in Mumbai, India.",
type: "hackathon",
link: "https://luma.com/ypj8ecj0",
location: "Online (with demos at IIT Bombay)",
date: "November 14 - December 06, 2025",
image: require("../static/img/events/hackathon-kaigi.png"),
start_date: "November 14, 2025",
end_date: "December 06, 2025",
},
];

View File

@@ -1,10 +1,8 @@
---
html: addresses.html
parent: accounts.html
seo:
description: Addresses uniquely identify XRP Ledger accounts, using base58 format.
labels:
- Accounts
- Accounts
---
# Addresses
@@ -24,16 +22,16 @@ Some addresses have special meaning, or historical uses, in the XRP Ledger. In m
|-------------------------------|------|---------|-------------|
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) use this address as a placeholder for the issuer of a trust line balance. | Yes |
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/ledger/Ledger.cpp#L184). | No |
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Old JavaScript client libraries generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
## Address Encoding
{% admonition type="success" name="Tip" %}These technical details are only relevant for people building low-level library software for XRP Ledger compatibility!{% /admonition %}
[[Source]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/AccountID.cpp#L133-L175 "Source")
XRP Ledger addresses are encoded using [base58][] with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.

View File

@@ -154,14 +154,14 @@ The process of deriving a key pair depends on the signing algorithm. In all case
The key derivation processes described here are implemented in multiple places and programming languages:
- In C++ in the `rippled` code base:
- [Seed definition](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
- [General & Ed25519 key derivation](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
- [secp256k1 key derivation](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
- [Seed definition](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/Seed.cpp)
- [General & Ed25519 key derivation](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/SecretKey.cpp)
- [secp256k1 key derivation](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/SecretKey.cpp)
- In Python 3 in {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}this repository's code samples section{% /repo-link %}.
- In JavaScript in the [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs) package.
### Ed25519 Key Derivation
[[Source]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/SecretKey.cpp#L311-L317 "Source")
[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg "Passphrase → Seed → Secret Key → Prefix + Public Key")
@@ -182,7 +182,7 @@ The key derivation processes described here are implemented in multiple places a
Validator ephemeral keys cannot be Ed25519.
### secp256k1 Key Derivation
[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/SecretKey.cpp "Source")
[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg "Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair")
@@ -201,7 +201,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu
2. Calculate the [SHA-512Half][] of the concatenated (seed+root sequence) value.
3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/SecretKey.cpp#L103-L114 "Source")
A valid secp256k1 key must not be zero, and it must be numerically less than the _secp256k1 group order_. The secp256k1 group order is the constant value `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.

View File

@@ -107,7 +107,7 @@ When the consensus process completes, each server independently computes a new l
2. Place the agreed-upon transaction set in _canonical order_ so that every server processes them the same way.
[Canonical order](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36) is not the order the transactions were received, because servers may receive the same transactions in different order. To prevent participants from competing over transaction ordering, canonical order is hard to manipulate.
[Canonical order](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/CanonicalTXSet.cpp) is not the order the transactions were received, because servers may receive the same transactions in different order. To prevent participants from competing over transaction ordering, canonical order is hard to manipulate.
3. Process each transaction according to its instructions, in order. Update the ledger's state data accordingly.

View File

@@ -1,11 +1,9 @@
---
html: invariant-checking.html
parent: consensus.html
seo:
description: Understand what invariant checking is, why it exists, how it works, and what invariant checks are active.
labels:
- Blockchain
- Security
- Blockchain
- Security
---
# Invariant Checking
@@ -29,49 +27,25 @@ The processing of incorrect transaction would undermine the value of trust in th
## How it Works
The invariant checker is a second layer of code that runs automatically in real-time after each transaction. Before the transaction's results are committed to the ledger, the invariant checker examines those changes for correctness. If the transaction's results would break one of the XRP Ledger's strict rules, the invariant checker rejects the transaction. Transactions that are rejected this way have the result code `tecINVARIANT_FAILED` and are included in the ledger with no effects.
The invariant checker is a second layer of code that runs automatically in real-time after each transaction. Before the transaction's results are committed to the ledger, the invariant checker examines those changes for correctness. If the transaction's results would break one of the XRP Ledger's strict rules, the invariant checker rejects the transaction. Transactions that are rejected this way have the [result code](../../references/protocol/transactions/transaction-results/index.md) `tecINVARIANT_FAILED` and are included in the ledger with no effects.
To include the transaction in the ledger with a `tec`-class code, some minimal processing is necessary. If this minimal processing still breaks an invariant, the transaction fails with the code `tefINVARIANT_FAILED` instead, and is not included in the ledger at all.
## Active Invariants
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/InvariantCheck.h "Source")
The XRP Ledger checks all the following invariants on each transaction:
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "Source")
- [Transaction Fee Check](#transaction-fee-check)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "Source")
- [XRP Not Created](#xrp-not-created)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "Source")
- [Account Roots Not Deleted](#account-roots-not-deleted)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "Source")
- [XRP Balance Checks](#xrp-balance-checks)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "Source")
- [Ledger Entry Types Match](#ledger-entry-types-match)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "Source")
- [No XRP Trust Lines](#no-xrp-trust-lines)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "Source")
- [No Bad Offers](#no-bad-offers)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "Source")
- [No Zero Escrow](#no-zero-escrow)
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "Source")
- [Valid New Account Root](#valid-new-account-root)
@@ -97,7 +71,7 @@ The XRP Ledger checks all the following invariants on each transaction:
### XRP Balance Checks
- **Invariant Condition(s):**
- An account's XRP balance must be of type XRP, and it cannot be less than 0 or more than 100 billion XRP exactly.
- An account's XRP balance must be of type XRP, and it cannot be less than 0 or more than [100 billion XRP exactly](https://github.com/XRPLF/rippled/blob/a7792ebcae63db64e9ae3d7704576252837c2512/include/xrpl/protocol/SystemParameters.h#L44-L51).
### Ledger Entry Types Match
@@ -155,18 +129,12 @@ The XRP Ledger checks all the following invariants on each transaction:
## See Also
- **Blog:**
- [Protecting the Ledger: Invariant Checking](https://xrpl.org/blog/2017/invariant-checking.html)
- [Protecting the Ledger: Invariant Checking](/blog/2017/invariant-checking.md)
- **Repository:**
- [Invariant Check.h](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
- [Invariant Check.cpp](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
- [System Parameters](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
- [XRP Amount](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
- [Ledger Formats](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
- [`InvariantCheck.h`](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/InvariantCheck.h)
- [`InvariantCheck.cpp`](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/InvariantCheck.cpp)
- [`XRPAmount.h`](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/XRPAmount.h)
- **Other:**
- [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)
- [Calculating Balance Changes for a Transaction](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

View File

@@ -1,11 +1,9 @@
---
html: peer-protocol.html
parent: networks-and-servers.html
seo:
description: The peer protocol specifies the language rippled servers speak to each other.
labels:
- Core Server
- Blockchain
- Core Server
- Blockchain
---
# Peer Protocol
@@ -18,11 +16,11 @@ The peer protocol is the main mode of communication between servers in the XRP L
- Requesting ledger data from historical ledgers, or providing that data.
- Proposing a set of transactions for consensus, or sharing the calculated outcome of applying a consensus transaction set.
To set up a peer-to-peer connection, one server connects to another using HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). (For more information, see the [Overlay Network](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
To set up a peer-to-peer connection, one server connects to another using HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). For more information, see the source code's [Overlay Network](https://github.com/XRPLF/rippled/blob/master/src/xrpld/overlay/README.md#handshake) article.
## Peer Discovery
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server makes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/overlay/detail/OverlayImpl.cpp#L495-L508). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server makes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.

View File

@@ -1,6 +1,4 @@
---
html: escrow.html
parent: payment-types.html
seo:
description: Escrow holds funds until specified conditions are met.
labels:
@@ -12,27 +10,45 @@ Traditionally, an escrow is a contract between two parties to facilitate financi
The XRP Ledger takes escrow a step further, replacing the third party with an automated system built into the ledger. An escrow locks up XRP or fungible tokens, which can't be used or destroyed until conditions are met.
{% amendment-disclaimer name="TokenEscrow" mode="updated" /%}
## Token Escrow
The [TokenEscrow amendment][] extends escrow functionality to fungible tokens, which means [Trust Line Tokens](../../concepts/tokens/fungible-tokens/trust-line-tokens.md) and [Multi-Purpose Tokens (MPTs)](../../concepts/tokens/fungible-tokens/multi-purpose-tokens.md#transferability-controls) can be held in escrow.
For Trust Line Tokens to be held in escrow, the issuing account must have the **Allow Trust Line Locking** flag enabled, which allows tokens issued by the account to be held in escrow. For MPTs, the issuer needs to enable the **Can Escrow** and **Can Transfer** flags when creating the token issuance, so that the tokens can be held in escrow and transferred.
While issuers can't create escrows with their own issued tokens, they can serve as recipients. When an issuer receives escrowed tokens, the process works the same way as a direct payment.
If a token requires authorization, the sender must be pre-authorized by the issuer before creating an escrow and must also be authorized to receive the tokens back when an expired escrow is canceled, regardless of who submits the cancellation transaction. The recipient must be pre-authorized before the escrow can be finished.
## Types of Escrow
The XRP Ledger supports three types of escrow:
- **Time-based Escrow:** Funds only become available after a certain amount of time passes.
- **Conditional Escrow:** This escrow is created with a corresponding condition and fulfillment. The condition serves as a lock on the funds and won't release until the correct fulfillment key is provided.
- **Combination Escrow:** This escrow combines the features of time-based and conditional escrow. The escrow is completely inaccessible until the specified time passes, after which the funds can be release by providing the correct fulfillment.
- **Combination Escrow:** This escrow combines the features of time-based and conditional escrow. The escrow is completely inaccessible until the specified time passes, after which the funds can be released by providing the correct fulfillment.
## Escrow Lifecycle
The lifecycle of an escrow is as follows:
1. The sender creates an escrow using the `EscrowCreate` transaction. This transaction defines:
- An number of XRP or fungible tokens to lock up.
- The conditions to release the XRP or fungible tokens.
- The recipient of the XRP or fungible tokens.
- An amount of XRP or fungible tokens to lock up.
- The conditions to release the funds.
- For **XRP escrows** this can include a time when the escrow can complete, a cryptographic condition that must be fulfilled, and optionally a time when the escrow expires.
- For **token escrows** similar conditions apply, but an expiration time is _mandatory_.
- The recipient of the funds. Any applicable transfer rates or fees are captured at creation time and will apply when the escrow completes, ensuring predictability for the recipient.
2. When the transaction is processed, the XRP Ledger creates an `Escrow` object that holds the escrowed XRP or fungible token.
2. When the transaction is processed successfully, the XRP Ledger creates an `Escrow` object that holds the escrowed funds.
3. The recipient sends an `EscrowFinish` transaction to deliver the XRP or fungible tokens. If the conditions have been met, this destroys the `Escrow` object and delivers the XRP or fungible tokens to the recipient.
3. The recipient sends an `EscrowFinish` transaction to deliver the funds. If the conditions are met, this destroys the `Escrow` object and delivers the funds to the recipient. Additionally, any missing trust lines or MPT entries may be auto-created for recipients if authorization isn't required.
{% admonition type="info" name="Note" %}If the escrow has an expiration time and isn't successfully finished before then, the escrow becomes expired. An expired escrow remains in the ledger until an `EscrowCancel` transaction cancels it, destroying the `Escrow` object and returning the escrowed XRP or fungible tokens to the sender.{% /admonition %}
{% admonition type="info" name="Note" %}
If the escrow has an expiration time and isn't successfully finished before then, the escrow becomes expired. An expired escrow remains in the ledger until an `EscrowCancel` transaction cancels it, returning the escrowed funds to the sender.
{% /admonition %}
## Escrow States
@@ -42,13 +58,16 @@ The following diagram shows the states an Escrow can progress through:
The diagram shows three different cases for three possible combinations of the escrow's "finish-after" time (`FinishAfter` field), crypto-condition (`Condition` field), and expiration time (`CancelAfter` field):
{% admonition type="info" name="Note" %}
While XRP escrows can sometimes exist without an expiration time, token escrows must **always** have an expiration time (`CancelAfter` field).
{% /admonition %}
- **Time-based Escrow (left):** With only a finish-after time, the escrow is created in the **Held** state. After the specified time has passed, it becomes **Ready** and anyone can finish it. If the escrow has an expiration time and no one finishes it before that time passes, then the escrow becomes **Expired**. In the expired state, an escrow cannot be finished, and anyone can cancel it. If the escrow does not have a `CancelAfter` field, it never expires and cannot be canceled.
- **Combination Escrow (center):** If the escrow specifies both a crypto-condition (`Condition` field) _and_ a "finish-after" time (`FinishAfter` field), the escrow is **Held** until its finish-after time has passed. Then it becomes **Conditionally Ready**, and can finish it if they supply the correct fulfillment to the crypto-condition. If the escrow has an expiration time (`CancelAfter` field), and no one finishes it before that time passes, then the escrow becomes **Expired**. In the expired state, an escrow cannot be finished, and anyone can cancel it. If the escrow does not have a `CancelAfter` field, it never expires and cannot be canceled.
- **Conditional Escrow (right):** If the escrow specifies a crypto-condition (`Condition` field) and not a finish-after time, the escrow becomes **Conditionally Ready** immediately when it is created. During this time, anyone can finish the escrow, but only if they supply the correct fulfillment to the crypto-condition. If no one finishes the escrow before its expiration time (`CancelAfter` field), the escrow becomes **Expired**. (An escrow without a finish-after time _must_ have an expiration time.) In the expired state, the escrow can no longer be finished, and anyone can cancel it.
## Limitations
- The costs can make it infeasible for small amounts.
@@ -57,7 +76,9 @@ The diagram shows three different cases for three possible combinations of the e
- You can't create an escrow with past time values.
- Timed releases and expirations resolve according to [ledger close times](../ledgers/ledger-close-times.md). In practice, actual release and expiration times can vary by about five seconds as ledgers close.
- The only supported crypto-condition type is PREIMAGE-SHA-256.
- If a token holder is deep frozen (Trust Line Tokens) or locked (MPTs), they cannot finish an escrow to receive tokens, but they can still cancel an escrow to return tokens to the sender. Individual or global freezes for Trust Line Tokens don't prevent escrow completion.
- For tokens requiring authorization, both sender and recipient must be pre-authorized by the issuer before creating or finishing the escrow, respectively. Authorization cannot be granted during the escrow completion process.
## EscrowFinish Transaction Cost
@@ -65,7 +86,7 @@ When using crypto-conditions, the EscrowFinish transaction must pay a [higher tr
The additional transaction cost required is proportional to the size of the fulfillment. If the transaction is [multi-signed](../accounts/multi-signing.md), the cost of multi-signing is added to the cost of the fulfillment.
Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts)** plus 10 drops per 16 bytes in the size of the fulfillment**.
Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts)** plus 10 drops per 16 bytes in the size of the fulfillment.
{% admonition type="info" name="Note" %}The above formula is based on the assumption that the reference cost of a transaction is 10 drops of XRP.{% /admonition %}

View File

@@ -1,22 +1,22 @@
---
seo:
description: Payment Channels enable fast, asynchronous payments that can be divided into very small increments and settled later.
description: Payment Channels enable fast, asynchronous XRP payments that can be divided into very small increments and settled later.
labels:
- Payment Channels
- Smart Contracts
---
# Payment Channels
Payment Channels are an advanced feature for sending "asynchronous" payments that can be divided into very small increments and settled later.
Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later.
The XRP or fungible tokens for a payment channel are set aside temporarily. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](../consensus-protocol/index.md). (This is an _asynchronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP or fungible tokens authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims.
The XRP for a payment channel is set aside temporarily. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](../consensus-protocol/index.md). (This is an _asynchronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims.
Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based on the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECDSA signatures. Research has [demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second](https://ed25519.cr.yp.to/ed25519-20110926.pdf) on commodity hardware in 2011.
## Why Use Payment Channels
The process of using a payment channel always involves two parties, a payer and a payee. The payer is an individual person or institution using the XRP Ledger who is a customer of the payee. The payee is a person or business who receives XRP or fungible tokens as payment for goods or services.
The process of using a payment channel always involves two parties, a payer and a payee. The payer is an individual person or institution using the XRP Ledger who is a customer of the payee. The payee is a person or business who receives XRP as payment for goods or services.
Payment Channels do not intrinsically specify anything about what you can buy and sell with them. However, the types of goods and services that are a good fit for payment channels are:

View File

@@ -31,16 +31,10 @@ LP tokens enable liquidity providers to:
An AMM holds two different assets: at most one of these can be XRP, and one or both of them can be [tokens](../index.md).
For any given pair of assets, there can be up to one AMM in the ledger. Anyone can create the AMM for an asset pair if it doesn't exist, or deposit to an AMM if it already exists.
When you want to trade in the decentralized exchange, your [Offers](offers.md) and [Cross-Currency Payments](../../payment-types/cross-currency-payments.md) can automatically use AMMs to complete the trade. A single transaction might execute by matching Offers, AMMs, or a mix of both, depending on what's cheaper.
When you want to trade in the decentralized exchange, your [offers](offers.md) and [cross-currency payments](../../payment-types/cross-currency-payments.md) can automatically use AMMs to complete the trade. A single transaction might execute by matching offers, AMMs, or a mix of both, depending on what's cheaper. You can [read a transaction's metadata](../../transactions/finality-of-results/look-up-transaction-results.md) to see what liquidity it consumed.
![1 Transaction using offers, AMMs, or both.](/docs/img/cpt-amm-or-offer.png)
{% admonition type="info" name="Note" %}
You can determine if a `Payment` or `OfferCreate` transaction interacted with an AMM by checking for a [`RippleState`](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) ledger entry in the transaction metadata. A `Flags` value of `16777216` indicates AMM liquidity was consumed.
{% /admonition %}
An AMM sets its exchange rate based on the balance of assets in the pool. When you trade against an AMM, the exchange rate adjusts based on how much your trade shifts the balance of assets the AMM holds. As its supply of one asset goes down, the price of that asset goes up; as its supply of an asset goes up, the price of that asset goes down.
![As supply increases, prices drop, and vice-versa.](/docs/img/cpt-amm-balance.png)

View File

@@ -85,7 +85,7 @@ Trust line limits protect you from receiving more of a token as payment than you
Existing Offers are grouped by exchange rate, which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher exchange rate are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same exchange rate are taken on the basis of which offer was placed first.
When Offers execute in the same ledger block, the order in which they execute is determined by the [canonical order](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source code: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source code: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.
When Offers execute in the same ledger block, the order in which they execute is determined by the [canonical order](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/CanonicalTXSet.cpp "Source code: Transaction ordering") in which transactions were applied to the ledger. Transactions that fail initially can be pushed back and retried at the end of the ledger. This behavior is designed to be deterministic, efficient, and hard to game.
## Offer Expiration

View File

@@ -45,6 +45,94 @@ Every MPT issuance has a set of key properties defined in the ledger as an [MPTo
After the MPT is issued, the on-chain data cannot be changed. However, the proposed [XLS-94: Dynamic MPT standard](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0094-dynamic-MPT) {% not-enabled /%} would allow fields to be marked as mutable during creation, so that those fields can be changed later.
#### Metadata Schema
To fit within the 1024-byte limit, MPT metadata must use compressed JSON keys. The following table describes these keys and their corresponding fields:
| Field Name | Key | Type | Required? | Description |
|:--------------- |:---- |:---------------- |---------- |-------------|
| ticker | `t` | String | Yes | The ticker symbol used to represent the token. Must be uppercase letters (A-Z) and digits (0-9) only. A maximum of 6 characters is recommended. |
| name | `n` | String | Yes | The display name of the token. Any UTF-8 string is permitted. |
| desc | `d` | String | No | A short description of the token. Any UTF-8 string is permitted. |
| icon | `i` | String | Yes | The URI to the token icon. Can be `hostname/path` (HTTPS is assumed), or full URI for other protocols. |
| asset_class | `ac` | String | Yes | Categorizes tokens by their primary purpose and backing. See [Asset Class](#asset-class) for more details. |
| asset_subclass | `as` | String | No | An optional subcategory that is only required if the `asset_class` is `rwa`. See [Asset Subclass](#asset-subclass) for more details. |
| issuer_name | `in` | String | Yes | Name of the entity issuing the token. Any UTF-8 string is permitted. |
| uris | `us` | Array | No | The list of related URIs such as website, documentation, and social media. See [URIs](#uris) for more details.|
| additional_info | `ai` | Object or String | No | Freeform field for key token details like interest rate, maturity date, term, or other relevant info. Any valid JSON object or UTF-8 string is permitted. |
##### Asset Class
The `asset_class` field categorizes tokens by their primary purpose and backing. These categories help applications understand the nature of the token and its intended use case.
| Category | Definition |
|----------|------------|
| `rwa` | Tokens representing real-world assets (RWAs), which derive value from legally enforceable claims on physical or off-chain financial assets. |
| `memes` | Community-driven tokens without intrinsic backing or utility claims, primarily driven by internet culture or speculation. |
| `wrapped` | Tokens representing assets from other blockchains, typically backed 1:1 by bridges or custodians. |
| `gaming` | Tokens used in games or virtual worlds, often representing in-game currency, assets, or rewards. |
| `defi` | Tokens native to or used within DeFi protocols, including governance tokens, DEX tokens, and lending assets. |
| `other` | Tokens that do not clearly fit into the defined categories. This may include experimental, test, or tokens with unique use cases not covered elsewhere. |
##### Asset Subclass
When `asset_class` is set to `rwa`, an `asset_subclass` can be specified to provide more granular categorization. This describes what type of real-world asset backs the token and what legal or regulatory framework might apply.
| Subclass | Definition |
|----------|------------|
| `stablecoin` | Tokens pegged to a stable value, typically fiat currencies like USD, which are backed by reserves like cash, treasuries, or crypto collateral. |
| `commodity` | Tokens that represent physical commodities like gold, silver, or oil, often redeemable or legally linked to off-chain reserves. |
| `real_estate` | Tokens representing ownership or claims on real estate, including fractionalized property shares or REIT-like instruments. |
| `private_credit` | Tokens representing debt obligations from private entities, such as loans, invoices, or receivables. |
| `equity` | Tokens representing ownership shares in companies, similar to traditional stock or equity instruments. |
| `treasury` | Tokens backed by government debt instruments, such as U.S. Treasury bills or bonds. |
| `other` | Tokens that do not fit into the predefined categories, including experimental, hybrid, or emerging real-world asset types. |
##### URIs
The `us` array contains a list of URI objects, each with a URI link, category, and human-readable title.
| Field Name | Key | Type | Required? | Description |
|:---------- |:--- |:------ |:--------- |:-------------|
| uri | `u` | String | Yes |`hostname/path` or full URI link to the related resource. |
| category | `c` | String | Yes | The category of the link provided. Allowed values are: `website`, `social`, `docs`, `other`. |
| title | `t` | String | Yes | Human-readable label for the link. |
#### Example JSON Metadata
The following example shows metadata for a treasury-backed token.
```json
{
"t": "TBILL",
"n": "T-Bill Yield Token",
"d": "A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.",
"i": "example.org/tbill-icon.png",
"ac": "rwa",
"as": "treasury",
"in": "Example Yield Co.",
"us": [
{
"u": "exampleyield.co/tbill",
"c": "website",
"t": "Product Page"
},
{
"u": "exampleyield.co/docs",
"c": "docs",
"t": "Yield Token Docs"
}
],
"ai": {
"interest_rate": "5.00%",
"interest_type": "variable",
"yield_source": "U.S. Treasury Bills",
"maturity_date": "2045-06-30",
"cusip": "912796RX0"
}
}
```
### Transferability Controls
MPTs can be configured with different levels of transferability controls by adjusting the following flags:

View File

@@ -227,15 +227,15 @@ If the payment contains a `CreatedNode` with `"LedgerEntryType": "AccountRoot"`,
#### Token Payments
Payments involving tokens are a bit more complicated.
Payments involving [trust line tokens](../../tokens/fungible-tokens/trust-line-tokens.md) are a bit more complicated.
All changes in token balances are reflected in [RippleState objects](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md), which represent [trust lines](../../tokens/fungible-tokens/index.md). An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; in the metadata, this is only recorded as a single change to the shared `Balance` for the RippleState object. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.
All changes to trust line token balances are reflected in [RippleState entries](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md), which represent [trust lines](../../tokens/fungible-tokens/index.md). An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; transaction metadata records only a single net change to the shared `Balance` of a `RippleState` entry. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.
A single payment may go across a long [path](../../tokens/fungible-tokens/paths.md) consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called [rippling](../../tokens/fungible-tokens/rippling.md). Depending on the `issuer` specified in the transaction's `Amount` field, it is also possible that the amount delivered may be split between several trust lines (`RippleState` accounts) connected to the destination account.
A single payment may go across a long [path](../../tokens/fungible-tokens/paths.md) consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called [rippling](../../tokens/fungible-tokens/rippling.md). Depending on the `issuer` specified in the transaction's `Amount` field, it is also possible that the amount delivered may be split between several trust lines (separate RippleState entries) connected to the destination account.
{% admonition type="success" name="Tip" %}The order that modified objects are presented in the metadata does not necessarily match the order those objects were visited while processing a payment. To better understand payment execution, it may help to reorder `AffectedNodes` members to reconstruct the paths the funds took through the ledger.{% /admonition %}
Cross-currency payments consume [Offers](../../../references/protocol/ledger-data/ledger-entry-types/offer.md) in part or entirely to change between different currency codes and issuers. If a transaction shows `DeletedNode` objects for `Offer` types, that can indicate an Offer that was fully consumed, or an Offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing. If a transaction shows a `ModifiedNode` of type `Offer`, that indicates an Offer that was partially consumed.
Cross-currency payments use [offers](../../tokens/decentralized-exchange/offers.md) and [AMMs](../../tokens/decentralized-exchange/automated-market-makers.md) to convert between different currency codes and issuers. Offers can be partially or fully consumed. If a transaction shows `DeletedNode` objects for `Offer` types, that can indicate an offer that was fully consumed, or an offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing. If a transaction shows a `ModifiedNode` of type `Offer`, that indicates an offer that was partially consumed.
The [`QualityIn` and `QualityOut` settings of trust lines](../../../references/protocol/transactions/types/trustset.md) can affect how one side of a trust line values the token, so that the numeric change in balances is different from how the sender values that token. The `delivered_amount` shows how much was delivered as valued by the recipient.
@@ -243,9 +243,17 @@ If the amount to be sent or received is outside of the [token precision](../../.
Depending on the length of the [paths](../../tokens/fungible-tokens/paths.md), the metadata for cross-currency payments can be _long_. For example, [transaction 8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B) delivered 2.788 GCB issued by `rHaaans...`, spending XRP but passing through USD from 2 issuers, paying XRP to 2 accounts, removing an unfunded offer from `r9ZoLsJ...` to trade EUR for ETH, plus bookkeeping for a total of 17 different ledger objects modified. <!-- SPELLING_IGNORE: gcb -->
#### Using AMM Liquidity
You can tell if an AMM was involved in a transaction by looking for [RippleState entries](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) that belong to an AMM. Check the `Flags` value of each `RippleState` entry in the `AffectedNodes` array; if the [`lsfAMMNode` flag](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestate-flags) is enabled, then that trust line is connected to an AMM. Flags are combined using bitwise operations. To check if `lsfAMMNode` is enabled, use a bitwise-AND operator, like the following pseudo-code:
```
isEnabled = RippleState.Flags & lsfAMMNode
```
### Offers
An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer to the ledger's order books. For example:
An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer entry to the ledger's order books. For example:
```json
{
@@ -268,11 +276,11 @@ An [OfferCreate transaction][] may or may not create an object in the ledger, de
}
```
A `ModifiedNode` of type `Offer` indicates an Offer that was matched and partially consumed. A single transaction can consume a large number of Offers. An Offer to trade two tokens might also consume Offers to trade XRP because of [auto-bridging](../../tokens/decentralized-exchange/autobridging.md). All or part of an exchange can be auto-bridged.
A `ModifiedNode` of type `Offer` indicates an offer that was matched and partially consumed. A single transaction can consume a large number of offers. An offer to trade two tokens might also consume offers to trade XRP because of [auto-bridging](../../tokens/decentralized-exchange/autobridging.md). All or part of an exchange can be auto-bridged. Offers can also use AMMs to convert currency; you can recognize when this happens by [checking for a `RippleState` entry with the `lsfAMMNode` flag](#using-amm-liquidity) in the `AffectedNodes` array.
A `DeletedNode` of type `Offer` can indicate a matching Offer that was fully consumed, an Offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing, or an Offer that was canceled as part of placing a new Offer. You can recognize a canceled Offer because the `Account` that placed it is the sender of the transaction that deleted it.
A `DeletedNode` of type `Offer` can indicate a matching offer that was fully consumed, an offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing, or an offer that was canceled as part of placing a new offer. You can recognize a canceled offer because the `Account` that placed it is the sender of the transaction that deleted it.
Example of a deleted Offer:
Example of a deleted offer:
```json
{
@@ -300,11 +308,11 @@ Example of a deleted Offer:
}
```
Offers can create, delete, and modify both types of [DirectoryNode objects](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md), to keep track of who placed which Offers and which Offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
Offers can create, delete, and modify [DirectoryNode entries](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md), both to keep track of who placed which offers and which offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no Offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an Offer. If not, the Offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an offer. If not, the offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the Offer created a trust line](../../tokens/decentralized-exchange/offers.md#offers-and-trust) to hold a token received in the trade.
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the offer created a trust line](../../tokens/decentralized-exchange/offers.md#offers-and-trust) to hold a token received in the trade.
### Escrows

View File

@@ -64,7 +64,7 @@ For each new ledger version, the server picks a soft limit on the number of tran
The open ledger cost requirement is [proportional to the normal cost of the transaction](#fee-levels), not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](../accounts/multi-signing.md) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.
See also: [Fee Escalation explanation in `rippled` repository](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md).
See also: [Fee Escalation explanation in `rippled` repository](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/FeeEscalation.md).
### Queued Transactions

View File

@@ -43,11 +43,6 @@ Edit your `rippled.cfg` file.
# No [ips] stanza. Use the default hubs to connect to Mainnet.
```
```{% label="Sidechain-Devnet" %}
[ips]
sidechain-net2.devnet.rippletest.net 51235
```
{% /tabs %}
2. Comment out the previous `[ips]` stanza, if there is one:
@@ -77,11 +72,6 @@ Edit your `rippled.cfg` file.
main
```
```{% label="Sidechain-Devnet" %}
[network_id]
262
```
{% /tabs %}
For custom networks, everyone who connects to the network should use a value unique to that network. When creating a new network, choose a network ID at random from the integers 11 to 4,294,967,295.
@@ -120,14 +110,6 @@ Edit your `validators.txt` file. This file is located in the same folder as your
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
```
```{% label="Sidechain-Devnet" %}
[validator_list_sites]
https://vlsidechain-net2.devnet.rippletest.net
[validator_list_keys]
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
```
{% /tabs %}
{% admonition type="success" name="Tip" %}Preview packages might come with the necessary stanzas pre-configured, but check them just in case.{% /admonition %}
@@ -181,13 +163,6 @@ For some test networks using experimental features, you must also forcefully ena
```
{% /tab %}
{% tab label="Sidechain-Devnet" %}
```
[features]
XChainBridge
```
{% /tab %}
{% /tabs %}
{% admonition type="danger" name="Warning" %}Do not use the `[features]` stanza when connecting to Mainnet or Testnet. Forcefully enabling different features than the rest of the network could cause your server to diverge from the network.{% /admonition %}

View File

@@ -8,7 +8,7 @@ labels:
- Core Server
---
# Online Deletion
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/SHAMapStoreImp.cpp "Source")
The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted.

View File

@@ -18,7 +18,7 @@ rippled -a --start --conf=/path/to/rippled.cfg
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](../commandline-usage.md#stand-alone-mode-options).
In a genesis ledger, the [genesis address](../../concepts/accounts/addresses.md#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
In a genesis ledger, the [genesis address](../../concepts/accounts/addresses.md#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/ledger/Ledger.cpp#L184) as follows:
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`

View File

@@ -1,10 +1,8 @@
---
html: understanding-log-messages.html
parent: troubleshoot-the-rippled-server.html
seo:
description: Interpret and respond to warning and error messages in the debug log.
labels:
- Core Server
- Core Server
---
# Understanding Log Messages
@@ -122,10 +120,10 @@ A large number of these messages around the same time may indicate a problem, su
The following log message indicates that a client to the server's public API has been dropped as a result of [rate limiting](../../references/http-websocket-apis/api-conventions/rate-limiting.md):
```text
Resource:WRN Consumer entry 169.55.164.21 dropped with balance 15970 at or above drop threshold 15000
Resource:WRN Consumer entry 169.55.164.21 dropped with balance 25970 at or above drop threshold 25000
```
The entry contains the IP address of the client that exceeded its rate limit, and the client's "balance", which is a score estimating the rate at which the client has been using the API. The threshold for dropping a client is [hardcoded to a score of 15000](https://github.com/XRPLF/rippled/blob/06c371544acc3b488b9d9c057cee4e51f6bef7a2/src/ripple/resource/impl/Tuning.h#L34-L35).
The entry contains the IP address of the client that exceeded its rate limit, and the client's "balance", which is a score estimating the rate at which the client has been using the API. The threshold for dropping a client is [hardcoded to a score of 25000](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/include/xrpl/resource/detail/Tuning.h#L35). {% badge href="https://xrpl.org/blog/2025/rippled-2.3.1" %}Updated in: rippled 2.3.1{% /badge %}
If you see frequent messages from the same IP address, you may want to block those IP addresses from your network to reduce the load on your server's public API. (For example, you may be able to configure your firewall to block those IP addresses.)

View File

@@ -1,14 +1,12 @@
---
html: validation_create.html
parent: key-generation-methods.html
seo:
description: Generate keys for a rippled server to identify itself to the network.
labels:
- Security
- Core Server
- Security
- Core Server
---
# validation_create
[[Source]](https://github.com/XRPLF/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/ValidationCreate.cpp "Source")
Use the `validation_create` command to generate [cryptographic keys a `rippled` server can use to identify itself to the network](../../../../concepts/networks-and-servers/peer-protocol.md#node-key-pair). Similar to the [wallet_propose method][], this method only generates a set of keys in the proper format. It does not any makes changes to the XRP Ledger data or server configuration.
@@ -16,7 +14,7 @@ _The `validation_create` method is an [admin method](../index.md) that cannot be
You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications ([node key pair](../../../../concepts/networks-and-servers/peer-protocol.md#node-key-pair)).
{% admonition type="success" name="Tip" %}For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` RPM) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](../../../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md#3-enable-validation-on-your-rippled-server).{% /admonition %}
{% admonition type="success" name="Tip" %}For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` package build) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](../../../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md#3-enable-validation-on-your-rippled-server).{% /admonition %}
### Request Format

View File

@@ -1,21 +1,17 @@
---
html: wallet_propose.html
parent: key-generation-methods.html
seo:
description: Generate keys for a new account.
labels:
- Security
- Accounts
- Security
- Accounts
---
# wallet_propose
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/WalletPropose.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/WalletPropose.cpp "Source")
Use the `wallet_propose` method to generate a key pair and XRP Ledger address. This command only generates key and address values, and does not affect the XRP Ledger itself in any way. To become a funded address stored in the ledger, the address must [receive a Payment transaction](../../../../concepts/accounts/index.md#creating-accounts) that provides enough XRP to meet the [reserve requirement](../../../../concepts/accounts/reserves.md).
Use the `wallet_propose` method to generate a key pair and XRP Ledger address. This command only generates key and address values, and does not affect the XRP Ledger itself in any way. To become a funded account in the ledger, the address must [receive a Payment transaction](../../../../concepts/accounts/index.md#creating-accounts) that provides enough XRP to meet the [reserve requirement](../../../../concepts/accounts/reserves.md).
*The `wallet_propose` method is an [admin method](../index.md) that cannot be run by unprivileged users!* (This command is restricted to protect against people sniffing network traffic for account secrets, since admin commands are not usually transmitted over the outside network.)
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.31.0" %}Updated in: rippled 0.31.0{% /badge %}
### Request Format
An example of the request format:

View File

@@ -1,13 +1,11 @@
---
html: can_delete.html
parent: logging-and-data-management-methods.html
seo:
description: Allow online deletion of ledgers up to a specific ledger.
labels:
- Data Retention
- Data Retention
---
# can_delete
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/CanDelete.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/CanDelete.cpp "Source")
The `can_delete` method informs the `rippled` server of the latest ledger version which may be deleted when using [online deletion with advisory deletion enabled](../../../../infrastructure/configuration/data-retention/online-deletion.md#advisory-deletion). If advisory deletion is not enabled, this method does nothing.

View File

@@ -1,15 +1,13 @@
---
html: ledger_cleaner.html
parent: logging-and-data-management-methods.html
seo:
description: Configure the ledger cleaner service to check for corrupted data.
labels:
- Data Retention
- Data Retention
---
# ledger_cleaner
[[Source]](https://github.com/XRPLF/rippled/blob/df54b47cd0957a31837493cd69e4d9aade0b5055/src/ripple/rpc/handlers/LedgerCleaner.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/LedgerCleanerHandler.cpp "Source")
The `ledger_cleaner` command controls the [Ledger Cleaner](https://github.com/XRPLF/rippled/blob/f313caaa73b0ac89e793195dcc2a5001786f916f/src/ripple/app/ledger/README.md#the-ledger-cleaner), an asynchronous maintenance process that can find and repair corruption in `rippled`'s database of ledgers.
The `ledger_cleaner` command controls the [Ledger Cleaner](https://github.com/XRPLF/rippled/tree/master/src/xrpld/app/ledger#the-ledger-cleaner), an asynchronous maintenance process that can find and repair corruption in `rippled`'s database of ledgers.
_The `ledger_cleaner` method is an [admin method](../index.md) that cannot be run by unprivileged users._

View File

@@ -1,13 +1,11 @@
---
html: ledger_request.html
parent: logging-and-data-management-methods.html
seo:
description: Query peer servers for a specific ledger version.
labels:
- Data Retention
- Data Retention
---
# ledger_request
[[Source]](https://github.com/XRPLF/rippled/blob/e980e69eca9ea843d200773eb1f43abe3848f1a0/src/ripple/rpc/handlers/LedgerRequest.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/LedgerRequest.cpp "Source")
The `ledger_request` command tells server to fetch a specific ledger version from its connected peers. This only works if one of the server's immediately-connected peers has that ledger. You may need to run the command several times to completely fetch a ledger.
@@ -61,7 +59,7 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"result" : {
"acquiring" : {
"hash" : "01DDD89B6605E20338B8EEB8EB2B0E0DD2F685A2B164F3790C4D634B5734CC26",
"have_header" : false,
@@ -76,7 +74,7 @@ Connecting to 127.0.0.1:5005
"ledger_index" : 18851277
},
"status" : "error"
}
}
}
```
{% /tab %}
@@ -87,43 +85,43 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"hash" : "EB68B5B4F6F06BF59B6D7532BCB98BB98E2F10C2435D895217AA0AA7E910FBD5",
"have_header" : true,
"have_state" : false,
"have_transactions" : false,
"needed_state_hashes" : [
"C46F7B9E795135447AF24BAF999AB8FC1612A997F6EAAF8B784C226FF0BD8E25",
"E48F528E4FC2A1DC492C6264B27B420E2285B2A3ECF3A253DB480DA5BFB7F858",
"B62CD0B2E1277F78BC279FA037F3F747587299B60D23A551C3F63DD137DC0CF8",
"30014C55701FB8426E496A47B297BEC9E8F5BFA47763CC22DBD9024CC81D39DD",
"7EB59A853913898FCEA7B701637F33B1054BD36C32A0B910B612EFB9CDFF6334",
"07ECAD3066D62583883979A2FADAADC8F7D89FA07375843C8A47452639AB2421",
"97A87E5246AF78463485CB27E08D561E22AAF33D5E2F08FE2FACAE0D05CB5478",
"50A0525E238629B32324C9F59B4ECBEFE3C21DC726DB9AB3B6758BD1838DFF68",
"8C541B1ED47C9282E2A28F0B7F3DDFADF06644CAB71B15A3E67D04C5FAFE9BF4",
"2C6CC536C778D8C0F601E35DA7DD9888C288897E4F603E76357CE2F47E8A7A9F",
"309E78DEC67D5725476A59E114850556CC693FB6D92092997ADE97E3EFF473CC",
"8EFF61B6A636AF6B4314CAC0C08F4FED0759E1F782178A822EDE98275E5E4B10",
"9535645E5D249AC0B6126005B79BB981CBA00286E00154D20A3BCF65743EA3CA",
"69F5D6FCB41D1E6CEA5ADD42CBD194086B45E957D497DF7AEE62ADAD485660CE",
"07E93A95DBB0B8A00925DE0DF6D27E41CACC77EF75055A89815006109D82EAD3",
"7FDF25F660235DCAD649676E3E6729DF920A9B0B4B6A3B090A3C64D7BDE2FB20"
],
"needed_transaction_hashes" : [
"BA914854F2F5EDFCBD6E3E0B168E5D4CD0FC92927BEE408C6BD38D4F52505A34",
"AE3A2DB537B01EB33BB3A677242DE52C9AE0A64BD9222EE55E52855276E7EA2A",
"E145F737B255D93769673CBA6DEBA4F6AC7387A309DAACC72EA5B07ECF03C215",
"073A118552AA60E1D3C6BE6F65E4AFA01C582D9C41CCC2887244C19D9BFA7741",
"562DB8580CD3FE19AF5CEA61C2858C10091151B924DBF2AEB7CBB8722E683204",
"437C0D1C2391057079E9539CF028823D29E6437A965284F6E54CEBF1D25C5D56",
"1F069486AF5533883609E5C8DB907E97273D9A782DF26F5E5811F1C42ED63A3D",
"CAA6B7DA68EBA71254C218C81A9EA029A179694BDD0D75A49FB03A7D57BCEE49"
],
"peers" : 6,
"status" : "success",
"timeouts" : 1
}
"result" : {
"hash" : "EB68B5B4F6F06BF59B6D7532BCB98BB98E2F10C2435D895217AA0AA7E910FBD5",
"have_header" : true,
"have_state" : false,
"have_transactions" : false,
"needed_state_hashes" : [
"C46F7B9E795135447AF24BAF999AB8FC1612A997F6EAAF8B784C226FF0BD8E25",
"E48F528E4FC2A1DC492C6264B27B420E2285B2A3ECF3A253DB480DA5BFB7F858",
"B62CD0B2E1277F78BC279FA037F3F747587299B60D23A551C3F63DD137DC0CF8",
"30014C55701FB8426E496A47B297BEC9E8F5BFA47763CC22DBD9024CC81D39DD",
"7EB59A853913898FCEA7B701637F33B1054BD36C32A0B910B612EFB9CDFF6334",
"07ECAD3066D62583883979A2FADAADC8F7D89FA07375843C8A47452639AB2421",
"97A87E5246AF78463485CB27E08D561E22AAF33D5E2F08FE2FACAE0D05CB5478",
"50A0525E238629B32324C9F59B4ECBEFE3C21DC726DB9AB3B6758BD1838DFF68",
"8C541B1ED47C9282E2A28F0B7F3DDFADF06644CAB71B15A3E67D04C5FAFE9BF4",
"2C6CC536C778D8C0F601E35DA7DD9888C288897E4F603E76357CE2F47E8A7A9F",
"309E78DEC67D5725476A59E114850556CC693FB6D92092997ADE97E3EFF473CC",
"8EFF61B6A636AF6B4314CAC0C08F4FED0759E1F782178A822EDE98275E5E4B10",
"9535645E5D249AC0B6126005B79BB981CBA00286E00154D20A3BCF65743EA3CA",
"69F5D6FCB41D1E6CEA5ADD42CBD194086B45E957D497DF7AEE62ADAD485660CE",
"07E93A95DBB0B8A00925DE0DF6D27E41CACC77EF75055A89815006109D82EAD3",
"7FDF25F660235DCAD649676E3E6729DF920A9B0B4B6A3B090A3C64D7BDE2FB20"
],
"needed_transaction_hashes" : [
"BA914854F2F5EDFCBD6E3E0B168E5D4CD0FC92927BEE408C6BD38D4F52505A34",
"AE3A2DB537B01EB33BB3A677242DE52C9AE0A64BD9222EE55E52855276E7EA2A",
"E145F737B255D93769673CBA6DEBA4F6AC7387A309DAACC72EA5B07ECF03C215",
"073A118552AA60E1D3C6BE6F65E4AFA01C582D9C41CCC2887244C19D9BFA7741",
"562DB8580CD3FE19AF5CEA61C2858C10091151B924DBF2AEB7CBB8722E683204",
"437C0D1C2391057079E9539CF028823D29E6437A965284F6E54CEBF1D25C5D56",
"1F069486AF5533883609E5C8DB907E97273D9A782DF26F5E5811F1C42ED63A3D",
"CAA6B7DA68EBA71254C218C81A9EA029A179694BDD0D75A49FB03A7D57BCEE49"
],
"peers" : 6,
"status" : "success",
"timeouts" : 1
}
}
```
{% /tab %}
@@ -134,26 +132,26 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"ledger" : {
"accepted" : true,
"account_hash" : "84EBB27D9510AD5B9A3A328201921B3FD418D4A349E85D3DC69E33C7B506407F",
"close_time" : 486691300,
"close_time_human" : "2015-Jun-04 00:01:40",
"close_time_resolution" : 10,
"closed" : true,
"hash" : "DCF5D723ECEE1EF56D2B0024CD9BDFF2D8E3DC211BD2B9460165922564ACD863",
"ledger_hash" : "DCF5D723ECEE1EF56D2B0024CD9BDFF2D8E3DC211BD2B9460165922564ACD863",
"ledger_index" : "13840000",
"parent_hash" : "8A3F6FBC62C11DE4538D969F9C7966234635FE6CEB1133DDC37220978F8100A9",
"seqNum" : "13840000",
"totalCoins" : "99999022883526403",
"total_coins" : "99999022883526403",
"transaction_hash" : "3D759EF3AF1AE2F78716A8CCB2460C3030F82687E54206E883703372B9E1770C"
},
"ledger_index" : 13840000,
"status" : "success"
}
"result" : {
"ledger" : {
"accepted" : true,
"account_hash" : "84EBB27D9510AD5B9A3A328201921B3FD418D4A349E85D3DC69E33C7B506407F",
"close_time" : 486691300,
"close_time_human" : "2015-Jun-04 00:01:40",
"close_time_resolution" : 10,
"closed" : true,
"hash" : "DCF5D723ECEE1EF56D2B0024CD9BDFF2D8E3DC211BD2B9460165922564ACD863",
"ledger_hash" : "DCF5D723ECEE1EF56D2B0024CD9BDFF2D8E3DC211BD2B9460165922564ACD863",
"ledger_index" : "13840000",
"parent_hash" : "8A3F6FBC62C11DE4538D969F9C7966234635FE6CEB1133DDC37220978F8100A9",
"seqNum" : "13840000",
"totalCoins" : "99999022883526403",
"total_coins" : "99999022883526403",
"transaction_hash" : "3D759EF3AF1AE2F78716A8CCB2460C3030F82687E54206E883703372B9E1770C"
},
"ledger_index" : 13840000,
"status" : "success"
}
}
```

View File

@@ -1,13 +1,11 @@
---
html: log_level.html
parent: logging-and-data-management-methods.html
seo:
description: Get or modify log verbosity.
description: Get or modify log verbosity.
labels:
- Data Retention
- Data Retention
---
# log_level
[[Source]](https://github.com/XRPLF/rippled/blob/155fcdbcd0b4927152892c8c8be01d9cf62bed68/src/ripple/rpc/handlers/LogLevel.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/LogLevel.cpp "Source")
The `log_level` command changes the `rippled` server's logging verbosity, or returns the current logging level for each category (called a _partition_) of log messages.
@@ -21,10 +19,10 @@ An example of the request format:
{% tab label="WebSocket" %}
```json
{
"id": "ll1",
"command": "log_level",
"severity": "debug",
"partition": "PathRequest"
"id": "ll1",
"command": "log_level",
"severity": "debug",
"partition": "PathRequest"
}
```
{% /tab %}

View File

@@ -1,13 +1,11 @@
---
html: logrotate.html
parent: logging-and-data-management-methods.html
seo:
description: Reopen the log file.
description: Reopen the log file.
labels:
- Data Retention
- Data Retention
---
# logrotate
[[Source]](https://github.com/XRPLF/rippled/blob/743bd6c9175c472814448ea889413be79dfd1c07/src/ripple/rpc/handlers/LogRotate.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/LogRotate.cpp "Source")
The `logrotate` command closes and reopens the log file. This is intended to help with log rotation on Linux file systems.
@@ -49,8 +47,8 @@ An example of the request format:
{% tab label="WebSocket" %}
```json
{
"id": "lr1",
"command": "logrotate"
"id": "lr1",
"command": "logrotate"
}
```
{% /tab %}

View File

@@ -1,15 +1,13 @@
---
html: connect.html
parent: peer-management-methods.html
seo:
description: Force the rippled server to connect to a specific peer.
labels:
- Core Server
- Core Server
---
# connect
[[Source]](https://github.com/XRPLF/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/Connect.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Connect.cpp "Source")
The `connect` command forces the `rippled` server to connect to a specific peer `rippled` server.
The `connect` command forces the `rippled` server to connect to a specific peer server.
*The `connect` method is an [admin method](../index.md) that cannot be run by unprivileged users!*

View File

@@ -1,13 +1,11 @@
---
html: peer_reservations_add.html
parent: peer-management-methods.html
seo:
description: Add a reserved slot for a specific peer server.
labels:
- Core Server
- Core Server
---
# peer_reservations_add
[[Source]](https://github.com/XRPLF/rippled/blob/4a1148eb2849513dd1e7ae080288fd47ab57a376/src/ripple/rpc/handlers/Reservations.cpp#L36 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Reservations.cpp "Source")
The {% code-page-name /%} method adds or updates a reserved slot for a specific peer server in the XRP Ledger [peer-to-peer network](../../../../concepts/networks-and-servers/peer-protocol.md).

View File

@@ -1,13 +1,11 @@
---
html: peer_reservations_del.html
parent: peer-management-methods.html
seo:
description: Remove a reserved slot for a specific peer server.
labels:
- Core Server
- Core Server
---
# peer_reservations_del
[[Source]](https://github.com/XRPLF/rippled/blob/4a1148eb2849513dd1e7ae080288fd47ab57a376/src/ripple/rpc/handlers/Reservations.cpp#L89 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Reservations.cpp "Source")
The {% code-page-name /%} method removes a specific [peer reservation][], if one exists.
@@ -83,13 +81,13 @@ An example of a successful response:
{% tab label="JSON-RPC" %}
```json
{
"result" : {
"previous" : {
"description" : "Ripple s1 server 'WOOL'",
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
},
"status" : "success"
}
"result" : {
"previous" : {
"description" : "Ripple s1 server 'WOOL'",
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
},
"status" : "success"
}
}
```
{% /tab %}
@@ -100,13 +98,13 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"previous" : {
"description" : "Ripple s1 server 'WOOL'",
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
},
"status" : "success"
}
"result" : {
"previous" : {
"description" : "Ripple s1 server 'WOOL'",
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
},
"status" : "success"
}
}
```
{% /tab %}

View File

@@ -1,13 +1,11 @@
---
html: peer_reservations_list.html
parent: peer-management-methods.html
seo:
description: List reserved slots for specific peer servers.
labels:
- Core Server
- Core Server
---
# peer_reservations_list
[[Source]](https://github.com/XRPLF/rippled/blob/4a1148eb2849513dd1e7ae080288fd47ab57a376/src/ripple/rpc/handlers/Reservations.cpp#L116 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Reservations.cpp "Source")
The {% code-page-name /%} method lists [peer reservations][].
@@ -32,7 +30,7 @@ An example of the request format:
{% tab label="JSON-RPC" %}
```json
{
"method": "{% $frontmatter.seo.title %}"
"method": "{% $frontmatter.seo.title %}"
}
```
{% /tab %}

View File

@@ -1,13 +1,11 @@
---
html: peers.html
parent: peer-management-methods.html
seo:
description: Get information about the peer servers connected.
labels:
- Core Server
- Core Server
---
# peers
[[Source]](https://github.com/XRPLF/rippled/blob/52f298f150fc1530d201d3140c80d3eaf781cb5f/src/ripple/rpc/handlers/Peers.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Peers.cpp "Source")
The `peers` command returns a list of all other `rippled` servers currently connected to this one over the [Peer Protocol](../../../../concepts/networks-and-servers/peer-protocol.md), including information on their connection and sync status.
@@ -183,90 +181,90 @@ An example of a successful response:
{% tab label="JSON-RPC" %}
```json
{
"result" : {
"cluster" : {},
"peers" : [
{
"address" : "50.22.123.222:51235",
"complete_ledgers" : "32570 - 51815097",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 7,
"metrics" : {
"avg_bps_recv" : "1152",
"avg_bps_sent" : "332",
"total_bytes_recv" : "96601",
"total_bytes_sent" : "45322"
},
"public_key" : "n9LbkoB9ReSbaA9SGL317fm6CvjLcFG8hGoierLYfwiCDsEXHcP3",
"uptime" : 1,
"version" : "rippled-1.3.1"
},
{
"address" : "212.83.147.67:51235",
"complete_ledgers" : "51815014 - 51815040",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 1,
"metrics" : {
"avg_bps_recv" : "0",
"avg_bps_sent" : "1490",
"total_bytes_recv" : "18348",
"total_bytes_sent" : "46013"
},
"public_key" : "n94s5V53w1g4HdEdHdUU1FVrqHTVDbcb7bt44ib9JcM3c281LoDr",
"sanity" : "unknown",
"uptime" : 2,
"version" : "rippled-1.3.1"
},
{
"address" : "158.69.24.50:51235",
"complete_ledgers" : "51478098 - 51815098",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 55,
"metrics" : {
"avg_bps_recv" : "88080",
"avg_bps_sent" : "2703",
"total_bytes_recv" : "2786780",
"total_bytes_sent" : "89368"
},
"public_key" : "n9KfEhmmdxmjJdpbpRHGJ9ezoNzdyUepA11cT71jmq1fMDsZAcSh",
"uptime" : 3,
"version" : "rippled-1.3.1"
},
{
"address" : "[::ffff:174.64.99.193]:51235",
"complete_ledgers" : "51813091 - 51815091",
"latency" : 16000,
"ledger" : "CF72319DC762355C92BDD29E4CE066CEB03FF2A077A511D586B9FD7B74F55D94",
"load" : 325,
"metrics" : {
"avg_bps_recv" : "19012",
"avg_bps_sent" : "52053",
"total_bytes_recv" : "586809",
"total_bytes_sent" : "1678192"
},
"public_key" : "n9MH4Xu8FYPPoUFs679NQp7F6epFznM7x6bF4sAJWQvKkPBUHgd3",
"uptime" : 26,
"version" : "rippled-1.4.0-b8"
},
{
"address" : "[::ffff:94.237.45.66]:51235",
"complete_ledgers" : "51814966 - 51815093",
"latency" : 8773,
"ledger" : "61CF015A709122917B001367EE81E5E0D56E485A0BCAB53785A1CB830E0F9589",
"load" : 3522,
"metrics" : {
"avg_bps_recv" : "368875",
"avg_bps_sent" : "59308",
"total_bytes_recv" : "11558753",
"total_bytes_sent" : "2257872"
},
"public_key" : "n9Lg83FYh8YDivG9TcgXhq5Y3PwunmRqVfvibd19Ko9uu3DtqLBM",
"uptime" : 37,
"version" : "rippled-1.3.1"
}
],
"status" : "success"
}
"result" : {
"cluster" : {},
"peers" : [
{
"address" : "50.22.123.222:51235",
"complete_ledgers" : "32570 - 51815097",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 7,
"metrics" : {
"avg_bps_recv" : "1152",
"avg_bps_sent" : "332",
"total_bytes_recv" : "96601",
"total_bytes_sent" : "45322"
},
"public_key" : "n9LbkoB9ReSbaA9SGL317fm6CvjLcFG8hGoierLYfwiCDsEXHcP3",
"uptime" : 1,
"version" : "rippled-1.3.1"
},
{
"address" : "212.83.147.67:51235",
"complete_ledgers" : "51815014 - 51815040",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 1,
"metrics" : {
"avg_bps_recv" : "0",
"avg_bps_sent" : "1490",
"total_bytes_recv" : "18348",
"total_bytes_sent" : "46013"
},
"public_key" : "n94s5V53w1g4HdEdHdUU1FVrqHTVDbcb7bt44ib9JcM3c281LoDr",
"sanity" : "unknown",
"uptime" : 2,
"version" : "rippled-1.3.1"
},
{
"address" : "158.69.24.50:51235",
"complete_ledgers" : "51478098 - 51815098",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 55,
"metrics" : {
"avg_bps_recv" : "88080",
"avg_bps_sent" : "2703",
"total_bytes_recv" : "2786780",
"total_bytes_sent" : "89368"
},
"public_key" : "n9KfEhmmdxmjJdpbpRHGJ9ezoNzdyUepA11cT71jmq1fMDsZAcSh",
"uptime" : 3,
"version" : "rippled-1.3.1"
},
{
"address" : "[::ffff:174.64.99.193]:51235",
"complete_ledgers" : "51813091 - 51815091",
"latency" : 16000,
"ledger" : "CF72319DC762355C92BDD29E4CE066CEB03FF2A077A511D586B9FD7B74F55D94",
"load" : 325,
"metrics" : {
"avg_bps_recv" : "19012",
"avg_bps_sent" : "52053",
"total_bytes_recv" : "586809",
"total_bytes_sent" : "1678192"
},
"public_key" : "n9MH4Xu8FYPPoUFs679NQp7F6epFznM7x6bF4sAJWQvKkPBUHgd3",
"uptime" : 26,
"version" : "rippled-1.4.0-b8"
},
{
"address" : "[::ffff:94.237.45.66]:51235",
"complete_ledgers" : "51814966 - 51815093",
"latency" : 8773,
"ledger" : "61CF015A709122917B001367EE81E5E0D56E485A0BCAB53785A1CB830E0F9589",
"load" : 3522,
"metrics" : {
"avg_bps_recv" : "368875",
"avg_bps_sent" : "59308",
"total_bytes_recv" : "11558753",
"total_bytes_sent" : "2257872"
},
"public_key" : "n9Lg83FYh8YDivG9TcgXhq5Y3PwunmRqVfvibd19Ko9uu3DtqLBM",
"uptime" : 37,
"version" : "rippled-1.3.1"
}
],
"status" : "success"
}
}
```
@@ -278,90 +276,90 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {},
"peers" : [
{
"address" : "50.22.123.222:51235",
"complete_ledgers" : "32570 - 51815097",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 7,
"metrics" : {
"avg_bps_recv" : "1152",
"avg_bps_sent" : "332",
"total_bytes_recv" : "96601",
"total_bytes_sent" : "45322"
},
"public_key" : "n9LbkoB9ReSbaA9SGL317fm6CvjLcFG8hGoierLYfwiCDsEXHcP3",
"uptime" : 1,
"version" : "rippled-1.3.1"
},
{
"address" : "212.83.147.67:51235",
"complete_ledgers" : "51815014 - 51815040",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 1,
"metrics" : {
"avg_bps_recv" : "0",
"avg_bps_sent" : "1490",
"total_bytes_recv" : "18348",
"total_bytes_sent" : "46013"
},
"public_key" : "n94s5V53w1g4HdEdHdUU1FVrqHTVDbcb7bt44ib9JcM3c281LoDr",
"sanity" : "unknown",
"uptime" : 2,
"version" : "rippled-1.3.1"
},
{
"address" : "158.69.24.50:51235",
"complete_ledgers" : "51478098 - 51815098",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 55,
"metrics" : {
"avg_bps_recv" : "88080",
"avg_bps_sent" : "2703",
"total_bytes_recv" : "2786780",
"total_bytes_sent" : "89368"
},
"public_key" : "n9KfEhmmdxmjJdpbpRHGJ9ezoNzdyUepA11cT71jmq1fMDsZAcSh",
"uptime" : 3,
"version" : "rippled-1.3.1"
},
{
"address" : "[::ffff:174.64.99.193]:51235",
"complete_ledgers" : "51813091 - 51815091",
"latency" : 16000,
"ledger" : "CF72319DC762355C92BDD29E4CE066CEB03FF2A077A511D586B9FD7B74F55D94",
"load" : 325,
"metrics" : {
"avg_bps_recv" : "19012",
"avg_bps_sent" : "52053",
"total_bytes_recv" : "586809",
"total_bytes_sent" : "1678192"
},
"public_key" : "n9MH4Xu8FYPPoUFs679NQp7F6epFznM7x6bF4sAJWQvKkPBUHgd3",
"uptime" : 26,
"version" : "rippled-1.4.0-b8"
},
{
"address" : "[::ffff:94.237.45.66]:51235",
"complete_ledgers" : "51814966 - 51815093",
"latency" : 8773,
"ledger" : "61CF015A709122917B001367EE81E5E0D56E485A0BCAB53785A1CB830E0F9589",
"load" : 3522,
"metrics" : {
"avg_bps_recv" : "368875",
"avg_bps_sent" : "59308",
"total_bytes_recv" : "11558753",
"total_bytes_sent" : "2257872"
},
"public_key" : "n9Lg83FYh8YDivG9TcgXhq5Y3PwunmRqVfvibd19Ko9uu3DtqLBM",
"uptime" : 37,
"version" : "rippled-1.3.1"
}
],
"status" : "success"
}
"result" : {
"cluster" : {},
"peers" : [
{
"address" : "50.22.123.222:51235",
"complete_ledgers" : "32570 - 51815097",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 7,
"metrics" : {
"avg_bps_recv" : "1152",
"avg_bps_sent" : "332",
"total_bytes_recv" : "96601",
"total_bytes_sent" : "45322"
},
"public_key" : "n9LbkoB9ReSbaA9SGL317fm6CvjLcFG8hGoierLYfwiCDsEXHcP3",
"uptime" : 1,
"version" : "rippled-1.3.1"
},
{
"address" : "212.83.147.67:51235",
"complete_ledgers" : "51815014 - 51815040",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 1,
"metrics" : {
"avg_bps_recv" : "0",
"avg_bps_sent" : "1490",
"total_bytes_recv" : "18348",
"total_bytes_sent" : "46013"
},
"public_key" : "n94s5V53w1g4HdEdHdUU1FVrqHTVDbcb7bt44ib9JcM3c281LoDr",
"sanity" : "unknown",
"uptime" : 2,
"version" : "rippled-1.3.1"
},
{
"address" : "158.69.24.50:51235",
"complete_ledgers" : "51478098 - 51815098",
"ledger" : "223DB74FE021AB1A4AA9E1CC588E0DBCC3FC7C080B93C01C30C246D89F951EA2",
"load" : 55,
"metrics" : {
"avg_bps_recv" : "88080",
"avg_bps_sent" : "2703",
"total_bytes_recv" : "2786780",
"total_bytes_sent" : "89368"
},
"public_key" : "n9KfEhmmdxmjJdpbpRHGJ9ezoNzdyUepA11cT71jmq1fMDsZAcSh",
"uptime" : 3,
"version" : "rippled-1.3.1"
},
{
"address" : "[::ffff:174.64.99.193]:51235",
"complete_ledgers" : "51813091 - 51815091",
"latency" : 16000,
"ledger" : "CF72319DC762355C92BDD29E4CE066CEB03FF2A077A511D586B9FD7B74F55D94",
"load" : 325,
"metrics" : {
"avg_bps_recv" : "19012",
"avg_bps_sent" : "52053",
"total_bytes_recv" : "586809",
"total_bytes_sent" : "1678192"
},
"public_key" : "n9MH4Xu8FYPPoUFs679NQp7F6epFznM7x6bF4sAJWQvKkPBUHgd3",
"uptime" : 26,
"version" : "rippled-1.4.0-b8"
},
{
"address" : "[::ffff:94.237.45.66]:51235",
"complete_ledgers" : "51814966 - 51815093",
"latency" : 8773,
"ledger" : "61CF015A709122917B001367EE81E5E0D56E485A0BCAB53785A1CB830E0F9589",
"load" : 3522,
"metrics" : {
"avg_bps_recv" : "368875",
"avg_bps_sent" : "59308",
"total_bytes_recv" : "11558753",
"total_bytes_sent" : "2257872"
},
"public_key" : "n9Lg83FYh8YDivG9TcgXhq5Y3PwunmRqVfvibd19Ko9uu3DtqLBM",
"uptime" : 37,
"version" : "rippled-1.3.1"
}
],
"status" : "success"
}
}
```
{% /tab %}

View File

@@ -1,13 +1,11 @@
---
html: ledger_accept.html
parent: server-control-methods.html
seo:
description: Close and advance the ledger in stand-alone mode.
labels:
- Core Server
- Core Server
---
# ledger_accept
[[Source]](https://github.com/XRPLF/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/LedgerAccept.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/LedgerAccept.cpp "Source")
The `ledger_accept` method forces the server to close the current-working ledger and move to the next ledger number. This method is intended for testing purposes only, and is only available when the `rippled` server is running stand-alone mode.
@@ -22,8 +20,8 @@ An example of the request format:
{% tab label="WebSocket" %}
```json
{
"id": "Accept my ledger!",
"command": "ledger_accept"
"id": "Accept my ledger!",
"command": "ledger_accept"
}
```
{% /tab %}

View File

@@ -1,13 +1,11 @@
---
html: stop.html
parent: server-control-methods.html
seo:
description: Shut down the rippled server.
labels:
- Core Server
- Core Server
---
# stop
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/Stop.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Stop.cpp "Source")
Gracefully shuts down the server.

View File

@@ -1,13 +1,11 @@
---
html: sign.html # watch for clashes w/ this filename
parent: signing-methods.html
seo:
description: Cryptographically sign a transaction.
labels:
- Transaction Sending
- Transaction Sending
---
# sign
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/SignHandler.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/SignHandler.cpp "Source")
The `sign` method takes a [transaction in JSON format](../../../protocol/transactions/index.md) and a [seed value](../../../../concepts/accounts/cryptographic-keys.md), and returns a signed binary representation of the transaction. To contribute one signature to a [multi-signed transaction](../../../../concepts/accounts/multi-signing.md), use the [sign_for method][] instead.

View File

@@ -1,21 +1,16 @@
---
html: sign_for.html
parent: signing-methods.html
seo:
description: Contribute to a multi-signature.
labels:
- Transaction Sending
- Transaction Sending
---
# sign_for
[[Source]](https://github.com/XRPLF/rippled/blob/release/src/ripple/rpc/handlers/SignFor.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/SignFor.cpp "Source")
The `sign_for` command provides one signature for a [multi-signed transaction](../../../../concepts/accounts/multi-signing.md).
{% partial file="/docs/_snippets/public-signing-note.md" /%}
This command requires the [MultiSign amendment][] to be enabled.
## Request Format
An example of the request format:
@@ -157,33 +152,33 @@ An example of a successful response:
200 OK
{
"result" : {
"status" : "success",
"tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
"tx_json" : {
"Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee" : "30000",
"Flags" : 262144,
"LimitAmount" : {
"currency" : "USD",
"issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value" : "100"
},
"Sequence" : 2,
"Signers" : [
{
"Signer" : {
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}
],
"SigningPubKey" : "",
"TransactionType" : "TrustSet",
"hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
}
}
"result" : {
"status" : "success",
"tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
"tx_json" : {
"Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee" : "30000",
"Flags" : 262144,
"LimitAmount" : {
"currency" : "USD",
"issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value" : "100"
},
"Sequence" : 2,
"Signers" : [
{
"Signer" : {
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}
],
"SigningPubKey" : "",
"TransactionType" : "TrustSet",
"hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
}
}
}
```
{% /tab %}
@@ -194,33 +189,33 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
"tx_json" : {
"Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee" : "30000",
"Flags" : 262144,
"LimitAmount" : {
"currency" : "USD",
"issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value" : "100"
},
"Sequence" : 2,
"Signers" : [
{
"Signer" : {
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}
],
"SigningPubKey" : "",
"TransactionType" : "TrustSet",
"hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
}
}
"result" : {
"status" : "success",
"tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
"tx_json" : {
"Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee" : "30000",
"Flags" : 262144,
"LimitAmount" : {
"currency" : "USD",
"issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value" : "100"
},
"Sequence" : 2,
"Signers" : [
{
"Signer" : {
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}
],
"SigningPubKey" : "",
"TransactionType" : "TrustSet",
"hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
}
}
}
```
{% /tab %}

View File

@@ -1,14 +1,12 @@
---
html: consensus_info.html
parent: status-and-debugging-methods.html
seo:
description: Get information about the state of consensus as it happens.
description: Get information about the state of consensus as it happens.
labels:
- Blockchain
- Core Server
- Blockchain
- Core Server
---
# consensus_info
[[Source]](https://github.com/XRPLF/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/ConsensusInfo.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/ConsensusInfo.cpp "Source")
The `consensus_info` command provides information about the [consensus process](../../../../concepts/consensus-protocol/index.md) for debugging purposes.
@@ -59,74 +57,74 @@ An example of a successful response:
{% tab label="JSON-RPC" %}
```json
{
"result" : {
"info" : {
"acquired" : {
"4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306" : "acquired"
},
"close_granularity" : 10,
"close_percent" : 50,
"close_resolution" : 10,
"close_times" : {
"486082972" : 1,
"486082973" : 4
},
"current_ms" : 1003,
"have_time_consensus" : false,
"ledger_seq" : 13701086,
"our_position" : {
"close_time" : 486082973,
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"peer_positions" : {
"0A2EAF919033A036D363D4E5610A66209DDBE8EE" : {
"close_time" : 486082972,
"peer_id" : "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"1567A8C953A86F8428C7B01641D79BBF2FD508F3" : {
"close_time" : 486082973,
"peer_id" : "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"202397A81F20B44CF44EA99AF761295E5A8397D2" : {
"close_time" : 486082973,
"peer_id" : "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"5C29005CF4FB479FC49EEFB4A5B075C86DD963CC" : {
"close_time" : 486082973,
"peer_id" : "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"EFC49EB648E557CC50A72D715249B80E071F7705" : {
"close_time" : 486082973,
"peer_id" : "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
}
},
"previous_mseconds" : 2005,
"previous_proposers" : 5,
"proposers" : 5,
"proposing" : false,
"state" : "consensus",
"synched" : true,
"validating" : false
},
"status" : "success"
}
"result" : {
"info" : {
"acquired" : {
"4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306" : "acquired"
},
"close_granularity" : 10,
"close_percent" : 50,
"close_resolution" : 10,
"close_times" : {
"486082972" : 1,
"486082973" : 4
},
"current_ms" : 1003,
"have_time_consensus" : false,
"ledger_seq" : 13701086,
"our_position" : {
"close_time" : 486082973,
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"peer_positions" : {
"0A2EAF919033A036D363D4E5610A66209DDBE8EE" : {
"close_time" : 486082972,
"peer_id" : "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"1567A8C953A86F8428C7B01641D79BBF2FD508F3" : {
"close_time" : 486082973,
"peer_id" : "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"202397A81F20B44CF44EA99AF761295E5A8397D2" : {
"close_time" : 486082973,
"peer_id" : "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"5C29005CF4FB479FC49EEFB4A5B075C86DD963CC" : {
"close_time" : 486082973,
"peer_id" : "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"EFC49EB648E557CC50A72D715249B80E071F7705" : {
"close_time" : 486082973,
"peer_id" : "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
}
},
"previous_mseconds" : 2005,
"previous_proposers" : 5,
"proposers" : 5,
"proposing" : false,
"state" : "consensus",
"synched" : true,
"validating" : false
},
"status" : "success"
}
}
```
{% /tab %}
@@ -137,74 +135,74 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
"acquired" : {
"4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306" : "acquired"
},
"close_granularity" : 10,
"close_percent" : 50,
"close_resolution" : 10,
"close_times" : {
"486082972" : 1,
"486082973" : 4
},
"current_ms" : 1003,
"have_time_consensus" : false,
"ledger_seq" : 13701086,
"our_position" : {
"close_time" : 486082973,
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"peer_positions" : {
"0A2EAF919033A036D363D4E5610A66209DDBE8EE" : {
"close_time" : 486082972,
"peer_id" : "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"1567A8C953A86F8428C7B01641D79BBF2FD508F3" : {
"close_time" : 486082973,
"peer_id" : "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"202397A81F20B44CF44EA99AF761295E5A8397D2" : {
"close_time" : 486082973,
"peer_id" : "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"5C29005CF4FB479FC49EEFB4A5B075C86DD963CC" : {
"close_time" : 486082973,
"peer_id" : "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"EFC49EB648E557CC50A72D715249B80E071F7705" : {
"close_time" : 486082973,
"peer_id" : "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
}
},
"previous_mseconds" : 2005,
"previous_proposers" : 5,
"proposers" : 5,
"proposing" : false,
"state" : "consensus",
"synched" : true,
"validating" : false
},
"status" : "success"
}
"result" : {
"info" : {
"acquired" : {
"4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306" : "acquired"
},
"close_granularity" : 10,
"close_percent" : 50,
"close_resolution" : 10,
"close_times" : {
"486082972" : 1,
"486082973" : 4
},
"current_ms" : 1003,
"have_time_consensus" : false,
"ledger_seq" : 13701086,
"our_position" : {
"close_time" : 486082973,
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"peer_positions" : {
"0A2EAF919033A036D363D4E5610A66209DDBE8EE" : {
"close_time" : 486082972,
"peer_id" : "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"1567A8C953A86F8428C7B01641D79BBF2FD508F3" : {
"close_time" : 486082973,
"peer_id" : "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"202397A81F20B44CF44EA99AF761295E5A8397D2" : {
"close_time" : 486082973,
"peer_id" : "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"5C29005CF4FB479FC49EEFB4A5B075C86DD963CC" : {
"close_time" : 486082973,
"peer_id" : "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
},
"EFC49EB648E557CC50A72D715249B80E071F7705" : {
"close_time" : 486082973,
"peer_id" : "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7",
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
"propose_seq" : 0,
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
}
},
"previous_mseconds" : 2005,
"previous_proposers" : 5,
"proposers" : 5,
"proposing" : false,
"state" : "consensus",
"synched" : true,
"validating" : false
},
"status" : "success"
}
}
```
{% /tab %}

View File

@@ -1,18 +1,16 @@
---
html: feature.html
parent: status-and-debugging-methods.html
seo:
description: Get information about protocol amendments.
labels:
- Blockchain
- Core Server
- Blockchain
- Core Server
---
# feature
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/Feature1.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Feature1.cpp "Source")
The `feature` command returns information about [amendments](../../../../concepts/networks-and-servers/amendments.md) this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the [amendment process](../../../../concepts/networks-and-servers/amendments.md#amendment-process).
You can use the `feature` command to configure the server to vote against or in favor of an amendment. This change persists even if you restart the server. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}Updated in: rippled 1.7.0{% /badge %}
You can use the `feature` command to configure the server to vote against or in favor of an amendment. This change persists even if you restart the server.
_The `feature` method documented on this page is an [admin method](../index.md). For the non-admin version, see the [`feature` public API method](../../public-api-methods/server-info-methods/feature.md)._

View File

@@ -1,13 +1,11 @@
---
html: fetch_info.html
parent: status-and-debugging-methods.html
seo:
description: Get information about the server's sync with the network.
labels:
- Core Server
- Core Server
---
# fetch_info
[[Source]](https://github.com/XRPLF/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/FetchInfo.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/FetchInfo.cpp "Source")
The `fetch_info` command returns information about objects that this server is currently fetching from the network, and how many peers have that information. It can also be used to reset current fetches.
@@ -65,37 +63,37 @@ An example of a successful response:
{% tab label="JSON-RPC" %}
```json
{
"result" : {
"info" : {
"348928" : {
"hash" : "C26D432B06F84861BCACD7942EDC3FE0B2E1DEB966A9E516A0FD275A375C2010",
"have_header" : true,
"have_state" : false,
"have_transactions" : true,
"needed_state_hashes" : [
"BF8DC6B1E10D1D3565BF0649075D22EBFD34F751AFCC0E53E81D74786BC88922",
"34E37A71CB51A12C73A435250E6A6349F7884C7EEBA6B88FA31F0244E967E88F",
"BFB7D3008A7D61FD6A0538D1C2E70CFB94CE8DC66606319C372F278A48629765",
"41C0C61D701FB1EA586F0EF1FC7A91FEC476D979589DA60507F05C13F7C21975",
"6DDE8840A2C3C7FF05E5FFEE4D06408694C16A8357338FE0C4581DC3D8A00BBA",
"6C69D833B582C849917806FA009518832BB50E900E43716FD7CC1966428DD0CF",
"1EDC020CFC4AF19B625C52E20B66D6AE672821CCC461E8A9C457A3B2955657F7",
"FC0616A66A2B0589CA513F3341D4EA51E782C4601E5072308478E3CC19264640",
"19FC607B5DE1B64681A676EC1ED5507B9555B0E098CD9D898320297DE1A64033",
"5E128D3FC990074E35687387A14AA12D9FD287E5AB57CB9B2FD83DE635DF5CA9",
"DE72820F3981770F2AA8770BC233B80661F1A452819D8529008875FF8DED87A9",
"3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
"0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
"4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
"08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
"779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
],
"peers" : 2,
"timeouts" : 0
}
},
"status" : "success"
}
"result" : {
"info" : {
"348928" : {
"hash" : "C26D432B06F84861BCACD7942EDC3FE0B2E1DEB966A9E516A0FD275A375C2010",
"have_header" : true,
"have_state" : false,
"have_transactions" : true,
"needed_state_hashes" : [
"BF8DC6B1E10D1D3565BF0649075D22EBFD34F751AFCC0E53E81D74786BC88922",
"34E37A71CB51A12C73A435250E6A6349F7884C7EEBA6B88FA31F0244E967E88F",
"BFB7D3008A7D61FD6A0538D1C2E70CFB94CE8DC66606319C372F278A48629765",
"41C0C61D701FB1EA586F0EF1FC7A91FEC476D979589DA60507F05C13F7C21975",
"6DDE8840A2C3C7FF05E5FFEE4D06408694C16A8357338FE0C4581DC3D8A00BBA",
"6C69D833B582C849917806FA009518832BB50E900E43716FD7CC1966428DD0CF",
"1EDC020CFC4AF19B625C52E20B66D6AE672821CCC461E8A9C457A3B2955657F7",
"FC0616A66A2B0589CA513F3341D4EA51E782C4601E5072308478E3CC19264640",
"19FC607B5DE1B64681A676EC1ED5507B9555B0E098CD9D898320297DE1A64033",
"5E128D3FC990074E35687387A14AA12D9FD287E5AB57CB9B2FD83DE635DF5CA9",
"DE72820F3981770F2AA8770BC233B80661F1A452819D8529008875FF8DED87A9",
"3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
"0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
"4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
"08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
"779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
],
"peers" : 2,
"timeouts" : 0
}
},
"status" : "success"
}
}
```
{% /tab %}
@@ -106,37 +104,37 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
"348928" : {
"hash" : "C26D432B06F84861BCACD7942EDC3FE0B2E1DEB966A9E516A0FD275A375C2010",
"have_header" : true,
"have_state" : false,
"have_transactions" : true,
"needed_state_hashes" : [
"BF8DC6B1E10D1D3565BF0649075D22EBFD34F751AFCC0E53E81D74786BC88922",
"34E37A71CB51A12C73A435250E6A6349F7884C7EEBA6B88FA31F0244E967E88F",
"BFB7D3008A7D61FD6A0538D1C2E70CFB94CE8DC66606319C372F278A48629765",
"41C0C61D701FB1EA586F0EF1FC7A91FEC476D979589DA60507F05C13F7C21975",
"6DDE8840A2C3C7FF05E5FFEE4D06408694C16A8357338FE0C4581DC3D8A00BBA",
"6C69D833B582C849917806FA009518832BB50E900E43716FD7CC1966428DD0CF",
"1EDC020CFC4AF19B625C52E20B66D6AE672821CCC461E8A9C457A3B2955657F7",
"FC0616A66A2B0589CA513F3341D4EA51E782C4601E5072308478E3CC19264640",
"19FC607B5DE1B64681A676EC1ED5507B9555B0E098CD9D898320297DE1A64033",
"5E128D3FC990074E35687387A14AA12D9FD287E5AB57CB9B2FD83DE635DF5CA9",
"DE72820F3981770F2AA8770BC233B80661F1A452819D8529008875FF8DED87A9",
"3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
"0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
"4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
"08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
"779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
],
"peers" : 2,
"timeouts" : 0
}
},
"status" : "success"
}
"result" : {
"info" : {
"348928" : {
"hash" : "C26D432B06F84861BCACD7942EDC3FE0B2E1DEB966A9E516A0FD275A375C2010",
"have_header" : true,
"have_state" : false,
"have_transactions" : true,
"needed_state_hashes" : [
"BF8DC6B1E10D1D3565BF0649075D22EBFD34F751AFCC0E53E81D74786BC88922",
"34E37A71CB51A12C73A435250E6A6349F7884C7EEBA6B88FA31F0244E967E88F",
"BFB7D3008A7D61FD6A0538D1C2E70CFB94CE8DC66606319C372F278A48629765",
"41C0C61D701FB1EA586F0EF1FC7A91FEC476D979589DA60507F05C13F7C21975",
"6DDE8840A2C3C7FF05E5FFEE4D06408694C16A8357338FE0C4581DC3D8A00BBA",
"6C69D833B582C849917806FA009518832BB50E900E43716FD7CC1966428DD0CF",
"1EDC020CFC4AF19B625C52E20B66D6AE672821CCC461E8A9C457A3B2955657F7",
"FC0616A66A2B0589CA513F3341D4EA51E782C4601E5072308478E3CC19264640",
"19FC607B5DE1B64681A676EC1ED5507B9555B0E098CD9D898320297DE1A64033",
"5E128D3FC990074E35687387A14AA12D9FD287E5AB57CB9B2FD83DE635DF5CA9",
"DE72820F3981770F2AA8770BC233B80661F1A452819D8529008875FF8DED87A9",
"3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
"0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
"4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
"08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
"779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
],
"peers" : 2,
"timeouts" : 0
}
},
"status" : "success"
}
}
```
{% /tab %}

View File

@@ -1,13 +1,11 @@
---
html: get_counts.html
parent: status-and-debugging-methods.html
seo:
description: Get statistics about the server's internals and memory usage.
labels:
- Core Server
- Core Server
---
# get_counts
[[Source]](https://github.com/XRPLF/rippled/blob/c7118a183a660648aa88a3546a6b2c5bce858440/src/ripple/rpc/handlers/GetCounts.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/GetCounts.cpp "Source")
The `get_counts` command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory.

View File

@@ -1,13 +1,11 @@
---
html: print.html
parent: status-and-debugging-methods.html
seo:
description: Get information about internal subsystems.
labels:
- Core Server
- Core Server
---
# print
[[Source]](https://github.com/XRPLF/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/Print.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Print.cpp "Source")
The `print` command returns the current status of various internal subsystems, including peers, the ledger cleaner, and the resource manager.
@@ -49,183 +47,183 @@ Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"app" : {
"ledgercleaner" : {
"status" : "idle"
},
"peers" : {
"peerfinder" : {
"bootcache" : {
"entries" : 109
},
"config" : {
"auto_connect" : "true",
"features" : "",
"max_peers" : 21,
"out_peers" : 10,
"port" : 51235,
"want_incoming" : "true"
},
"counts" : {
"accept" : 0,
"close" : 0,
"cluster" : "0",
"connect" : 0,
"fixed" : "0",
"in" : "0/11",
"out" : "10/10",
"total" : "10"
},
"fixed" : 0,
"livecache" : {
"entries" : [
{
"address" : "23.239.3.247:51235",
"expires" : "30000000000 nanoseconds",
"hops" : 2
},
{
"address" : "192.170.145.88:51235",
"expires" : "30000000000 nanoseconds",
"hops" : 1
},
{
"address" : "198.204.238.130:51235",
"expires" : "26000024558 nanoseconds",
"hops" : 1
},
{
"address" : "203.127.12.115:51235",
"expires" : "26000024558 nanoseconds",
"hops" : 2
},
{
"address" : "212.83.147.67:51235",
"expires" : "26000024558 nanoseconds",
"hops" : 2
}
],
"hist" : "0, 10, 74, 10, 0, 0, 0, 0",
"size" : "94"
},
"peers" : [
{
"local_address" : "10.1.10.78:48923",
"remote_address" : "52.24.43.83:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:50004",
"remote_address" : "52.26.205.197:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:37019",
"remote_address" : "168.1.60.132:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:38775",
"remote_address" : "192.170.145.88:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:34793",
"remote_address" : "198.204.238.130:51235",
"state" : "active"
}
]
}
},
"resource" : {
"admin" : [
{
"balance" : 0,
"count" : 1,
"name" : "\"127.0.0.1\""
}
],
"inactive" : [],
"inbound" : [],
"outbound" : [
{
"balance" : 23,
"count" : 1,
"name" : "93.190.138.234:51235"
},
{
"balance" : 35,
"count" : 1,
"name" : "198.204.238.130:51235"
},
{
"balance" : 31,
"count" : 1,
"name" : "52.26.205.197:51235"
},
{
"balance" : 32,
"count" : 1,
"name" : "54.186.73.52:51235"
},
{
"balance" : 15,
"count" : 1,
"name" : "72.251.233.164:51235"
}
]
},
"server" : {
"active" : "2",
"hist" : "16",
"history" : [
{
"bytes_in" : "214",
"bytes_out" : "11688",
"elapsed" : "0 seconds",
"id" : "16",
"requests" : 1,
"when" : "2015-Jun-16 16:33:50"
},
{
"bytes_in" : "214",
"bytes_out" : "11431",
"elapsed" : "0 seconds",
"id" : "15",
"requests" : 1,
"when" : "2015-Jun-16 16:11:59"
},
{
"bytes_in" : "227",
"bytes_out" : "337",
"elapsed" : "0 seconds",
"id" : "3",
"requests" : 1,
"when" : "2015-Jun-16 14:57:23"
},
{
"bytes_in" : "214",
"bytes_out" : "2917",
"elapsed" : "0 seconds",
"id" : "2",
"requests" : 1,
"when" : "2015-Jun-16 12:39:29"
},
{
"bytes_in" : "220",
"bytes_out" : "1426",
"elapsed" : "0 seconds",
"id" : "1",
"requests" : 1,
"when" : "2015-Jun-16 12:39:13"
}
]
},
"validators" : {}
},
"status" : "success"
}
"result" : {
"app" : {
"ledgercleaner" : {
"status" : "idle"
},
"peers" : {
"peerfinder" : {
"bootcache" : {
"entries" : 109
},
"config" : {
"auto_connect" : "true",
"features" : "",
"max_peers" : 21,
"out_peers" : 10,
"port" : 51235,
"want_incoming" : "true"
},
"counts" : {
"accept" : 0,
"close" : 0,
"cluster" : "0",
"connect" : 0,
"fixed" : "0",
"in" : "0/11",
"out" : "10/10",
"total" : "10"
},
"fixed" : 0,
"livecache" : {
"entries" : [
{
"address" : "23.239.3.247:51235",
"expires" : "30000000000 nanoseconds",
"hops" : 2
},
{
"address" : "192.170.145.88:51235",
"expires" : "30000000000 nanoseconds",
"hops" : 1
},
{
"address" : "198.204.238.130:51235",
"expires" : "26000024558 nanoseconds",
"hops" : 1
},
{
"address" : "203.127.12.115:51235",
"expires" : "26000024558 nanoseconds",
"hops" : 2
},
{
"address" : "212.83.147.67:51235",
"expires" : "26000024558 nanoseconds",
"hops" : 2
}
],
"hist" : "0, 10, 74, 10, 0, 0, 0, 0",
"size" : "94"
},
"peers" : [
{
"local_address" : "10.1.10.78:48923",
"remote_address" : "52.24.43.83:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:50004",
"remote_address" : "52.26.205.197:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:37019",
"remote_address" : "168.1.60.132:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:38775",
"remote_address" : "192.170.145.88:51235",
"state" : "active"
},
{
"local_address" : "10.1.10.78:34793",
"remote_address" : "198.204.238.130:51235",
"state" : "active"
}
]
}
},
"resource" : {
"admin" : [
{
"balance" : 0,
"count" : 1,
"name" : "\"127.0.0.1\""
}
],
"inactive" : [],
"inbound" : [],
"outbound" : [
{
"balance" : 23,
"count" : 1,
"name" : "93.190.138.234:51235"
},
{
"balance" : 35,
"count" : 1,
"name" : "198.204.238.130:51235"
},
{
"balance" : 31,
"count" : 1,
"name" : "52.26.205.197:51235"
},
{
"balance" : 32,
"count" : 1,
"name" : "54.186.73.52:51235"
},
{
"balance" : 15,
"count" : 1,
"name" : "72.251.233.164:51235"
}
]
},
"server" : {
"active" : "2",
"hist" : "16",
"history" : [
{
"bytes_in" : "214",
"bytes_out" : "11688",
"elapsed" : "0 seconds",
"id" : "16",
"requests" : 1,
"when" : "2015-Jun-16 16:33:50"
},
{
"bytes_in" : "214",
"bytes_out" : "11431",
"elapsed" : "0 seconds",
"id" : "15",
"requests" : 1,
"when" : "2015-Jun-16 16:11:59"
},
{
"bytes_in" : "227",
"bytes_out" : "337",
"elapsed" : "0 seconds",
"id" : "3",
"requests" : 1,
"when" : "2015-Jun-16 14:57:23"
},
{
"bytes_in" : "214",
"bytes_out" : "2917",
"elapsed" : "0 seconds",
"id" : "2",
"requests" : 1,
"when" : "2015-Jun-16 12:39:29"
},
{
"bytes_in" : "220",
"bytes_out" : "1426",
"elapsed" : "0 seconds",
"id" : "1",
"requests" : 1,
"when" : "2015-Jun-16 12:39:13"
}
]
},
"validators" : {}
},
"status" : "success"
}
}
```

View File

@@ -1,14 +1,12 @@
---
html: validator_info.html
parent: status-and-debugging-methods.html
seo:
description: Get the server's validation settings, if configured as a validator.
labels:
- コアサーバ
- ブロックチェーン
- Core Server
- Blockchain
---
# validator_info
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/ValidatorInfo.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/ValidatorInfo.cpp "Source")
The {% code-page-name /%} method returns the current validator settings of the server, if it is configured as a validator.

View File

@@ -1,14 +1,12 @@
---
html: validator_list_sites.html
parent: status-and-debugging-methods.html
seo:
description: Get information about sites that publish validator lists.
labels:
- Core Server
- Blockchain
- Core Server
- Blockchain
---
# validator_list_sites
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/ValidatorListSites.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/ValidatorListSites.cpp "Source")
The `validator_list_sites` command returns status information of sites serving validator lists.

View File

@@ -1,14 +1,12 @@
---
html: validators.html
parent: status-and-debugging-methods.html
seo:
description: Get information about the current validators.
labels:
- Core Server
- Blockchain
- Core Server
- Blockchain
---
# validators
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/Validators.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/Validators.cpp "Source")
The `validators` command returns human readable information about the current list of published and [trusted validators](../../../../concepts/consensus-protocol/index.md#trust-based-validation) used by the server.

View File

@@ -1,13 +1,11 @@
---
html: health-check.html
parent: peer-port-methods.html
seo:
description: Special API method for reporting server health.
labels:
- Core Server
- Core Server
---
# Health Check
[[Source]](https://github.com/XRPLF/rippled/blob/de0c52738785de8bf837f9124da65c7905e7bb5a/src/ripple/overlay/impl/OverlayImpl.cpp#L1084-L1168 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/overlay/detail/OverlayImpl.cpp#L943-L1038 "Source")
The Health Check is a special [peer port method](index.md) for reporting on the health of an individual `rippled` server. This method is intended for use in automated monitoring to recognize outages and prompt automated or manual interventions such as restarting the server. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}New in: rippled 1.6.0{% /badge %}

View File

@@ -1,13 +1,12 @@
---
html: validator-list.html
parent: peer-port-methods.html
seo:
description: Special API method for sharing recommended validator lists.
labels:
- Core Server
- Blockchain
- Core Server
- Blockchain
---
# Validator List Method
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/overlay/detail/OverlayImpl.cpp#L875-L940 "Source")
The validator list method is a special API endpoint that fetches a current, trusted validator list a `rippled` server is using. This often represents the exact list of validators a server trusts.
@@ -45,7 +44,7 @@ The JSON object has the following fields:
| `public_key` | String | The public key used to verify this validator list data, in hexadecimal. This is a 32-byte Ed25519 public key prefixed with the byte `0xED`. |
### Manifest Data
[[Source]](https://github.com/XRPLF/rippled/blob/97712107b71a8e2089d2e3fcef9ebf5362951110/src/ripple/app/misc/impl/Manifest.cpp#L43-L66 "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/8d1b3b39940eca2735a0e9279bdd92b0748fd84c/src/xrpld/app/misc/detail/Manifest.cpp#L54-L82 "Source")
A "manifest" contains information uniquely identifying a person or organization involved in the consensus process, either a **validator** or a **list publisher**. A validator's manifest contains the _public_ information from that [validator's token](../../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md#3-enable-validation-on-your-rippled-server). A list publisher's manifest provides information about the list publisher. Both are typically encoded to binary in the XRP Ledger's standard [binary serialization format](../../protocol/binary-format.md). (There is no standard JSON representation of a manifest.)

View File

@@ -5,7 +5,7 @@ labels:
- Payment Channels
---
# account_channels
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/AccountChannels.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/AccountChannels.cpp "Source")
The `account_channels` method returns information about an account's Payment Channels. This includes only channels where the specified account is the channel's source, not the destination. (A channel's "source" and "owner" are the same.) All information retrieved is relative to a particular version of the ledger.
@@ -57,14 +57,11 @@ The request includes the following parameters:
| Field | Type | Required? | Description |
|:----------------------|:---------------------|:----------|-------------|
| `account` | String - [Address][] | Yes | Look up channels where this account is the channel's owner/source. |
| `amount` | Object or String | No | The total amount allocated to this channel. |
| `balance` | Object or String | No | The total amount paid out from this channel, as of the ledger version used. (You can calculate the amount left in the channel by subtracting `balance` from `amount`). |
| `destination_account` | String - [Address][] | No | A second account; if provided, filter results to payment channels whose destination is this account. |
| `ledger_hash` | String | No | The unique hash of the ledger version to use. (See [Specifying Ledgers][]) |
| `ledger_index` | Number or String | No | The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
| `limit` | Number | No | Limit the number of transactions to retrieve. Cannot be less than 10 or more than 400. Positive values outside this range are replaced with the closest valid option. The default is 200. |
| `marker` | [Marker][] | No | Value from a previous paginated response. Resume retrieving data where that response left off. |
| `transfer_rate` | Number | No | The fee to charge when users make claims on a payment channel, initially set on the creation of a payment channel and updated on subsequent funding or claim transactions. |
## Response Format
@@ -175,8 +172,6 @@ Each Channel Object has the following fields:
| Field | Type | Description |
|:----------------------|:-----------------|:----------------------------------|
| `account` | String | The owner of the channel, as an [Address][]. |
| `amount` | Object or String | The total amount of [XRP, in drops][] or fungible tokens allocated to this channel. |
| `balance` | String | The total amount of [XRP, in drops][] or fungible tokens paid out from this channel, as of the ledger version used. (You can calculate the amount left in the channel by subtracting `balance` from `amount`.) |
| `channel_id` | String | A unique ID for this channel, as a 64-character hexadecimal string. This is also the [ID of the channel object](../../../protocol/ledger-data/ledger-entry-types/paychannel.md#paychannel-id-format) in the ledger's state data. |
| `destination_account` | String | The destination account of the channel, as an [Address][]. Only this account can receive the `amount` in the channel while it is open. |
| `settle_delay` | Unsigned Integer | The number of seconds the payment channel must stay open after the owner of the channel requests to close it. |

View File

@@ -7,7 +7,7 @@ labels:
- Tokens
---
# account_currencies
[[Source]](https://github.com/XRPLF/rippled/blob/df966a9ac6dd986585ecccb206aff24452e41a30/src/ripple/rpc/handlers/AccountCurrencies.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/AccountCurrenciesHandler.cpp "Source")
The `account_currencies` command retrieves a list of currencies that an account can send or receive, based on its trust lines. (This is not a thoroughly confirmed list, but it can be used to populate user interfaces.)

View File

@@ -6,7 +6,7 @@ labels:
- XRP
---
# account_info
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/AccountInfo.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/AccountInfo.cpp "Source")
The `account_info` command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger.

View File

@@ -65,8 +65,6 @@ The request accepts the following parameters:
| `limit` | Number | No | Limit the number of trust lines to retrieve. The server may return less than the specified limit, even if there are more pages of results. Must be within the inclusive range 10 to 400. Positive values outside this range are replaced with the closest valid option. The default is 200. |
| `marker` | [Marker][] | No | Value from a previous paginated response. Resume retrieving data where that response left off. |
| `peer` | String - [Address][] | No | A second account; if provided, filter results to trust lines connecting the two accounts. |
| `locked_balance` | Object | No | The total amount locked in payment channels or escrow. |
| `lock_count` | Number | No | the total number of lock balances on a RippleState ledger object. |
The following parameters are deprecated and may be removed without further notice: `ledger` and `peer_index`.

View File

@@ -1,13 +1,11 @@
---
html: account_nfts.html
parent: account-methods.html
seo:
description: Get a list of all NFTs for an account.
labels:
- Non-fungible Tokens, NFTs
- Non-fungible Tokens, NFTs
---
# account_nfts
[[Source]](https://github.com/xrplf/rippled/blob/master/src/ripple/rpc/handlers/AccountObjects.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/AccountObjects.cpp "Source")
The `account_nfts` method returns a list of `NFToken` objects for the specified account.

View File

@@ -7,7 +7,7 @@ labels:
- Decentralized Exchange
---
# account_offers
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/AccountOffers.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/AccountOffers.cpp "Source")
The `account_offers` method retrieves a list of [offers](../../../../concepts/tokens/decentralized-exchange/offers.md) made by a given [account](../../../../concepts/accounts/index.md) that are outstanding as of a particular [ledger version](../../../../concepts/ledgers/index.md).

View File

@@ -1,14 +1,12 @@
---
html: account_tx.html
parent: account-methods.html
seo:
description: Get a list of transactions affecting an account.
labels:
- Payments
- Accounts
- Payments
- Accounts
---
# account_tx
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/AccountTx.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/AccountTx.cpp "Source")
The `account_tx` method retrieves a list of validated transactions that involve a given account.

View File

@@ -1,6 +1,4 @@
---
html: gateway_balances.html
parent: account-methods.html
seo:
description: Calculate total amounts issued by an account.
labels:
@@ -8,7 +6,7 @@ labels:
- Accounts
---
# gateway_balances
[[Source]](https://github.com/XRPLF/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/GatewayBalances.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/GatewayBalances.cpp "Source")
The `gateway_balances` command calculates the total balances issued by a given account, optionally excluding amounts held by [operational addresses](../../../../concepts/accounts/account-types.md).

View File

@@ -1,13 +1,11 @@
---
html: noripple_check.html
parent: account-methods.html
seo:
description: Get recommended changes to an account's Default Ripple and No Ripple settings.
labels:
- Tokens
- Tokens
---
# noripple_check
[[Source]](https://github.com/XRPLF/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/NoRippleCheck.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/NoRippleCheck.cpp "Source")
The `noripple_check` command provides a quick way to check the status of [the Default Ripple field for an account and the No Ripple flag of its trust lines](../../../../concepts/tokens/fungible-tokens/rippling.md), compared with the recommended settings.

Some files were not shown because too many files have changed in this diff Show More