rippled 3.2.0 changes the example config's [port_peer] default from 51235
to the IANA-registered port 2459. Update new-node/own-server references
and fix the renamed config link (rippled-example.cfg -> xrpld-example.cfg).
Existing nodes (e.g. s2.ripple.com) keep 51235, so real-hub references are
left unchanged.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Faucet: improve handling of saved address, display of modes
Faucet improvements: suggestions from code review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Gem Wallet is an open-source, self-custody mobile wallet for iOS and Android that supports XRP and XRPL tokens.
https://gemwallet.com/xrp-wallet/
The official website of the wallet is Gemwallet.com
- Switch all code samples to server_state (integer drops)
- Add drops_to_xrp conversion for display in JS, Python, and Go
- Add Account Management group to sidebar under Best Practices
- Update links to the renamed tutorial
- No redirect added yet (will be done alongside other tutorials-iav4
redirects)
- Remove redundant "set-regular-key" JS/Py sample code
- Move Go sample code to updated JS/Py folder
- Add a little more detail to 'Assign...' tutorial for SEO (so people
looking for key rotation practices will find it)
Rewrite 'Assign a Regular Key Pair' tutorial w/ JS code sample
Add Python sample code for assign regular key
Slight rephrasings re: changing regular key
Remove emoji from code sample per @maria-robobug review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
More changes per review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Add new code samples for setting up multisigning
Rewrite 'Set Up Multi-signing' Tutorial
Remove emoji from multi-signing setup code sample
Apply suggestions from review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Adjust 'See Also' in multi-signing setup
New code samples for sending multi-signed tx
Rewrite 'Send a Multi-Signed Transaction' tutorial
Remove old multisigning code samples
These code samples weren't bad, but they didn't fully embody best
practices like reliable transaction submission, and they're fully
obsolete with the new multi-signing code samples in place.
Apply suggestions from review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Rewrite 'Remove a Regular Key Pair' tutorial
Remove emojis from code sample
Remove regular key: edits per review
Rewrite "Disable Master Key Pair" tutorial
Remove emojis from code samples
Disable master key pair: edits per @maria-robobug review
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
I tried out this tutorial today and managed to complete it successfully, but I have some suggestions to help with some hiccups I encountered along the way.
Minor edit re: each node steps for validators.txt
Fix private network fixes
- Update "Send a Time-Held Escrow" to "Send a Timed Escrow" with new
code samples in JS and Python.
- Update "Send a Conditionally-Held Escrow" to "Send a Conditional
Escrow" with new code samples in JS and Python.
- Update "Cancel an Expired Escrow" and "Look Up Escrows" with new code
samples.
- Remove translations of the old tutorials, which are substantially
different from the new tutorials.
- Remove websocket API examples that were used in the old tutorials.
- Remove the "Use Escrow as a Smart Contract" article, which was an
awkward mix between a use case and a tutorial.
- Update sidebars and redirects for the removed and renamed tutorials.
This skill generates a draft release notes blog post for a new rippled version, then sorts the entries into the correct subsections.
## Execution constraints
- **Do NOT write scripts** to sort or process the file. Prefer the Edit tool for targeted changes. Use Write only when replacing large sections that are impractical to edit incrementally.
- **Output progress**: Before each major step (generating raw release notes, reviewing file, processing amendments, sorting entries, reformatting, cleanup), output a brief status message so the user can see progress.
## Step 1: Generate the raw release notes
Run the Python script from the repo root. Pass through all arguments from `$ARGUMENTS`:
- **Unsorted entries**: After the **Bug Bounties and Responsible Disclosures** section is an unsorted list of entries with title, link, labels, files, and description for context
## Step 3: Process amendments
Handle Amendments first, before sorting other entries.
**3a. Process the auto-sorted Amendments subsection:**
The HTML comment contains three lists — follow them exactly:
- **Include**: Keep these entries.
- **Exclude**: Remove these entries.
- Entries on **neither** list: Remove these entries.
**3b. Scan unsorted entries for unreleased amendment work:**
Search through ALL unsorted entries for titles, labels, descriptions, or files that reference amendments on the "Exclude" or "Other amendments not part of this release" lists. Remove entries that directly implement, enable, fix, or refactor these amendments. Keep entries that are general changes that merely reference the amendment as motivation — if the code change is useful on its own regardless of whether the amendment ships, keep it.
**3c. If you disagree with any amendment decisions, make a note to the user but do NOT deviate from the rules.**
## Step 4: Sort remaining unsorted entries into subsections
Move each remaining unsorted entry into the appropriate subsection.
Use these signals to categorize:
**Files changed** (strongest signal):
- Only `.github/`, `CMakeLists.txt`, `conan*`, CI config files → **CI/Build**
- Only `src/test/`, `*_test.cpp` files → **Testing**
- Only `*.md`, `docs/` files → **Documentation**
**Labels** (strong signal):
-`Bug` label → **Bug Fixes**
**Title prefixes** (medium signal):
-`fix:` → **Bug Fixes**
-`feat:` → **Features**
-`refactor:` → **Refactors**
-`docs:` → **Documentation**
-`test:` → **Testing**
-`ci:`, `build:`, `chore:` → **CI/Build**
**Description content** (when other signals are ambiguous):
- Read the PR description to understand the change's purpose
- PRs that change API behavior, remove features, or have "Breaking change" checked in their description → **Breaking Changes**
Additional sorting guidance:
- Watch for revert pairs: If a PR was committed and then reverted (or vice versa), check that the net effect is accounted for — don't include both.
## Step 5: Reformat sorted entries
After sorting, reformat each entry to match the release notes style.
**Amendment entries** should follow this format:
```markdown
- **amendmentName**: Description of what the amendment does. ([#1234](https://github.com/XRPLF/rippled/pull/1234))
```
- Use more detail for amendment descriptions since they are the most important. Use present tense.
- If there are multiple entries for the same amendment, merge into one, prioritizing the entry that describes the actual amendment.
**Feature and Breaking Change entries** should follow this format:
```markdown
- Description of the change. ([#1234](https://github.com/XRPLF/rippled/pull/1234))
```
- Keep the description concise. Use past tense.
**All other entries** should follow this format:
```markdown
- The PR title of the entry. ([#1234](https://github.com/XRPLF/rippled/pull/1234))
```
- Copy the PR title as-is. Only fix capitalization, remove conventional commit prefixes (fix:, feat:, ci:, refactor:, docs:, test:, chore:, build:), and adjust to past tense if needed. Do NOT rewrite, paraphrase, or summarize.
## Step 6: Clean up
- Add a short and generic description of changes to the existing `seo.description` frontmatter, e.g., "This version introduces new amendments and bug fixes." Do not create long lists of detailed changes.
- Add a more detailed summary of the release to the existing "Introducing XRP Ledger Version X.Y.Z" section. Include amendment names (organized in a list if more than 2), featuress, and breaking changes. Limit this to 1 paragraph.
- Do NOT delete the **Credits** or **Bug Bounties and Responsible Disclosures** sections
- Remove empty subsections that have no entries
- Remove all HTML comments (sorting instructions)
- Do a final review of the release notes. If you see anything strange, or were forced to take unintuitive actions by these instructions, notify the user, but don't make changes.
4. Si el estafador intercambió XRP por otro token en el XRP Ledger, contacta con el emisor del token. El emisor podría ser capaz [congelar la línea de confianza del estafador]((../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md) de prevenir que el estafador pueda enviar esos tokens a otras personas.
4. Si el estafador intercambió XRP por otro token en el XRP Ledger, contacta con el emisor del token. El emisor podría ser capaz [congelar la línea de confianza del estafador]((../docs/tutorials/tokens/fungible-tokens/freeze-a-trust-line.md) de prevenir que el estafador pueda enviar esos tokens a otras personas.
Para más detalles sobre reportar estafadores, consultar [Ayuda de Xrplorer Forensics](https://xrplorer.com/forensics/help).
@@ -88,7 +88,7 @@ El [metodo wallet_propose][] es una forma de generar el par de claves maestras.
**Atención:** Si un actor malicioso conoce tu clave privada maestra (o semilla), tendrá control completo sobre tu cuenta, a no ser que tu par de claves maestras se inhabilite. Puedes tomar todo tu dinero de la cuenta posee y causar un daño irreparable. ¡Trata tus valores secretos con cuidado!
Dado que cambiar el par de claves maestras es imposible, debes cuidarlo en proporción al valor de lo que posea. Una buena práctica es [guardar tu par de claves maestras offline](../../tutorials/how-tos/manage-account-settings/offline-account-setup.md) y configurar un par de claves normales para firmar transacciones en tu cuenta. Al mantener el par de claves maestras activadas pero offline, puedes estar razonablemente seguro de que nadie puede acceder a él a través de Internet, pero aun así deberías encontrarlo en caso de una emergencia.
Dado que cambiar el par de claves maestras es imposible, debes cuidarlo en proporción al valor de lo que posea. Una buena práctica es [guardar tu par de claves maestras offline](/docs/tutorials/best-practices/key-management/offline-account-setup.md) y configurar un par de claves normales para firmar transacciones en tu cuenta. Al mantener el par de claves maestras activadas pero offline, puedes estar razonablemente seguro de que nadie puede acceder a él a través de Internet, pero aun así deberías encontrarlo en caso de una emergencia.
Mantener tu par de claves maestras offline significa no colocar tu información secreta (passphrase, semilla, or clave privada) en cualquier sitio en que los actores maliciosos puedan tener acceso a él. En general, esto quiere decir que no está al alcance de un programa inofrmático que interactúe con Internet. Por ejemplo, puedes guardarlo en un equipo que no se conecta nunca a Internet, en un trozo de papel guardado en una caja fuerte, o tenerla completamente memorizada. (Memorizarla tiene algunos puntos inconvenientes, incluido ser imposible pasar la clave una vez muerto.)
@@ -119,7 +119,7 @@ Una buena práctica de seguridad es guardar tu clave privada maestra en algun si
El par de claves normales tiene el mismo formato que el par de claves maestras. Las generas de la misma forma (por ejemplo, usando el [método wallet_propose][]). La única diferencia es que el par de claves normales es que el par no está intrínsicamente vinculado a la cuenta para la que firma transacciones. Es posible (pero no es buena idea) utilizar el par de claves maestras de una cuenta como lel par de claves normales para otra cuenta.
La [transacción SetRegularKey][] asigna o cambia el par de claves normales de una cuenta. Para un tutorial de asignación o cambio de un par de claves normales, ver [Asignar par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md).
La [transacción SetRegularKey][] asigna o cambia el par de claves normales de una cuenta. Para un tutorial de asignación o cambio de un par de claves normales, ver [Asignar par de claves normales](/docs/tutorials/best-practices/key-management/assign-a-regular-key-pair.md).
## Algorítmos de firma
@@ -248,8 +248,8 @@ Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un val
- **Conceptos:**
- [Direcciones de emisión y operacionales](account-types.md)
- **Tutoriales:**
- [Asignación de par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
- [Cambiar o eliminar par de claves normales](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
- [Asignación de par de claves normales](/docs/tutorials/best-practices/key-management/assign-a-regular-key-pair.md)
- [Cambiar o eliminar par de claves normales](/docs/tutorials/best-practices/key-management/remove-a-regular-key-pair.md)
- **Referencias:**
- [Transacción SetRegularKey][]
- [Objeto de ledger AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
@@ -60,7 +60,7 @@ Podría darse el caso donde crees una lista de multi firma como "plan de respald
Para enviar transacciones multi-signed de forma satisfactoria, debes de hacer todo lo siguiente:
* La dirección que envía la transacción (especificada en el campo `Account`) debe tener un [objeto `SignerList` en el ledger ](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md). Para instrucciones de cómo hacer esto, ver [Set Up Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md).
* La dirección que envía la transacción (especificada en el campo `Account`) debe tener un [objeto `SignerList` en el ledger ](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md). Para instrucciones de cómo hacer esto, ver [Set Up Multi-Signing](/docs/tutorials/best-practices/key-management/set-up-multi-signing.md).
* La transacción debe incluir el campo `SigningPubKey` como un valor vacío.
* La transacción debe incluir el [campo `Signers`](../../references/protocol/transactions/common-fields.md#signers-field) conteniendo un array de firmas.
* Las firmas presentadas en el array `Signers` debe coincidir con los firmantes definidos en la `SignerList`.
@@ -72,8 +72,8 @@ Para enviar transacciones multi-signed de forma satisfactoria, debes de hacer to
@@ -54,7 +54,7 @@ Las aplicaciones pueden buscar los valores de las reservas base e incremental ac
Para determinar las reservas de propietario de una cuenta, hay que multiplicar la reserva incremental por el número de objetos que la cuenta posee. Para mirar el número de objetos que una cuenta posee, llama al [método account_info][] y toma `account_data.OwnerCount`.
Para calcular el requisito total de direcciones, multiplica `OwnerCount` por `reserve_inc_xrp`, y luego suma `reserve_base_xrp`. [Aquí tienes una demostración](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17) del cálculo en Python.
Para calcular el requisito total de direcciones, multiplica `OwnerCount` por `reserve_inc_xrp`, y luego suma `reserve_base_xrp`. [Aquí tienes una demostración](/docs/tutorials/sample-apps/build-a-desktop-wallet-in-python.md#codeblock-17) del cálculo en Python.
## Quedarse por debajo del requisito de reserva
@@ -76,6 +76,6 @@ El XRP Ledger tiene un mecanismo para ajustar los requisitos de reserva. Estos a
- [Objeto AccountRoot][]
- [Votación de Fee](../consensus-protocol/fee-voting.md)
- [Pseudo-transacción SetFee][]
- [Tutorial: Calcular y mostrar los requisitos de reserva (Python)](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#3-display-an-account)
- [Tutorial: Calcular y mostrar los requisitos de reserva (Python)](/docs/tutorials/sample-apps/build-a-desktop-wallet-in-python.md#3-display-an-account)
@@ -27,7 +27,7 @@ Necesitas confiar en el servidor que utilizas. Si te conectas a un servidor mali
* Podría selectivamente mostrar u ocultar los caminos (o paths) de pago y las foertas de intercambio de divisas para garantizar su propio beneficio mientras no te ofrece la mejor oferta.
* Si le enviaste la clave secreta de tu dirección, esto podría generar transacciones arbitrarias en tu nombre e incluso transferir o destruir todo el dinero que la dirección posee.
Adicionalmente, ejecutar tu propio servidor te da [acceso de administrador](../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access), lo que te permite ejecutar comandos exclusivos de administrador y de carga intensa. Si utilizas un servidor compartido, debes preocuparte por los otros usuarios del mismo servidor compitiendo contra ti por el poder de computación del servidor. Muchos de los comandos en el API WebSocket puede poner mucha presión sobre el servidor, por lo que el servidor tiene la opción de reducir sus respuestas cuando lo necesite. Si compartes un servidor con otros, puede que no siempre consigas los mejores resultados posibles.
Adicionalmente, ejecutar tu propio servidor te da [acceso de administrador](/docs/tutorials/get-started/get-started-http-websocket-apis.md#admin-access), lo que te permite ejecutar comandos exclusivos de administrador y de carga intensa. Si utilizas un servidor compartido, debes preocuparte por los otros usuarios del mismo servidor compitiendo contra ti por el poder de computación del servidor. Muchos de los comandos en el API WebSocket puede poner mucha presión sobre el servidor, por lo que el servidor tiene la opción de reducir sus respuestas cuando lo necesite. Si compartes un servidor con otros, puede que no siempre consigas los mejores resultados posibles.
Finalmente, si ejecutas un servidor de validación, puedes utilizar un servidor común como proxy a la red pública mientras mantienes tu servidor de vaalidación en una red privada la cual es solo accesible desde el mundo exterior desde tu servidor común. Esto hace más difícil comprometer la integridad de tu servidor de validación.
@@ -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.
@@ -12,7 +12,7 @@ El software del servidor `rippled` puede ejecutarse en varios modos dependiendo
- [**Modo P2P**](#modo-p2p) - Este es el modo principal del servidor: sigue la red peer-to-peer, procesa transacciones, y mantiene cierta cantidad de [histórico del ledger](ledger-history.md). Este modo se puede configurar para alguno o todos los siguientes roles:
- [**Validador**](#validadores) - Ayuda a asegurar la red participando en el consenso.
- [**Servidor API**](#servidores-api) - Proporciona [acceso API](../../tutorials/http-websocket-apis/build-apps/get-started.md) para leer datos del ledger compartido, enviar transacciones, y mirar la actividad en el ledger. Opcionalmente, puede ser un [**servidor full history**](#servidores-full-history), el cual guarda un registro completo de transacciones y el histórico del ledger.
- [**Servidor API**](#servidores-api) - Proporciona [acceso API](/docs/tutorials/get-started/get-started-http-websocket-apis.md) para leer datos del ledger compartido, enviar transacciones, y mirar la actividad en el ledger. Opcionalmente, puede ser un [**servidor full history**](#servidores-full-history), el cual guarda un registro completo de transacciones y el histórico del ledger.
- [**Servidor hub**](#hubs-públicos) - Transmite mensajes entre muchos otros miembros de la red peer-to-peer.
- [**Modo solitario**](#modo-solitario) - Un modo offline para pruebas. No se conecta a la red peer-to-peer ni usa consenso.
- [Canjear un cheque por la cantidad exacta](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
- [Canjear un cheque por una cantidad flexible](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
- [Cancelar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cancel-a-check.md)
-**Tutoriales de cheques:**
- [Enviar un cheque](/docs/tutorials/payments/send-a-check.md)
@@ -39,8 +39,7 @@ El siguiente diagrama resume el ciclo de vida de un canal de pago:
- **Conceptos relacionados:**
- [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
- **Tutoriales y casos de uso:**
- [Utilizar canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
- [Abrir un canal de pago para activar una red de intercambio](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/open-a-payment-channel-to-enable-an-inter-exchange-network.md)
- [Utilizar canales de pago](../../tutorials/payments/use-payment-channels.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
@@ -19,6 +19,6 @@ Generalmente, al enviar stablecoins, utilizas una [transacción Payment][]. Algu
- Omitir el campo `Paths`. Este campo es innecesario cuando se envía directamente desde el emisor, o desde una cartera caliente siempre y cuando los tokens que se envían y los que se reciben tengan el mismo código de divisa y emisor, es decir, sean la misma stablecoin. El campo `Paths` está destinado a [Pagos entre divisas](cross-currency-payments.md) y a pagos multi-salto (rippling) más largos. Si realizas una búsqueda de rutas (paths) de manera ingenua y adjuntas las rutas a tu transacción, tu pago puede tomar un camino indirecto más costoso en lugar de fallar si el camino directo no está disponible; los usuarios malintencionados incluso pueden configurar esto.
- Si recibes un código de resultado `tecPATH_DRY`, esto suele indicar que el cliente no tiene configurada la línea de confianza (trustline) necesaria, o que los ajustes de rippling de tu emisor no están configurados correctamente.
Para un tutorial detallado sobre cómo emitir un token en el XRP Ledger, ya sea una stablecoin u otro tipo, visita [Emitir un token fungible](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md).
Para un tutorial detallado sobre cómo emitir un token en el XRP Ledger, ya sea una stablecoin u otro tipo, visita [Emitir un token fungible](../../tutorials/tokens/fungible-tokens/issue-a-fungible-token.md).
El XRP Ledger posiblemente tenga el _exchange descentralizado_ más antiguo del mundo (a veces abreviado como "DEX"), operando de manera continua desde el lanzamiento del XRP Ledger en 2012. Este exchange permite a los usuarios comprar y vender [tokens](../index.md) por XRP u otros tokens, con [costes](../../transactions/fees.md) mínimos cargados a la red misma (no pagados a ninguna parte).
**Atención**: Cualquiera puede [emitir un token](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) con el código de moneda o símbolo de ticker que desee y venderlo en el exchange descentralizado. Siempre realiza una debida diligencia antes de comprar un token y presta atención al emisor. De lo contrario, podrías entregar algo de valor y recibir tokens sin valor a cambio.
**Atención**: Cualquiera puede [emitir un token](../../../tutorials/tokens/fungible-tokens/issue-a-fungible-token.md) con el código de moneda o símbolo de ticker que desee y venderlo en el exchange descentralizado. Siempre realiza una debida diligencia antes de comprar un token y presta atención al emisor. De lo contrario, podrías entregar algo de valor y recibir tokens sin valor a cambio.
description: Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system. #TODO: translate
`Batch`トランザクションは、最大8つのトランザクションを単一のバッチで送信します。各トランザクションは、4つのモード(全て成功または全て失敗(All or Nothing)、一つのみ成功(Only One)、失敗まで継続(Until Failure)、および独立実行(Independent))のいずれかでアトミックに実行されます。
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.