run prettier

add config
Merge pull request #3403 from XRPLF/mvadari-patch-1
2026-01-13 19:25:17 +00:00 · 2026-01-12 14:19:31 -05:00 · 2026-01-12 14:19:12 -05:00 · 2026-01-12 10:26:35 -08:00 · 2026-01-12 13:24:03 -05:00 · 2026-01-12 10:05:46 +00:00
1854 changed files with 375253 additions and 104331 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -8,8 +8,6 @@ yarn-error.log
 *.iml
 .venv/
 _code-samples/*/js/package-lock.json
-*.css.map

 # PHP
 composer.lock
-.cursor/
--- a/.prettierrc.yaml
+++ b/.prettierrc.yaml
@@ -0,0 +1,4 @@
+semi: false
+singleQuote: true
+tabWidth: 2
+printWidth: 150
--- a/@l10n/es-ES/CODE_OF_CONDUCT.md
+++ b/@l10n/es-ES/CODE_OF_CONDUCT.md
@@ -8,19 +8,19 @@ Con el fin de fomentar un ambiente abierto y acogedor, nosotros, como contribuid

 Ejemplos de comportamiento que contribuyen a crear un ambiente positivo incluyen:

-* Utilizar lenguaje acogedor e inclusivo
-* Ser respetuoso con los diferentes puntos de vista y experiencias
-* Saber aceptar las críticas constructivas
-* Centrarse en lo que es lo mejor para la comunidad
-* Mostrar empatía hacia otros miembros de la comunidad
+- Utilizar lenguaje acogedor e inclusivo
+- Ser respetuoso con los diferentes puntos de vista y experiencias
+- Saber aceptar las críticas constructivas
+- Centrarse en lo que es lo mejor para la comunidad
+- Mostrar empatía hacia otros miembros de la comunidad

 Ejemplos de comportamiento que no contribuyen a crear un ambiente positivo incluyen:

-* Utilizar un lenguaje o imágenes sexualizadas y atención o insinuaciones sexuales no deseadas
-* Trolear, comentario insultantes/peyorativos y ataques personales o políticos
-* Acoso público o en privado
-* Publicar información privada de otras personas, así cómo direcciones físicas o electrónicas, sin permiso explícito
-* Cualquier otra conducta que pueda ser razonablemente considerada inapropiada en un sentido profesional
+- Utilizar un lenguaje o imágenes sexualizadas y atención o insinuaciones sexuales no deseadas
+- Trolear, comentario insultantes/peyorativos y ataques personales o políticos
+- Acoso público o en privado
+- Publicar información privada de otras personas, así cómo direcciones físicas o electrónicas, sin permiso explícito
+- Cualquier otra conducta que pueda ser razonablemente considerada inapropiada en un sentido profesional

 ## Nuestras responsabilidades

--- a/@l10n/es-ES/CONTRIBUTING.md
+++ b/@l10n/es-ES/CONTRIBUTING.md
@@ -1,3 +1,3 @@
 # Contribuir

-Para obtener información sobre cómo contribuir a este repositorio, consulta [Contribute Documentation (XRPL.org)](https://xrpl.org/es_ES/contribute-documentation.html).
+Para obtener información sobre cómo contribuir a este repositorio, consulta [Contribute Documentation (XRPL.org)](https://xrpl.org/es_ES/contribute-documentation.html).
--- a/@l10n/es-ES/about/faq.md
+++ b/@l10n/es-ES/about/faq.md
@@ -1,11 +1,13 @@
 ---
 seo:
-    description: Respuestas a preguntas frecuentes sobre el XRP Ledger, el ecosistema XRPL y la comunidad.
+  description: Respuestas a preguntas frecuentes sobre el XRP Ledger, el ecosistema XRPL y la comunidad.
 subtitle: Respuestas a tus preguntas XRPL
 labels:
  - Blockchain
 ---
+
 ###### FAQ
+
 # Respuestas a Tus Preguntas XRPL

 <!--#{ Use H4s for questions and H2s for sections. This keeps the sidebar nav from getting too clustered and allows the faq filter to stylize things as an accordion. #}-->
@@ -38,27 +40,22 @@ Todos los nodos garantizan que las transacciones cumplen los requisitos del prot

 Ver [Consenso](../docs/concepts/consensus-protocol/index.md) para más información sobre el proceso de consenso.

-
 #### ¿Cuánto cuesta mantener un validador?

 Mantener un validador no requiere de comisiones o XRP. Es comparable al gasto de ejecutar un servidor de correo electrónico en términos de uso de electricidad.

-
 #### ¿Qué son Las Listas de Nodos Únicos (UNLs)?

 Las UNLs son las listas de validadores que un participante determinado cree que no conspirarán para defraudarle. Cada operador de servidor puede elegir su propia UNL, generalmente basándose en un cojunto determinado proporcionado por un publicador de confianza. (La lista predeterminada de un publicador a veces es llamada UNL predeterminada, o _dUNL_.) <!-- STYLE_OVERRIDE: will --> <!-- SPELLING_IGNORE: dUNL -->

-
 #### ¿Qué UNL debería escoger?

 Dado que cualquiera puede montar un validador, la carga de elegir un conjunto confiable de validadores recae sobre los participantes. Actualmente, la XRP Ledger Foundation y Ripple publican listas predeterminadas recomendadas de valiadores de alta calidad, basadas en desesmpeño pasado, identidades comprobadas, y políticas de IT responsables. Sin embargo, cada participante de la red puede elegir qué validadores considera confiables y no necesita seguir a uno de los publicadores mencionados anteriormente.

-
 #### Si Ripple recomienda la adopción de su UNL, ¿Esto no crea un sistema centralizado?

 No. Cada participante elige directa o indirectamente su UNL. Si Ripple dejase de operar o actuase de manera maliciosa, los participantes pueden cambiar sus UNLs para usar una lista de un publicador diferente.

-
 #### ¿Cuál es la estructura de incentivos para los validadores?

 El principal incentivo para ejecutar un validador es preservar y proteger el funcionamiento estable y la evolución sensata de la red. Son los validadores quienes deciden la evolución del XRP Ledger, por lo que cualquier negocio que utilice o dependa del XRP Ledger tiene un incentivo inherente para garantizar la confiabilidad y estabilidad de la red. Los validadores también se ganan el respeto y la buena voluntad de la comunidad al contribuir de esta manera.
@@ -67,12 +64,10 @@ Si ejecutas un servidor XRP Ledger para participar en la red, el costo y el esfu

 Para ver ejemplos de cómo los incentivos pueden distorsionar el comportamiento de validación, lee sobre [valor extraíble del minero (MEV en inglés)](https://arxiv.org/abs/1904.05234).

-
 #### ¿Pueden las instituciones financieras establecer validadores de transacciones para ayudarlas a cumplir estándares y requisitos institucionales específicos?

 No, las instituciones no pueden configurar políticas de validación personalizadas para elegir permitir algunas transacciones y rechazar otras. Los validadores siguen el protocolo o no. Si el software no sigue las reglas del protocolo, no funciona. Por lo tanto, no se recomienda que las instituciones busquen implementaciones personalizadas sin experiencia interna.

-
 #### ¿Qué pasa si más del 20% de los nodos de la red no están de acuerdo con la mayoría? ¿Cómo se elige la versión final del ledger?

 Normalmente, si hay una disputa sobre la validez de una transacción, esa transacción se pospone hasta que la mayoría pueda llegar a un acuerdo. Pero si más del 20% de la red no siguiera las mismas reglas de protocolo que la mayoría, la red se detendría temporalmente. Podría reanudarse cuando los participantes reconfiguren sus UNL en función de aquellos que quieran llegar a un consenso entre ellos. Se desea este retraso temporal en el procesamiento en lugar de duplicar el gasto.
@@ -83,7 +78,6 @@ Sin embargo, sólo puede haber una última versión del ledger _validated_ en un

 Para obtener más información sobre cómo se comporta el mecanismo de consenso del XRP Ledger en situaciones adversas, consulta [Protecciones de consenso contra ataques y modos de fallo](../docs/concepts/consensus-protocol/consensus-protections.md).

-
 #### ¿El XRP Ledger tiene un proceso formal para añadir validadores?

 No, un proceso formal para agregar validadores no es compatible con XRP Ledger, porque es un sistema sin autoridad central.
@@ -92,28 +86,24 @@ Los publicadores de UNL predeterminados individuales establecen sus propias pol

 Para recomendaciones y mejores prácticas, consulta [Ejecutar `rippled` como validador](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).

-
 #### Si la dUNL tiene lmayor influencia en la red, ¿quiere decir que XRPL es centralizado?
+
 Los validadores pueden optar por no utilizar la dUNL o cualquier UNL ampliamente utilizada. Cualquiera puede crear una nueva UNL en cualquier momento.

 Puede haber varias UNL en uso en la misma red. Cada operador puede personalizar la UNL de su propio servidor o elegir seguir una lista recomendada diferente. Todos estos servidores todavía pueden ejecutar la misma cadena y llegar a un consenso entre sí.

 Sin embargo, si tu UNL no coincide lo suficiente con las UNL utilizadas por otros, existe el riesgo de que su servidor se separe (fork) del resto de la red. Siempre que tu UNL tenga > 90 % de superposición con la utilizada por las personas con las que transaccionas, estás completamente a salvo de bifurcarte. Si tiene menos superposición, es posible que aún puedas seguir la misma cadena, pero las posibilidades de bifurcarte aumentan con una menor superposición, peor conectividad de red y la presencia de validadores maliciosos o poco confiables en tu UNL.

-
 ## Papel de XRP

-
 #### ¿Cuál es el proposito de XRP?

 XRP se creó como el activo nativo de XRP Ledger para potenciar una nueva generación de pagos digitales: más rápidos, más ecológicos y más baratos que cualquier activo digital anterior. También sirve para proteger el ledger del spam y para [conectar divisas](../docs/concepts/tokens/decentralized-exchange/autobridging.md) en el exchange descentralizado del XRP Ledger, cuando hacerlo es beneficioso para los usuarios. Con el tiempo, la comunidad XRP Ledger ha sido pionera en nuevos [casos de uso](/about/uses) para XRP, al igual que el propio XRP Ledger.

-
 #### ¿Cómo responde el XRP Ledger al flood de transaciones?

 El XRP Ledger está diseñado para establecer el [coste de transacción](../docs/concepts/transactions/transaction-cost.md) dinámicamente en función de la demanda como una medida antispam. El impacto de cualquier posible manipulación de XRP es minimizado a medida que la red crece, crece la capitalización y crece el volumen de transacciones.

-
 #### ¿Qué ocurre con el lavado de dinero y la actividad económica sospechosa?

 <!-- STYLE_OVERRIDE: regarding -->
@@ -124,10 +114,8 @@ Ripple se compromete a monitorear e informar cualquier indicador AML en la red X

 [XRP Forensics / xrplorer](https://xrplorer.com/) mantiene una lista de asesoramiento para rastrear y minimizar el lavado de dinero, las estafas, el fraude y el uso ilícito del XRP Ledger. Los exchanges y otros proveedores de servicios pueden utilizar este servicio para prevenir y reaccionar ante delitos financieros.

-
 ## Consideraciones de seguridad

-
 #### ¿Cuál es el proceso para revisar las contribuciones de código de terceros?

 El proceso de contribución de código comienza cuando un desarrollador abre una [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) a un repositorio de código fuente como el [repositorio `rippled`](https://github.com/xrplf/rippled/), que contiene la implementación de referencia de Ripple del núcleo del servidor y del protocolo de XRP Ledger.
@@ -136,7 +124,6 @@ Este pull request activa pruebas unitarias y de integración automatizadas, así

 Una vez que el pull request pasa las pruebas automatizadas y recibe la aprobación de los revisores, un [mantenedor del repositorio](https://opensource.guide/best-practices/) confiable puede prepararlo para su inclusión en la próxima versión beta.

-
 #### ¿Ripple posee o controla el XRP Ledger o la red XRP Ledger?

 No, Ripple no posee ni controla el XRP Ledger o la red XRP Ledger.
@@ -145,7 +132,6 @@ Ripple contribuye a una implementación de referencia del nucleo del servidor de

 Varias entidades publican listas de validadores recomndadados (UNLs). Desde julio de 2023, Ripple mantiene solo uno de los 35 validadores que están en la UNL por defecto.

-
 #### ¿El XRP Ledger distingue entre el código base para la validación y el del software del usuario?

 Sí. Hay varias [librerías de cliente para XRP Ledger](../docs/references/client-libraries.md) que están destinadas a desarrolladores de software de usuario. Estas librerias tienen distintos códigos base y repositorios del [núcleo del servidor XRP Ledger](../docs/concepts/networks-and-servers/index.md) que alimenta la red y valida las transacciones.
--- a/@l10n/es-ES/about/privacy-policy.md
+++ b/@l10n/es-ES/about/privacy-policy.md
@@ -1,8 +1,9 @@
 ---
 seo:
-    title: Política de privacidad
-    description: Esta política describe cómo MTU XRP Ledger Trust respeta tu privacidad y detalla la recopilación, uso, y divulgación de los datos involucrados en el uso de este servicio.
+  title: Política de privacidad
+  description: Esta política describe cómo MTU XRP Ledger Trust respeta tu privacidad y detalla la recopilación, uso, y divulgación de los datos involucrados en el uso de este servicio.
 ---
+
 # Política de privacidad de XRPL.org

 Última actualización: 20 de enero, 2023
@@ -13,14 +14,14 @@ MTU XRP Ledger Trust (“MTU XRP Ledger Trust”, "Nosotros"", "Nuestro") respet

 Para los fines de esta Política de Privacidad:

-* _Compañía_ - (referida como "MTU XRP Ledger Trust", "Nosotros", "Nuestro" en esta política) se refiere a XRPL.org
-* _Cookies_ - son pequeños ficheros que se colocan en tu ordenador, dispositivo móvil o cualquier otro dispositivo por un sitio web, conteniendo detalles de tu historial de navegación en ese sitio web entre sus muchos usos.
-* _Dispositivo_ - significa cualquier dispositivo que puede acceder al servicio, como un ordenador, un teléfono móvil o una tablet digital.
-* _Datos personales_ - es cualquier información que se relacione con un usuario identificado o identificable.
-* _Servicio_ - se refiere a este sitio web XRPL.org.
-* _Proveedor de servicios_ - significa cualquier persona normal o jurídica que procesa los datos en nombre de MTU XRP Ledger Trust. Se refiere a tercaras compañías o individuos contratados por MTU XRP Ledger Trust para facilitar el Servicio, para proveer el Servicio en nombre de MTU XRP Ledger Trust, para realizar servicios relacionados con el Servicio o para asistir a MTU XRP Ledger Trust analizando como el Servicio es utilizado.
-* _Datos de Uso_ - se refiere a datos recopilados automáticamente, generados por el uso del Servicio o la infraestructura del Servicio en sí (por ejemplo, la duración de una página visitada).
-* _Tú_ - significa el individuo que accede o usa el Servicio, o MTU XRP Ledger Trust, u otra entidad legal en nombre de la cual dicho individuo accede al Servicio, según corresponda.
+- _Compañía_ - (referida como "MTU XRP Ledger Trust", "Nosotros", "Nuestro" en esta política) se refiere a XRPL.org
+- _Cookies_ - son pequeños ficheros que se colocan en tu ordenador, dispositivo móvil o cualquier otro dispositivo por un sitio web, conteniendo detalles de tu historial de navegación en ese sitio web entre sus muchos usos.
+- _Dispositivo_ - significa cualquier dispositivo que puede acceder al servicio, como un ordenador, un teléfono móvil o una tablet digital.
+- _Datos personales_ - es cualquier información que se relacione con un usuario identificado o identificable.
+- _Servicio_ - se refiere a este sitio web XRPL.org.
+- _Proveedor de servicios_ - significa cualquier persona normal o jurídica que procesa los datos en nombre de MTU XRP Ledger Trust. Se refiere a tercaras compañías o individuos contratados por MTU XRP Ledger Trust para facilitar el Servicio, para proveer el Servicio en nombre de MTU XRP Ledger Trust, para realizar servicios relacionados con el Servicio o para asistir a MTU XRP Ledger Trust analizando como el Servicio es utilizado.
+- _Datos de Uso_ - se refiere a datos recopilados automáticamente, generados por el uso del Servicio o la infraestructura del Servicio en sí (por ejemplo, la duración de una página visitada).
+- _Tú_ - significa el individuo que accede o usa el Servicio, o MTU XRP Ledger Trust, u otra entidad legal en nombre de la cual dicho individuo accede al Servicio, según corresponda.

 ## Recopilación y uso de tus datos

@@ -36,9 +37,9 @@ Nosotros también podemos recopilar información que Tu navegador envía cada ve

 Nosotros utilizamos Cookies y tecnologías de seguimiento similares para rastrear la actividad en Nuestro Servicio y almacenar cierta información. Las tecnologías de seguimiento utilizadas son beacons, tags y scripts para recopilar y rastrear información y para mejorar y analizar Nuestro Servicio. Las tecnologías que utilizamos pueden incluir:

-* _Cookies o Cookies del Navegador_ - Una cookie es un pequeño archivo colocado en Tu Dispositivo. Puede instruir a Tu navegador para que rechace todas las Cookies o para que te indique cuándo se envía una Cookie. Sin embargo, si Tu no aceptas Cookies, es posible que no puedas utilizar algunas partes de nuestro Servicio. A menos que hayas ajustado Tu configuración del navegador para que rechace Cookies, nuestro Servicio puede utilizar Cookies.
-* _Cookies Flash_ - Ciertas funciones de nuestro Servicio pueden utilizar objetos almacenados localmente (o Cookies Flash) para recopilar y almacenar información sobre Tus preferencias o Tu actividad en nuestro Servicio. Las Cookies Flash no son administradas por la misma configuración del navegador que se utiliza para las Cookies del Navegador.
-* _Web Beacons_ - Ciertas secciones de nuestro Servicio pueden contener pequeños archivos electrónicos conocidos como web beacons (también denominadas clear gifs, pixel tags y gifs de píxeles únicos) que permiten a la Compañía, por ejemplo, contar usuarios que han visitado esas páginas o abierto un correo electrónico y para otras estadísticas relacionadas con el sitio web (por ejemplo, registrar la popularidad de una cierta sección y verificar la integridad del sistema y del servidor).
+- _Cookies o Cookies del Navegador_ - Una cookie es un pequeño archivo colocado en Tu Dispositivo. Puede instruir a Tu navegador para que rechace todas las Cookies o para que te indique cuándo se envía una Cookie. Sin embargo, si Tu no aceptas Cookies, es posible que no puedas utilizar algunas partes de nuestro Servicio. A menos que hayas ajustado Tu configuración del navegador para que rechace Cookies, nuestro Servicio puede utilizar Cookies.
+- _Cookies Flash_ - Ciertas funciones de nuestro Servicio pueden utilizar objetos almacenados localmente (o Cookies Flash) para recopilar y almacenar información sobre Tus preferencias o Tu actividad en nuestro Servicio. Las Cookies Flash no son administradas por la misma configuración del navegador que se utiliza para las Cookies del Navegador.
+- _Web Beacons_ - Ciertas secciones de nuestro Servicio pueden contener pequeños archivos electrónicos conocidos como web beacons (también denominadas clear gifs, pixel tags y gifs de píxeles únicos) que permiten a la Compañía, por ejemplo, contar usuarios que han visitado esas páginas o abierto un correo electrónico y para otras estadísticas relacionadas con el sitio web (por ejemplo, registrar la popularidad de una cierta sección y verificar la integridad del sistema y del servidor).

 Las Cookies pueden ser "Persistentes" o de "Sesión". Las Cookies Persistentes permanecen en Tu computadora personal o dispositivo móvil cuando te desconectas, mientras que las Cookies de Sesión se eliminan tan pronto como cierras Tu navegador web.

@@ -79,11 +80,11 @@ Bajo ciertas circunstancias, La Compañía puede estar obligada a divulgar Tus D

 La Compañía puede divulgar Tus Datos de Uso en creencia de buena fe de que dicha accion es necesaria para:

-* Cumplir con una obligación legal
-* Proteger y defender los derechos y propiedades de La Compañía
-* Prevenir o investigar posibles irregularidades en relación con el Servicio
-* Proteger la seguridad personal de los Usuarios del Servicio o del público
-* Protegerse contra la responsabilidad legal
+- Cumplir con una obligación legal
+- Proteger y defender los derechos y propiedades de La Compañía
+- Prevenir o investigar posibles irregularidades en relación con el Servicio
+- Proteger la seguridad personal de los Usuarios del Servicio o del público
+- Protegerse contra la responsabilidad legal

 ## Seguridad de Tus Datos Personales

--- a/@l10n/es-ES/community/report-a-scam.md
+++ b/@l10n/es-ES/community/report-a-scam.md
@@ -2,27 +2,28 @@
 html: report-a-scam.html
 parent: contribute.html
 ---
+
 # Reportar una estafa

 En una industria que evoluciona dónde la confianza y la seguridad son críticas, las estafas continuan impidiendo el progreso en cripto y blockchain. Individuos y equipos de la comunidad XRP Ledger, como el equipo de Xrplorer forensics, ayuda a mitigar a esos timadores ofreciendo herramientas gratuitas para reportar estafas.

 ## Tomar medidas
+
 Si piensas que has sido estafado, asegúrate de recoleccionar toda la información que puedas sobre la estafa y el estafador tan pronto como sea posible. Revisa las opciones abajo de cómo tomar medidas.

 **Atención:** Por favor, ten en cuenta que _nadie_ puede congelar cuentas o revertir transacciones en el XRP Ledger. Esto es debido al diseño descentralizado de la blockchain del XRP Ledger.

 1. Envía la cartera del estafador al [equipo Xrplorer forensics](https://xrplorer.com/forensics/submit).

-     Esto ayuda a marcar cuentas usadas en actividades ilicitas e las incluye en un monitoreo adicional, auto-trazable, y con advertencias a otros usuarios, carteras, y exchanges. 
+   Esto ayuda a marcar cuentas usadas en actividades ilicitas e las incluye en un monitoreo adicional, auto-trazable, y con advertencias a otros usuarios, carteras, y exchanges.

 2. Reporta tu caso a tu autoridad policial local. Si el estafador es arrestado, es posible que consigas tu dinero de vuelta.

 3. Si el estafador envió tu XRP a un exchange, asegúrate de contactar con el equipo de soporte del exchange. El exchange puede congelar la cuenta del estafador en el exchange. Aquí hay enlaces de soporte a unos cuantos exchanges conocidos:
-
-    - [Binance](https://www.binance.com/en/support)
-    - [Coinbase](https://help.coinbase.com/)
-    - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
-    - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
+   - [Binance](https://www.binance.com/en/support)
+   - [Coinbase](https://help.coinbase.com/)
+   - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
+   - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)

 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.

--- a/@l10n/es-ES/docs/concepts/accounts/account-types.md
+++ b/@l10n/es-ES/docs/concepts/accounts/account-types.md
@@ -2,21 +2,21 @@
 html: account-types.html
 parent: accounts.html
 seo:
-    description: Los negocios que envían transacciones en el XRP Ledger automáticamente, deben configurar direcciones separadas para diferentes propósitos para minimizar el riesgo.
+  description: Los negocios que envían transacciones en el XRP Ledger automáticamente, deben configurar direcciones separadas para diferentes propósitos para minimizar el riesgo.
 labels:
  - Tokens
  - Seguridad
 ---
+
 # Tipos de cuenta

 {% partial file="/docs/_snippets/issuing-and-operational-addresses-intro.md" /%}

-
 ## Ciclo de vida de los fondos

 Cuando un emisor de tokens sigue esta separacion de roles, los fondos tienden a fluir en direcciones específicas, como se muetra en el siguiente diagrama:

-[{% inline-svg file="/docs/img/issued-currency-funds-flow.svg" /%}](/docs/img/issued-currency-funds-flow.svg "Diagrama: Los fondos fluyen desde la dirección emisora hasta las direcciones de reserva, a direcciones operacionales, hacia las direcciones de clientes y socios, y finalmente de regreso a la dirección emisora.")
+[{% inline-svg file="/docs/img/issued-currency-funds-flow.svg" /%}](/docs/img/issued-currency-funds-flow.svg 'Diagrama: Los fondos fluyen desde la dirección emisora hasta las direcciones de reserva, a direcciones operacionales, hacia las direcciones de clientes y socios, y finalmente de regreso a la dirección emisora.')

 La dirección emisora crea tokens enviando pagos a direcciones de reserva. Esos tokens tienen un valor negativo desde la perspectiva de la dirección emisora, ya que (a menudo) representan obligaciones. Los mismos tokens tienen valor positivo desde la otras perspectivas, incluyendo desde la perspectiva de las direcciones de reserva.

@@ -28,7 +28,6 @@ Como siempre, los pagos con tokens deben moverse a través de líneas de confian

 Eventualmente, alguien envía tokens de vuelta al emisor. Esto destruye esos tokens, reduciendo las obligaciones del emisor con el XRP Ledger. Si el token es una stablecoin, esto es el primer paso para canjear los tokens por los activos correspondientes fuera del ledger.

-
 ## Dirección emisora

 La dirección emisora es como una caja fuerte. Los socios, clientes y direcciones operacionales crean, líneas de confianza (trust lines) a la dirección emisora, pero esta dirección envía la menor cantidad de transacciones posibles. Periodícamente, un operador humano crea y firma una transacción desde la dirección emisora para recargar los balances de una dirección operacional o de reserva. Idealmente, la clave secreta utilizada para firmar esas transacciones nunca debería ser accesible desde ningun equipo conectado a Internet.
@@ -43,7 +42,6 @@ Si un actor malicioso descubre la clave secreta de la dirección emisora de una

 Una institución financiera puede emitir más de un token en el XRP Ledger desde una única dirección de emisión. Sin embargo, hay algunas configuraciones que se aplican por igual a todos los tokens (fungibles) emitidos desde una dirección, incluido el porcentaje de [comisiones de transferencia](../tokens/fungible-tokens/transfer-fees.md) y el estado [congelación global](../tokens/fungible-tokens/freezes.md). Si la intitución financiera quiere la flexibilidad de manejar las configuraciones de distinta manera para cada token, la institución debe tener múltiples direcciones emisoras.

-
 ## Direcciones operacionales

 Una dirección operacional es como una caja registradora. Realiza pagos en nombre de la institución para transferir tokens a clientes y socios. Para firmar transacciones automáticamente, la clave secreta para una dirección operacional debe ser alacenada en un servidor que está conectado a Internet. (La clave secreta puede estar almacenada encriptada, pero el servidor debe desencriptarla para firmar las transacciones.) Clientes y socios no crean ni deben crear trust lines a direcciones operacionales.
@@ -54,10 +52,9 @@ Cada dirección operacional tiene un balance limitado de tokens y XRP. Cuando el

 Si un actor malicioso descubre la clave secreta detrás de una dirección operacional, la institución financiera sólo puede perder tanto como esa dirección operacional contiene. La institución puede cambiar a una nueva dirección operacional sin que los clientes y socios tengan que realizar ninguna acción.

-
 ## Direcciones de reserva

-Otro paso opcional que una institución puede equilibrar el riesgo y la convivencia es utilizada como "direcciones de reserva"  como paso intermedio entre la dirección emisora y las direcciones operativas. La institución puede financiar direcciones XRP Ledger adicionales como direcciones de reserva, cuyas claves no están disponibles para los servidores siempre en línea, sino que confian a diferentes usuarios confiables.
+Otro paso opcional que una institución puede equilibrar el riesgo y la convivencia es utilizada como "direcciones de reserva" como paso intermedio entre la dirección emisora y las direcciones operativas. La institución puede financiar direcciones XRP Ledger adicionales como direcciones de reserva, cuyas claves no están disponibles para los servidores siempre en línea, sino que confian a diferentes usuarios confiables.

 Cuando una dirección operacional se está quedando sin fondos (ya sea tokens o XRP), un usuario confiable pueed utilizar su dirección de reserva para recargar el balance de una dirección operacional. Cuando una dirección de reserva se queda sin fondos, la institución puede usar la dirección emisora para enviar más fondos a la dirección de reserva en una sola transacción, y la dirección de reserva puede distribuir esos fondos entre sí si es necesario. Esto mejora la seguridad de la dirección emisora, permitíendole hacer menos transacciones, sin dejar demasiado dinero en un único sistema automatizado.

@@ -67,18 +64,17 @@ Como con las direcciones operacionales, una direccion de reserva debe tener una

 Si una dirección de reserva se ve comprometida, las consecuencias son similares a las de una dirección operacional. Un actor malintencionado puede robar cualquier saldo que posea la dirección de reserva, y la institución financiera puede cambiar a una nueva dirección de reserva sin que los clientes y socios realicen ninguna acción.

-
 ## Ver también

 - **Conceptos:**
-    - [Cuentas](index.md)
-    - [Claves criptográficas](cryptographic-keys.md)
+  - [Cuentas](index.md)
+  - [Claves criptográficas](cryptographic-keys.md)
 - **Tutoriales:**
-    - [Asignar par de claves regulares](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
-    - [Cambiar o eliminar par de claves regulares](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+  - [Asignar par de claves regulares](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+  - [Cambiar o eliminar par de claves regulares](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
 - **Referencias:**
-    - [metodo account_info][]
-    - [Transacción SetRegularKey][]
-    - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+  - [metodo account_info][]
+  - [Transacción SetRegularKey][]
+  - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/accounts/addresses.md
+++ b/@l10n/es-ES/docs/concepts/accounts/addresses.md
@@ -2,10 +2,11 @@
 html: addresses.html
 parent: accounts.html
 seo:
-    description: Las direcciones identifican de manera única las cuentas del XRP Ledger, utilizando el formato base58.
+  description: Las direcciones identifican de manera única las cuentas del XRP Ledger, utilizando el formato base58.
 labels:
  - Cuentas
 ---
+
 # Direcciones

 {% partial file="/docs/_snippets/data_types/address.md" /%}
@@ -14,20 +15,17 @@ Cualquier dirección válida puede [convertirse en una cuenta en el XRP Ledger](

 Crear una dirección válida es una tarea estríctamente matemática que empieza con el par de claves. Puedes generar un par de claves y calcular su dirección completamente offline sin comunicarte con el XRP Ledger o con cualquier otra entidad. La conversión desde una clave pública a una dirección implica una función hash unidireccional, por lo que es posible confirmar que esa clave pública coincide con una dirección pero es imposible derivar la clave pública únicamente a partir de la dirección. (Esta es parte de la razón por la que las transacciones firmadas incluyen la clave pública _y_ la dirección del remitente.)

-
 ## Direcciones especiales

 Algunas direcciones tienen un significado especial, o usos históricos, en el XRP Ledger. En muchos casos, se tratan de direcciones "black hole" o agujero negro, lo que significa que la dirección no se deriva de una clave secreta conocida. Como es efectivamente imposible adivinar una clave secreta a partir de una sola dirección, cualquier XRP que posean direcciones black hole estarán perdidos para siempre.

-
-| Dirección                     | Nombre | Significado | ¿Black Hole? |
-|-------------------------------|--------|-------------|--------------|
-| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `0`. En comunicaciones peer-to-peer, `rippled` utiliza esta dirección como el emisor de XRP. | Sí |
-| `rrrrrrrrrrrrrrrrrrrrBZbvji`  | ACCOUNT\_ONE | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `1`. En el ledger, las [entradas RippleState](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) utilizan esta dirección como marcador de posición para el emisor de un balance de una trust line. | Sí |
-| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | La cuenta génesis | Cuando `rippled` inicia un nuevo ledger génesis desde el principio (por ejemplo, en modo solitario), esta cuenta contiene todo el XRP. Esta cuenta es generada con el valor semilla `masterpassphrase` el cual está [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
-| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | black hole de reserva de nombre de Ripple | En el pasado, Ripple pedía a los usuarios enviar XRP a esta cuenta para reservar nombres Ripple.| Sí |
-| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | Dirección NaN | Versiones previas de [ripple-lib](https://github.com/XRPLF/xrpl.js) generaban esta dirección cuando se codificaba el valor [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) utilizan el formato de codificación [base58][] del XRP Ledger. | Sí |
-
+| Dirección                            | Nombre                                    | Significado                                                                                                                                                                                                                                                                                                                                             | ¿Black Hole? |
+| ------------------------------------ | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
+| `rrrrrrrrrrrrrrrrrrrrrhoLvTp`        | ACCOUNT_ZERO                              | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `0`. En comunicaciones peer-to-peer, `rippled` utiliza esta dirección como el emisor de XRP.                                                                                                                                                                              | Sí           |
+| `rrrrrrrrrrrrrrrrrrrrBZbvji`         | ACCOUNT_ONE                               | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `1`. En el ledger, las [entradas RippleState](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) utilizan esta dirección como marcador de posición para el emisor de un balance de una trust line.                                                  | Sí           |
+| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | La cuenta génesis                         | Cuando `rippled` inicia un nuevo ledger génesis desde el principio (por ejemplo, en modo solitario), esta cuenta contiene todo el XRP. Esta cuenta es generada con el valor semilla `masterpassphrase` el cual está [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No           |
+| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ`        | black hole de reserva de nombre de Ripple | En el pasado, Ripple pedía a los usuarios enviar XRP a esta cuenta para reservar nombres Ripple.                                                                                                                                                                                                                                                        | Sí           |
+| `rrrrrrrrrrrrrrrrrrrn5RM1rHd`        | Dirección NaN                             | Versiones previas de [ripple-lib](https://github.com/XRPLF/xrpl.js) generaban esta dirección cuando se codificaba el valor [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) utilizan el formato de codificación [base58][] del XRP Ledger.                                                                   | Sí           |

 ## Codificación de una dirección

@@ -39,11 +37,11 @@ Las direcciones XRP Ledger están codificadas utilizando [base58][] con el _dicc

 El siguiente diagrama muestra la relación entre las claves y las direcciones:

-[{% inline-svg file="/docs/img/address-encoding.svg" /%}](/docs/img/address-encoding.svg "Clave pública maestra + Prefijo Tipo →  ID de cuenta + Checksum → Dirección")
+[{% inline-svg file="/docs/img/address-encoding.svg" /%}](/docs/img/address-encoding.svg 'Clave pública maestra + Prefijo Tipo →  ID de cuenta + Checksum → Dirección')

 La fórmula para calcular direcciones XRP Ledger desde una clave pública es la siguiente. Para ver el código de ejemplo completo, consulta [`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js). Para el proceso de derivar la clave pública desde una passphrase a un valor semilla, consulta [Derivación de clave](cryptographic-keys.md#key-derivation).

-1. Importa los algoritmos necesarios: SHA-256, RIPEMD160, y base58. Configura el diccionario para base58.
+1.  Importa los algoritmos necesarios: SHA-256, RIPEMD160, y base58. Configura el diccionario para base58.

        ```
        'use strict';
@@ -56,7 +54,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
        assert(crypto.getHashes().includes('ripemd160'));
        ```

-2. Empieza con una clave pública 33-byte ECDSA secp256k1, o una clave pública 32-byte Ed25519. Para claves Ed25519, prefija la clave con el byte `0xED`.
+2.  Empieza con una clave pública 33-byte ECDSA secp256k1, o una clave pública 32-byte Ed25519. Para claves Ed25519, prefija la clave con el byte `0xED`.

        ```
        const pubkey_hex =
@@ -65,7 +63,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
        assert(pubkey.length == 33);
        ```

-3. Calcula el hash [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) del hash SHA-256 de la clave pùblica. Este valor es el ID de cuenta o "Account ID".
+3.  Calcula el hash [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) del hash SHA-256 de la clave pùblica. Este valor es el ID de cuenta o "Account ID".

        ```
        const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
@@ -74,7 +72,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
        const account_id = pubkey_outer_hash.digest();
        ```

-4. Calcula el hash SHA-256 hash del hash SHA-256 del Account ID; toma los 4 primeros bytes. Este valor es el "checksum".
+4.  Calcula el hash SHA-256 hash del hash SHA-256 del Account ID; toma los 4 primeros bytes. Este valor es el "checksum".

        ```
        const address_type_prefix = Buffer.from([0x00]);
@@ -84,7 +82,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
        const checksum =  chksum_hash2.slice(0,4);
        ```

-5. Concatena el payload y el checksum. Calcula el valor base58 del buffer concatenado. El resultado es la dirección.
+5.  Concatena el payload y el checksum. Calcula el valor base58 del buffer concatenado. El resultado es la dirección.

        ```
        const dataToEncode = Buffer.concat([payload, checksum]);
--- a/@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md
+++ b/@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md
@@ -2,11 +2,12 @@
 html: cryptographic-keys.html
 parent: accounts.html
 seo:
-    description: Utiliza las claves criptográficas para aprobar transacciones para que el XRP Ledger pueda ejecutarlas.
+  description: Utiliza las claves criptográficas para aprobar transacciones para que el XRP Ledger pueda ejecutarlas.
 labels:
  - Smart Contracts
  - Seguridad
 ---
+
 # Claves criptográficas

 En el XRP Ledger, una firma digital _autoriza_ a una [transacción](../transactions/index.md) a hacer un grupo específico de acciones. Solo las transacciones firmadas pueden ser enviadas a la red y ser incluidas en un ledger validado.
@@ -19,14 +20,13 @@ Para realizar una firma digital, utilizas un par de claves criptográficas asoci

 Muchas [librerías de cliente](../../references/client-libraries.md) y aplicaciones pueden generar un par de claves adecuadas para usar con el XRP Ledger. Sin embargo, solo deberías utilizar los pares de claves que fueron generados en dispositivos y software en los que confías. Las aplicaciones comprometidas pueden exponer tu secreto a usuarios maliciosos que pueden enviar transacciones desde tu cuenta luego.

-
 ## Componentes de clave

 Un par de claves criptográficas es una **clave privada** y una **clave pública** que están conectadas matemáticamente a través de un proceso de derivación de claves. Cada clave es un número; la clave privada debería elegirse usando una fuente de aleatoriedad fuerte. El [algoritmo de firma criptográfica](#algoritmos-de-firma) define el proceso de derivación de claves y establece restricciones en los números que pueden ser claves criptográficas.

 Al tratar con el XRP Ledger, también puedes utilizar algunos valores relacionados como passphrase, semilla, ID de cuenta, y dirección.

-[{% inline-svg file="/docs/img/cryptographic-keys.svg" /%}](/docs/img/cryptographic-keys.svg "Diagrama: Passphrase → Semilla → Clave privada → Clave pública → ID de cuenta ←→ Dirección")
+[{% inline-svg file="/docs/img/cryptographic-keys.svg" /%}](/docs/img/cryptographic-keys.svg 'Diagrama: Passphrase → Semilla → Clave privada → Clave pública → ID de cuenta ←→ Dirección')
 _Figura: Una vista simplificada de la relación entre los valores de clave criptográfica._

 La passphrase, semilla, y la clave privada son **secretos**: si conoces alguno de estos valores para una cuenta, puedes generar firmas válidas y tienes el control total sobre la cuenta. Si tienes una cuenta, se **muy cuidadoso** con la información secreta de tu cuenta. Si no tienes estos secretos, no puedes usar tu cuenta. Si alguien más tiene acceso a ellos, puede tener el control de tu cuenta.
@@ -37,11 +37,11 @@ Para más detalles técnicos y como la derivación de clave funciona, ver [Deriv

 ### Passphrase

-Puedes, opcionalmente, usar una passphrase u algún otro valor de entrada como forma de elegir una semilla o una clave privada. Esto es menos seguro que elegir la semilla o la clave privada desde la aleatoriedad, pero hay algunos casos excepcionales dónde quieras hacer esto. (Por ejemplo, en 2018 "XRPuzzler" regaló XRP a la primera persona [en resolver un puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); él utilizó la solución del puzzle como la passphrase para la cuenta que tenía el premio en XRP.)  <!-- SPELLING_IGNORE: xrpuzzler -->
+Puedes, opcionalmente, usar una passphrase u algún otro valor de entrada como forma de elegir una semilla o una clave privada. Esto es menos seguro que elegir la semilla o la clave privada desde la aleatoriedad, pero hay algunos casos excepcionales dónde quieras hacer esto. (Por ejemplo, en 2018 "XRPuzzler" regaló XRP a la primera persona [en resolver un puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); él utilizó la solución del puzzle como la passphrase para la cuenta que tenía el premio en XRP.) <!-- SPELLING_IGNORE: xrpuzzler -->

 La passphrase es información secreta, por lo que debes protegerla con mucho cuidado. Cualquiera que conozca la passphrase de la dirección tiene control total efectivo sobre la cuenta.

-### Semilla 
+### Semilla

 Un valor _semilla_ es un valor compacto que se utiliza para [derivar](#derivación-de-claves) las claves privada y pública actual de una cuenta. En la respuesta de un [método wallet_propose][], las `master_key`, `master_seed`, y `master_seed_hex` todas representan el mismo valor semilla, en varios formatos. Cualquiera de esos formatos puede ser utilizado para firmar transacciones. A pesar de tener el prefijo `master_`, las claves que esta semilla representa no necesariamente representan las claves maestras de una cuenta; puedes usar un par de claves como una clave normal o un miembro de una lista de firmantes.

@@ -59,10 +59,9 @@ La _clave pública_ es un valor utilizado para verificar la autenticidad de una

 Las transacciones en el XRP Ledger deben incluir las claves públicas para que la red pueda verificar las firmas de las transacciones. La clave pública no se puede utilizar para crear firmas válidas, así que es seguro compartirla públicamente.

-
 ### ID de cuenta y dirección

-El **ID de cuenta** es el identificador principal para una [cuenta](index.md) o para un par de claves. Se deriva de la clave pública. En el protocolo XRP Ledger, el ID de cuenta es un dato binario de 20 bytes. La mayoría de las APIs XRP Ledger representan la  Account ID como una dirección, en uno de dos formatos:
+El **ID de cuenta** es el identificador principal para una [cuenta](index.md) o para un par de claves. Se deriva de la clave pública. En el protocolo XRP Ledger, el ID de cuenta es un dato binario de 20 bytes. La mayoría de las APIs XRP Ledger representan la Account ID como una dirección, en uno de dos formatos:

 - Una "dirección clásica" escribe una ID de cuenta en [base58][] con un checksum. En una respuesta del [método wallet_propose][], este es el valor `account_id`.
 - Una "dirección-X" combina una ID de cuenta _y_ un [Tag de destino](../transactions/source-and-destination-tags.md) y escribe el valor combinado en [base58][] con un checksum.
@@ -79,7 +78,6 @@ El XRP Ledger soporta más de un [algoritmo de firma criptográfica](#algoritmos

 El campo `key_type` en el [método wallet_propose][] se refiere al algoritmo de firma criptográfica que se utilizará.

-
 ## Par de claves maestras

 El par de claves maestras consiste en una clave privada y una clave publica. La dirección de una cuenta es derivada del par de claves maestras, por lo que están intrinsecamente relacionadas. No puedes cambiar o eliminar el par de claves maestras, pero puedes desactivarlo.
@@ -92,8 +90,6 @@ Dado que cambiar el par de claves maestras es imposible, debes cuidarlo en propo

 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.)

-
-
 ### Permisos especiales

 **Solo** el par de claves maestras pueden autorizar transacciones para hacer ciertas cosas:
@@ -108,7 +104,6 @@ Mantener tu par de claves maestras offline significa no colocar tu información

 Una clave normal o [multi-firma](multi-signing.md) puede hacer cualquier otra cosa igual que el par de claves maestras. En particular, una vez has deshabilitado el par de claves maestras, puedes volver a habilitarlo utilizando un par de claves normales o multi firma. También puedes [eliminar una cuenta](deleting-accounts.md) si cumple con los requisitos para su eliminación.

-
 ## Par de claves normales

 Una cuenta XRP Ledger puede autorizar un par de claves secundario, conocido como _par de claves normales_. Tras hacerlo, puedes utilizar cualquiera, el [par de claves maestras](#par-de-claves-maestras) o el par de claves normales para autorizar transacciones. Puedes eliminar o reemplazar tu par de claves normales en cualquier momento sin cambiar el resto de la cuenta.
@@ -121,28 +116,25 @@ El par de claves normales tiene el mismo formato que el par de claves maestras.

 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).

-
 ## Algorítmos de firma

 Los pares de claves criptográficas están siempre atadas a un algorítmo de firma específico, el cual define la relación matemática entre la clave secreta y la clave pública. Los algorítmos de firma criptográficos tienen la propiedad de, dado el estado actual de las técnicas de criptografía, es "fácil" utilizar una clave secreta para clacular la clave pública coincidente, pero es imposible calcular la clave secreta vinculante partiendo de la clave pública. <!-- STYLE_OVERRIDE: easy -->

 El XRP Ledger soporta los siguientes algoritmos de firma criptográfica:

-| Tipo de clave  | Algoritmo | Descripción |
-|-------------|-----------|---|
-| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) usando la curva eliptica [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | Este es el mismo esquema que utiliza Bitcoin. El XRP Ledger utiliza este tipo de claves por defecto. |
-| `ed25519`   | [EdDSA](https://tools.ietf.org/html/rfc8032) usando la curva elíptica [Ed25519](https://ed25519.cr.yp.to/) | Este es un algoritmo más novedoso que tiene mejor rendimiento y otras propiedades convenientes. Como las claves públicas Ed25519 son un byte menos que las claves secp256k1, `rippled` prefija las claves públicas Ed25519 con el byte `0xED` así ambos tipos de claves públicas son de 33 bytes. |
+| Tipo de clave | Algoritmo                                                                                                                                                    | Descripción                                                                                                                                                                                                                                                                                       |
+| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `secp256k1`   | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) usando la curva eliptica [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | Este es el mismo esquema que utiliza Bitcoin. El XRP Ledger utiliza este tipo de claves por defecto.                                                                                                                                                                                              |
+| `ed25519`     | [EdDSA](https://tools.ietf.org/html/rfc8032) usando la curva elíptica [Ed25519](https://ed25519.cr.yp.to/)                                                   | Este es un algoritmo más novedoso que tiene mejor rendimiento y otras propiedades convenientes. Como las claves públicas Ed25519 son un byte menos que las claves secp256k1, `rippled` prefija las claves públicas Ed25519 con el byte `0xED` así ambos tipos de claves públicas son de 33 bytes. |

 Cuando generas un par de claves con el [método wallet_propose][], puedes especificar el `key_type` para elegir que tipo de algorítmo criptográfico se utiliza para derivar las claves. Si has generado un tipo de clave disitnto al de por defecto, debes especificar también el `key_type` cuando firmas transacciones.

-Los tipos de pares de claves admitidos pueden utilizarse indistintatemente en todo el XRP Ledger como pares de claves maestras, pares de claves normales, y miembros de listas de firmantes. El proceso de  [derivación de una dirección](addresses.md#address-encoding) es el mismo para pares de claves secp256k1 y Ed25519.
-
+Los tipos de pares de claves admitidos pueden utilizarse indistintatemente en todo el XRP Ledger como pares de claves maestras, pares de claves normales, y miembros de listas de firmantes. El proceso de [derivación de una dirección](addresses.md#address-encoding) es el mismo para pares de claves secp256k1 y Ed25519.

 ### Algoritmos futuros

 En el futuro, es posible que el XRP Ledger necesite nuevos algoritmos de firma criptográficos para mantenerse al día con el desarrollo en criptográfia. Por ejemplo, si los ordenadores cuánticos utilizasen el [algoritmo de Shor](https://en.wikipedia.org/wiki/Shor's_algorithm) (o algo similar) no tardarán en romper la curva elíptica criptográfica, los desarrolladores XRP Ledger pueden añadir un algoritmo criptográfico que no es facil de romper. A mediados de 2020, no existe un algoritmo de firma "resistente a la cuántica" y los ordenadores cuánticos no son lo suficientemente prácticos para ser una amenaza, por lo que no hay planes inmediatos para añadir algoritmos específicos. <!-- STYLE_OVERRIDE: will, easily -->

-
 ## Derivación de claves

 El proceso de derivar un par de claves depende del algoritmo de firma. En todos los casos, las claves son generadas desde un valor _seed_ (semilla) que es de 16 bytes (128 bits) de longitud. El valor semilla puede ser totalmente aleatorio (recomendado) o puede ser derivado de una passphrase específica tomando el [hash SHA-512][Hash] y manteniendo los primeros 16 bytes (como [SHA-512Half][], pero manteniendo solo 128 bits en vez de los 256 bits de la salida).
@@ -152,37 +144,39 @@ El proceso de derivar un par de claves depende del algoritmo de firma. En todos
 Los procesos de derivación de claves descritos aquí están implementados en múltiples lugares y lenguajes de programación:

 - En C++ en el código base de `rippled`:
-    - [Definición de semilla](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
-    - [Derivación de clave general & Ed25519](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
-    - [Derivación de clave secp256k1](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+  - [Definición de semilla](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
+  - [Derivación de clave general & Ed25519](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+  - [Derivación de clave secp256k1](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
 - En Python 3 en {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}esta sección de códigos de ejemplo del repositorio{% /repo-link %}.
 - En JavaScript en el paquete [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs).

 ### Derivación de clave Ed25519
+
 [[Fuente]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Fuente")

-[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg "Passphrase → Semilla → Clave secreta → Prefijo + Clave pública")
+[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg 'Passphrase → Semilla → Clave secreta → Prefijo + Clave pública')

 1. Calcular el [SHA-512Half][] del valor de la semilla. El resultado es la clave secreta de 32-byte.

-    **Consejo:** Todos los números 32-byte son válidos como claves secretas Ed25519. Sin embargo, Sin embargo, solo los números elegidos aleatoriamente son suficientemente seguros para ser usados como claves secretas.
+   **Consejo:** Todos los números 32-byte son válidos como claves secretas Ed25519. Sin embargo, Sin embargo, solo los números elegidos aleatoriamente son suficientemente seguros para ser usados como claves secretas.

 2. Para calcular una clave pública Ed25519, utiliza la derivación estandar de clave pública para [Ed25519](https://ed25519.cr.yp.to/software.html) para derivar una clave pública de 32-byte.

-    **Atención:** Como con cualquier algoritmo criptográfico, utiliza una implementación estandar, reconocida y públicamente auditada cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales para Ed25519 y secp256k1.
+   **Atención:** Como con cualquier algoritmo criptográfico, utiliza una implementación estandar, reconocida y públicamente auditada cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales para Ed25519 y secp256k1.

 3. Prefija el byte `0xED` en la clave pública 32-byte para indicar que es una clave pública Ed25519, resultando en 33 bytes.

-    Si estás impementando código para firmar transacciones, elimina el prefijo `0xED` y utiliza la clave 32-byte para el proceso de firma actual.
+   Si estás impementando código para firmar transacciones, elimina el prefijo `0xED` y utiliza la clave 32-byte para el proceso de firma actual.

 4. Cuando serializas una clave pública de cuenta a [base58][], utiliza el prefijo de la clave pública de cuenta `0x23`.

-    Las claves efímeras de validador no pueden ser Ed25519.
+   Las claves efímeras de validador no pueden ser Ed25519.

 ### Derivación de clave secp256k1
+
 [[Fuente]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Fuente")

-[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg "Passphrase → Semilla → Par de claves inicial (Root Key Pair) → Par de claves intermedias → Par de claves maestras")
+[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg 'Passphrase → Semilla → Par de claves inicial (Root Key Pair) → Par de claves intermedias → Par de claves maestras')

 La derivación de claves de cuentas XRP Ledger secp256k1 involucra más pasos que con la derivación de clave Ed25519 por el siguiente par de razones:

@@ -191,23 +185,22 @@ La derivación de claves de cuentas XRP Ledger secp256k1 involucra más pasos qu

 Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un valor semilla es como sigue:

-1. Calcular un par de claves iniciales (root key pair) a partir del valor semilla, como sigue:
-
+1.  Calcular un par de claves iniciales (root key pair) a partir del valor semilla, como sigue:
    1. Concatenar lo siguiente en orden, para un total de 20 bytes:
-        - El valor semilla  (16 bytes)
-        - El valor "sequencia root" (4 bytes), como un entero big-endian no asignado. Utiliza 0 como un valor inicial para la secuencia root.
+       - El valor semilla (16 bytes)
+       - El valor "sequencia root" (4 bytes), como un entero big-endian no asignado. Utiliza 0 como un valor inicial para la secuencia root.

    2. Calcular el [SHA-512Half][] del valor concatenado ( semilla+secuencia root).

    3. Si el resultado no es una clave secreta válida secp256k1, incrementa la secuencia root en 1 y vuelve a empezar. [[Fuente]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Fuente")

-        Una clave válida secp256k1 debe no ser cero, y debe ser numericamente menor que _secp256k1 group order_. El orden grupo secp256k1 es un valor constante `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.
+       Una clave válida secp256k1 debe no ser cero, y debe ser numericamente menor que _secp256k1 group order_. El orden grupo secp256k1 es un valor constante `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.

    4. Con una clave secreta secp256k1 válida, utiliza la derivación de clave pública ECDSA estandar con la curva secp256k1 para derivar la clave pública inicial (root). (Como siempre para algoritmos critográficos, utiliza una implementación auditada públicamente, conocida y estandar cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones para funciones principales de Ed25519 y secp256k1.)

    **Consejo:** Los validadores utilizan este par de claves iniciales (root). Si estás calculando un par de claves para un validador, puedes parar aquí. Para disntiguir entre estos dos tipos de claves públicas, la serialización para claves públicas de validador [base58][] usa el prefijo `0x1c`.

-2. Convierte la clave pública inicial (root) a su forma comprimida de 33-byte.
+2.  Convierte la clave pública inicial (root) a su forma comprimida de 33-byte.

    La forma no comprimida de cualquier clave pública ECDSA consiste en un par de enteros de 32-byte: una coordinada X, y una coordinada Y. La forma comprimida es la coordinada X y un prefijo de one-byte: `0x02` si la coordinada Y es par, o `0x03` si la coordinada Y es impar.

@@ -217,12 +210,11 @@ Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un val
        $ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
        ```

-3. Deriva un "par de claves intermedio" desde la clave pública ráiz comprimida, así:
-
+3.  Deriva un "par de claves intermedio" desde la clave pública ráiz comprimida, así:
    1. Concatena lo siguiente en orden, para un total de 41 bytes:
-        - La clave pública comprimida (33 bytes)
-        - `0x00000000000000000000000000000000` (4 bytes de ceros). (Este valor estaba pensado para derivar diferentes números de la misma familia, pero en la práctica solo el valor 0 es utilizado.)
-        - Una valor "secuencia clave" (4 bytes), como un entero no asignado big-endian. Utiliza 0 como valor inicial para la secuencia clave.
+       - La clave pública comprimida (33 bytes)
+       - `0x00000000000000000000000000000000` (4 bytes de ceros). (Este valor estaba pensado para derivar diferentes números de la misma familia, pero en la práctica solo el valor 0 es utilizado.)
+       - Una valor "secuencia clave" (4 bytes), como un entero no asignado big-endian. Utiliza 0 como valor inicial para la secuencia clave.

    2. Calcula el [SHA-512Half][] del valor concatenado.

@@ -230,30 +222,28 @@ Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un val

    4. Con una clave secreta secp256k1 válida, utiliza la derivación de clave pública ECDSA estandar con la curva secp256k1 para derivar la clave pública intermedia. (Como siempre con los algoritmos criptográficos, utiliza una implementación públicamente auditada, conocida y estandar cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales Ed25519 y secp256k1.)

-4. Deriva el par de claves públicas añadiendo la clave pública intermedia a la clave pública inicial (root). De manera similar, deriva la clave secreta añadiendo la clave secreta intermedia a la clave secreta inicial (root).
-
+4.  Deriva el par de claves públicas añadiendo la clave pública intermedia a la clave pública inicial (root). De manera similar, deriva la clave secreta añadiendo la clave secreta intermedia a la clave secreta inicial (root).
    - Una clave secreta ECDSA es un número entero muy largo, por lo que puedes calcular la suma de dos números secretos sumando el módulo el orden de grupo secp256k1.

    - Una clave pública ECDSA es un punto de la curva elíptica, por lo que necesitarás matemática de curva elíptica para sumar los puntos.

-5. Convierte la clave pública maestra asu forma comprimida de 33-byte, como antes.
+5.  Convierte la clave pública maestra asu forma comprimida de 33-byte, como antes.

-6. Cuando serialices la clave pública de la cuenta a su formato  [base58][], utiliza el prefijo de la clave pública de la cuenta, `0x23`.
+6.  Cuando serialices la clave pública de la cuenta a su formato [base58][], utiliza el prefijo de la clave pública de la cuenta, `0x23`.

    Ver [Codificación de dirección](addresses.md#address-encoding) para información y códigos de ejemplo para convertir de una clave pública de cuenta a su dirección.

-
 ## Ver también

 - **Conceptos:**
-    - [Direcciones de emisión y operacionales](account-types.md)
+  - [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](../../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)
 - **Referencias:**
-    - [Transacción SetRegularKey][]
-    - [Objeto de ledger AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
-    - [método wallet_propose][]
-    - [método account_info][]
+  - [Transacción SetRegularKey][]
+  - [Objeto de ledger AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+  - [método wallet_propose][]
+  - [método account_info][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md
+++ b/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md
@@ -2,10 +2,11 @@
 html: decentralized-identifiers.html
 parent: accounts.html
 seo:
-    description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
+  description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
 labels:
  - DID
 ---
+
 # Identificadores descentralizados

 _(REquiere de la [enmienda DID][] {% not-enabled /%})_
@@ -22,18 +23,16 @@ Los principios clave de un DID son:

 **Nota:** La implementación de DIDs en el XRP Ledger cumple con los requisitos de la [especificación DID v1.0](https://www.w3.org/TR/did-core/).

-
 ## Cómo funciona

 1. El dueño de una cuenta XRPL genera un DID que es controlado por la cuenta.
 2. El DID se asocia a un documento DID definido por la especificaciones W3C.
 3. El DID es usado para las siguientes tareas digitales como:
-    - Firmar documentos digitales.
-    - Realizar transacciones en linea seguras.
-    - Iniciar sesión en sitios web.
+   - Firmar documentos digitales.
+   - Realizar transacciones en linea seguras.
+   - Iniciar sesión en sitios web.
 4. El verificador resuelve el DID a su docuemnto para verificar la identidad del sujeto.

-
 ## Documentos DID

 Los documentos DID contienen la información necesaria para verificar criptográficamente la identidad del sujeto descrito por el documento DID. El sujeto puede ser una persona, organización, o cosa. Por ejemplo, un documento DID podría contener claves criptográficas públicas que el sujeto DID puede utilizar para autenticarse y demostrar su asociación con el DID.
@@ -44,31 +43,29 @@ En el XRP Ledger, hay numerosas formas de asociar un DID a un documento DID:

 1. Almacenar una referencia al documento en el campo `URI` del objeto `DID`, que apunta al documento almacenado en otra red de almacenamiento descentralizado, como es IPFS o STORJ.
 2. Almacenar un documento DID mínimo en el campo `DIDDocument` del objeto `DID`.
-3. Utilizar un documento DID _implicito_ generado  a partir del DID y otra información pública disponible.
-    **Nota:** Los casos de uso más simples pueden solo necesitar firmas y rokens de autorización simples. En casos donde no haya un documento DID explicitamente en el ledger, un documento implicito es utilizado en su lugar. Por ejemplo, el documento DID de `did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` habilita solo la clave única `0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` para autorizar cambios en el documento DID o firmar credenciales en nombre del DID.
-
+3. Utilizar un documento DID _implicito_ generado a partir del DID y otra información pública disponible.
+   **Nota:** Los casos de uso más simples pueden solo necesitar firmas y rokens de autorización simples. En casos donde no haya un documento DID explicitamente en el ledger, un documento implicito es utilizado en su lugar. Por ejemplo, el documento DID de `did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` habilita solo la clave única `0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` para autorizar cambios en el documento DID o firmar credenciales en nombre del DID.

 ### Ejemplo de documento DID XRPL

 ```json
 {
-    "@context": "https://w3id.org/did/v1",
-    "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-    "publicKey": [
-        {
-            "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
-            "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
-            "curve": "secp256k1",
-            "expires": 15674657,
-            "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
-        }
-    ]
+  "@context": "https://w3id.org/did/v1",
+  "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "publicKey": [
+    {
+      "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
+      "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
+      "curve": "secp256k1",
+      "expires": 15674657,
+      "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
+    }
+  ]
 }
 ```

 Para aprender más sobre las propiedades principales de un documento DID, ver: [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/#core-properties).

-
 ## Precauciones de privacidad y seguridad

 - Quien controla las claves privadas de la cuenta XRPL, controla el DID y las referencias al documento DID a la que resuelve. Asegúrate de que tus claves privadas no se comprometan.
--- a/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
+++ b/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
@@ -1,9 +1,10 @@
 ---
 seo:
-    description: Acerca de eliminar una cuenta XRP Ledger.
+  description: Acerca de eliminar una cuenta XRP Ledger.
 labels:
  - Cuentas
 ---
+
 # Eliminar Cuentas

 El dueño de una cuenta puede enviar una [transacción AccountDelete][] para eliminar la cuenta y las entradas relativas del ledger, enviando la mayoría del XRP en balance restante a otra cuenta. Para evitar la creación y eliminación de cuentas sin sentido, eliminar una cuenta requiere quemar una cantidad superior a la usual utilizada como [coste de transacción](../transactions/transaction-cost.md).
@@ -18,10 +19,10 @@ Para ser eliminada, una cuenta debe cumplir los siguientes requisitos:

 - El número de `Sequence` de la cuenta más 256 debe ser menor que el [Índice del ledger][] actual.
 - La cuenta no debe estar enlazada a de los siguientes tipos de [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md) (como remitente o destinatario):
-    - `Escrow`
-    - `PayChannel`
-    - `RippleState`
-    - `Check`
+  - `Escrow`
+  - `PayChannel`
+  - `RippleState`
+  - `Check`
 - La cuenta debe tener menos de 1000 objetos en el ledger.
 - La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente {% $env.PUBLIC_OWNER_RESERVE %}).

@@ -34,4 +35,5 @@ A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la
 Instituciones que reciben y envían valor en nombre de muchos usuarios pueden utilizar [**Source Tags** y **Destination Tags**](../transactions/source-and-destination-tags.md) para distinguir pagos desde y para sus clientes usando una (o un puñado) de cuentas en el XRP Ledger.

 <!--{# common link defs #}-->
+
 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/accounts/depositauth.md
+++ b/@l10n/es-ES/docs/concepts/accounts/depositauth.md
@@ -2,11 +2,12 @@
 html: depositauth.html
 parent: accounts.html
 seo:
-    description: La configuración DepositAuth le permite a una cuenta bloquear pagos entrantes por defecto.
+  description: La configuración DepositAuth le permite a una cuenta bloquear pagos entrantes por defecto.
 labels:
  - Pagos
  - Seguridad
 ---
+
 # Autorización para depositar

 _(Añadido por la [enmienda DepositAuth][].)_
@@ -41,29 +42,27 @@ Para conseguir un efecto total de Deposit Authorization, Ripple recomienda adem
 Una cuenta con Deposit Authorization activado:

 - **No puede** ser destinatario de [transacciones Payment][], con **las siguientes excepciones**:
-    - Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
-    - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
+  - Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
+  - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
 - Puede recibir XRP de [transacciones PaymentChannelClaim][] **únicamente en los siguientes casos**:
-    - El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
-    - El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
+  - El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
+  - El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
 - Puede recibir XRP de [transacciones EscrowFinish][] **únicamente en los siguientes casos**:
-    - El remitente de una transacción EscrowFinish es el destino de un escrow.
-    - El destino de una transacción EscrowFinish tiene [preautorizado](#preautorización) al remitente de un EscrowFinish. _(Añadido en la [enmienda DepositPreauth][])_
+  - El remitente de una transacción EscrowFinish es el destino de un escrow.
+  - El destino de una transacción EscrowFinish tiene [preautorizado](#preautorización) al remitente de un EscrowFinish. _(Añadido en la [enmienda DepositPreauth][])_
 - **Puede** recibir XRP o tokens enviando una transacción [CheckCash][]. _(Añadido por la [enmienda Checks][].)_
 - **Puede** recibir XRP o tokens enviando [transacciones OfferCreate][].
-    - Si la cuenta envía una transacción OfferCreate que no está completamente ejecutada in mediatamente, **puede** recibir el resto del XRP o token solicitado después cuando la oferta sea consumida por otras transacciones [Payment][] y [OfferCreate][] de la cuenta.
+  - Si la cuenta envía una transacción OfferCreate que no está completamente ejecutada in mediatamente, **puede** recibir el resto del XRP o token solicitado después cuando la oferta sea consumida por otras transacciones [Payment][] y [OfferCreate][] de la cuenta.
 - Si la cuenta ha creado cualquier línea de confianza (trust lines) sin la marca [No Ripple flag](../tokens/fungible-tokens/rippling.md) activada, o ha activado el flag Default Ripple y emitido una moneda, la cuenta **puede** recibir los tokens de esas trust lines en [transacciones Payment][] como resultado del rippling. No puede ser el destino de esas transacciones.
 - En general, una cuenta en el XRP Ledger **no puede** recibir divisas no-XRP en el XRP Ledger mientras que lo siguiente sea cierto. (Esta regla no es específica del flag DepositAuth.)
-    - La cuenta no ha creado trust lines con límites distintos a cero.
-    - La cuenta no ha emitido tokens en trust lines creadas por otros.
-    - La cuenta no ha generado ninguna oferta.
+  - La cuenta no ha creado trust lines con límites distintos a cero.
+  - La cuenta no ha emitido tokens en trust lines creadas por otros.
+  - La cuenta no ha generado ninguna oferta.

 La siguiente tabla resume cuando un tipo de transacción puede depositar dinero con DepositAuth activado o desactivado:

 {% partial file="/docs/_snippets/depositauth-semantics-table.md" /%}

-
-
 ## Activar o desactivar Deposit Authorization

 Una cuenta puede activar la autorización de depositar enviando una [transacción AccountSet][] con el campo `SetFlag` con el valor de `asfDepositAuth` (9). La cuenta puede desactivar la autorización de depositar enviando una [transacción AccountSet][] con el campo `ClearFlag` con el valor de `asfDepositAuth` (9). Para más información sobre flags en AccountSet, consultar [AccountSet flags](../../references/protocol/transactions/types/accountset.md).
@@ -72,7 +71,7 @@ Una cuenta puede activar la autorización de depositar enviando una [transacció

 Para ver cuando una cuenta tiene Deposit Authorization activado, utiliza el [método account_info][] para mirar en la cuenta. Compara el valor de los campos `Flags` (en el objeto `result.account_data`) con los [bitwise flags definidos para un objeto de ledger AccountRoot ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md).

-Si el resultado de los valores  bitwise `Flags` Y el valor del flag `lsfDepositAuth` (`0x01000000`) es distinto a cero, entonces la cuenta tiene el DepositAuth activado. Si el resultado es cero, entonces la cuenta tiene DepositAuth desactivado.
+Si el resultado de los valores bitwise `Flags` Y el valor del flag `lsfDepositAuth` (`0x01000000`) es distinto a cero, entonces la cuenta tiene el DepositAuth activado. Si el resultado es cero, entonces la cuenta tiene DepositAuth desactivado.

 ## Preautorización

@@ -101,7 +100,6 @@ Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta au
 - Si la cuenta de destino requiere de Deposit Authorization. (Si no requiere de autorización, todas las cuentas de origen son consideradas autorizadas.)
 - Si la cuenta de origen es preautorizada para enviar dinero al destino.

-
 ## Ver también

 - La referencia [transación DepositPreauth][].
@@ -113,7 +111,6 @@ Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta au
 - [Pagos parciales](../payment-types/partial-payments.md) provee una forma para que cuentas puedan devolver pagos no deseados restando los [costes de transferencia](../tokens/fungible-tokens/transfer-fees.md) y los ratios de exchanges de la cantidad enviada en lugar de sumarlos a la cantidad enviada.
 <!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->

-
 [enmienda DepositPreauth]: /resources/known-amendments.md#depositpreauth

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/accounts/index.md
+++ b/@l10n/es-ES/docs/concepts/accounts/index.md
@@ -2,68 +2,64 @@
 html: accounts.html
 parent: concepts.html
 seo:
-    description: Aprende sobre cuentas en el XRP Ledger. AccouLas cuentas pueden enviar transacciones y almacenar XRP.
+  description: Aprende sobre cuentas en el XRP Ledger. AccouLas cuentas pueden enviar transacciones y almacenar XRP.
 labels:
  - Cuentas
  - Pagos
 ---
+
 # Cuentas

 Una "Cuenta" en el XRP Ledger representa a un titular de XRP y a un emisor de [transacciones](../../references/protocol/transactions/index.md).

 Una cuenta consiste en una dirección, un balance en XRP, un número de secuencia y un historial de sus transacciones. Para poder enviar transacciones, el dueño también necesita uno o más pares de claves criptográficas asociadas con la cuenta.

-
 ## Estructura de la cuenta

- Los elementos principales de una cuenta son:
+Los elementos principales de una cuenta son:

 - Una **cuenta** identificable, como `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`.
 - Un **balance en XRP**. Parte de este XRP se aparte para la [Reserva](reserves.md).
 - Un **número de secuencia**, el cual ayuda a asegurar que cualquier transacción que esta cuenta envíe se aplique en el orden correcto y solo una vez. Para ejecutar una transacción, el número de secuencia de la transacción y el número de secuencia de su remitente deben coincidir. Después, como parte de la aplicación de la transacción, el número de secuencia de la cuenta incrementa en 1. (Ver también: [Tipos de datos básicos: Secuencia de cuenta](../../references/protocol/data-types/basic-data-types.md#account-sequence).)
 - Un **histórico de transacciones** que afectaron a la cuenta y sus balances.
 - Una o más maneras de [autorizar transacciones](../transactions/index.md#authorizing-transactions), posiblemente incluyendo:
-    - Un par de claves maestras intrínseco a la cuenta. (Esto puedes desactivarse pero no cambiarse.)
-    - Una par de claves "normales" ("regular" en inglés) que se pueden rotar.
-    - Una lista de firmantes para [multi-firma](multi-signing.md). (Almacenado por separado de los datos principales de la cuenta.)
+  - Un par de claves maestras intrínseco a la cuenta. (Esto puedes desactivarse pero no cambiarse.)
+  - Una par de claves "normales" ("regular" en inglés) que se pueden rotar.
+  - Una lista de firmantes para [multi-firma](multi-signing.md). (Almacenado por separado de los datos principales de la cuenta.)

 Los datos principales de una cuenta se guardan en una entrada del ledger [AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md). Una cuenta puede ser también el dueña (o parcialmente dueña) de varios otros tipos de entradas del ledger.

 **Consejo:** Una "Cuenta" en el XRP Ledger está en algún lugar entre el uso financiero (como una "cuenta bancaria") y el uso informático (como una "cuenta UNIX"). Las monedas y activos no XRP no se guardan en una cuenta del XRP Ledger en sí misma; cada uno de estos activos se almacena en una relación contable llamada "Línea de confianza" (trust line en inglés) que conecta a dos partes.

-
 ## Creación de cuentas

 No hay una transacción dedicada a "crear una cuenta". La [transacción Payment][] automáticamente crea una nueva cuenta si el pago envía suficiente XRP a una dirección matemáticamente válida que aún no tiene una cuenta. Esto se llama _finnaciar_ una cuenta, y crea una [entrada AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) en el ledger. No hay otra transacción que cree una cuenta.

-**Atención:** Financiar una cuenta **no te da** privilegios especiales sobre esa cuenta. Quien tenga la clave secreta correspondiente a la dirección de la cuenta tiene control total sobre la cuenta y todo el XRP que contiene.  Para algunas direcciones, es posible que nadie tenga la clave secreta, en este caso la cuenta es un agujero negro [black hole](addresses.md#special-addresses) y el XRP se pierde para siempre.
+**Atención:** Financiar una cuenta **no te da** privilegios especiales sobre esa cuenta. Quien tenga la clave secreta correspondiente a la dirección de la cuenta tiene control total sobre la cuenta y todo el XRP que contiene. Para algunas direcciones, es posible que nadie tenga la clave secreta, en este caso la cuenta es un agujero negro [black hole](addresses.md#special-addresses) y el XRP se pierde para siempre.

 La forma típica de obtener una cuenta en el XRP Ledger es la siguiente:

 1. Genera un par de claves desde una fuente de fuerte aleatoriedad y calcula la dirección de ese par de claves.

 2. Hacer que alguien que ya tenga una cuenta en el XRP Ledger envíe XRP a la dirección que generaste.
+   - Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.

-    - Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.
-
-        **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
-
-
+     **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.

 ## Ver también

 - **Conceptos:**
-    - [Reservas](reserves.md)
-    - [Claves criptográficas](cryptographic-keys.md)
-    - [Cuentas emisoras y operacionales](account-types.md)
+  - [Reservas](reserves.md)
+  - [Claves criptográficas](cryptographic-keys.md)
+  - [Cuentas emisoras y operacionales](account-types.md)
 - **Referencias:**
-    - [Método account_info][]
-    - [Método wallet_propose][]
-    - [Transacción AccountSet][]
-    - [Transacción Payment][]
-    - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+  - [Método account_info][]
+  - [Método wallet_propose][]
+  - [Transacción AccountSet][]
+  - [Transacción Payment][]
+  - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
 - **Tutoriales:**
-    - [Administrar configuración de la cuenta (Categoría)](../../tutorials/how-tos/manage-account-settings/index.md)
-    - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+  - [Administrar configuración de la cuenta (Categoría)](../../tutorials/how-tos/manage-account-settings/index.md)
+  - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/accounts/multi-signing.md
+++ b/@l10n/es-ES/docs/concepts/accounts/multi-signing.md
@@ -2,11 +2,12 @@
 html: multi-signing.html
 parent: accounts.html
 seo:
-    description: Utiliza la firma múltiple para mayor seguridad enviando transacciones.
+  description: Utiliza la firma múltiple para mayor seguridad enviando transacciones.
 labels:
  - Smart Contracts
  - Seguridad
 ---
+
 # Multi-Signing

 La firma múltiple o multi-signing en el XRP Ledger es un método para [autorizar transacciones](../transactions/index.md#authorizing-transactions) para el XRP Ledger usando una combinación de múltiples claves secretas. Puedes tener cualquier combinación de métodos de autorización activados para tu dirección, incluido el multi-signing, un [par de claves maestras](cryptographic-keys.md#par-de-claves-maestras), y un [par de claves normales](cryptographic-keys.md#par-de-claves-normales). (El único requisito es que _al menos un_ método debe estar activado.)
@@ -34,13 +35,13 @@ Asignas un peso a cada firmantes de la lista. El peso representa la autoridad de
 El valor cuórum de una lista es una peso mínimo total requerido para autorizar la transacción. El cuórum debe ser mayor a 0 pero menor o igual a la suma de los valores de los pesos en la lista de firmantes: lo que significa, que debe ser posible conseguir un cuórum con los pesos de firmante dados.

 ### Localizador de cartera
+
 <!-- STYLE_OVERRIDE: wallet -->

 También puedes añadir hasta 256 bits de datos arbitrarios para cada entrada por firmante de la lista. Estos datos no son necessarios o usados por la red, pero pueden ser utilizados por smart contracts u otras aplicaciones para identificar o confirmar otros datos sobre los firmantes.

 _(Añadido en la [enmienda ExpandedSignerList][].)_

-
 ### Ejemplos uitilzando Signer Weight y Quorum

 Los pesos y el cuórum te permiten establecer un nivel apropiado de supervisión para cada transacción, en función de la confianza relativa y la autoridad relegada a los responsables que administran la cuenta.
@@ -55,32 +56,31 @@ En cada uno de los tres ejemplos anteriores, deshabilitarías la clave maestra s

 Podría darse el caso donde crees una lista de multi firma como "plan de respaldo". El dueño de la cuenta normalmente usa la clave normal para sus transacciones (no una clave multi-signing). Por seguridad, el propietario añade una lista de firmantes que contiene a 3 amigos, los tres con un peso de 1, y un cuórum de 3. Si el propietario de la cuenta perdiese la clave privada, puede pedir a sus amigos que multi firmen una transacción para reemplazar la clave normal.

-
 ## Mandar transacciones Multi-Signed

 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 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`.
-* Para las firmas presentadas, el peso total asociado con esos firmantes debe ser igual o mayor al cuórum de la `SignerList`.
-* El [coste de transacción](../transactions/transaction-cost.md) (especificado en el campo `Fee`) debe ser al menos (N+1) veces el coste de una transacción normal, donde N es el número de firmas presentadas.
-* Todos los campos de la transacción deben ser definidos antes de recolectar las firmas. No puedes [auto-rellenar](../../references/protocol/transactions/common-fields.md#auto-fillable-fields) los campos.
-* Si se presenta en forma binaria, el array de `Signers` debe estar ordenado en base al valor números de las direcciones de los firmantes, con el valor menor, primero . (Si se envía como JSON, el [método submit_multisigned][] se ocupa de ello automáticamente.)
+- 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 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`.
+- Para las firmas presentadas, el peso total asociado con esos firmantes debe ser igual o mayor al cuórum de la `SignerList`.
+- El [coste de transacción](../transactions/transaction-cost.md) (especificado en el campo `Fee`) debe ser al menos (N+1) veces el coste de una transacción normal, donde N es el número de firmas presentadas.
+- Todos los campos de la transacción deben ser definidos antes de recolectar las firmas. No puedes [auto-rellenar](../../references/protocol/transactions/common-fields.md#auto-fillable-fields) los campos.
+- Si se presenta en forma binaria, el array de `Signers` debe estar ordenado en base al valor números de las direcciones de los firmantes, con el valor menor, primero . (Si se envía como JSON, el [método submit_multisigned][] se ocupa de ello automáticamente.)

 ## Ver también

 - **Tutoriales:**
-    - [Configurar Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
-    - [Envíar una transacción Multi-Signed](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
+  - [Configurar Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
+  - [Envíar una transacción Multi-Signed](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
 - **Conceptos:**
-    - [Claves criptográficas](cryptographic-keys.md)
-    - [Coste de transacción especial para transacciones Multi-signed](../transactions/transaction-cost.md#special-transaction-costs)
+  - [Claves criptográficas](cryptographic-keys.md)
+  - [Coste de transacción especial para transacciones Multi-signed](../transactions/transaction-cost.md#special-transaction-costs)
 - **Referencias:**
-    - [Transacción SignerListSet][]
-    - [Objeto SignerList](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
-    - [método sign_for][]
-    - [método submit_multisigned][]
+  - [Transacción SignerListSet][]
+  - [Objeto SignerList](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
+  - [método sign_for][]
+  - [método submit_multisigned][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/accounts/reserves.md
+++ b/@l10n/es-ES/docs/concepts/accounts/reserves.md
@@ -2,12 +2,13 @@
 html: reserves.html
 parent: accounts.html
 seo:
-    description: Las cuentas XRP Ledger exigen una reserva de XRP para reducir el spam en la información del ledger.
+  description: Las cuentas XRP Ledger exigen una reserva de XRP para reducir el spam en la información del ledger.
 labels:
  - Comisiones
  - Cuentas
 top_nav_grouping: Páginas populares
 ---
+
 # Reservas

 El XRP Ledger aplica un _requisito de reserva_, en XRP, para proteger el ledger global compartido de crecer excesivamente como resultado del spam o del uso malicioso. El objetivo es limitar el crecimiento del ledger para coincida con las mejoras tecnológicas de tal forma que un equipo basico actual pueda siempre tener el ledger actual en RAM.
@@ -20,8 +21,8 @@ El requisito de reserva cambia de tanto en tanto debido al proceso de [Votación

 Los requisito de reserva consta de dos partes:

-* La **reserva base** es la cantidad mínima de XRP que es necesaria para cada dirección en el ledger.
-* La **reserva de propietario** es un incremento del requisito de reserva por cada objeto que la dirección posee en el ledger. El coste por artículo se le conoce como _reserva incremental_.
+- La **reserva base** es la cantidad mínima de XRP que es necesaria para cada dirección en el ledger.
+- La **reserva de propietario** es un incremento del requisito de reserva por cada objeto que la dirección posee en el ledger. El coste por artículo se le conoce como _reserva incremental_.

 Los requerimientos de reserva actuales en Mainnet son:

@@ -48,7 +49,7 @@ Algunos casos especiales:
 Las aplicaciones pueden buscar los valores de las reservas base e incremental actuales utilizando el [método server_info][] o el [método server_state][]:

 | Método                  | Unidades             | Campo de reserva base               | Campo de reserva incremental       |
-|-------------------------|----------------------|-------------------------------------|------------------------------------|
+| ----------------------- | -------------------- | ----------------------------------- | ---------------------------------- |
 | [método server_info][]  | Decimal XRP          | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
 | [método server_state][] | Drops enteros de XRP | `validated_ledger.reserve_base`     | `validated_ledger.reserve_inc`     |

@@ -56,7 +57,6 @@ Para determinar las reservas de propietario de una cuenta, hay que multiplicar l

 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.

-
 ## Quedarse por debajo del requisito de reserva

 Durante el procesamiento de transacciones, el [coste de transacción](../transactions/transaction-cost.md) destruye parte del XRP del saldo de la dirección que envía la transacción. Esto puede causar que una dirección XRP se quede por debajo del requisito de reserva. Puedes incluso destruir _todo_ tu XRP de esta forma.
@@ -65,7 +65,6 @@ Cuando tu cuenta posee menos XRP XRP que el requisito actual de reserva, no pued

 **Consejo:** Si tu dirección está debajo del requisito de reserva, puedes enviar unas [transacciones OfferCreate][] para aadquirir más XRP y volver a superar el requisito de reeerva. Sin embargo, dado que no puedes crear una [entrada en el ledger Offer](../../references/protocol/ledger-data/ledger-entry-types/offer.md) cuando estás por debajo de la reserva, esta transacción puede consumir solo Offers que ya esté en el libro de ordenes.

-
 ## Cambiar los requisitos de reserva

 El XRP Ledger tiene un mecanismo para ajustar los requisitos de reserva. Estos ajustes pueden considerar, por ejemplo, cambios a largo plazo del valor de XRP, mejoras en la capacidad del hardware de los equipos convencionales, o una eficiencia incrementada en la implementación del software del servidor. Cualquier cambio tiene que ser aprobado por un proceso de consenso. Ver [Votación de fee](../consensus-protocol/fee-voting.md) para más información.
--- a/@l10n/es-ES/docs/concepts/accounts/tickets.md
+++ b/@l10n/es-ES/docs/concepts/accounts/tickets.md
@@ -2,11 +2,12 @@
 html: tickets.html
 parent: accounts.html
 seo:
-    description: Envía transacciones en un orden no secuencial.
+  description: Envía transacciones en un orden no secuencial.
 labels:
  - Cuentas
  - Enviar transacciones
 ---
+
 # Tickets

 _(Añadido por la [enmienda TicketBatch][].)_
@@ -25,18 +26,17 @@ Sin embargo, hay situaciones donde los números de secuencia son demasiado limit

 Los Tickets facilitan una solución para todos estos problemas apartando números de secuencia que se pueden uitlizar más adelante, fuera de su orden normal, pero aún así no más de una vez cada uno.

-
 ## Los tickets son números de secuencia reservados

 Un Ticket es un registro de que se ha apartado un número de secuencia para utilizar más adelante. Una cuenta envía primero una [transacción TicketCreate][] para apartar una o más números de secuencia como Tickets; esto deja un registro en los [datos de estado del ledger](../ledgers/index.md), en la forma de un [objeto Ticket][], para cada número de secuencia reservado.

 Los Tickets están numerados usando los números de secuencia que han sido apartado para crearlos. Por ejemplo, si un número de secuencia de cuenta actual es 101 y has creado 3 Tickets, esos Tickets tienen los números de secuencia de Ticket 102, 103, y 104. Haciendo esto se incrementa el número de secuencia de la cuenta a 105.

-[{% inline-svg file="/docs/img/ticket-creation.svg" /%}](/docs/img/ticket-creation.svg "Diagrama: Creación de tres tickets")
+[{% inline-svg file="/docs/img/ticket-creation.svg" /%}](/docs/img/ticket-creation.svg 'Diagrama: Creación de tres tickets')

 Más tarde, puedes enviar una transacción utilizando un Ticket específico en vez de un número de secuencia; haciendo eso eliminas el Ticket correspondiente de los datos de estado del ledger y no cambia el número de secuencia normal de tu cuenta. También puedes todavía enviar transacciones utilizando el números de secuencia normal sin utilizar Tickets. Puedes utilizar cualquiera de tus Tickets disponibles en cualquier orden en cualquier momento, pero cada Ticket puede utilizarse solo una vez.

-[{% inline-svg file="/docs/img/ticket-usage.svg" /%}](/docs/img/ticket-usage.svg "Diagrama: Usando el ticket 103.")
+[{% inline-svg file="/docs/img/ticket-usage.svg" /%}](/docs/img/ticket-usage.svg 'Diagrama: Usando el ticket 103.')

 Continuando con el ejemplo anterior, puedes enviar una transacción utilizando el número de secuencia 105 o cualquiera de los tres Tickets que has creado. Si envías una transacción utilizando el Ticket 103, esto eliminará el Ticket 103 del ledger. Tu próxima transacción despues de esa puede uitlizar el número de secuencia 105, el Ticket 102, o el Ticket 104.

@@ -59,15 +59,14 @@ Cualquier cuenta puede crear y utilizar Tickets en cualquier tipo de transaccion

 ## Ver también

-
 - **Conceptos:**
-    - [Multi-Signing](multi-signing.md)
+  - [Multi-Signing](multi-signing.md)
 - **Tutoriales:**
-    - [Usar Tickets](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
+  - [Usar Tickets](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
 - **Referencias:**
-    - [Transacción TicketCreate][]
-    - [Campos comunes de una transacción](../../references/protocol/transactions/common-fields.md)
-    - [Objeto Ticket](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
-    - [Método account_objects ][]
+  - [Transacción TicketCreate][]
+  - [Campos comunes de una transacción](../../references/protocol/transactions/common-fields.md)
+  - [Objeto Ticket](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
+  - [Método account_objects ][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
@@ -2,10 +2,11 @@
 html: consensus-principles-and-rules.html
 parent: consensus.html
 seo:
-    description: Las reglas y principios del algoritmo de consenso que permite a los usuarios para transferir fondos (incluidas divisas fiat, divisas digitales y cualquier otra forma de valor) a través de fronteras nacionales igual de facil que enviar un correo electrónico.
+  description: Las reglas y principios del algoritmo de consenso que permite a los usuarios para transferir fondos (incluidas divisas fiat, divisas digitales y cualquier otra forma de valor) a través de fronteras nacionales igual de facil que enviar un correo electrónico.
 labels:
  - Blockchain
 ---
+
 # Los principios y reglas del consenso

 El XRP Ledger es un sistema de pagos universal que permite a los usuarios transferir fondos a través de fronteras nacionales de la misma forma que se envía un correo electrónico. Como otras redes de pagos peer-to-peer como Bitcoin, el XRP Ledger permite transacciones de liquidación peer-to-peer a través de una red descentralizada de ordenadores. A diferencia de otros protocolos de divisas digitales, el XRP Ledger permite a los usuarios denominar sus transacciones con cualquier divisa que prefieran, incluyendo divisas fiat, divisas digitales y cualquier otra forma de valor, y XRP (el activo nativo del XRP Ledger).
@@ -20,7 +21,6 @@ Principalmente, el XRP Ledger es una base de datos compartida que registra infor

 Como sistema criptográfico, los dueños de cuentas del XRP Ledger son identificados como _identidades criptográficas_, las cuales corresponden a pares de claves públicas/privadas. Las transacciones son autorizadas por firmas criptográficas que coinciden con esas identidades. Cada servidor procesa cada transacción de acuerdo con las mismas reglas deterministas conocidas. Finalmente, el objetivo es para cada servidor en la red tener una copia completa de exactamente el estado del mismo ledger, sin necesidad de una única autoridad central que arbitre las transacciones.

-
 ### El problema del doble gasto

 El problema del "doble gasto" es un desafío fundamental para cualquier sistema de pagos digital. El problema viene del requisito de que cuando el dinero es gastado en un sitio, no puede ser gastado en otro lugar. Generalmente, el problema ocurre cuando tiene dos transacciones cualesquiera de las cuales una es válida pero no ambas juntas.
@@ -33,7 +33,6 @@ Convencionalmente, los sistemas de pagos resuelven el problema del doble gasto t

 Las tecnologías de contabilidad distribuida, como el XRP Ledger, no tiene una autoridad central. Estas tecnologías deben resolver el problema del doble gasto de alguna otra forma.

-
 ## Cómo funciona el consenso

 ### Simplificando el problema
@@ -56,14 +55,14 @@ La función principal del consenso es que los participantes en el proceso acuerd

 1. Si no hay ninguna razón por la que una transacción debería no estar incluida en dicho grupo de transacciones, todos los participantes honestos aceptan incluirla. Si todos los participantes ya están de acuerdo, el consenso no tiene trabajo que hacer.
 2. Si hay alguna razón por la que una transacción no debe incluirse en dicho grupo de transacciones, todos los participantes honestos estarán dispuestos a excluirla. Si la transacción todavía es válida, no hay razón para incluirla en la siguiente ronda, y todos deberían aceptar incluirla en ese momento.
-3. Es extremadamente raro para un participante que le importe cómo las transacciones fueron agrupadas. El acuerdo es más fácil cuando la prioridad de cualquiera es llegar a un acuerdo y  sólo desafiarlo cuando hay intereses divergentes.
+3. Es extremadamente raro para un participante que le importe cómo las transacciones fueron agrupadas. El acuerdo es más fácil cuando la prioridad de cualquiera es llegar a un acuerdo y sólo desafiarlo cuando hay intereses divergentes.
 4. Las reglas deterministas pueden ser usadas incluso para formar agrupaciones, llegando a desacuerdos solo en los casos extremos. Por ejemplo, si hay dos transacciones conflictivas en una ronda, las reglas deterministas pueden ser utilizadas para determinar cuál se incluye en la siguiente ronda.

 La principal prioridad de cada participante es la exactitud. Primero deben hacer cumplir las reglas para estar seguros de que nadie viola la integridad del ledger compartido. Por ejemplo, una transacción que no está correctamente firmada nunca debe ser procesada (incluso si otros participantes quieren que se procese). Sin embargo, la segunda prioridad de cada participante honesto es el llegar a un acuerdo. Una red con posibles gastos dobles no tiene ninguna utilidad, así que cada participante honesto valora el acuerdo por encima de la exactitud.

 ### Rondas de consenso

-Una ronda de consenso es una intento de ponerse de acuerdo en un grupo de transacciones para que puedan ser procesadas. Una ronda de consenso empieza con cada participante que lo desea  tomando una posición inicial. Este es el conjunto de transacciones válidas que han visto.
+Una ronda de consenso es una intento de ponerse de acuerdo en un grupo de transacciones para que puedan ser procesadas. Una ronda de consenso empieza con cada participante que lo desea tomando una posición inicial. Este es el conjunto de transacciones válidas que han visto.

 Después, los participantes se "avalanzan" al consenso: Si una transacción particular no tiene apoyo mayoritario, los participantes concuerdan apartar esa transacción. Si una transacción en concreto sí tiene el apoyo mayoritario, los participantes concuerdan incluir esa transacción. Así leves mayorías rápidamente consiguen apoyo completo y leves minorías rápidamente consiguen rechazo universal en la ronda actual.

@@ -73,7 +72,7 @@ Cuando un participante ve a una sobremayoría que está de acuerdo en el conjunt

 ### El consenso puede fallar

-No es práctico desarrollar un algoritmo de consenso que nunca falla para alcanzar un consenso perfecto. Para entender el por qué, considera cómo finaliza el proceso de consenso. En algún momento, cada participante debe declarar que ha alcanzado consenso y que un grupo de transacciones conocido ha sido el resultado de  ese proceso. Esta declaración compromete al participante de que un particular grupo de transacciones como resultado de ese proceso de consenso.
+No es práctico desarrollar un algoritmo de consenso que nunca falla para alcanzar un consenso perfecto. Para entender el por qué, considera cómo finaliza el proceso de consenso. En algún momento, cada participante debe declarar que ha alcanzado consenso y que un grupo de transacciones conocido ha sido el resultado de ese proceso. Esta declaración compromete al participante de que un particular grupo de transacciones como resultado de ese proceso de consenso.

 Algún participante debe hacer esto primero o ningún participante podrá hacerlo nunca, y nunca llegarán a alcanzar consenso. Ahora, considera al participante que hace esto primero. Cuando este participante decide que el consenso ha finalizado, otros participantes no han llegado todavía a tomar esa decisión. Si fuesen incapaces de cambiar el conjunto acordado desde su punto de vista, ellos habrían decidido que el consenso se había alacanzado ya. Por lo que deben todavía ser capaces de cambiar el conjunto agregado.. <!-- STYLE_OVERRIDE: will -->

@@ -114,18 +113,18 @@ El algoritmo de consenso del XRP Ledger provee una alternativa robusta a sistema
 ## Ver también

 - **Conceptos:**
-    - [Consenso](index.md)
-    - [Investigación del consenso](consensus-research.md)
-    - [Vídeo del mecanismo de consenso del XRPL](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
+  - [Consenso](index.md)
+  - [Investigación del consenso](consensus-research.md)
+  - [Vídeo del mecanismo de consenso del XRPL](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
 - **Tutoriales:**
-    - [Envío de transacciones confiable](../transactions/reliable-transaction-submission.md)
-    - [Ejecutar `rippled` como Validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+  - [Envío de transacciones confiable](../transactions/reliable-transaction-submission.md)
+  - [Ejecutar `rippled` como Validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
 - **Referencias:**
-    - [Referencia del formato ledger](../../references/protocol/ledger-data/index.md)
-    - [Referencia del formato de transacción](../../references/protocol/transactions/index.md)
-    - [método consensus_info][]
-    - [método validator_list_sites][]
-    - [método validators][]
-    - [método consensus_info][]
+  - [Referencia del formato ledger](../../references/protocol/ledger-data/index.md)
+  - [Referencia del formato de transacción](../../references/protocol/transactions/index.md)
+  - [método consensus_info][]
+  - [método validator_list_sites][]
+  - [método validators][]
+  - [método consensus_info][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md
@@ -1,14 +1,15 @@
 ---
 seo:
-    description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
+  description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
 labels:
  - Blockchain
 ---
+
 # Protecciones del consenso contra ataques y modos de fallo

 El Protocolo de Consenso del XRP Ledger es un mecanismo de consenso _tolerante a fallos bizantinos_, lo que quiere decir que está diseñado para trabajar incluso si todo tipo de cosas salen mal: los participantes dependen de una red abierta poco confiable, y actores maliciosos pueden estar intentando controlar o interrumpir el sistema en un momento dado. Encima de eso, el conjunto de participantes en el Protocolo de Consenso del XRP Ledger no se conoce de antemano y puede cambiar con el tiempo.

-Confirmar transacciones de una forma rápida mientras se mantiene las propiedades deseadas de la red es un desafío complejo, y  es imposible construir un sistema perfecto. El Protocolo de Conenso del XRP Ledger está diseñado para funcionar lo mejor posible en la mayoría de las situaciones, y para fallar elegántemente en aquellas que no es posible.
+Confirmar transacciones de una forma rápida mientras se mantiene las propiedades deseadas de la red es un desafío complejo, y es imposible construir un sistema perfecto. El Protocolo de Conenso del XRP Ledger está diseñado para funcionar lo mejor posible en la mayoría de las situaciones, y para fallar elegántemente en aquellas que no es posible.

 Esta página describe algunos de los desafíos que el Protocolo de Consenso del XRP LEdger se encuentra y cómo se enfrenta a ellos.

@@ -28,7 +29,6 @@ Si más del 20% de los validadores son inalcanzables o no se comportan adecuadam

 La única forma de confirmar una transacción inválida sería conseguir que el 80% de los validadores confiables aprueben la transacción y estén de acuerdo en el resultado exacto. (Las transacciones inválidas incluyen ese dinero gastado que ya ha sido gastado, o de otra forma estaría rompiendo las reglas de la red.) En otras palabras, una gran mayoría de los validadores confiables habrían _colisionado_. Con docenas de validadores confiables corriendo por diferentes personas y negocios en diferentes partes del mundo, esto es muy dificil de conseguir intencionadamente.

-
 ## Vulnerabilidades de software

 Como con cualquier sistema de software, los bugs (o código intencionalmente malicioso) en la implementación del Protocolo de Consenso del XRP Ledger, los paquetes de software comúnmente implementados, o sus dependencias, son un problema que hay que tomarse seriamente. Incluso los bugs que causan que un servidor falle cuando ve valores de entrada cocinados pueden abusasrse para interrumpir el proceso de la red. Los desarrolladores del XRP Ledger toman precauciones para abordar esta amenaza en la referencia de implementaciones de software de XRP Ledger, incluyen:
@@ -39,21 +39,18 @@ Como con cualquier sistema de software, los bugs (o código intencionalmente mal
 - Revisiones profesionales encargadas periodicamentes para detectar vulnerabilidades e inseguridades.
 - Un [programa de recompensas de bugs](https://ripple.com/bug-bounty/) que premia a investigadores de seguridad que revelan responsablemente las vulnerabilidades.

-
 ## Ataques Sybil

 Un _[ataque Sybil](https://en.wikipedia.org/wiki/Sybil_attack)_ es un intento de tomar el control de una red usando un gran número de identidades falsas. En el XRP Ledger, un ataque Sybil tomaría la forma de ejecutar un gran número de validadores, y luego convencer a otros de confiar en esos validadores. Este tipo de ataques son teóricamente posibles, pero sería muy dificil de hacer porque la intervención humana es necesaria para ser confiados por otros.

-No importa cuantos servidores un atacante ejecuta, esos servidores no tienen voz ni voto sobre lo que los participantes existentes consideran validados a no ser que esos participantes decidan confiar en los validadores del atacante. Otros servidores solo  escuchan lo que los validadores que tienen configurados para confiar, ya sea por una lista de validodres o una configuración explícita. (Ver [requisitos de superposición de validador](#requisitos-de-superposición-del-validador) para un sumario de cómo una lista de validadores funciona.)
+No importa cuantos servidores un atacante ejecuta, esos servidores no tienen voz ni voto sobre lo que los participantes existentes consideran validados a no ser que esos participantes decidan confiar en los validadores del atacante. Otros servidores solo escuchan lo que los validadores que tienen configurados para confiar, ya sea por una lista de validodres o una configuración explícita. (Ver [requisitos de superposición de validador](#requisitos-de-superposición-del-validador) para un sumario de cómo una lista de validadores funciona.)

 Esta confianza no ocurre automáticamente, para realizar un ataque Sybil exitosamente habría que añadirle el laborioso trabajo de convencer a personas y empresas de reconfigurar sus servidores XRP Ledger para confiar en los validadores del atacante. Incluso en el caso de que una entidad individual sea engañada haciendo eso, esto tendrá un impacto mínimo en otros que no han cambiado sus configuraciones.

-
 ## Ataque del 51%

 Un "ataque de 51%" es un ataque en un sistema blockchain donde un bando controla más del 50% de todo el poder de minado o votación. (Técnicamente, el ataque está incorrectamente llamado porque _cualquier_ valor superior al 50% es suficiente.) El XRP Ledger no es vulnerable a un ataque del 51% porque no utiliza minería en su mecanismo de consenso. La analogía más cercana para el XRP Ledger es un [ataque Sybil](#ataques-sybil), el cuál sería complicado de realizar.

-
 ## Requisitos de superposición del validador

 Para todos los participantes en el XRP Ledger se pongan de acuerdo en qué consideran como validado, deben empezar eligiendo un conjunto de validadores confiables que son muy parecidos a los conjuntos elegidos por los demás. En el peor escenario, menos del 90% de superposición podría causar que algunos participantes diverjan entre ellos. Por esa razón, existen listas firmadas de validadores recomendados, destinadas a incluir servidores bien mantenidos y confiables administrados por la industria y la comunidad.
@@ -64,7 +61,6 @@ Técnicamente, si ejecutas un servidor, puedes configurar tu propia lista o expl

 Se está investigando un nuevo diseño del protocolo de consenso mejorado que permita listas de validadores más hetereogeneas. Para más información, ver la [Investigación del consenso](consensus-research.md) page.

-
 ## Ver también

 - Para una descripción detallada del protocolo de consenso, ver [Consenso](index.md).
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md
@@ -2,18 +2,19 @@
 html: consensus-research.html
 parent: consensus.html
 seo:
-    description: Artículos académicos sobre algoritmos de consenso investigaciones relacionadas.
+  description: Artículos académicos sobre algoritmos de consenso investigaciones relacionadas.
 labels:
  - Blockchain
 ---
+
 # Investigación del consenso

 Ripple investiga los límites teóricos y prácticos de los protocolos de consenso del XRP Ledger. La siguiente tabla enumera los artículas académicos publicados por Ripple:

-| Fecha | Título | Autores | Resumen |
-|---|---|---|---|
-| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | Introduce un novedoso algoritmo de transmisión a nivel atómico llamado Cobalt que permite más flexibilida d de consenso en las UNL. |
-| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | Un análisis actualizado y detallado del algoritmo de consenso del XRP Ledger y sus propiedad de seguridad y actividad. |
-| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | Introduce el algoritmo de consenso detrás del XRP Ledger. |
+| Fecha      | Título                                                                                              | Autores                  | Resumen                                                                                                                             |
+| ---------- | --------------------------------------------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
+| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240)                         | MacBrough                | Introduce un novedoso algoritmo de transmisión a nivel atómico llamado Cobalt que permite más flexibilida d de consenso en las UNL. |
+| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242)                   | Chase, MacBrough         | Un análisis actualizado y detallado del algoritmo de consenso del XRP Ledger y sus propiedad de seguridad y actividad.              |
+| 2014       | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | Introduce el algoritmo de consenso detrás del XRP Ledger.                                                                           |

 <!-- SPELLING_IGNORE: bft, liveness -->
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md
@@ -2,19 +2,19 @@
 html: consensus-structure.html
 parent: consensus.html
 seo:
-    description: Entender el rol del consenso en el XRP Ledger.
+  description: Entender el rol del consenso en el XRP Ledger.
 labels:
  - Blockchain
 ---
+
 # Estructura de consenso

-Escrito por Dave Cohen, David Schwartz, y Arthur Britto._
+Escrito por Dave Cohen, David Schwartz, y Arthur Britto.\_

 Este artículo proporciona una visión a alto nivel del XRP Ledger, la información que almacena, y cómo las [transacciones](../../references/protocol/transactions/index.md) dan como resultado cambios en el ledger.

 Al crear aplicaciones en el XRP Ledger, es importante entender el proceso, para no sorprenderse por el comportamiento de las APIs de XRP Ledger y sus efectos.

-
 ## Introducción

 La red peer-to-peer XRP Ledger proporciona un libro de contabilidad (ledger) compartido a nivel mundial, que brinda información autorizada a aplicaciones sobre el estado de su contenido. Este estado de la información incluye:
@@ -27,13 +27,13 @@ La red peer-to-peer XRP Ledger proporciona un libro de contabilidad (ledger) com

 Para una descripción técnica completa de todos los datos que se incluyen en una versión de un ledger, ver la [Referencia de formato de ledger](../../references/protocol/ledger-data/index.md).

-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-complete.svg" /%}](/docs/img/anatomy-of-a-ledger-complete.svg "Figura 1: Elementos del XRP Ledger")
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-complete.svg" /%}](/docs/img/anatomy-of-a-ledger-complete.svg 'Figura 1: Elementos del XRP Ledger')

 _Figura 1: Elementos del XRP Ledger_

 El XRP Ledger tiene una nueva versión de un ledger cada ciertos segundos. Cuando la red acuerda el contenido de una nueva versión del ledger, la versión del ledger es _validado_, y sus contenidos no se pueden cambiar nunca. Las versiones validadadas de ledgers que precedieron forman el histórico del ledger. Incluso el ledger validado más reciente es parte del histórico, ya que representa el estado de la red hasta hace poco tiempo. En la actualidad, la red está evaluando transacciones que pueden aplicarse y finalizarse en la próxima versión del ledger. Mientras la evaluación está ocurriendo, la red tiene versiones de ledger que aun no están validadas.

-[{% inline-svg file="/docs/img/ledger-history.svg" /%}](/docs/img/ledger-history.svg "Figura 2: Histórico del XRP Ledger")
+[{% inline-svg file="/docs/img/ledger-history.svg" /%}](/docs/img/ledger-history.svg 'Figura 2: Histórico del XRP Ledger')

 _Figure 2: Histórico del XRP Ledger_

@@ -45,13 +45,13 @@ Los cambios a nivel de usuario son el resultado de transacciones. Ejemplos de [t

 Cada versión del ledger también contiene un conjunto de transacciones y metadata sobre esas transacciones. Las transacciones que incluye son solo aquellas que han sido aplicadas para la anterior versión del ledger para crear la nueva versión del ledger. Los metadatos o metadata se registran a los mismos efectos en el estado del dato del ledger.

-[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "Figura 3: Transacciones aplicadas a la versión del ledger")
+[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg 'Figura 3: Transacciones aplicadas a la versión del ledger')

 _Figure 3: Transacciones aplicadas a la versión del ledger_

 El conjunto de transacciones incluidas en una instancia ledger se guardan en ese ledger y permite auditorías de la historia del XRP Ledger. Si un balance de cuenta es diferente en un ledger N+1 respecto al ledger N, entonces el ledger N+1 contiene las transacciones responsables del cambio.

-Las transacciones que aparecen en un ledger validado pueden haber logrado cambiar el ledger, o pueden haberse procesado sin haber realizado la acción requerida. Las transacciones exitosas tienen el [código resultado](../../references/protocol/transactions/transaction-results/index.md) **`tesSUCCESS`**  el cual indica los cambios solicitados para aplicar en el ledger. Las transacciones fallidas en el ledger tienen el código de resultado de clase **`tec`**.<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
+Las transacciones que aparecen en un ledger validado pueden haber logrado cambiar el ledger, o pueden haberse procesado sin haber realizado la acción requerida. Las transacciones exitosas tienen el [código resultado](../../references/protocol/transactions/transaction-results/index.md) **`tesSUCCESS`** el cual indica los cambios solicitados para aplicar en el ledger. Las transacciones fallidas en el ledger tienen el código de resultado de clase **`tec`**.<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>

 Todas las transacciones incluidas en un ledger destruyen algo de XRP como un [coste de transacción](../transactions/transaction-cost.md), sin importar si tenían un código **`tes`** o **`tec`**. La cantidad exacta de XRP destruido es definido por las instrucciones de transacción firmadas.

@@ -59,13 +59,13 @@ Hay otras clases de códigos de resultado además de **`tes`** y **`tec`**. Cual

 Cuando se trabaja con [APIs del XRP Ledger](../../references/http-websocket-apis/index.md), las aplicaciones deben distinguir entre transacciones candidatas propuestas para la inclusión en un ledger y transacciones validadas que están incluidas en un ledger. Solo los resultados de transacciones encontrados en un ledger validado son inmutables. Una transacción candidata puede eventualmente estar incluida en un leger validado, o puede que no.

-Importante: Algunas [APIs `rippled`](../../references/http-websocket-apis/index.md) proporcionan resultados provisionales, basados en transacciones candidatas <a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>. Las aplicaciones nunca deben  basarse en resultados provisionales para determinar el resultado final de una transacción. La única forma de conocer si finalmente una transacción se ha realizado correctamente, es comprobar el estado de la transacción hasta que esté en un ledger validado y además tenga el código de resultado `tesSUCCESS`. Si la transacción está en un ledger validado con otro código de resultado, ha fallado. Si el ledger especificado en [`LastLedgerSequence`](../../references/protocol/transactions/common-fields.md) en una transacción ha sido validado, pero la transacción no aparece en ese ledger o en alguno anterior, entonces esa transacción ha fallado y nunca aparecerá en ningún ledger. Un resultado es definitivo solo para transacciones en un ledger validado o nunca podrán aparecer por las restricciones de `LastLedgerSequence` explicadas más adelante en este documento.
+Importante: Algunas [APIs `rippled`](../../references/http-websocket-apis/index.md) proporcionan resultados provisionales, basados en transacciones candidatas <a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>. Las aplicaciones nunca deben basarse en resultados provisionales para determinar el resultado final de una transacción. La única forma de conocer si finalmente una transacción se ha realizado correctamente, es comprobar el estado de la transacción hasta que esté en un ledger validado y además tenga el código de resultado `tesSUCCESS`. Si la transacción está en un ledger validado con otro código de resultado, ha fallado. Si el ledger especificado en [`LastLedgerSequence`](../../references/protocol/transactions/common-fields.md) en una transacción ha sido validado, pero la transacción no aparece en ese ledger o en alguno anterior, entonces esa transacción ha fallado y nunca aparecerá en ningún ledger. Un resultado es definitivo solo para transacciones en un ledger validado o nunca podrán aparecer por las restricciones de `LastLedgerSequence` explicadas más adelante en este documento.

 ## El protocolo XRP Ledger – Consenso y validación

 La red peer-to-peer XRP Ledger consiste en muchos servidores independientes XRP Ledger (normalmente ejecutando [`rippled`](../networks-and-servers/index.md)) que aceptan y procesan transacciones. Las aplicaciones cliente firman y envían transacciones a servidores XRP Ledger, que transmiten estas transacciones candidatas a través de la red de procesamiento. Ejemplos de aplicaciones cliente incluyen carteras web y móvil, conexiones con instituciones financieras, y plataformas de trading electrónicas.

-[{% inline-svg file="/docs/img/xrp-ledger-network.svg" /%}](/docs/img/xrp-ledger-network.svg "Figura 4: Participantes en el Protocolo XRP Ledger")
+[{% inline-svg file="/docs/img/xrp-ledger-network.svg" /%}](/docs/img/xrp-ledger-network.svg 'Figura 4: Participantes en el Protocolo XRP Ledger')

 _Figura 4: Participantes en el Protocolo XRP Ledger_

@@ -79,7 +79,7 @@ Los servidores de la red comparten información sobre transacciones candidatas.

 Durante el consenso, cada servidor evalúa propuestas de un específico grupo de servidores, conocidos como validadores confiables por ese servidor, o _Unique Node List (UNL)_.<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a> Los validadores confiables representan un subconjunto de la red la cual, en conjunto, es "confiable" para no confabular en un intento de defraudar al servidor que evalúa las propuestas. Esta definición de "confianza" no requiere que se confie en cada validador individual elegido. Más bien, los validadores son elegidos en base a la expectativa de que no confabularán en un esfuerzo coordinado para falsificar los datos transmitidos en la red <a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>. <!-- STYLE_OVERRIDE: will -->

-[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg "Figura 5: Los validadores proponen y revisar conjuntos de transacciones")
+[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg 'Figura 5: Los validadores proponen y revisar conjuntos de transacciones')

 _Figura 5: Validadores proponen y revisan conjuntos de transacciones — Al comienzo del consenso, los validadores pueden tener un conjunto distinto de transacciones. En siguientes rondas, los servidores modificarán sus propuestas para coincidir con las propuestas de sus validadores confiables. Este proceso determina qué transacciones deberían aplicar a la versión del ledger que se está actualmente debatiendo, y cuales deberían posponerse para próximas versiones del ledger._

@@ -98,7 +98,6 @@ La validación puede dividirse en aproximadamente dos partes:

 Cada servidor en la red realiza una validación separada y local.

-
 #### Calcular y compartir validaciones

 Cuando el proceso de consenso se completa, cada servidor independientemente computa un nuevo ledger a partir del conjunto de transacciones acordado. Cada servidor calcula los resultados siguiendo las mismas reglas, las cuales pueden ser resumidas de la siguiente manera:
@@ -107,21 +106,21 @@ Cuando el proceso de consenso se completa, cada servidor independientemente comp

 2. Colocar el conjunto de transacciones acordado en _orden canónico_ para que cada servidor la procese de la misma forma.

-    [Orden canónico](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36) no es el orden de cómo las transacciones fueron recibidas, porque los servidores pueden recibir las mismas transacciones en diferente orden. Para prevenir a los participantes de competir sobre el orden de las trnasacciones, el orden canónico es difícil de manipular.
+   [Orden canónico](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36) no es el orden de cómo las transacciones fueron recibidas, porque los servidores pueden recibir las mismas transacciones en diferente orden. Para prevenir a los participantes de competir sobre el orden de las trnasacciones, el orden canónico es difícil de manipular.

 3. Procesar cada transacción según sus instrucciones, en orden. Actualizar el estado del dato del ledger en consecuencia.

-    Si la transacción no puede ser ejecutada exitósamente, incluye la transacción con un [código de resultado de clase `tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
+   Si la transacción no puede ser ejecutada exitósamente, incluye la transacción con un [código de resultado de clase `tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>

-    Para ciertos fallos de transacciones "recuperables", se mueve la transacción al final del orden canónico para volver a intentarla después de que se hayan ejecutado otras transacciones del mismo ledger.
+   Para ciertos fallos de transacciones "recuperables", se mueve la transacción al final del orden canónico para volver a intentarla después de que se hayan ejecutado otras transacciones del mismo ledger.

 4. Actualizar la cabecera del ledger con el apropiado metadata.

-    Esto incluye datos tales como el ledger index o índice del ledger, el hash identificativo del ledger previo validado (el "padre" de este), la hora de cierre aproximada de esta versión del ledger, y los hashes criptográficos de los contenidos de este ledger.
+   Esto incluye datos tales como el ledger index o índice del ledger, el hash identificativo del ledger previo validado (el "padre" de este), la hora de cierre aproximada de esta versión del ledger, y los hashes criptográficos de los contenidos de este ledger.

 5. Calcular el hash identificativo de la nueva versión del ledger.

-[{% inline-svg file="/docs/img/consensus-calculate-validation.svg" /%}](/docs/img/consensus-calculate-validation.svg "Figura 7: Un servidor XRP Ledger calcula la validación de un ledger")
+[{% inline-svg file="/docs/img/consensus-calculate-validation.svg" /%}](/docs/img/consensus-calculate-validation.svg 'Figura 7: Un servidor XRP Ledger calcula la validación de un ledger')

 _Figura 7: Un servidor XRP Ledger calcula la validación de un ledger — Cada servidor aplica transacciones acordadas por el anterior ledger validado. Los validadores envían sus resultados a toda la red._

@@ -129,7 +128,7 @@ _Figura 7: Un servidor XRP Ledger calcula la validación de un ledger — Cada s

 Cada validador transmite sus resultados en forma de un mensaje firmado que contiene el hash de la versión de ledger calculada. Estos mensajes, llamados _validaciones_, permiten a cada servidor comparar el ledger que calculó con el de sus pares.

-[{% inline-svg file="/docs/img/consensus-declare-validation.svg" /%}](/docs/img/consensus-declare-validation.svg "Figura 8: El ledger es validado cuando la supermayoría de pares calcula el mismo resultado")
+[{% inline-svg file="/docs/img/consensus-declare-validation.svg" /%}](/docs/img/consensus-declare-validation.svg 'Figura 8: El ledger es validado cuando la supermayoría de pares calcula el mismo resultado')

 _Figura 8: El ledger es validado cuando la supermayoría de pares calcula el mismo resultado - Cada servidor compara su su ledger calculado con los hashes recibidos de sus validadores elegidos. Si no hay acuerdo, el servidor debe recaluclar o recuperar el ledger correcto._

@@ -141,7 +140,6 @@ Si la red no logra un acuerdo de supermayoría sobre las validaciones, esto impl

 Una vez que alcanzan supermayoría en el acuerdo de las validaciones, los servidores trabajan con el nuevo ledger validado, ledger index N+1. El consenso y el proceso de validación se repite <a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>, considerando transacciones candidatas que no fueron incluidas en la última ronda junto con nuevas transacciones presentadas mientras tanto.

-
 ## Conclusiones claves

 Las transacciones enviadas al XRP Ledger no son procesadas inmediatamente. Durante un periodo de tiempo, cada transacciones permanece como candidata.
@@ -150,12 +148,12 @@ El ciclo de vida de una sola transacción es el siguiente:

 - Una transacción es creada y firmada por un dueño de una cuenta.
 - La transacción es enviada a la red.
-    - Transacciones mal formadas podrán ser rechazadas inmediatamente.
-    - Transacciones bien formadas pueden ser provisionalmente exitosas, y luego fallar.
-    - Transacciones bien formadas pueden provisionalmente fallar, y luego fallar.
+  - Transacciones mal formadas podrán ser rechazadas inmediatamente.
+  - Transacciones bien formadas pueden ser provisionalmente exitosas, y luego fallar.
+  - Transacciones bien formadas pueden provisionalmente fallar, y luego fallar.
 - Durante el consenso, la transacción es incluida en el ledger.
-    - El resultado de un consenso exitoso es un ledger validado.
-    - Si una ronda de consenso falla, el proceso de consenso se repita hasta que es exitoso.
+  - El resultado de un consenso exitoso es un ledger validado.
+  - Si una ronda de consenso falla, el proceso de consenso se repita hasta que es exitoso.
 - El ledger validado incluye la transacción y esta afecta al estado del ledger.

 Las aplicaciones deben solo confiar en información de ledgers validados, no en resultados provisionales de transacciones candidatas. Algunas [APIs de `rippled`](../../references/http-websocket-apis/index.md) devuelven inicialmente unos resultados provisionales para las transacciones. Los resultados de una transacción se convierten en inmutables solo si la transacción es incluida en un ledger validado, o la transacción incluye `LastLedgerSequence` y no aparece en ningún ledger validado con ese ledger index o menor.
@@ -164,31 +162,27 @@ Buenas prácticas para aplicaciones enviando transsacciones incluyen:

 - Utilizar el parámetro `LastLedgerSequence` para asegurar que las transacciones se validen o fallen de forma determinista y rápida.
 - Comprobar los resultados de transacciones en ledgers validados.
-    - Hasta que el ledger que contiene la transacción es validado, o haya pasado `LastLedgerSequence`, los resultados son provisionales.
-    - Transacciones con el código resultado **`tesSUCCESS`** y `"validated": true` se han realizado correctamente de forma inmutable.
-    - Transacciones con otro código resultado y `"validated": true` han fallado de forma inmutable.
-    - Transacciones que no aparecen en ningún ledger validado, incluido el ledger validado identificado por el `LastLedgerSequence` de la transacción ha fallado de forma inmutable.
-        - Tener cuidado de usar un servidor con un histórico de ledger continuo para detectar este caso <a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>.
-    - Puede ser necesario comprobar el estado de una transacción repetidamente hasta que el identificado por `LastLedgerSequence` es validado.
+  - Hasta que el ledger que contiene la transacción es validado, o haya pasado `LastLedgerSequence`, los resultados son provisionales.
+  - Transacciones con el código resultado **`tesSUCCESS`** y `"validated": true` se han realizado correctamente de forma inmutable.
+  - Transacciones con otro código resultado y `"validated": true` han fallado de forma inmutable.
+  - Transacciones que no aparecen en ningún ledger validado, incluido el ledger validado identificado por el `LastLedgerSequence` de la transacción ha fallado de forma inmutable.
+    - Tener cuidado de usar un servidor con un histórico de ledger continuo para detectar este caso <a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>.
+  - Puede ser necesario comprobar el estado de una transacción repetidamente hasta que el identificado por `LastLedgerSequence` es validado.

 ## Ver también

 - **Conceptos:**
-    - [Investigación del consenso](consensus-research.md)
-    - [El mecanismo del consenso (YouTube)](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
+  - [Investigación del consenso](consensus-research.md)
+  - [El mecanismo del consenso (YouTube)](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
 - **Tutoriales:**
-    - [Envío de transacciones de forma correcta](../transactions/reliable-transaction-submission.md)
-    - [Ejecutar `rippled` como un validator](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+  - [Envío de transacciones de forma correcta](../transactions/reliable-transaction-submission.md)
+  - [Ejecutar `rippled` como un validator](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
 - **Referencias:**
-    - [Referencia del fromato del ledger](../../references/protocol/ledger-data/index.md)
-    - [Referencia del formato de la transacción](../../references/protocol/transactions/index.md)
-    - [método consensus_info][]
-    - [método validator_list_sites][]
-    - [método validators][]
-
-
-
-
+  - [Referencia del fromato del ledger](../../references/protocol/ledger-data/index.md)
+  - [Referencia del formato de la transacción](../../references/protocol/transactions/index.md)
+  - [método consensus_info][]
+  - [método validator_list_sites][]
+  - [método validators][]

 ## Pies de notas

@@ -202,7 +196,7 @@ Buenas prácticas para aplicaciones enviando transsacciones incluyen:

 <a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> – Cada servidor define su propios validadores confiables, pero la consistencia de la red depende en diferentes servidores eligiendo listas que tienen un mayor grado de superposición. Por esta razón, Ripple publica una lista de validadores recomendados.

-<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – Si las propuestas de  todos los validadores fueron evaluadas, en lugar de exclusivamente por los validadores elegidos para no confabular, un atacante malicioso podría ejecutar más validadores para ganar poder desproporcionado sobre el proceso de validación, así podrían introducir transacciones inválidas u omitir transacciones válidas de las propuestas. La lista de validadores elegida [defiende de ataques Sybil](consensus-protections.md#ataques-sybil).
+<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – Si las propuestas de todos los validadores fueron evaluadas, en lugar de exclusivamente por los validadores elegidos para no confabular, un atacante malicioso podría ejecutar más validadores para ganar poder desproporcionado sobre el proceso de validación, así podrían introducir transacciones inválidas u omitir transacciones válidas de las propuestas. La lista de validadores elegida [defiende de ataques Sybil](consensus-protections.md#ataques-sybil).

 <a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – El umbral de supermayoría, a partir de noviembre del 2014, requiere que al menos el 80% de pares deben estar de acuerdo en un ledger para ser validado. Est el mismo porcentaje necesario para una ronda de consenso. Ambos umbrales están sujetos a cambio y no necesitan ser iguales.

--- a/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
@@ -2,11 +2,12 @@
 html: fee-voting.html
 parent: consensus.html
 seo:
-    description: Cómo los validadores votan las comisiones o fees (coste de transacción y requisitos de reserva).
+  description: Cómo los validadores votan las comisiones o fees (coste de transacción y requisitos de reserva).
 labels:
  - Fees
  - XRP
 ---
+
 # Votación de comisiones o fees

 Los validadores pueden votar por cambiar los [costes de transacción](../transactions/transaction-cost.md) básicos como los [requisitos de reserva](../accounts/reserves.md). Si las preferencias en la configuración de un validador son diferentes a los ajustes actuales de la red, el validador expresa sus preferencias a la red periódicamente. Si un cuórum de validadores está de acuerdo en un cambio, pueden aplicar un cambio que se haga efectivo a partir de entonces. Los validadores pueden hacer esto por varias razones, especialmente para adaptarse a cambios en el valor de XRP a largo plazo.
@@ -17,53 +18,52 @@ Los operadores de [validadores `rippled`](../../infrastructure/configuration/ser

 Los parámetros que puedes configurar son los siguientes:

-| Parámetro | Descripción | Valor recomendado |
-|-----------|-------------|-------------------|
-| `reference_fee` | Cantidad de XRP, en _drops_ (1 XRP = 1 millón de drops.), que debe ser destruido para enviar la transacción de referencia, la transacción más barata posible. El coste de una transacción real es un múltiplo de ese valor, escalado dinámicamente basado en la carga de de los servidores individuales. | `10` (0.00001 XRP) |
-| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
-| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
+| Parámetro         | Descripción                                                                                                                                                                                                                                                                                              | Valor recomendado                          |
+| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
+| `reference_fee`   | Cantidad de XRP, en _drops_ (1 XRP = 1 millón de drops.), que debe ser destruido para enviar la transacción de referencia, la transacción más barata posible. El coste de una transacción real es un múltiplo de ese valor, escalado dinámicamente basado en la carga de de los servidores individuales. | `10` (0.00001 XRP)                         |
+| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger.                                                                                                                              | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
+| `owner_reserve`   | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger.                                                                                                                                                                                                   | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |

 <!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->

 ## Proceso de votación

-Cada 256º ledger  se denomina un "flag" ledger. (Un flag ledger se define de manera que el `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` es igual a `0`.) En el ledger inmediatamente antes del flag ledger, cada validador cuyas preferencias de reserva de cuenta o coste de transacción son diferentes a la configuración actual de la red distribuye un mensaje de "voto" junto con su validación del ledger, indicando los valores que prefiere ese validador.
+Cada 256º ledger se denomina un "flag" ledger. (Un flag ledger se define de manera que el `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` es igual a `0`.) En el ledger inmediatamente antes del flag ledger, cada validador cuyas preferencias de reserva de cuenta o coste de transacción son diferentes a la configuración actual de la red distribuye un mensaje de "voto" junto con su validación del ledger, indicando los valores que prefiere ese validador.

 En el propio flag ledger en sí, no ocurre nada, pero los validadores reciben y toman nota de los votos de los otros validadores en los que confían.

-Después de contar los votos de otros validadores, cada validador intenta llegar a un acuerdo entre sus propias preferencias y las preferencias de la mayoría de validadores en los que confía. (Por ejemplo, si un validador quiere aumentar el coste de transacción mínima de 10 a 100, pero la mayoría de los validadores solo quiere aumentarla de 10 a 20, el validador decide aumentar el coste de transacción a 20. Sin embargo, el validador nunca estará de acuerdo en un valor menor a 10 o superior a 100.) Si es posible llegar a un compromiso, el validador inserta una [pseudo  transacción SetFee](../../references/protocol/transactions/pseudo-transaction-types/setfee.md) en su propuesta para el ledger siguiente al flag ledger. Otros validaodres que quieran el mismo cambio, insertan la misma pseudo-transacción SetFee en sus propuestas para el mismo ledger. (Los validadores cuyas preferencias coincidan con las existentes en la red no hacen nada.) Si una pseudo-transacción SetFee sobrevive al proceso de consenso para ser incluida en un ledger validado, entonces el nuevo coste de transacción y configuración de reservas indicados por la pseudo transacción SetFee toman efecto empezando por el siguiente ledger.
+Después de contar los votos de otros validadores, cada validador intenta llegar a un acuerdo entre sus propias preferencias y las preferencias de la mayoría de validadores en los que confía. (Por ejemplo, si un validador quiere aumentar el coste de transacción mínima de 10 a 100, pero la mayoría de los validadores solo quiere aumentarla de 10 a 20, el validador decide aumentar el coste de transacción a 20. Sin embargo, el validador nunca estará de acuerdo en un valor menor a 10 o superior a 100.) Si es posible llegar a un compromiso, el validador inserta una [pseudo transacción SetFee](../../references/protocol/transactions/pseudo-transaction-types/setfee.md) en su propuesta para el ledger siguiente al flag ledger. Otros validaodres que quieran el mismo cambio, insertan la misma pseudo-transacción SetFee en sus propuestas para el mismo ledger. (Los validadores cuyas preferencias coincidan con las existentes en la red no hacen nada.) Si una pseudo-transacción SetFee sobrevive al proceso de consenso para ser incluida en un ledger validado, entonces el nuevo coste de transacción y configuración de reservas indicados por la pseudo transacción SetFee toman efecto empezando por el siguiente ledger.

 En resumen:

-* **Flag ledger -1**: Los validadores emiten sus votos.
-* **Flag ledger**: Los validadores cuentan sus votos y deciden qué SetFee incluir, si hay alguna.
-* **Flag ledger +1**: Los validadores incluyen una pseudo-transacción SetFee pseudo-transaction en sus ledgers propuestos.
-* **Flag ledger +2**: La nueva configuración toma efecto, si la pseudo-transacción alcanza consenso.
+- **Flag ledger -1**: Los validadores emiten sus votos.
+- **Flag ledger**: Los validadores cuentan sus votos y deciden qué SetFee incluir, si hay alguna.
+- **Flag ledger +1**: Los validadores incluyen una pseudo-transacción SetFee pseudo-transaction en sus ledgers propuestos.
+- **Flag ledger +2**: La nueva configuración toma efecto, si la pseudo-transacción alcanza consenso.

 ## Valores máximos de comisiones o fees

 Los valores máximos posibles para las comisiones están limitadas por los tipos de datos internos almacenados en el [objeto de ledger FeeSettings](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md). Los valores son los siguientes:

-| Parámetro | Valor máximo (drops) | Valor máximo (XRP)
-|-----------|-----------------------|----|
-| `reference_fee` | 2<sup>64</sup> | (Más XRP del que nunca ha existido.) |
-| `account_reserve` | 2<sup>32</sup> drops | Aproximadamente 4294 XRP |
-| `owner_reserve` | 2<sup>32</sup> drops | Aproximadamente 4294 XRP |
-
+| Parámetro         | Valor máximo (drops) | Valor máximo (XRP)                   |
+| ----------------- | -------------------- | ------------------------------------ |
+| `reference_fee`   | 2<sup>64</sup>       | (Más XRP del que nunca ha existido.) |
+| `account_reserve` | 2<sup>32</sup> drops | Aproximadamente 4294 XRP             |
+| `owner_reserve`   | 2<sup>32</sup> drops | Aproximadamente 4294 XRP             |

 ## Ver también

 - **Conceptos:**
-    - [Enmiendas](../networks-and-servers/amendments.md)
-    - [Coste de transacción](../transactions/transaction-cost.md)
-    - [Reservas](../accounts/reserves.md)
-    - [Cola de transacción](../transactions/transaction-queue.md)
+  - [Enmiendas](../networks-and-servers/amendments.md)
+  - [Coste de transacción](../transactions/transaction-cost.md)
+  - [Reservas](../accounts/reserves.md)
+  - [Cola de transacción](../transactions/transaction-queue.md)
 - **Tutoriales:**
-    - [Configurar `rippled`](../../infrastructure/configuration/index.md)
+  - [Configurar `rippled`](../../infrastructure/configuration/index.md)
 - **Referencias:**
-    - [Método fee][]
-    - [Método server_info][]
-    - [Objeto FeeSettings](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
-    - [Pseudo-transacción SetFee][]
+  - [Método fee][]
+  - [Método server_info][]
+  - [Objeto FeeSettings](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
+  - [Pseudo-transacción SetFee][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/index.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/index.md
@@ -2,18 +2,18 @@
 html: consensus.html
 parent: concepts.html
 seo:
-    description: El consenso es cómo los nuevos bloques de transacciones son confirmados por la blockchain XRP Ledger.
+  description: El consenso es cómo los nuevos bloques de transacciones son confirmados por la blockchain XRP Ledger.
 labels:
  - Blockchain
 top_nav_grouping: Popular Pages
 ---
+
 # El protocolo de consenso

 Este tema explica cómo el XRP Ledger descentralizado confirma nuevas transacciones y nuevas versiones de ledgers, creando una blockchain.

 El consenso es la propiedad más importante de cualquier sistema de pagos descentralizado. En sistemas de pagos centralizados tradicionales, un administrador autorizado tiene la última palabra en cómo los pagos deben ocurrir. En sistemas descentralizados, por definición, no hay un administrador para hacerlo. En cambio, los sistemas descentralizados como el XRP Ledger definen un conjunto de reglas que todos los participantes siguen, así cada participante puede estar de acuerdo en la misma exacta serie de eventos y sus resultados en cualquier momento. A este conjunto de reglas les llamamos un _protocolo de consenso_.

-
 ## Propiedades del protocolo de consenso

 El XRP Ledger utiliza el protocolo de consenso de una forma diferente a todos los activos digitales anteriores. Este protocolo, conocido como el Protocolo de Consenso de XRP Ledger, está diseñado para tener las siguientes propiedades importantes:
@@ -32,7 +32,6 @@ Este protocolo sigue evolucionando, al igual que nuestro conocimiento de sus lí

 Los protocolos de consenso son una solución al _problema del doble gasto_: el desafío de prevenir a alguien de gastar con éxito dos veces el mismo dinero digital. La parte más dificil de este problema es poner las transacciones en orden: sin una autoridad central, puede ser dificil resolver disputas sobre qué transacciones van primero cuando dos o más transacciones mutuamente excluyentes se envían al mismo tiempo. Para un análisis del problema del doble gasto, cómo el Protocolo de Consenso XRP Ledger resuelve este problema, las concesiones y limitaciones involucradas, ver [Principios y reglas del consenso](consensus-principles-and-rules.md).

-
 ## Histórico del ledger

 El XRP Ledger procesa transacciones en bloques llamadados "versiones del ledger", o "ledgers" abreviado. Cada versión del ledger contiene tres partes:
@@ -41,27 +40,25 @@ El XRP Ledger procesa transacciones en bloques llamadados "versiones del ledger"
 - El conjunto de transacciones que han sido aplicadas en el ledger anterior para dar como resultado este.
 - Metadatos sobre la versión actual del ledger, como el índice del ledger, un [hash criptográfico](https://en.wikipedia.org/wiki/Cryptographic_hash_function) que identifica de forma única su contenido, e información sobre el ledger parental que se usó como base para construir este.

-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Figura 1: Anatomía de una versión de un ledger, que incluye transacciones, estado, y metadatos")
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg 'Figura 1: Anatomía de una versión de un ledger, que incluye transacciones, estado, y metadatos')

 Cada versión del ledger está numerado por un _ledger index_ o índice ledger y se basa en una versión anterior del ledger cuyo índice es uno menos, y se remonta hasta el punto de partida llamado el _ledger génesis_ con un índice ledger 1.[¹](#footnote-1) Como Bitcoin y otras tecnologías blockchain, esto forma el histórico público de todas las transacciones y sus resultados. A diferencia de otras tecnologías blockchain, cada nuevo "bloque" en el XRP Ledger contiene la totalidad del estado actual, por lo que no tienes que recopilar toda el histórico completo para conocer qué esta pasando ahora.[²](#footnote-2)

 El objetivo principal del Protocolo de Consenso del XRP Ledger es acordar un conjunto de transacciones para añadir la nueva siguiente versión del ledger, aplicarlos en un orden bien definido, y después confirmar con todo el mundo para tener los mismos resultados. Cuando esto ocurre satisfactoriamente, una versión del ledger es considerado _validado_, y definitivo. A partir de aquí, el proceso continua construyendo la siguiente versión del ledger.

-
 ## Validación basada en la confianza

 El principio básico detrás del mecanismo de consenso del XRP Ledger es que un poco de confianza ayuda mucho. Cada participante en la red elige un conjunto de _validadores_, servidores [configurados específicamente para participar activamente en el consenso](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md), gestionados por diferentes equipos que se espera que se comporten honestamente la mayor parte del tiempo según el protocolo. Aún más importante, el conjunto de validadores elegidos no deberían confabular entre sí para infringir las reglas de la misma manera. Esta lista se llama _Lísta Única de Nodos_, o UNL.

 A medida que la red avanza, cada servidor escucha a sus validadores de confianza[³](#footnote-3); siempre y cuando un porcentaje lo suficientemente grande de ellos esté de acuerdo en que un conjunto de transacciones debería ocurrir y que un ledger dado es el resultado, el servidor declara un consenso. Si no están de acuerdo, los validadores modifican sus propuestas para que coincidan más con las de otros validadores en los que confían, repitiendo el proceso en varias rondas hasta alcanzar un consenso.

-[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg "Figura 2: Rondas de consenso. Los validadores revisan sus propuestas para coincidir con otros validadores en los que confían")
+[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg 'Figura 2: Rondas de consenso. Los validadores revisan sus propuestas para coincidir con otros validadores en los que confían')

-Esta bien si una pequeña porción de los validadores no funciona correctamente todo el tiempo. Siempre que menos del 20% de los  validadores de confianza fallen, el consenso puede continuar sin impedimentos; y confirman una transacción inválida requeriría que más del 80% de los validadodres de confianza se confabulasen. Si más del 20% o menos del 80% de los validadores confiables fallan, la red para de progresar.
+Esta bien si una pequeña porción de los validadores no funciona correctamente todo el tiempo. Siempre que menos del 20% de los validadores de confianza fallen, el consenso puede continuar sin impedimentos; y confirman una transacción inválida requeriría que más del 80% de los validadodres de confianza se confabulasen. Si más del 20% o menos del 80% de los validadores confiables fallan, la red para de progresar.

 Para una exploración de cómo el Protocolo de Consenso del XRP Ledger responde a varios desafíos, ataques, y casos de fallo, ver [Protecciones del Consenso contra Ataques y Modos de Fallo](consensus-protections.md).

-
----
+---

 ## Pies de página

--- a/@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md
@@ -2,11 +2,12 @@
 html: invariant-checking.html
 parent: consensus.html
 seo:
-    description: Entender qué es la verificación invariantes, por qué existe, cómo funciona, y qué comprobaciones de invariantes están activas.
+  description: Entender qué es la verificación invariantes, por qué existe, cómo funciona, y qué comprobaciones de invariantes están activas.
 labels:
  - Blockchain
  - Seguridad
 ---
+
 # Comprobación de invariantes

 La comprobación de invariantes es una característica de seguridad del XRP Ledger. Consiste en un conjunto de comprobaciones, separadas del procesamiento normal de transacciones, que garantiza que ciertas _invariantes_ se mantienen ciertas en todas las transacciones.
@@ -15,7 +16,6 @@ Como muchas características de seguridad, todos esperamos que la comprobación

 Las invariantes no deberían activarse, pero aseguran la integridad del XRP Ledger contra errores aún por descubrir o incluso creados.

-
 ## Por qué existe

 - El código fuente del XRP Ledger es complejo y extenso; hay un potencial alto de que el código se ejecute incorrectamente.
@@ -25,15 +25,12 @@ Específicamente, la ejecución de transacciones incorrectas podría crear datos

 El procesamiento de transacciones incorrectas socavaría el valor de confianza en el XRP Ledger. Las comprobación de invariantes proporciona valor a todo el XRP Ledger porque agrega la característica de confiabilidad.

-
-
 ## Cómo funciona

 El comprobador de invariantes es una segunda capa de código que se ejecuta automáticamente en tiempo real después de cada transacción. Antes de que los resultados de la transacción se confirmen en el ledger, el comprobador de invariantes examina esos cambios en busca de corrección. Si los resultados de la transacción rompieran una de las reglas estrictas del XRP Ledger, el comprobador de invariantes rechazará la transacción. Las transacciones que son rechazadas de esta manera tienen el código de resultado `tecINVARIANT_FAILED` y se incluyen en el ledger sin efectos.

 Para incluir la transacción en el ledger con un código de clase `tec`, es necesario realizar algún procesamiento mínimo. Si este procesamiento mínimo aún rompe un invariante, la transacción falla con el código `tefINVARIANT_FAILED` en su lugar, y no se incluye en el ledger en absoluto.

-
 ## Invariantes activas

 El XRP Ledger comprueba todas las siguientes invariantes en cada transación:
@@ -74,99 +71,89 @@ El XRP Ledger comprueba todas las siguientes invariantes en cada transación:

 - [Nueva Account Root válida](#nueva-account-root-válida)

-
 ### Comprobación de coste de transacción

 - **Condicion(es) invariantes:**
-    - La cantidad de [coste de transacción](../transactions/transaction-cost.md) nunca debe ser negativa, ni tampoco más grande que la especificada en el coste de la transacción.
-
+  - La cantidad de [coste de transacción](../transactions/transaction-cost.md) nunca debe ser negativa, ni tampoco más grande que la especificada en el coste de la transacción.

 ### XRP no creado

 - **Condicion(es) invariantes:**
-    - Una transacción no debe crear XRP y solo debería destruir el XRP del [coste de transacción](../transactions/transaction-cost.md).
-
+  - Una transacción no debe crear XRP y solo debería destruir el XRP del [coste de transacción](../transactions/transaction-cost.md).

 ### Account Roots no eliminadas

 - **Condicion(es) invariantes:**
-    - Una [cuenta](../accounts/index.md) no puede ser eliminada del ledger excepto por una [transacción AccountDelete][].
-    - Una transacción AccountDelete exitosa siempre borra exactamente 1 cuenta.
-
+  - Una [cuenta](../accounts/index.md) no puede ser eliminada del ledger excepto por una [transacción AccountDelete][].
+  - Una transacción AccountDelete exitosa siempre borra exactamente 1 cuenta.

 ### Comprobaciones de balance XRP

 - **Condicion(es) invariantes:**
-    - El balance de XRP de una cuenta debe ser de tipo XRP, y no puede ser menor a 0 o más de 100 mil millones XRP exactamente.
-
+  - El balance de XRP de una cuenta debe ser de tipo XRP, y no puede ser menor a 0 o más de 100 mil millones XRP exactamente.

 ### Coincidencia de tipos de entrada de ledger

 - **Condicion(es) invariantes:**
-    - Las entradas de los ledgers modificados deberían coincidir en tipo y las entradas añadidas deben ser de un [tipo válido](../../references/protocol/ledger-data/ledger-entry-types/index.md).
-
+  - Las entradas de los ledgers modificados deberían coincidir en tipo y las entradas añadidas deben ser de un [tipo válido](../../references/protocol/ledger-data/ledger-entry-types/index.md).

 ### No XRP Trust Lines

 - **Condicion(es) invariantes:**
-    - [Trust lines](../tokens/fungible-tokens/index.md) o líneas de confianza utilizando XRP no están permitidas.
-
+  - [Trust lines](../tokens/fungible-tokens/index.md) o líneas de confianza utilizando XRP no están permitidas.

 ### No malas ofertas

 - **Condicion(es) invariantes:**
-    - Las [ofertas](../../references/protocol/ledger-data/ledger-entry-types/offer.md) deben ser de cantidades no negativas y no pueden ser de XRP para XRP.
-
+  - Las [ofertas](../../references/protocol/ledger-data/ledger-entry-types/offer.md) deben ser de cantidades no negativas y no pueden ser de XRP para XRP.

 ### No escrow cero

 - **Condicion(es) invariantes:**
-    - Una entrada [escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md) debe contener más de 0 XRP y menos que 100 mil millones de XRP.
-
+  - Una entrada [escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md) debe contener más de 0 XRP y menos que 100 mil millones de XRP.

 ### Nueva Account Root válida

 - **Condicion(es) invariantes:**
-    - Una nueva [account root](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) debe ser la consecuencia de un pago.
-    - Una nueva account root debe tener la correcta [secuencia](../../references/protocol/data-types/basic-data-types.md#account-sequence) de inicio.
-    - Una transacción no debe crear más de una nueva [cuenta](../accounts/index.md).
+  - Una nueva [account root](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) debe ser la consecuencia de un pago.
+  - Una nueva account root debe tener la correcta [secuencia](../../references/protocol/data-types/basic-data-types.md#account-sequence) de inicio.
+  - Una transacción no debe crear más de una nueva [cuenta](../accounts/index.md).

 ### ValidNFTokenPage

 - **Condicion(es) invariantes:**
-    - El número de NFTs acuñados o quemados solo puede ser cambiado por transacciones `NFTokenMint` o `NFTokenBurn`.
-    - Una transacción NFTokenMint exitosa debe incrementar el número de NFTs.
-    - Una transacción NFTokenMint fallida no puede cambiar el número de NFTs acuñados.
-    - Una transacción NFTokenMint no puede cambiar el número de NFTs quemados.
-    - Una transacción NFTokenBurn debe incrementar el número de NFTs quemados.
-    - Una transacción NFTokenBurn no debe cambiar el número de NFTs quemados.
-    - Una transacción NFTokenBurn no puede cambiar el número de NFTs acuñados.
+  - El número de NFTs acuñados o quemados solo puede ser cambiado por transacciones `NFTokenMint` o `NFTokenBurn`.
+  - Una transacción NFTokenMint exitosa debe incrementar el número de NFTs.
+  - Una transacción NFTokenMint fallida no puede cambiar el número de NFTs acuñados.
+  - Una transacción NFTokenMint no puede cambiar el número de NFTs quemados.
+  - Una transacción NFTokenBurn debe incrementar el número de NFTs quemados.
+  - Una transacción NFTokenBurn no debe cambiar el número de NFTs quemados.
+  - Una transacción NFTokenBurn no puede cambiar el número de NFTs acuñados.

 ### NFTokenCountTracking

 - **Condicion(es) invariantes:**
-    - La página está correctamente asociada al dueño.
-    - La página está correctamente ordenada entre el siguiente y el anterior enlace.
-    - La página contiene un número válido de NFTs.
-    - Los NFTs en esta página no pertenecen a una página anterior o posterior.
-    - Los NFTs están correctamente ordenados en la página.
-    - Cada URI, si está presente, no está vacío.
+  - La página está correctamente asociada al dueño.
+  - La página está correctamente ordenada entre el siguiente y el anterior enlace.
+  - La página contiene un número válido de NFTs.
+  - Los NFTs en esta página no pertenecen a una página anterior o posterior.
+  - Los NFTs están correctamente ordenados en la página.
+  - Cada URI, si está presente, no está vacío.

 ## Ver también

 - **Blog:**
-    - [Protegiendo el ledger: Comprobación de invariantes](https://xrpl.org/blog/2017/invariant-checking.html)
+  - [Protegiendo el ledger: Comprobación de invariantes](https://xrpl.org/blog/2017/invariant-checking.html)

 - **Repositorio:**
-    - [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)
-    - [Parámetros del sistema](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
-    - [Cantidad XRP](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
-    - [Formatos de ledger](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
-
+  - [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)
+  - [Parámetros del sistema](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
+  - [Cantidad XRP](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
+  - [Formatos de ledger](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)

 - **Otros:**
-    - [Trust Lines autorizadas](../tokens/fungible-tokens/authorized-trust-lines.md)
-    - [Calculando cambios de balance para una transacción](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
+  - [Trust Lines autorizadas](../tokens/fungible-tokens/authorized-trust-lines.md)
+  - [Calculando cambios de balance para una transacción](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" /%}
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
@@ -2,10 +2,11 @@
 html: negative-unl.html
 parent: consensus.html
 seo:
-    description: Comprende cómo la UNL negativa mejora la resiliencia durante interrupciones parciales.
+  description: Comprende cómo la UNL negativa mejora la resiliencia durante interrupciones parciales.
 labels:
  - Blockchain
 ---
+
 # UNL negativa

 _Añadida por la [enmienda NegativeUNL](/resources/known-amendments.md#negativeunl)._
@@ -36,14 +37,12 @@ Si más del 20% de los validadores de repente se desconectan todos a la vez, los

 La UNL negativa no tiene efecto sobre el modo solitario o [stand-alone mode](../networks-and-servers/rippled-server-modes.md) porque el servidor no utiliza el consenso en el modo solitario.

-
 ## Cómo funciona

 La UNL negativa está estrechamente ligada al [proceso de consenso](index.md) y está diseñada con salvaguardas para mantener la continuidad y confiabilidad de la red en situaciones adversas. Cuando todos los validadores confiables están funcionando normalmente, la UNL negativa no se utiliza y no tiene efecto. Cuando algunos validadores parecen estar desconectados o desincronizados, se aplican las reglas de la UNL negativa.

 La UNL negativa está diseñada intencionalmente para cambiar a una velocidad lenta, para evitar desacuerdos basados en el tiempo sobre qué la UNL negativa debería aplicarse al proceso de consenso de una versión dada del ledger.

-
 ### Medición de fiabilidad

 Cada servidor en la red tiene una UNL, la lista de validadores en los que confía para no colisionar. (Por defecto, la UNL exacta de un servidor se configura implícitamente en función de la lista de validadores recomendada que Ripple publica). Cada servidor sigue la _fiabilidad_ de sus validadores de confianza utilizando una métrica única: el porcentaje de los últimos 256 ledgers donde el voto de validación del validador coincidió con la vista de consenso del servidor. En otras palabras:
@@ -64,8 +63,6 @@ Cada servidor, incluidos los validadores, calcula de forma independiente las pun

 **Consejo:** Los validadores siguen su propia fiabilidad, pero no proponen agregarse a la UNL negativa. La medida de fiabilidad de un validador por sí sola no puede tener en cuenta cuán exitosamente se propagan sus votos de validación a través de la red, por lo que es menos confiable que las mediciones de servidores externos.

-
-
 ### Modificación de la UNL negativa

 Una versión del ledger se considera un _flag ledger_ si su índice de ledger o index es divisible entera por 256. La UNL negativa solo se puede modificar en flag ledgers. (Los flag ledgers ocurren una vez cada 15 minutos en la red principal, Mainnet, de XRP Ledger. Pueden estar más separados en redes de prueba (test) que tienen un volumen de transacciones bajo).
@@ -74,32 +71,30 @@ En cada flag ledger, se aplican todos los siguientes cambios:

 1. Los cambios la UNL negativa que se programaron en el flag ledger anterior entran en vigencia para la siguiente versión del ledger. El proceso de consenso para validar este flag ledger en sí mismo no utiliza el cambio programado.

-    **Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).
+   **Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).

 2. Si la UNL negativa no está llena, cada servidor propone añadir **hasta 1** validador a la UNL negativa entre sus validadores confiables con una fiabilidad inferior al 50%.
 3. Si la UNL negativa no está vacía, cada servidor propone eliminar **hasta 1** validador de la UNL negativa. Un servidor puede proponer eliminar un validador de la UNL negativa por dos motivos:
-    - Califica a ese validador con una fiabilidad > 80%.
-    - No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
+   - Califica a ese validador con una fiabilidad > 80%.
+   - No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
 4. Si un cambio propuesto a la UNL negativa logra un consenso, el cambio se programa para entrar en vigencia en el siguiente flag ledger. Se puede programar hasta una adición y una eliminación de esta manera.

 Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/index.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.

 Los cambios programados y efectivos de la UNL negativa se rastrean en el [objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) en los datos de estado del ledger.

-
 ### Límites de la UNL negativa

 Para prevenir que la red se fragmente en dos o más subredes, la UNL negativa no puede reducir el requisito de cuórum a menos del 60% de las entradas de UNL _totales_. Para hacer cumplir esto, un servidor considera que la UNL negativa está "llena" si el número de validadores en la UNL negativa es del 25% (redondeado hacia abajo) del número de validadores en la UNL configurada del servidor. (El 25% se basa en el cálculo de que si se eliminan el 25% de los validadores, un consenso del 80% del 75% restante equivale al 60% del número original). Si un servidor considera que la UNL negativa está llena, no propondrá nuevas adiciones a la UNL negativa; pero, como siempre, el resultado final depende de lo que haga un consenso de validadores de confianza.

-
 ### Elección de múltiples validadores candidatos

 Es posible que múltiples validadores sean candidatos para ser agregados a la UNL negativa, según el umbral de fiabilidad. Dado que como máximo se puede agregar un validador a la UNL negativa a la vez, los servidores deben elegir qué validador proponer agregar. Si hay múltiples candidatos, el servidor elige cuál proponer con el siguiente mecanismo:

 1. Comienza con el hash del ledger de la versión anterior.
-0. Toma la clave pública de cada validador candidato.
-0. Cacula el valor de exclusión-o (XOR) del validador candidato y el hash del ledger padre.
-0. Propón el validador con el resultado numéricamente más bajo de la operación XOR.
+2. Toma la clave pública de cada validador candidato.
+3. Cacula el valor de exclusión-o (XOR) del validador candidato y el hash del ledger padre.
+4. Propón el validador con el resultado numéricamente más bajo de la operación XOR.

 Si hay múltiples candidatos para ser eliminados de la UNL negativa en un flag ledger dado, los servidores utilizan el mismo mecanismo para elegir entre ellos.

@@ -109,7 +104,6 @@ Este mecanismo tiene varias propiedades útiles:
 - La mayoría de los servidores eligen el mismo candidato incluso si calculan puntuaciones ligeramente diferentes para sus validadores de confianza. Esto se mantiene incluso si esos servidores discrepan sobre qué validador es _menos_ o _más_ confiable. Esto incluso se mantiene en muchos casos en los que los servidores discrepan sobre si algunos validadores están por encima o por debajo de los umbrales de fiabilidad. Por lo tanto, es probable que la red llegue a un consenso sobre qué validador agregar o eliminar.
 - No siempre da los mismos resultados en cada versión del ledger. Si un cambio propuesto a la UNL negativa no logra un consenso, la red no queda atrapada con algunos servidores intentando y fallando en agregar o eliminar ese validador cada vez. La red puede intentar agregar o eliminar un candidato diferente de la UNL negativa en un flag ledger posterior.

-
 ### Filtrado de validaciones

 Durante [el paso de validación del proceso de consenso](consensus-structure.md#validation), se desactivan los validadores en la UNL negativa del ledger padre. Cada servidor calcula una "UNL efectiva" que consiste en su UNL configurada con los validadores desactivados eliminados, y recalcula su cuórum. (El cuórum siempre es al menos el 80% de la UNL efectiva y al menos el 60% de la UNL configurada). Si un validador desactivado envía votos de validación, los servidores siguen esos votos para fines de cálculo de la medida de fiabilidad del validador desactivado, pero no utilizan esos votos para determinar si una versión del ledger ha alcanzado un consenso.
@@ -124,55 +118,53 @@ El siguiente ejemplo demuestra cómo afecta la UNL negativa al proceso de consen

 1. Supón que la UNL de tu servidor consta de 38 validadores de confianza, por lo que un cuórum del 80% es al menos 31 de 38 validadores.

-[{% inline-svg file="/docs/img/negative-unl-01.svg" /%}](/docs/img/negative-unl-01.svg "Diagrama: Caso normal: UNL negativa sin utilizar, el cuorum es 80% de los validadores configurados.")
+[{% inline-svg file="/docs/img/negative-unl-01.svg" /%}](/docs/img/negative-unl-01.svg 'Diagrama: Caso normal: UNL negativa sin utilizar, el cuorum es 80% de los validadores configurados.')

 2. Imagina que 2 de esos validadores, llamados MissingA y UnsteadyB, parecen haberse desconectado. (Ambos tienen puntuaciones de fiabilidad < 50%.) Durante el proceso de consenso para el ledger _N_, muchos de los validadores restantes proponen agregar a UnsteadyB en la UNL negativa. La moción pasa mediante un cuórum de al menos 31 de los validadores restantes, y el ledger _N_ se valida con UnsteadyB programado para ser desactivado.

-[{% inline-svg file="/docs/img/negative-unl-02.svg" /%}](/docs/img/negative-unl-02.svg "Diagrama: UnsteadyB está programado para desactivarse.")
-
+[{% inline-svg file="/docs/img/negative-unl-02.svg" /%}](/docs/img/negative-unl-02.svg 'Diagrama: UnsteadyB está programado para desactivarse.')

 3. Para ledgers desde _N+1_ hasta _N+256_, el proceso de consenso continua sin cambios.

 4. En el siguiente flag ledger, ledger _N+256_, UnsteadyB se mueve automáticamente de "programado" a la lista "desconectados" en el ledger. Además, dado que MissingA está todavía offline, un consenso de validadores programa a MissingA para ser desactivado en el siguiente flag ledger.

-[{% inline-svg file="/docs/img/negative-unl-04.svg" /%}](/docs/img/negative-unl-04.svg "Diagrama: UnsteadyB se desactiva y MissingA es programado para ser desactivado, también.")
+[{% inline-svg file="/docs/img/negative-unl-04.svg" /%}](/docs/img/negative-unl-04.svg 'Diagrama: UnsteadyB se desactiva y MissingA es programado para ser desactivado, también.')

 5. Para los ledgers _N+257_ a _N+512_, el cuorum es ahora 30 de 37 validadores.

 6. UnsteadyB vuelve a estar online en el ledger _N+270_. Envía votos de validación que están de acuerdo con el resto de la red de los ledgers _N+270_ a _N+511_, dándole una puntuación de confiabilidad de > 80%.

-[{% inline-svg file="/docs/img/negative-unl-06.svg" /%}](/docs/img/negative-unl-06.svg "Diagrama: UnsteadyB vuelve a estar online, pero sigue desactivado.")
+[{% inline-svg file="/docs/img/negative-unl-06.svg" /%}](/docs/img/negative-unl-06.svg 'Diagrama: UnsteadyB vuelve a estar online, pero sigue desactivado.')

 7. En el siguiente flag ledger, _N+256_, MissingA se mueve automáticamente a la lista de desactivados, como estaba programado. Mientras tanto, un consenso de validadores programa que UnsteadyB sea eliminado de la UNL negativa, debido a su mejora en la puntuación de confianza.

-[{% inline-svg file="/docs/img/negative-unl-07.svg" /%}](/docs/img/negative-unl-07.svg "Diagrama: MissingA está desactivado y UnsteadyB está programado para ser reactivado.")
+[{% inline-svg file="/docs/img/negative-unl-07.svg" /%}](/docs/img/negative-unl-07.svg 'Diagrama: MissingA está desactivado y UnsteadyB está programado para ser reactivado.')

 8. Para los ledgers _N+513_ a _N+768_, el cuorum es 29 de 36 validadores. UnsteadyB continua enviando validaciones de manera estable mientras que MissingA continua offline.

 9. En el flag ledger _N+768_, UnsteadyB es automáticamente eliminado de la lista de desactivados, como estaba programado.

-[{% inline-svg file="/docs/img/negative-unl-09.svg" /%}](/docs/img/negative-unl-09.svg "Diagrama: UnsteadyB es eliminado de la lista de desactivados.")
+[{% inline-svg file="/docs/img/negative-unl-09.svg" /%}](/docs/img/negative-unl-09.svg 'Diagrama: UnsteadyB es eliminado de la lista de desactivados.')

 10. Eventualmente, tú decides que MissingA es probable que no vuelva, así que lo eliminas de tu UNL. Tu servidor empieza a proponer eliminando a MissingA de la UNL negativa en cada flag ledger posterior.

-[{% inline-svg file="/docs/img/negative-unl-10.svg" /%}](/docs/img/negative-unl-10.svg "Diagrama: Después de eliminar a MissingA de tu UNL, se propone eliminarlo de la UNL negativa también.")
+[{% inline-svg file="/docs/img/negative-unl-10.svg" /%}](/docs/img/negative-unl-10.svg 'Diagrama: Después de eliminar a MissingA de tu UNL, se propone eliminarlo de la UNL negativa también.')

 11. A medida que los operadores de validadores eliminar a MissingA de sus UNLs, sus validadores también votan para eliminar MissingA de la UNL negativa. Cuando suficientes validadores lo han hecho, la propuesta de eliminar a MissingA consigue un consenso, y MissingA está programado para ser eliminado de la UNL negativa.

-[{% inline-svg file="/docs/img/negative-unl-11.svg" /%}](/docs/img/negative-unl-11.svg "Diagrama: MissingA es eliminado de la UNL negativa.")
-
+[{% inline-svg file="/docs/img/negative-unl-11.svg" /%}](/docs/img/negative-unl-11.svg 'Diagrama: MissingA es eliminado de la UNL negativa.')

 ## Ver también

 - **Conceptos:**
-    - [Protocolo de consenso](index.md)
+  - [Protocolo de consenso](index.md)
 - **Tutoriales:**
-    - [Conecta tu `rippled` a la red paralela](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
-    - [Ejecuta `rippled` como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+  - [Conecta tu `rippled` a la red paralela](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
+  - [Ejecuta `rippled` como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
 - **Referencias:**
-    - [Objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
-    - [Pseudo-transacción UNLModify][]
-    - [método ledger_entry][]
-    - [método consensus_info][]
+  - [Objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
+  - [Pseudo-transacción UNLModify][]
+  - [método ledger_entry][]
+  - [método consensus_info][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/ledgers/index.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/index.md
@@ -2,16 +2,17 @@
 html: ledgers.html
 parent: concepts.html
 seo:
-    description: Los libros contables o ledgers son la estructura de datos que contiene datos en la red compartida de XRP Ledger. Una cadena de ledgers registra el historial de transacciones y cambios de estado.
+  description: Los libros contables o ledgers son la estructura de datos que contiene datos en la red compartida de XRP Ledger. Una cadena de ledgers registra el historial de transacciones y cambios de estado.
 labels:
  - Blockchain
  - Retención de datos
 ---
+
 # Ledgers

 El XRP Ledger es un libro contable global compartido que está abierto para todos. Participantes individuales pueden confiar en la la integridad del ledger sin tener que confiar en una única institución para manejarlo. El protocolo XRP Ledger logra esto mediante la gestión de la base de datos de contabilidad que solo puede ser actualizada de acuerdo a unas reglas específicas. Cada servidor en la reed peer-to-peer guarda una copia completa de la base de datos del ledger o libro contable, y la red distribuye transacciones candidatas, las cuales se incluyen en bloques de acuerdo al [proceso de consenso](../consensus-protocol/index.md).

-[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "Diagrama: Cada ledger es el resultado de aplicar transacciones a la anterior versión del ledger.")
+[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg 'Diagrama: Cada ledger es el resultado de aplicar transacciones a la anterior versión del ledger.')

 El ledger global compartido consiste en una serie de bloques, llamadas versiones del ledger o simplemente _ledgers_. Cada versión del ledger tiene un índice o [Ledger Index][] el cual identifica el orden correcto de los ledgers. Cada ledger cerrado es permanente y también tiene un único valor hash que lo identifica.

@@ -19,13 +20,11 @@ En cualquier momento, cada servidor XRP Ledger tiene un ledger _abierto_ en prog

 Una versión del ledger consta de varias partes:

-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Diagrama: Un ledger tiene transacciones, un arbol de estado, y una cabecera con la hora de cierre y la información de validación")
-
-* Una **cabecera** - El índice del ledger o [Ledger Index][], hashes de sus otros contenidos, y otros metadatos.
-* Un **arbol de transacciones** - Las [transacciones](../../references/protocol/transactions/index.md) que se aplicaron al ledger anterior para hacer este.
-* Un **arbol de estado** - Todos los datos en el ledger, como [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md): balances, configuraciones, y demás.
-
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg 'Diagrama: Un ledger tiene transacciones, un arbol de estado, y una cabecera con la hora de cierre y la información de validación')

+- Una **cabecera** - El índice del ledger o [Ledger Index][], hashes de sus otros contenidos, y otros metadatos.
+- Un **arbol de transacciones** - Las [transacciones](../../references/protocol/transactions/index.md) que se aplicaron al ledger anterior para hacer este.
+- Un **arbol de estado** - Todos los datos en el ledger, como [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md): balances, configuraciones, y demás.

 ## Ver también

--- a/@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md
@@ -2,10 +2,11 @@
 html: ledger-close-times.html
 parent: ledgers.html
 seo:
-    description: Cómo el XRP Ledger calcula el valor de tiempo de cierre para cada versión del ledger.
+  description: Cómo el XRP Ledger calcula el valor de tiempo de cierre para cada versión del ledger.
 labels:
  - Blockchain
 ---
+
 # Tiempos de cierre del ledger

 La hora exacta en la que la versión del ledger se ha cerrado se queda guardada en el campo `close_time` de la cabecera del ledger o [ledger header](../../references/protocol/ledger-data/ledger-header.md). Para hacer más facil a la red llegar a un consenso en un tiempo de cierre exacto, este valor es redondeado a un número de segundos basado en el momento de resolución del cierre, actualmente 10 segundos. Si redondear causase a un tiempo de cierre ser igual que (o anterior) a su ledger padre, el ledger hijo tendrá su tiempo de cierre igual al tiempo de cierre del ledger padre más 1. Esto garantiza que los tiempos de cierre de los ledgers validados son estríctamente incrementales. <!-- STYLE_OVERRIDE: a number of -->
--- a/@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md
@@ -2,8 +2,9 @@
 html: ledger-structure.html
 parent: ledgers.html
 seo:
-    description: Un vistazo más cercano a los elementos de un bloque de ledger individual.
+  description: Un vistazo más cercano a los elementos de un bloque de ledger individual.
 ---
+
 # La estructura del ledger

 El XRP Ledger es una blockchain, lo que quiere decir que consiste en un histórico de bloques de datos consecutivos. Un bloque en la blockchain XRP Ledger se denomina una _versión del ledger_ o _ledger_ abreviado.
@@ -12,12 +13,11 @@ El protocolo de consenso toma la última versión del ledger como punto de parti

 Cada versión del ledger contiene _datos de estado_, un _conjunto de transacciones_, y una _cabecera_ que contiene metadatos.

-[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg "Diagrama: Un ledger está formado por una cabecera, un conjunto de transacciones, y datos de estado.")
-
+[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg 'Diagrama: Un ledger está formado por una cabecera, un conjunto de transacciones, y datos de estado.')

 ## Estado de datos

-[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg "Diagrama: Los datos de estado de un ledger, en forma de varios objetos los cuales a veces están unidos como en un grafo.")
+[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg 'Diagrama: Los datos de estado de un ledger, en forma de varios objetos los cuales a veces están unidos como en un grafo.')

 Los _datos de estado_ representan una fotografía de todas las cuentas, balances, configuraciones, y otra información de esta versión del ledger. Cuando un servidor se conecta a la red, una de las primeras cosas que hace es descargar un conjunto completo de los datos de estado actuales para poder procesar nuevas transacciones y responder consultas sobre el estado actual. Como cada servidor de la red tiene una copia completa de los datos del estado, todos los datos son públicos y cada copia es igualmente válida.

@@ -25,7 +25,7 @@ Los datos de estado consisten en objetos individuales llamados _entradas de ledg

 ## Conjunto de transacciones

-[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg "Diagrama: Un conjunto de transacciones del ledger, un grupo de transacciones organizado en orden canónico.")
+[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg 'Diagrama: Un conjunto de transacciones del ledger, un grupo de transacciones organizado en orden canónico.')

 Cada cambio realizado en el ledger es el resultado de una transacción. Cada versión del ledger contiene un _conjunto de transacciones_ que es un grupo de transacciones que se han aplicado recientemente en un orden específico. Si tomas los datos de estado de la versión anterior del ledger y aplicas este conjunto de transacciones del ledger encima de él, obtienes los datos de estado de este ledger como resultado.

@@ -34,33 +34,30 @@ Cada transacción en el conjunto del ledger tiene ambas de la siguientes partes:
 - _Instrucciones de la transaccion_ mostrando lo que el remitente le pidió hacer.
 - _Metadatos de la transacción_ mostrando exáctamente cómo la transacción debe ser procesada y cómo afecta a los datos de estado del ledger.

-
 ## Cabecera del ledger

 La _cabecera del ledger_ es un bloque de datos que resume la versión del ledger. Como la portada de un informe, identifica de forma única la versión del ledger, enumera sus contenidos, y muestra la hora en la que se creó, junto con algunas otras notas. La cabecera del ledger contiene la siguiente información:

 <!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->

- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg "") El _ledger index_, o índice del ledger identifica la posición del ledger en la cadena. Se construye en el ledger con un índice             restando uno, hasta llegar hasta el punto de inicio llamado como el _genesis ledger_. Esto forma un histórico público con todas las trnasacciones y resultados.
- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg "") El _ledger hash_, que identifica de manera única los contenidos del ledger. El hash es calculado de manera que si cambia algún detalle, la versión del ledger cambia, el hash es completamente diferente, lo que lo convierte también en un checksum que muestra que ninguno de los datos en el ledger se ha perdido, modificado, o corrompido.
- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg "") El _parent ledger hash_ o el hash del ledger padre. Una versión del ledger es definida en gran parte por la diferencia con el _parent ledger_ que viene antes de el, por lo que la cabecera también contiene el hash único para su ledger padre.
- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg "") El _close time_ u hora de cierre, la timestamp que marca cuando se finalizaron los contenidos del ledger. Este número se redondea por un número de segundos, generalmente 10.
- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg "") Un _hash de datos del estado_ el cual actua de checksum para los datos del estado.
- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg "") Un _hash del conjunto de transacciones_ el cual actua como checksum de los datos del conjuntos de transacciones.
- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg "") Algunas otras notas como la cantidad total de XRP en existencia y la cantidad que se redondeó la hora de cierre.
+- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg) El _ledger index_, o índice del ledger identifica la posición del ledger en la cadena. Se construye en el ledger con un índice restando uno, hasta llegar hasta el punto de inicio llamado como el _genesis ledger_. Esto forma un histórico público con todas las trnasacciones y resultados.
+- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg) El _ledger hash_, que identifica de manera única los contenidos del ledger. El hash es calculado de manera que si cambia algún detalle, la versión del ledger cambia, el hash es completamente diferente, lo que lo convierte también en un checksum que muestra que ninguno de los datos en el ledger se ha perdido, modificado, o corrompido.
+- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg) El _parent ledger hash_ o el hash del ledger padre. Una versión del ledger es definida en gran parte por la diferencia con el _parent ledger_ que viene antes de el, por lo que la cabecera también contiene el hash único para su ledger padre.
+- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg) El _close time_ u hora de cierre, la timestamp que marca cuando se finalizaron los contenidos del ledger. Este número se redondea por un número de segundos, generalmente 10.
+- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg) Un _hash de datos del estado_ el cual actua de checksum para los datos del estado.
+- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg) Un _hash del conjunto de transacciones_ el cual actua como checksum de los datos del conjuntos de transacciones.
+- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg) Algunas otras notas como la cantidad total de XRP en existencia y la cantidad que se redondeó la hora de cierre.

 Un conjunto de transacciones y los datos de estado son ilimitados en espacio, pero la cabecera del ledger siempre es de un tamaño fijo. Para los datos exactos y el formato binario de una cabecera del ledger, ver [Cabecera del leder](../../references/protocol/ledger-data/ledger-header.md).

-
 ## Estado de validación

-[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg "Diagrama: Un estado de validación de un ledger, el cual es añadido encima del ledger y no es parte del ledger en sí.")
+[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg 'Diagrama: Un estado de validación de un ledger, el cual es añadido encima del ledger y no es parte del ledger en sí.')

 Cuando un consenso de la Lista de Nodos Únicos de un servidor está de acuerdo en los contenidos de una versión del ledger, esa versión del ledger es marcada como validada e inmutable. Los contenidos del ledger solo pueden cambiar mediante transacciones posteriores que creen una nueva versión del ledger, continuando la cadena.

 Cuando una versión del ledger es creada por primera vez, no está todavía validada. Debido a las diferencias en cuanto llegan las transacciones a diferentes servidores, la red puede construir y proponer múltiples versiones diferentes del ledger para ser el siguiente en la cadena. El [protocolo de consenso](../consensus-protocol/index.md) decide cual de ellas se valida. (Las transacciones candidatas que no estén en la versión del ledger validado pueden generalmente incluirse en el conjunto de transacciones la siguiente versión del ledger en su lugar.)

-
 ## ¿Índice del ledger o Hash del ledger?

 Hay dos formas diferentes de identificar la versión del ledger: Su _ledger index_ o índice del ledger y su _ledger hash_ o hash del ledger. Estos dos campos identifican un ledger, pero tienen propósitos distintos. El índice del ledger te informa de la posición del ledger en la cadena, y el hash del ledger refleja los contenidos del ledger.
--- a/@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md
@@ -2,23 +2,24 @@
 html: open-closed-validated-ledgers.html
 parent: ledgers.html
 seo:
-    description: Los objetos del ledger tienen uno de los tres estados — abierto, cerrado, o validado.
+  description: Los objetos del ledger tienen uno de los tres estados — abierto, cerrado, o validado.
 labels:
  - Blockchain
 ---
+
 # Ledgers abiertos, cerrados, y validados

 El servidor `rippled` hace una distinción entre versiones de ledgers que están _abiertas_, _cerradas_, y _validadas_. Un servidor tiene un ledger abierto, cualquier número de ledgers cerrados pero no validados, y un historial inmutable de ledgers validados. La siguiente tabla resume las diferencias:

-| Tipo de ledger:                     | Abierto                        | Cerrado                                     | Validado |
-|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
-| **Propósito:**                     | Espacio de trabajo temporal         | Próximo estado propuesto                        | Estado previo confirmado |
-| **Número usado:**                 | 1                           | Cualquier número, normalmente 0 o 1             | Uno por ledger index, crece con el tiempo |
-| **¿Pueden los contenidos cambiar?**         | Sí                         | No, pero el ledger completo se podría reemplazar | Nunca |
-| **Transacciones se aplican en:** | El orden que son recibidas | Orden canónico                            | Orden canónino |
+| Tipo de ledger:                     | Abierto                     | Cerrado                                          | Validado                                  |
+| :---------------------------------- | :-------------------------- | :----------------------------------------------- | :---------------------------------------- |
+| **Propósito:**                      | Espacio de trabajo temporal | Próximo estado propuesto                         | Estado previo confirmado                  |
+| **Número usado:**                   | 1                           | Cualquier número, normalmente 0 o 1              | Uno por ledger index, crece con el tiempo |
+| **¿Pueden los contenidos cambiar?** | Sí                          | No, pero el ledger completo se podría reemplazar | Nunca                                     |
+| **Transacciones se aplican en:**    | El orden que son recibidas  | Orden canónico                                   | Orden canónino                            |

 No intuitivamente, el XRP Ledger nunca "cierra" un ledger abierto para convertirlo en un ledger cerrado. En cambio, el servidor descarta el ledger abierto, crea un nuevo ledger cerrado aplicando transacciones encima de los ledgers cerrados previos, entonces crea un nuevo ledger abierto utilizando el último ledger cerrado como base. Esto es una consecuencia de [cómo el consenso resuelve el problema del doble gasto](../consensus-protocol/consensus-principles-and-rules.md#simplificando-el-problema).

 Para un ledger abierto, los servidores aplican transacciones en el orden en el que esas transacciones aparecen, pero diferentes servidores puede que vean transacciones en diferentes órdenes. Como no hay un vigilante del tiempo para decidir qué transacción fue actualmente la primera, los servidores pueden no estar de acuerdo en el orden exacto de las transacciones que fueron enviadas casi al mismo tiempo. Por lo tanto, el proceso para calcular una versión de ledger cerrado que es elegible para [validación](../consensus-protocol/consensus-structure.md#validación) es diferente que el proceso de construir un ledger abierto con transacciones propuestas en su orden de llegada. Para crear un ledger "cerrado", cada servidor XRP Ledger comienza con un cojunto de transacciones y una versión anterior de ledger, o "padre". El servidores pone las transacciones en orden canónico, después las aplica al anterior ledger en ese orden. El orden canónico está diseñado para ser determinístico y eficiente, pero dificil de manipular, para incrementar la dificultad de adelantarse (o front-running) a las Ofertas en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).

-Por lo tanto, un ledger abierto es solo utilizado como un espacio de trabajo temporal, lo cual es una de las principales razones por las cuales  [los resultados tentativos pueden variar de los resultados finales](../transactions/finality-of-results/index.md) en las transacciones.
+Por lo tanto, un ledger abierto es solo utilizado como un espacio de trabajo temporal, lo cual es una de las principales razones por las cuales [los resultados tentativos pueden variar de los resultados finales](../transactions/finality-of-results/index.md) en las transacciones.
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md
@@ -2,13 +2,14 @@
 html: amendments.html
 parent: networks-and-servers.html
 seo:
-    description: Las enmiendas representan nuevas funcionalidades u otros cambios para el procesamiento de transacciones. Los validadores se coordinan a través del consenso para aplicar estas mejoras al XRP Ledger  de manera ordenada.
+  description: Las enmiendas representan nuevas funcionalidades u otros cambios para el procesamiento de transacciones. Los validadores se coordinan a través del consenso para aplicar estas mejoras al XRP Ledger  de manera ordenada.
 labels:
  - Blockchain
 ---
+
 # Enmiendas

-Las enmiendas representan nuevas funcionalidades u otros cambios en el procesamiento de transacciones. 
+Las enmiendas representan nuevas funcionalidades u otros cambios en el procesamiento de transacciones.

 El sistema de enmiendas utiliza el proceso de consenso para aprobar cualquier cambio que afecte el procesamiento de transacciones en el XRP Ledger. Los cambios en el proceso de transacción completamente funcionales se introducen como enmiendas; luego, los validadores votan sobre estos cambios. Si una enmienda recibe más del 80% de apoyo durante dos semanas, la enmienda se aprueba y el cambio se aplica permanentemente a todas las versiones de ledgers subsiguientes. Deshabilitar una enmienda aprobada requiere una nueva enmienda para hacerlo.

@@ -29,15 +30,14 @@ Cada 256º ledger se llama **flag** ledger. El flag ledger no tiene contenidos e
 1. **Flag Ledger -1:** Cuando los validadores `rippled` envían mensajes de validación, también envían sus votos sobre enmiendas.
 2. **Flag Ledger:** Los servidores interpretan los votos de los validadores confiables.
 3. **Flag Ledger +1:** Los servidores insertan la pseudo transacción `EnableAmendment` y marcan dependiendo de lo que piensan que ha pasado:
-    * El flag (o marca) `tfGotMajority` significa que la enmienda tiene más del 80% del apoyo.
-    * El flag (o marca) `tfLostMajority` significa que el apoyo de la enmienda ha descendido al 80% o menos.
-    * Que no haya flag (o marca) significa que la enmienda está activada.
+   - El flag (o marca) `tfGotMajority` significa que la enmienda tiene más del 80% del apoyo.
+   - El flag (o marca) `tfLostMajority` significa que el apoyo de la enmienda ha descendido al 80% o menos.
+   - Que no haya flag (o marca) significa que la enmienda está activada.

-    **Nota:** Es posible para una enmienda perder el 80% del apoyo en el mismo ledger en el que alcanza el periodo de dos semanas para ser activada. En esos casos, una pseudo-transaccion `EnableAmendment` es añadida en ambos escenarios, pero la enmienda es activada finalmente. 
+   **Nota:** Es posible para una enmienda perder el 80% del apoyo en el mismo ledger en el que alcanza el periodo de dos semanas para ser activada. En esos casos, una pseudo-transaccion `EnableAmendment` es añadida en ambos escenarios, pero la enmienda es activada finalmente.

 4. **Flag Ledger +2:** Enmiendas activadas aplican a transacciones en este ledger en adelante.

-
 ## Votación de enmienda

 Cada versión de `rippled` es compilada con una lista de [enmiendas conocidas](/resources/known-amendments.md) y el código para implementar esas enmiendas. Los operadores de los validadores `rippled` configuran sus servidores para votar en cada enmienda y cambiarlo en cada momento. Si un operador no elige un voto, el servidor por defecto tiene un voto definido en el códido fuente.
@@ -48,16 +48,16 @@ Las enmiendas deben mantener dos semanas el apoyo de más del 80% de los validad

 Las enmiendas que hayan tenido su código fuente removido sin haberse activado on consideradas **vetadas** por la red.

-
 ## Servidores bloqueados por enmienda
+
 <a id="amendment-blocked"></a>

 El bloqueo por enmienda es una característica de seguridad para proteger la precisión de los datos del XRP Ledger. Cuando una enmienda se activa, los servidores ejecutando versiones anteriores de `rippled` sin el código fuente de la enmienda ya no consiguen entender las reglas de la red. En vez de adivinar y malinterpretar los datos del ledger, estos servidores se convierten en servidores **bloqueados por enmienda** y no pueden:

-* Determinar la validez de un ledger.
-* Enviar o procesar transacciones.
-* Participar en el proceso de consenso.
-* Votar sobre futuras enmiendas.
+- Determinar la validez de un ledger.
+- Enviar o procesar transacciones.
+- Participar en el proceso de consenso.
+- Votar sobre futuras enmiendas.

 La configuración de votación de un servidor `rippled` no tiene impacto en convertirse en un servidor bloqueado por enmienda. Un servidor `rippled` siempre sigue las enmiendas activadas por el resto de la red, por lo que los bloqueos solo se basan en tener el código para entender los cambios de reglas. Esto significa que tu también te puedes convertir en alguien bloqueado por enmienda si conectas tu servidor a una red paralela con enmiendas activadas. Por ejemplo, La Devnet de XRP normalmente tiene enmiendas experimentales activadas. Si estás utilizando la última publicación o release en producción, tu servidor no tendrá ese código de esas enmiendas experimentales.

@@ -73,16 +73,15 @@ Cuando las enmiendas son activadas, el código fuente de comportamientos previos

 El [Estándar 11d de XRP Ledger](https://github.com/XRPLF/XRPL-Standards/discussions/19) define un proceso para retirar enmiendas antiguas y código asociado previo a la enmienda. Después de que una enmienda haya sido activada en Mainnet por dos años, puede ser retirado. Retirar una enmienda la convierte en parte del protocolo central incondicionalmente; ya no se sigue ni se trata como una enmienda, y todo el código anterior a la enmienda es eliminado.

-
 ## Ver también

 - **Conceptos:**
-    - [Consenso](../consensus-protocol/index.md)
+  - [Consenso](../consensus-protocol/index.md)
 - **Tutoriales:**
-    - [Ejecutar rippled como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
-    - [Configurar votación de enmiendas](../../infrastructure/configuration/configure-amendment-voting.md)
-    - [Contribuir al código del XRP Ledger](/resources/contribute-code/index.md)
+  - [Ejecutar rippled como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+  - [Configurar votación de enmiendas](../../infrastructure/configuration/configure-amendment-voting.md)
+  - [Contribuir al código del XRP Ledger](/resources/contribute-code/index.md)
 - **Referencias:**
-    - [Enmiendas conocidas](/resources/known-amendments.md)
+  - [Enmiendas conocidas](/resources/known-amendments.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md
@@ -2,10 +2,11 @@
 html: clustering.html
 parent: networks-and-servers.html
 seo:
-    description: Ejecuta servidores rippled en un cluster para compartir la carga criptográfica entre ellos.
+  description: Ejecuta servidores rippled en un cluster para compartir la carga criptográfica entre ellos.
 labels:
  - Servidor principal
 ---
+
 # Clustering

 Si estás ejecutando varios servidores `rippled` en un único datacenter, puedes configurar esos servidores dentro de un cluster para maximizar la eficiencia. Ejecutar tus servidores `rippled` en un cluster proporciona los siguientes beneficios:
@@ -19,11 +20,11 @@ Si estás ejecutando un validador como un [par privado](peer-protocol.md#pares-p
 ## Ver también

 - **Tutoriales:**
-    - [Cluster de servidores `rippled`](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
-    - [Ejecutar rippled como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+  - [Cluster de servidores `rippled`](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
+  - [Ejecutar rippled como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
 - **Referencias:**
-    - [método peers][]
-    - [método connect][]
-    - [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
+  - [método peers][]
+  - [método connect][]
+  - [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/index.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/index.md
@@ -2,10 +2,11 @@
 html: networks-and-servers.html
 parent: concepts.html
 seo:
-    description: rippled es el servidor peer-to-peer principal que maneja el XRP Ledger.
+  description: rippled es el servidor peer-to-peer principal que maneja el XRP Ledger.
 metadata:
  indexPage: true
 ---
+
 # Redes y servidores

 Hay dos tipos principales de software de servidores que alimentan el XRP Ledger:
@@ -17,15 +18,15 @@ Cualquiera puede ejecutar instancias de uno o ambos de estos tipos de servidores

 ## Razones por las que ejecutar tu propio servidor

-Para casos de uso más livianos y servidores individuales, puedes depender de  [servidores públicos][]. Sin embargo, cuanto más serio sea tu uso del XRP Ledger, más importante será tener tu propia infraestructura.
+Para casos de uso más livianos y servidores individuales, puedes depender de [servidores públicos][]. Sin embargo, cuanto más serio sea tu uso del XRP Ledger, más importante será tener tu propia infraestructura.

 Hay multitud de razones por las que quieres ejecutar tus propios servidores, pero la mayoría de ellas se pueden resumir en: puedes confiar en tu propio servidor, tienes control sobre la carga de trabajo, y no estás a merced de otros que decidan cuando y cómo puedes acceder. Por supuesto, debes tener tener unas buenas prácticas respecto a la seguridad de la red para proteger tu servidor de hackers maliciosos.

 Necesitas confiar en el servidor que utilizas. Si te conectas a un servidor malicioso, hay muchas maneras en las que se pueda aprovechar de ti o hacerte perder dinero. Por ejemplo:

-* Un servidor malicioso podría informar que has sido pagado cuando no se ha hecho el pago.
-* 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.
+- Un servidor malicioso podría informar que has sido pagado cuando no se ha hecho el pago.
+- 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.

@@ -37,5 +38,4 @@ Finalmente, si ejecutas un servidor de validación, puedes utilizar un servidor

 {% raw-partial file="/docs/_snippets/common-links.md" /%}

-
 {% child-pages /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md
@@ -2,12 +2,13 @@
 html: ledger-history.html
 parent: networks-and-servers.html
 seo:
-    description: Los servidores rippled almacenan una cantidad variable de transacciones e historial del estado localmente.
+  description: Los servidores rippled almacenan una cantidad variable de transacciones e historial del estado localmente.
 labels:
  - Retención de datos
  - Blockchain
  - Servidor principal
 ---
+
 # Histórico del ledger

 El [proceso de consenso](../consensus-protocol/index.md) crea una cadena de [versiones de ledgers validados](../ledgers/index.md), cada uno derivado del anterior aplicando un conjunto de [transacciones](../transactions/index.md). Cada [servidor `rippled`](index.md) almacena versiones de ledgers y el historial de transacciones locálmente. La cantidad de histórico de transacciones que un servidor almacena depende de cuanto tiempo ese servidor ha estado online y cuanto histórico está configurado para recuperar y mantener.
@@ -34,17 +35,16 @@ Rellenar el histórico es uno de las prioridades más bajas del servidor, por lo

 El XRP Ledger identifica datos (en varios niveles diferentes) mediante un hash único de sus contenidos. Los datos de estado del XRP Ledger contienen un resumen breve del histórico del ledger, en forma de [tipos de objeto LedgerHashes](../../references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md). Los serivodres usan los objetos LedgerHashes para conocer qué versiones del ledger hay que buscar, y confirmar que los datos del ledger que recibe son correctos y completos.

-
 <a id="with-advisory-deletion"></a><!-- old anchor to this area -->
+
 ### Rellenar
+
 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}Actualizado en: rippled 1.6.0{% /badge %}

 La cantidad de histórico que un servidor intenta descargar depende de su configuración. El servidor automáticamente intenta rellenar los huecos descargando el histórico hasta **el ledger más antiguo que está actualmente disponible**. Pues utilizar el campo `[ledger_history]` para hacer al servidor rellenar el histórico más allá de ese punto. Sin embargo, el servidor nunca descarga ledgers que estuviesen programados para su [eliminación](../../infrastructure/configuration/data-retention/online-deletion.md).

 El campo `[ledger_history]` define el número mínimo de ledgers que se acumulan antes del ledger actual validado. Utiliza el valor especial `full` para descargar el [histórico completo](#full-history) de la red. Si especificas un número de ledgers, debe ser igual o mayor que el campo `online_deletion`; no puedes utilizar `[ledger_history]` para hacer al servidor descargar _menos_ histórico. Para reducir la cantidad de histórico que un servidor almacena, cambia el ajuste [online deletion](../../infrastructure/configuration/data-retention/online-deletion.md). <!-- STYLE_OVERRIDE: a number of -->

-
-
 ## Histórico completo

 Algunos servidores en la red XRP Ledger están configurados como servidores "full-history". Estos servidores, los cuales requieren sifnificativamente más espacio de disco que otros servidores de seguimiento, almacenan todo el histórico disponible XRP Ledger y **no usan la opción online deletion**.
@@ -58,22 +58,21 @@ Los proveedores de servidores Full History se reservan el derecho de bloquear ac

 Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).

-
 ## Ver también

 - **Conceptos:**
-    - [Ledgers](../ledgers/index.md)
-    - [Consenso](../consensus-protocol/index.md)
+  - [Ledgers](../ledgers/index.md)
+  - [Consenso](../consensus-protocol/index.md)
 - **Tutoriales:**
-    - [Configurar `rippled`](../../infrastructure/configuration/index.md)
-        - [Configurar Online Deletion](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
-        - [Configurar Advisory Deletion](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
-        - [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
+  - [Configurar `rippled`](../../infrastructure/configuration/index.md)
+    - [Configurar Online Deletion](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
+    - [Configurar Advisory Deletion](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
+    - [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
 - **Referencias:**
-    - [método ledger][]
-    - [método server_info][]
-    - [método ledger_request][]
-    - [método can_delete][]
-    - [método ledger_cleaner][]
+  - [método ledger][]
+  - [método server_info][]
+  - [método ledger_request][]
+  - [método can_delete][]
+  - [método ledger_cleaner][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md
@@ -2,51 +2,48 @@
 html: parallel-networks.html
 parent: networks-and-servers.html
 seo:
-    description: Entender cómo las redes de prueba (test) y cadenas ledger alternativas se relacionan con el XRP Ledger en producción.
+  description: Entender cómo las redes de prueba (test) y cadenas ledger alternativas se relacionan con el XRP Ledger en producción.
 labels:
  - Blockchain
 ---
+
 # Redes paralelas

 Existe una red peer-to-peer en producción del XRP Ledger, y todos los negocios que tienen lugar en el XRP Ledger ocurren dentro de la red de producción: la Mainnet.

 Para ayudar a miembros de la comunidad del XRP Ledger a interactuar con la tecnología sin afectar nada a la Mainnet, hay redes alternativas, o altnets. Aquí hay un desglose de algunas altnets públicas:

-| Red | Cadencia de actualización | Descripción                                      |
-|:--------|:----------------|:-------------------------------------------------|
-| 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. |
+| Red     | Cadencia de actualización | Descripción                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| :------ | :------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 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.                                                                                                                                  |

 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.

 **Atención:** A diferencia de la Mainnet del XRP Ledger, las redes de prueba suelen ser _centralizadas_ y no hay garantías sobre la estabilidad y disponibilidad de estas redes. Han sido y siguen siendo utilizadas para probar diversas propiedades de la configuración del servidor, la topología de la red y el rendimiento de la red.

-
 ## Redes paralelas y consenso

 El factor principal en determinar qué red sigue un servidor es su UNL configurado-la lista de validadores en los que confía para no colisionar. Cada servidor utiliza su UNL configurada para saber qué ledger aceptar como la verdad. Cuando diferentes grupos de consenso de instancias de `rippled` solo confían en otros miembros del mismo grupo, cada grupo continúa como una red paralela. Incluso si equipos maliciosos o malintencionados se conectan a ambas redes, el proceso de consenso evita la confusión siempre y cuando los miembros de cada red no estén configurados para confiar en miembros de otra red en exceso de su configuración de cuórum.

 Ripple ejecuta los servidores principales en la Testnet y Devnet; también puedes [conectar tu propio servidor `rippled` para estas redes](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md). La Testnet y Devnet no utilizan conjuntos de validadores diversos y resistentes a la censura. Esto hace posible que Ripple reinicie la Testnet o Devnet en cualquier momento.

-
 ## Ver también

 - **Herramientas:**
-    - [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
+  - [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
 - **Conceptos:**
-    - [Consenso](../consensus-protocol/index.md)
-    - [Enmiendas](amendments.md)
+  - [Consenso](../consensus-protocol/index.md)
+  - [Enmiendas](amendments.md)
 - **Tutoriales:**
-    - [Conectar tu `rippled` en laTestnet XRP](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
-    - [Usar rippled en modo Stand-Alone](../../infrastructure/testing-and-auditing/index.md)
+  - [Conectar tu `rippled` en laTestnet XRP](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
+  - [Usar rippled en modo Stand-Alone](../../infrastructure/testing-and-auditing/index.md)
 - **Referencias:**
-    - [método server_info][]
-    - [método consensus_info][]
-    - [método validator_list_sites][]
-    - [método validators][]
-    - [Opciones modo Daemon](../../infrastructure/commandline-usage.md#daemon-mode-options)
+  - [método server_info][]
+  - [método consensus_info][]
+  - [método validator_list_sites][]
+  - [método validators][]
+  - [Opciones modo Daemon](../../infrastructure/commandline-usage.md#daemon-mode-options)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
@@ -2,11 +2,12 @@
 html: peer-protocol.html
 parent: networks-and-servers.html
 seo:
-    description: El protocolo de pares especifica el lenguaje en el que los servidores rippled hablan entre sí.
+  description: El protocolo de pares especifica el lenguaje en el que los servidores rippled hablan entre sí.
 labels:
  - Servidor principal
  - Blockchain
 ---
+
 # Protocolo de pares

 Los servidores en el XRP Ledger se comunican entre sí utilizando el protocolo de pares del XRP Ledger.
@@ -24,13 +25,12 @@ Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando

 El XRP Ledger utiliza el protocolo del "chismorreo" para ayudar a servidores a encontrar otros servidores para conectarse en la red XRP Ledger. Cuando un servidor se inicia, se reconecta a cualquier otro par al que se haya conectado anteriormente. Como alternativa, utiliza los [hubs públicos hardcodeados](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). Después de que un servidor se conecte correctamente a un par, le pregunta a ese par por información de contacto (generalmente, dirección IP y puerto) de otros servidores XRP Ledger que también pueden estar buscando pares. El servidor puede conectarse entonces a esos servidores, y preguntarles por información de contacto de todavía más servidores a los que conectarse. A través de este proceso, el servior hace suficientes conexiones de pares para que pueda permanecer contectado con el resto de la red incluso si pierde la conexión con cualquier par en particular.

-Normalmente, un servidor necesita conectarse a un hub público solo una vez, durante un corto período de tiempo, para encontrar otros pares. Después de hacerlo, el servidor puede o no permanecer conectado al hub, dependiendo de la estabilidad de su conexión de red, de lo ocupado que esté el hub y de cuántos otros pares de alta calidad encuentre el servidor. El servidor guarda las direcciones de estos otros pares para poder intentar reconectarse directamente a esos pares más tarde, después de una interrupción en la red o un reinicio. 
+Normalmente, un servidor necesita conectarse a un hub público solo una vez, durante un corto período de tiempo, para encontrar otros pares. Después de hacerlo, el servidor puede o no permanecer conectado al hub, dependiendo de la estabilidad de su conexión de red, de lo ocupado que esté el hub y de cuántos otros pares de alta calidad encuentre el servidor. El servidor guarda las direcciones de estos otros pares para poder intentar reconectarse directamente a esos pares más tarde, después de una interrupción en la red o un reinicio.

 El [método peers][] muestra una lista de pares a los que tu servidor está actualmente conectado.

 Para ciertos servidores de alto valor (tan importantes como [validadores](rippled-server-modes.md#modos-de-servidor-rippled)) puedes preferir no conectarte a pares no confiables a través del proceso de descubrimiento de pares. En este caso, puedes configurar tu servidor para usar solo [pares privados](#pares-privados).

-
 ## Puerto del protocolo de pares

 Para participar en el XRP Ledger, los servidores `rippled` conectan con pares arbitrarios utilizando el protocolo de pares. (Todos los pares son como no confiables, a no ser que sean de tipo [clusterizado](clustering.md) con el servidor actual.)
@@ -58,7 +58,6 @@ El par de claves de nodo se guarda en la base de datos y se reutiliza cuando el

 El par de claves de nodo también identifican otros servidores para propositos de [clustering](clustering.md) o [reservar huecos de pares](#pares-fijos-y-reservas-de-pares). Si tienes un cluster de servidores, debes configurar cada servidor en el cluster con un valor único en el apartado `[node_seed]`. Para más información de cómo configurar un cluster, ver [Servidores `rippled` clusterizados](../../infrastructure/configuration/peering/cluster-rippled-servers.md).

-
 ## Pares fijos y reservas de pares

 Normalmente, un servidor `rippled` intenta mantener un número saludable de pares, y se conecta automáticamente a pares no confiables hasta un número máximo. Puedes configurar un servidor `rippled` para permanecer conectado a servidores de pares específicos de varias maneras:
@@ -71,10 +70,9 @@ En los siguientes casos, un servidor `rippled` no se conecta a pares no confiabl
 - Si el servidor es configurado como un [par privado](#pares-privados), se conecta _solo_ a sus pares fijos.
 - Si el servidor esta ejecutando en [modo solitario][] no se conecta a _ningún_ par.

-
 ## Pares privados

-Puedes configurar un servidor `rippled` para actuar como un servidor "privado" para mantener oculta su dirección IP del público  general. Esta puede ser una precaución útil contra ataques de denegación de servicio e intentos de intrusión en servidores `rippled` importantes como los validadores de confianza. Para participar en la red peer-to-peer, un servidor privado debe estar configurado para conectarse a al menos un servidor no privado, que transmita sus mensajes al resto de la red.
+Puedes configurar un servidor `rippled` para actuar como un servidor "privado" para mantener oculta su dirección IP del público general. Esta puede ser una precaución útil contra ataques de denegación de servicio e intentos de intrusión en servidores `rippled` importantes como los validadores de confianza. Para participar en la red peer-to-peer, un servidor privado debe estar configurado para conectarse a al menos un servidor no privado, que transmita sus mensajes al resto de la red.

 **Atención:** Si configuras un servidor privado sin ningún [par fijo](#pares-fijos-y-reservas-de-pares), el servidor no puede conectarse a la red, por lo que no puede conocer el estado de la red, transmitir transacciones o participar en el proceso de consenso.

@@ -84,9 +82,9 @@ Configurar un servidor como un servidor privado tiene varios efectos:
 - El servidor no acepta conexiones entrantes de otros servidores a menos que se haya configurado explícitamente para aceptar conexiones de esos servidores.
 - El servidor pide a sus pares directos no revelar su dirección IP a comunicaciones no confiables, incluyendo a la [respuesta de la API del peer crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md). Esto no afecta a las comunicaciones confiables como el [método peers admin][peers method].

-    Los servidores siempre piden a sus pares ocultar las direcciones IP de validadores, independientemente de la configuración del servidor privada. Esto ayuda a proteger validadores de ser sobrecargados por ataques de denegación de servicio.
+  Los servidores siempre piden a sus pares ocultar las direcciones IP de validadores, independientemente de la configuración del servidor privada. Esto ayuda a proteger validadores de ser sobrecargados por ataques de denegación de servicio.

-    **Atención:** Es posible modificar el código fuente de un servidor para que ignore esta petición y comparta las direcciones IP de sus pares inmediatos de todos modos. Debes configurar tu servidor privado para que se conecte solo a servidores que sepas que no están modificados de esta manera.
+  **Atención:** Es posible modificar el código fuente de un servidor para que ignore esta petición y comparta las direcciones IP de sus pares inmediatos de todos modos. Debes configurar tu servidor privado para que se conecte solo a servidores que sepas que no están modificados de esta manera.

 ### Pros y contras de las configuraciones de pares

@@ -98,7 +96,6 @@ Para ser parte del XRP Ledger, un servidor `rippled` debe estar conectado al res

 Los pros y contras de cada configuración son los siguientes:

-
 <table>
 <thead><tr>
 <th>Configuración</th> <th>Pros</th> <th>Contras</th>
@@ -148,27 +145,26 @@ Los pros y contras de cada configuración son los siguientes:

 Para configurar tu servidor como un servidor privado, establece la opción `[peer_private]` a `1` en el fichero de configuración. Para intrudciones más detalladas, ver [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md).

-
 ## Ver también

 - **Conceptos:**
-    - [Consenso](../consensus-protocol/index.md)
-    - [Redes paralelas](parallel-networks.md)
+  - [Consenso](../consensus-protocol/index.md)
+  - [Redes paralelas](parallel-networks.md)
 - **Tutoriales:**
-    - [Cluster de servidores rippled](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
-    - [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md)
-    - [Configurar el Peer Crawler](../../infrastructure/configuration/peering/configure-the-peer-crawler.md)
-    - [Redireccionar puertos para pares](../../infrastructure/configuration/peering/forward-ports-for-peering.md)
-    - [Conectarse manualmente a un par específico](../../infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md)
-    - [Establecer número máximo de pares](../../infrastructure/configuration/peering/set-max-number-of-peers.md)
-    - [Utilizar la reserva de pares](../../infrastructure/configuration/peering/use-a-peer-reservation.md)
+  - [Cluster de servidores rippled](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
+  - [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md)
+  - [Configurar el Peer Crawler](../../infrastructure/configuration/peering/configure-the-peer-crawler.md)
+  - [Redireccionar puertos para pares](../../infrastructure/configuration/peering/forward-ports-for-peering.md)
+  - [Conectarse manualmente a un par específico](../../infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md)
+  - [Establecer número máximo de pares](../../infrastructure/configuration/peering/set-max-number-of-peers.md)
+  - [Utilizar la reserva de pares](../../infrastructure/configuration/peering/use-a-peer-reservation.md)
 - **Referencias:**
-    - [método peers][]
-    - [método peer_reservations_add][]
-    - [método peer_reservations_del][]
-    - [método peer_reservations_list][]
-    - [método connect][]
-    - [método fetch_info][]
-    - [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
+  - [método peers][]
+  - [método peer_reservations_add][]
+  - [método peer_reservations_del][]
+  - [método peer_reservations_list][]
+  - [método connect][]
+  - [método fetch_info][]
+  - [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md
@@ -2,25 +2,25 @@
 html: rippled-server-modes.html
 parent: networks-and-servers.html
 seo:
-    description: Aprende sobre los modos de servidor rippled, incluyendo servidores stock, servidores validadores y servidores que se ejecutan en modo solitario.
+  description: Aprende sobre los modos de servidor rippled, incluyendo servidores stock, servidores validadores y servidores que se ejecutan en modo solitario.
 labels:
  - Servidor principal
 ---
+
 # Modos de servidor rippled

 El software del servidor `rippled` puede ejecutarse en varios modos dependiendo de su configuración, incluyendo:

 - [**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 hub**](#hubs-públicos) - Transmite mensajes entre muchos otros miembros de la red peer-to-peer.
+  - [**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 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.

 Tambien puedes ejecutar el ejecutable `rippled` como una aplicación cliente para acceder [APIs `rippled`](../../references/http-websocket-apis/index.md) localmente. (Dos instancias del mismo binario pueden ejecutarse uno al lado del otro en este caso; uno como un servidor, y el otro ejecutándose brevemente como cliente y luego apagarlo.)

 Para más información sobre los comandos que ejecutar `rippled` en cada uno de estos modos, ver la [Referencia de línea de comandos](../../infrastructure/commandline-usage.md).

-
 ## Modo P2P

 El Modo P2P es el modo principal y predeterminado del servidor `rippled`, y puede manejar casi cualquier cosa que desees que haga tu servidor. Estos servidores forman una red peer-to-peer que procesa transacciones y mantiene el estado compartido del XRP Ledger. Si deseas enviar transacciones, leer datos del ledger o participar de otra manera en la red, tus solicitudes deben pasar por un servidor en Modo P2P en algún momento.
@@ -33,15 +33,13 @@ Los servidores en Modo P2P también pueden configurarse para proporcionar funcio

 Los servidores Modo P2P se conecta a [Mainnet](parallel-networks.md) por defecto.

-
 ### Servidores API

 Todos los servidores en Modo P2P proporcionan [APIs](../../references/http-websocket-apis/index.md) para propósitos como enviar transacciones, verificar balances y configuraciones, y administrar el servidor. Si consultas el XRP Ledger para obtener datos o enviar transacciones para uso comercial, puede ser útil [ejecutar tu propio servidor](index.md#razones-por-las-que-ejecutar-tu-propio-servidor).

 #### Servidores Full History

-A diferencia de algunas otras blockchains, el XRP Ledger no requiere que los servidores tengan un historial completo de transacciones para conocer el estado actual y procesar nuevas transacciones. Como operador de servidor, tú decides cuánto [histórico del ledger](ledger-history.md)  almacenar en un momento dado. Sin embargo, un servidor en Modo P2P solo puede responder a solicitudes de API utilizando el historial del ledger que tiene disponible localmente. Por ejemplo, si conservas seis meses de historial, tu servidor no puede describir el resultado de una transacción de hace un año. Los servidores API con histórico completo o [full history](ledger-history.md#full-history) pueden informar de todas las transacciones y balances desde el inicio del XRP Ledger.
-
+A diferencia de algunas otras blockchains, el XRP Ledger no requiere que los servidores tengan un historial completo de transacciones para conocer el estado actual y procesar nuevas transacciones. Como operador de servidor, tú decides cuánto [histórico del ledger](ledger-history.md) almacenar en un momento dado. Sin embargo, un servidor en Modo P2P solo puede responder a solicitudes de API utilizando el historial del ledger que tiene disponible localmente. Por ejemplo, si conservas seis meses de historial, tu servidor no puede describir el resultado de una transacción de hace un año. Los servidores API con histórico completo o [full history](ledger-history.md#full-history) pueden informar de todas las transacciones y balances desde el inicio del XRP Ledger.

 ### Hubs públicos

@@ -65,7 +63,6 @@ Puedes habilitar de forma segura la validación en un servidor que también se u

 Para más información sobre como ejecutar un validador, ver [Ejecutar `rippled` como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).

-
 ## Modo solitario

 En el modo solitario, el servidor opera sin conectarse a la red y sin participar en el proceso de consenso. Sin el proceso de consenso, debes avanzar manualmente el ledger y no se hace ninguna distinción entre "cerrado" y "validado" ledgers. Sin embargo, el servidor sigue proporcionando acceso a la API y procesa transacciones de la misma manera. Esto te permite:
@@ -74,11 +71,10 @@ En el modo solitario, el servidor opera sin conectarse a la red y sin participar
 - [Crear un nuevo ledger génesis](../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md) desde el inicio.
 - [Cargar una versión de ledger existente](../../infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md) desde el disco, luego reproducir transacciones específicas para recrear sus resultados y probar otras posibilidades.

-
 ## Ver también

 - **Tutoriales:**
-    - [Configurar `rippled`](../../infrastructure/configuration/index.md)
-    - [Usar rippled en modo solitario](../../infrastructure/testing-and-auditing/index.md)
+  - [Configurar `rippled`](../../infrastructure/configuration/index.md)
+  - [Usar rippled en modo solitario](../../infrastructure/testing-and-auditing/index.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md
@@ -2,8 +2,9 @@
 html: the-clio-server.html
 parent: networks-and-servers.html
 seo:
-    description: Clio es un servidor XRP Ledger optimizado para llamadas API.
+  description: Clio es un servidor XRP Ledger optimizado para llamadas API.
 ---
+
 # El servidor Clio

 Clio es un servidor API del XRP Ledger optimizado para llamadas de WebSocket o HTTP API para datos del ledger validados.
@@ -18,20 +19,19 @@ Mientras que Clio ofrece las [APIs HTTP / WebSocket](../../references/http-webso

 ## ¿Por qué debería ejecutar un servidor Clio?

-Hay multitud de razones por las que podrías querer ejecutar tu propio servidor Clio, pero la mayoría se pueden resumir en: carga reducida en el/los servidor(es) `rippled` conectado(s) a la red P2P, menor uso de memoria y sobrecarga de almacenamiento, escalabilidad horizontal más fácil y mayor rendimiento para las solicitudes API. 
+Hay multitud de razones por las que podrías querer ejecutar tu propio servidor Clio, pero la mayoría se pueden resumir en: carga reducida en el/los servidor(es) `rippled` conectado(s) a la red P2P, menor uso de memoria y sobrecarga de almacenamiento, escalabilidad horizontal más fácil y mayor rendimiento para las solicitudes API.

-* Carga reducida en el/los servidor(es) `rippled` - Un servidor Clio no se conecta a la red peer-to-peer. Utiliza gRPC para obtener datos validados de uno o más servidores `rippled` de confianza que están conectados a la red P2P. Por lo tanto, un servidor Clio maneja las solicitudes de manera más eficiente y reduce la carga en los servidores `rippled` que se ejecutan en modo P2P.
+- Carga reducida en el/los servidor(es) `rippled` - Un servidor Clio no se conecta a la red peer-to-peer. Utiliza gRPC para obtener datos validados de uno o más servidores `rippled` de confianza que están conectados a la red P2P. Por lo tanto, un servidor Clio maneja las solicitudes de manera más eficiente y reduce la carga en los servidores `rippled` que se ejecutan en modo P2P.

-* Menor uso de memoria y sobrecarga de almacenamiento - Clio utiliza Cassandra como base de datos y almacena datos en un formato eficiente en espacio, utilizando hasta 4 veces menos espacio que `rippled`.
+- Menor uso de memoria y sobrecarga de almacenamiento - Clio utiliza Cassandra como base de datos y almacena datos en un formato eficiente en espacio, utilizando hasta 4 veces menos espacio que `rippled`.

-* Escalabilidad horizontal más fácil - Múltiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio.
-
-* Mayor rendimiento para las solicitudes API - Un servidor Clio extrae datos validados de uno o más servidores `rippled` confiables y almacena estos datos de manera eficiente. Por lo tanto, maneja las llamadas API de manera eficiente, lo que resulta en un mayor rendimiento y, en algunos casos, una latencia más baja también.
+- Escalabilidad horizontal más fácil - Múltiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio.

+- Mayor rendimiento para las solicitudes API - Un servidor Clio extrae datos validados de uno o más servidores `rippled` confiables y almacena estos datos de manera eficiente. Por lo tanto, maneja las llamadas API de manera eficiente, lo que resulta en un mayor rendimiento y, en algunos casos, una latencia más baja también.

 ## ¿Cómo funciona un servidor Clio?

-[{% inline-svg file="/docs/img/clio-basic-architecture.svg" /%}](/docs/img/clio-basic-architecture.svg "Figura 1: ¿Cómo funciona un servidor Clio?")
+[{% inline-svg file="/docs/img/clio-basic-architecture.svg" /%}](/docs/img/clio-basic-architecture.svg 'Figura 1: ¿Cómo funciona un servidor Clio?')

 Cuando un servidor Clio almacena datos del ledger validados, como metadatos de transacciones, estados de cuentas y encabezados de ledger, en un almacén de datos persistente.

@@ -48,4 +48,4 @@ Clio **siempre** reenvía a `rippled` si alguna de las siguientes condiciones es

 - [Código fuente Clio](https://github.com/XRPLF/clio)
 - **Tutoriales:**
-    - [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)
+  - [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md
@@ -2,10 +2,11 @@
 html: transaction-censorship-detection.html
 parent: networks-and-servers.html
 seo:
-    description: El XRP Ledger proporciona un detector de censura de transacciones automatizado que está disponible en todos los servidores rippled.
+  description: El XRP Ledger proporciona un detector de censura de transacciones automatizado que está disponible en todos los servidores rippled.
 labels:
  - Blockchain
 ---
+
 # Detección de censura de transacciones

 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}Nuevo en: rippled 1.2.0{% /badge %}
@@ -14,8 +15,6 @@ El XRP Ledger está diseñado para ser resistente a la censura. En apoyo a este

 Mientras un servidor `rippled` está sincronizado con la red, el detector rastrea todas las transacciones que deberían haber sido aceptadas en la última ronda de [consensus](../consensus-protocol/index.md) e incluidas en el último ledger validado. El detector emite mensajes de registro de severidad creciente cuando ve transacciones que no han sido incluidas en un ledger validado después de varias rondas de consenso.

-
-
 ## ¿Cómo funciona?

 A alto nivel, así es cómo el detector de censura de transacciones funciona:
@@ -26,9 +25,9 @@ A alto nivel, así es cómo el detector de censura de transacciones funciona:

 3. El detector emite un [mensaje de advertencia](#ejemplo-de-mensaje-de-advertencia) en el registro para cualquier transacción que permanezca en el rastreador durante 15 ledgers, mostrándola como una transacción potencialmente censurada. La presencia de la transacción en el rastreador en este momento significa que no ha sido incluida en un ledger validado después de 15 rondas de consenso. Si la transacción permanece en el rastreador durante otros 15 ledgers, el detector emite otro mensaje de advertencia en el registro.

-    Mientras la transacción permanezca en el rastreador, el detector continuará emitiendo un mensaje de advertencia en el registro cada 15 ledgers, hasta cinco mensajes de advertencia. Después del quinto mensaje de advertencia, el detector emite un [mensaje de error](#ejemplo-de-mensaje-de-error) final en el registro y luego deja de emitir mensajes de advertencia y error.
+   Mientras la transacción permanezca en el rastreador, el detector continuará emitiendo un mensaje de advertencia en el registro cada 15 ledgers, hasta cinco mensajes de advertencia. Después del quinto mensaje de advertencia, el detector emite un [mensaje de error](#ejemplo-de-mensaje-de-error) final en el registro y luego deja de emitir mensajes de advertencia y error.

-    Si ves estos mensajes en el registro de tu servidor rippled, debes investigar por qué otros servidores no están incluyendo la transacción, comenzando con la suposición de que la causa es más probable que sea un [falso positivo](#potenciales-falsos-positivos) (error inocente) que una censura maliciosa.
+   Si ves estos mensajes en el registro de tu servidor rippled, debes investigar por qué otros servidores no están incluyendo la transacción, comenzando con la suposición de que la causa es más probable que sea un [falso positivo](#potenciales-falsos-positivos) (error inocente) que una censura maliciosa.

 ## Ejemplo de mensaje de advertencia

@@ -38,7 +37,6 @@ Esto es un ejemplo de mensaje de advertencia emitido por el detector de censura
 LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
 ```

-
 ## Ejemplo de mensaje de error

 Este es un ejemplo de mensaje de error emitido por el detector de censura de transacciones después de que la transacción E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 permaneciese en el rastreador por 75 ledgers (5 conjuntos de 15 ledgers), desde el ledger 18851530 hasta el ledger 18851605.
@@ -47,7 +45,6 @@ Este es un ejemplo de mensaje de error emitido por el detector de censura de tra
 LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
 ```

-
 ## Potenciales falsos positivos

 El detector de censura de transacciones puede emitir falsos positivos en ciertos escenarios. En este caso, un falso positivo significa que el detector ha marcado una transacción que ha permanecido en el rastreador durante 15 ledgers o más, pero por razones inocentes.
@@ -60,18 +57,17 @@ Aquí hay algunos escenarios que podrían causar que el detector emita mensajes

 - Los servidores en la red, incluido posiblemente tu propio servidor, tienen un error que les hace transmitir transacciones de manera inconsistente a otros servidores en la red.

-    Actualmente, no se conocen errores que causen este comportamiento inesperado. Sin embargo, si ves el impacto de lo que sospechas que es un error, considera reportarlo al programa [Ripple Bug Bounty](https://ripple.com/bug-bounty/).
-
+  Actualmente, no se conocen errores que causen este comportamiento inesperado. Sin embargo, si ves el impacto de lo que sospechas que es un error, considera reportarlo al programa [Ripple Bug Bounty](https://ripple.com/bug-bounty/).

 ## Ver también

 - **Conceptos:**
-    - [Principio de consenso y reglas](../consensus-protocol/consensus-principles-and-rules.md)
-    - [Cola de transacciones](../transactions/transaction-queue.md)
+  - [Principio de consenso y reglas](../consensus-protocol/consensus-principles-and-rules.md)
+  - [Cola de transacciones](../transactions/transaction-queue.md)
 - **Tutoriales:**
-    - [Envío confiable de transacciones](../transactions/reliable-transaction-submission.md)
-    - [Entendiendo los mensajes de registro](../../infrastructure/troubleshooting/understanding-log-messages.md)
+  - [Envío confiable de transacciones](../transactions/reliable-transaction-submission.md)
+  - [Entendiendo los mensajes de registro](../../infrastructure/troubleshooting/understanding-log-messages.md)
 - **Referencias:**
-    - [Resultados de transacciones](../../references/protocol/transactions/transaction-results/index.md)
+  - [Resultados de transacciones](../../references/protocol/transactions/transaction-results/index.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md
@@ -2,10 +2,11 @@
 html: bouncing-payments.html
 parent: payment-types.html
 seo:
-    description: Cuando el propósito de un pago no esté claro, devuélvelo al remitente.
+  description: Cuando el propósito de un pago no esté claro, devuélvelo al remitente.
 labels:
  - Tokens
 ---
+
 # Devolver pagos

 Cuando una de tus direcciones recibe un pago cuyo propósito no está claro, te recomendamos que intentes devolver el dinero a su remitente. Si bien esto requiere más trabajo que quedarse con el dinero, demuestra buena fe hacia los clientes. Puedes hacer que un operador rechace los pagos manualmente o crear un sistema para hacerlo automáticamente.
--- a/@l10n/es-ES/docs/concepts/payment-types/checks.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/checks.md
@@ -2,14 +2,14 @@
 html: checks.html
 parent: payment-types.html
 seo:
-    description: Los cheques permiten a los usuarios a crear pagos diferidos que pueden ser cancelados o cobrados por los destinatarios deliberados.
+  description: Los cheques permiten a los usuarios a crear pagos diferidos que pueden ser cancelados o cobrados por los destinatarios deliberados.
 labels:
  - Cheques
  - Pagos
  - Tokens
 ---
-# Cheques

+# Cheques

 La función de Cheques permite a los usuarios crear pagos aplazados similares a cheques en papel. A diferencia de un depósito en garantía (escrow) o canal de pago (payment channel), los fondos no se reservan cuando se crea un cheque, por lo que el dinero solo se mueve cuando se cobra el cheque. Si el remitente no tiene los fondos en el momento en que se cobra un cheque, la transacción falla; los destinatarios pueden intentar nuevamente las transacciones fallidas hasta que el cheque expire.

@@ -23,44 +23,41 @@ Los Cheques del XRP Ledger pueden tener tiempos de vencimiento después de los c

 - Cobros de cheques flexibles. El destnatario puede canjear el Cheque entre un nínimo y un máximo.

-
 ## Ciclo de vida de un cheque

 1. El remitente envía una [transacción CheckCreate][], que define:
-    - El destinatario.
-    - Una fecha de caducidad.
-    - La cantidad máxima que se puede cargar de su cuenta.
+   - El destinatario.
+   - Una fecha de caducidad.
+   - La cantidad máxima que se puede cargar de su cuenta.

-2. Cuando una transacción es procesada, el XRP Ledger crea un objeto `Check`. El cheque puede ser cancelado por el destinatario o el remitente con una  [transacción CheckCancel][].
+2. Cuando una transacción es procesada, el XRP Ledger crea un objeto `Check`. El cheque puede ser cancelado por el destinatario o el remitente con una [transacción CheckCancel][].

 3. El destinatario envía una [transacción CheckCash][] que transfiere los fondos y destruye el objeto `Check`. Los destinatarios tienen dos opciones para cobrar los cheques:
-    -  Cantidad exacta: Se especifica la cantidad exacta de dinero a cobrar que no puede exceder el máximo del cheque.
-    - Cantidad flexible: Se especifica una cantidad mínima para cobrar y el XRP Ledger manda tanto como sea posible hasta el máximo del cheque. Si el remitente no tiene fondos para cumplir al menos el mínimo específicado, la transacción falla.
+   - Cantidad exacta: Se especifica la cantidad exacta de dinero a cobrar que no puede exceder el máximo del cheque.
+   - Cantidad flexible: Se especifica una cantidad mínima para cobrar y el XRP Ledger manda tanto como sea posible hasta el máximo del cheque. Si el remitente no tiene fondos para cumplir al menos el mínimo específicado, la transacción falla.

 4. Si el cheque vence antes de que el destinatario lo cobre, el objeto `Check` permanece hasta que alguien lo cancele.

-
-
 ## Ver también

 Para más información sobre Cheques en el XRP Ledger, ver:

 - [Referencia transacción](../../references/protocol/transactions/types/index.md)
-    - [CheckCreate][]
-    - [CheckCash][]
-    - [CheckCancel][]
+  - [CheckCreate][]
+  - [CheckCash][]
+  - [CheckCancel][]
 - [Tutoriales de cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/index.md)
-    - [Enviar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
-    - [Buscar cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks.md)
-    - [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)
+  - [Enviar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
+  - [Buscar cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks.md)
+  - [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)
 - [Enmienda Cheques][]

 Para más información sobre funciones relacionadas, ver:

-* [Autorización de deposito](../accounts/depositauth.md)
-* [Escrow](escrow.md)
-* [Tutorial de canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
+- [Autorización de deposito](../accounts/depositauth.md)
+- [Escrow](escrow.md)
+- [Tutorial de canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md
@@ -2,41 +2,39 @@
 html: cross-currency-payments.html
 parent: payment-types.html
 seo:
-    description: Los pagos entre divisas entregan atómicamente una moneda diferente a la que envían mediante la conversión a través de rutas y libros de pedidos.
+  description: Los pagos entre divisas entregan atómicamente una moneda diferente a la que envían mediante la conversión a través de rutas y libros de pedidos.
 labels:
  - Entre divisas
  - Pagos
 ---
+
 # Pagos entre divisas

 El XRP Ledger te permite realizar pagos entre divisas de XRP y tokens. Los pagos entre divisas dentro del XRP Ledger son complétamente atómicos, lo que quiere decir que el pago se ejecuta por completo o no se ejecuta en absoluto.

 Por defecto, los pagos entre divisas entregan una cantidad fija a su destino a un coste variable para su origen. Los pagos entre divisas también pueden ser [pagos parciales](partial-payments.md) que entregan una cantidad variable dentro de un límite de envío establecido.

-
 ## Prerrequisitos

 - Por definición, un pago entre divisas implica al menos dos monedas, lo que significa que al menos una fivisa involucrada debe ser un [token](../tokens/index.md) que no sea XRP.
 - Debe existir al menos una ruta o [Path](../tokens/fungible-tokens/paths.md) entre el remitente y el receptor, y la liquidez total a lo largo de todas las rutas debe ser suficiente para ejecutar el pago. Los pagos entre divisas se convierten de una divisa a otra consumiendo ofertas u [Offers](../tokens/decentralized-exchange/offers.md) en el [exchange descentralizado](../tokens/decentralized-exchange/index.md) del XRP Ledger.

-
 ## Auto-puente

 Los pagos entre divisas que intercambian un token por otro token pueden utilizar automáticamente XRP como puente entre los tokens, cuando esto reduce el coste del pago. Por ejemplo, un pago que envía de USD a MXN convierte automáticamente USD a XRP y luego XRP a MXN si hacerlo es más barato que convertir USD a MXN diréctamente. Operaciones más grandes pueden utilizar una combinación de conversiones directas (USD-MXN) y puentes automáticos (USD-XRP-MXN).

 Para más información, ver auto-puente o [Auto-Bridging](../tokens/decentralized-exchange/autobridging.md).

-
 ## Ver también

 - **Conceptos:**
-    - [Tokens](../tokens/index.md)
-    - [Exchange descentralizado](../tokens/decentralized-exchange/index.md)
-    - [Paths](../tokens/fungible-tokens/paths.md)
+  - [Tokens](../tokens/index.md)
+  - [Exchange descentralizado](../tokens/decentralized-exchange/index.md)
+  - [Paths](../tokens/fungible-tokens/paths.md)
 - **References:**
-    - [Tipos de transacciones de pago][Payment transaction]
-    - [método path_find][]
-    - [método ripple_path_find][]
-    - [Interpretando metadatos de pagos entre divisas](../transactions/finality-of-results/look-up-transaction-results.md#token-payments)
+  - [Tipos de transacciones de pago][Payment transaction]
+  - [método path_find][]
+  - [método ripple_path_find][]
+  - [Interpretando metadatos de pagos entre divisas](../transactions/finality-of-results/look-up-transaction-results.md#token-payments)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md
@@ -2,48 +2,44 @@
 html: direct-xrp-payments.html
 parent: payment-types.html
 seo:
-    title: Pagos directos en XRP
-    description: Los pagos directos en XRP son la forma más rápida y sencilla de enviar valor en el XRP Ledger. Conoce ahora los conceptos básicos del ciclo de vida de pago directo en XRP.
+  title: Pagos directos en XRP
+  description: Los pagos directos en XRP son la forma más rápida y sencilla de enviar valor en el XRP Ledger. Conoce ahora los conceptos básicos del ciclo de vida de pago directo en XRP.
 labels:
  - XRP
  - Pagos
 ---
+
 # Pagos directos en XRP

 La base de cualquier sistema financiero es la transferencia de valor. El método más rápido y sencillo en el XRP Ledger es un pago directo en XRP de una cuenta a otra. A diferencia de otros métodos de pago que requieren múltiples transacciones para completarse, un pago directo en XRP se ejecuta en una sola transacción sin intermediarios, y típicamente se completa en 8 segundos o menos. Solo puedes hacer pagos directos cuando XRP es la moneda enviada y recibida.

-
-
 ## Ciclo de vida de pagos XRP directos

 1. El remitente crea una [transacción Payment][], que define los parámetros del pago. La transacción es un pago directo en XRP si XRP es la divisa enviada y recibida.

 2. El procesamiento de la transacción verifica los parámetros y circunstancias de la transacción; si la comprobación falla, el pago falla.
+   - Todos los campos están formateados correctamente.
+   - La dirección de envío es una cuenta activada en el XRP Ledger.
+   - Todas las firmas proporcionadas son válidas para la dirección de envío.
+   - La dirección de destino es diferente que la dirección de envío.
+   - El remitente tiene suficiente XRP en balance para enviar el pago.

-    - Todos los campos están formateados correctamente.
-    - La dirección de envío es una cuenta activada en el XRP Ledger.
-    - Todas las firmas proporcionadas son válidas para la dirección de envío.
-    - La dirección de destino es diferente que la dirección de envío.
-    - El remitente tiene suficiente XRP en balance para enviar el pago.
-
-2. El procesamiento del pago comprueba la dirección de destino; si alguna comprobación falla, el pago falla.
-
-    - Si la dirección de recepción está activada, el motor hace comprobaciones adicionales basados en sus configuraciones, como la autorización de depósito o [Deposit Authorization](../accounts/depositauth.md).
-    - Si la dirección de recepción no está activada, comprueba si el pago enviará suficiente XRP para cumplir con el mínimo del requisito de la [reserva de cuenta](../accounts/reserves.md). Si la reserva se cumple, una nueva cuenta es creada para la dirección y el balance inicial es la cantidad recibida.
+3. El procesamiento del pago comprueba la dirección de destino; si alguna comprobación falla, el pago falla.
+   - Si la dirección de recepción está activada, el motor hace comprobaciones adicionales basados en sus configuraciones, como la autorización de depósito o [Deposit Authorization](../accounts/depositauth.md).
+   - Si la dirección de recepción no está activada, comprueba si el pago enviará suficiente XRP para cumplir con el mínimo del requisito de la [reserva de cuenta](../accounts/reserves.md). Si la reserva se cumple, una nueva cuenta es creada para la dirección y el balance inicial es la cantidad recibida.

 4. El ledger quita y acredita a las correspondientes cuentas.
-    
-    **Nota:** Al remitente también se le carga el [coste de transacción](../transactions/transaction-cost.md) en XRP.
-    
+
+   **Nota:** Al remitente también se le carga el [coste de transacción](../transactions/transaction-cost.md) en XRP.

 ## Ver también

 - **Tutoriales:**
-    - [Enviar XRP (Tutorial interactivo)](../../tutorials/how-tos/send-xrp.md)
-    - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+  - [Enviar XRP (Tutorial interactivo)](../../tutorials/how-tos/send-xrp.md)
+  - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
 - **Referencias:**
-    - [Transacción Payment][]
-    - [Resultados de Transaction](../../references/protocol/transactions/transaction-results/index.md)
-    - [método account_info][] - para comprobar balances en XRP
+  - [Transacción Payment][]
+  - [Resultados de Transaction](../../references/protocol/transactions/transaction-results/index.md)
+  - [método account_info][] - para comprobar balances en XRP

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/escrow.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/escrow.md
@@ -2,10 +2,11 @@
 html: escrow.html
 parent: payment-types.html
 seo:
-    description: El Escrow retiene fondos hasta que las condiciones específicas se cumplan.
+  description: El Escrow retiene fondos hasta que las condiciones específicas se cumplan.
 labels:
  - Escrow
 ---
+
 # Escrow

 Tradicionalmente, un escrow es un contrato entre dos partes para facilitar transacciones financieras. Un tercero imparcial recibe y retiene los fondos, y solo los libera al destinatario previsto cuando se cumplen las condiciones especificadas en el contrato. Este método asegura que ambas partes cumplan con sus obligaciones.
@@ -23,16 +24,15 @@ El XRP Ledger soporta tres tipos de escrow:
 ## Ciclo de vida de un escrow

 1. El remitente crea un escrow utilizando la transacción `EscrowCreate`. Esta transacción define:
-
-    - Una cantidad de XRP para bloquear.
-    - Las condiciones para liberar el XRP.
-    - El destinatario del XRP.
+   - Una cantidad de XRP para bloquear.
+   - Las condiciones para liberar el XRP.
+   - El destinatario del XRP.

 2. Cuando se procesa la transacción, el XRP Ledger crea un objeto `Escrow` que retiene el XRP en el escrow.

 3. El destinatario envía una transacción `EscrowFinish` para entregar el XRP. Si las condiciones se han cumplido, esto destruye el objeto `Escrow` y entrega el XRP al destinatario.

-    **Nota:** Si el escrow tiene una fecha de caducidad y no se completa con éxito antes de este tiempo, el escrow se caduca. Un escrow caducado permanece en el ledger hasta que una transacción `EscrowCancel` lo cancele, destruyendo el objeto `Escrow` y devuelve el XRP al remitente.
+   **Nota:** Si el escrow tiene una fecha de caducidad y no se completa con éxito antes de este tiempo, el escrow se caduca. Un escrow caducado permanece en el ledger hasta que una transacción `EscrowCancel` lo cancele, destruyendo el objeto `Escrow` y devuelve el XRP al remitente.

 ## Estados del escrow

@@ -48,18 +48,16 @@ El diagrama muestra tres casos diferentes para tres posibles combinaciones de lo

 - **Escrow condicional (derecha):** Si el escrow especifica una criptocondición (campo `Condition`) y no por una fecha "terminar trás", el escrow se convierte en **Condicionalmente preparado** inmediatamente cuando se crea. Durante este tiempo, cualquiera puede finalizar el escrow, pero solo si suministran el cumplimiento correcto a la criptocondición. Si nadie finaliza el escrow antes de la fecha de caducidad (campo `CancelAfter`), el escrow se convierte en **Caducado**. (Un escrow sin una fecha de "finalizar-tras" _debe_ tener una fecha de caducidad.) En el estado de caducado, el escrow no puede ser finalizado, y cualquiera puede cancelarlo.

-
 ## Limitaciones

 - El escrow solo funciona con XRP, no con tokens.
 - Los costes pueden hacerlo poco práctico para cantidades pequeñas.
-    - El escrow requiere de dos transacciones: una para crear el escrow, y una para finalizarlo o cancelarlo. Las criptocondiciones incurren en un [coste de transacción](../transactions/transaction-cost.md) mayor al usual.
-    - Mientras que el escrow no se completa, el remitente es responsable del [requisito de reserva](../accounts/reserves.md) del objeto del `Escrow`.
+  - El escrow requiere de dos transacciones: una para crear el escrow, y una para finalizarlo o cancelarlo. Las criptocondiciones incurren en un [coste de transacción](../transactions/transaction-cost.md) mayor al usual.
+  - Mientras que el escrow no se completa, el remitente es responsable del [requisito de reserva](../accounts/reserves.md) del objeto del `Escrow`.
 - No puedes crear un escrow con valores de fechas pasados.
 - Las liberaciones y caducidad se resuelven en [tiempos de cierre de ledgers](../ledgers/ledger-close-times.md). En la práctica, los tiempos de liberaciones o caducidad pueden variar en 5 segundos respecto a los cierres de ledgers.
 - El único tipo de criptocondición aceptado es PREIMAGE-SHA-256.

-
 ## Coste de la transacción EscrowFinish

 Cuando uses criptocondiciones, la transacción EscrowFinish debe pagar un [mayor coste de transacción](../transactions/transaction-cost.md#special-transaction-costs) por la carga de procesamiento involucrada en la verificación de la criptocondición introducida.
@@ -76,20 +74,17 @@ Si el [coste de votar](../consensus-protocol/fee-voting.md) cambia el valor de `
 reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
 ```

-
-
 ## Ver también

 Para más información sobre Escrow en el XRP Ledger, consulta lo siguiente:

 - [Tutoriales Escrow](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)
 - [Referencia de transacciones](../../references/protocol/transactions/index.md)
-    - [Transacción EscrowCreate][]
-    - [Transacción EscrowFinish][]
-    - [Transacción EscrowCancel][]
+  - [Transacción EscrowCreate][]
+  - [Transacción EscrowFinish][]
+  - [Transacción EscrowCancel][]
 - [Referencia Ledger](../../references/protocol/ledger-data/index.md)
-    - [Objeto Escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
-
+  - [Objeto Escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)

 Para más información sobre el bloqueo de 55 mil millones de Ripple, consulta [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/).

--- a/@l10n/es-ES/docs/concepts/payment-types/index.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/index.md
@@ -4,13 +4,12 @@ parent: concepts.html
 metadata:
  indexPage: true
 seo:
-    title: Point-to-Point & Specialized Ledger Payment Types
-    description: Mientras que el XRP Ledger admite pagos XRP de punto a punto, también es compatible con tipos de pago más especializados. Descubre qué métodos de pago del ledger aquí.
+  title: Point-to-Point & Specialized Ledger Payment Types
+  description: Mientras que el XRP Ledger admite pagos XRP de punto a punto, también es compatible con tipos de pago más especializados. Descubre qué métodos de pago del ledger aquí.
 ---
-# Ledger Payment Types

+# Ledger Payment Types

 El XRP Ledger admite pagos de XRP de punto a punto junto con otros tipos de pago más especializados.

-
 {% child-pages /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/partial-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/partial-payments.md
@@ -2,11 +2,12 @@
 html: partial-payments.html
 parent: payment-types.html
 seo:
-    description: Los pagos parciales restan costes a la cantidad enviada, entregando una cantidad flexible. Los pagos parciales son útiles para devolver pagos no deseados sin incurrir en costes adicionales.
+  description: Los pagos parciales restan costes a la cantidad enviada, entregando una cantidad flexible. Los pagos parciales son útiles para devolver pagos no deseados sin incurrir en costes adicionales.
 labels:
  - Pagos
  - Seguridad
 ---
+
 # Pagos parciales

 El remitente de cualquier [transacción de pago][] puede habilitar el [flag de"Partial Payment"](../../references/protocol/transactions/types/payment.md#payment-flags) y enviar un pago que entregue menos de lo que indica el campo `Amount`. Al procesar cualquier Pago, utiliza el campo de metadatos `delivered_amount`, no el campo `Amount`. El `delivered_amount` es la cantidad que un pago realmente entregó.
@@ -51,7 +52,7 @@ Los pagos parciales tienen las siguientes limitaciones:

 - Un pago parcial no puede proporcionar el XRP para crear una dirección; en este caso se devuelve el [código de resultado][] `telNO_DST_PARTIAL`.
 - Pagos directoss de XRP a XRP no pueden ser pagos parciales; este caso devuelve el [código de resultado][] `temBAD_SEND_XRP_PARTIAL`.
-    - Sin embargo, los pagos entre divisas que involucran a XRP como una de las divisas _pueden_ ser pagos parciales.
+  - Sin embargo, los pagos entre divisas que involucran a XRP como una de las divisas _pueden_ ser pagos parciales.

 [código de resultado]: ../../references/protocol/transactions/transaction-results/index.md

@@ -70,15 +71,15 @@ Si ambas condiciones son verdaderas, entonces `delivered_amount` contiene el val

 Puedes encontrar el campo `delivered_amount` en los siguientes lugares:

-| API | Método | Campo |
-|-----|--------|-------|
-| [JSON-RPC / WebSocket][] | [método account_tx][] | `result.transactions` miembros del array `meta.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [método tx][] | `result.meta.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [método transaction_entry][] | `result.metadata.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [método ledger][] (con las transacciones ampliadas) | `result.ledger.transactions` miembros del array `metaData.delivered_amount` |
-| [WebSocket][] | [subscripciones Transaction](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Mensajes de subscripción de `meta.delivered_amount` |
-| ripple-lib v1.x | método `getTransaction` | `outcome.deliveredAmount` |
-| ripple-lib v1.x | método `getTransactions` | miembros del array `outcome.deliveredAmount` |
+| API                      | Método                                                                                                                                      | Campo                                                                       |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| [JSON-RPC / WebSocket][] | [método account_tx][]                                                                                                                       | `result.transactions` miembros del array `meta.delivered_amount`            |
+| [JSON-RPC / WebSocket][] | [método tx][]                                                                                                                               | `result.meta.delivered_amount`                                              |
+| [JSON-RPC / WebSocket][] | [método transaction_entry][]                                                                                                                | `result.metadata.delivered_amount`                                          |
+| [JSON-RPC / WebSocket][] | [método ledger][] (con las transacciones ampliadas)                                                                                         | `result.ledger.transactions` miembros del array `metaData.delivered_amount` |
+| [WebSocket][]            | [subscripciones Transaction](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Mensajes de subscripción de `meta.delivered_amount`                         |
+| ripple-lib v1.x          | método `getTransaction`                                                                                                                     | `outcome.deliveredAmount`                                                   |
+| ripple-lib v1.x          | método `getTransactions`                                                                                                                    | miembros del array `outcome.deliveredAmount`                                |

 [WebSocket]: ../../references/http-websocket-apis/index.md
 [JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
@@ -89,18 +90,17 @@ Si la integración de una institución financiera con el XRP Ledger asume que el

 **La forma correcta de procesar las transacciones de Pago entrantes es utilizar [el campo `delivered_amount` de los metadatos](#the-delivered_amount-field),** no el campo `Amount`. De este modo, una institución nunca se equivocará sobre cuanto recibe _realmente_.

-
 ### Pasos del escenario del Exploit

 Para realizar un exploit a una institución financiera vulnerable, un actor malicioso puede hacer lo siguiente:

-1. El actor malicioso envía una transacción de Pago a la institución. Esta transacción tiene un campo  `Amount` grande y tiene el flag de **`tfPartialPayment`** activado.
+1. El actor malicioso envía una transacción de Pago a la institución. Esta transacción tiene un campo `Amount` grande y tiene el flag de **`tfPartialPayment`** activado.
 2. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero en realidad entrega una cantidad muy pequeña de la divisa especificada.
 3. La institución vulnerable lee el campo `Amount` sin mirar el campo `Flags` o el campo de metadatos `delivered_amount`.
 4. La institutución vulnerable acredita al actor malicioso en un sistema externo, como el propio ledger de la institución, por el `Amount` completo, a pesar de recibir solo un `delivered_amount` pequeño en el XRP Ledger.
 5. El actor malicioso retira tanto saldo como sea posible antes de que la institución vulnerable note la discrepancia.
-    - Los actores maliciosos suelen preferir convertir el saldo a otra criptomoneda como Bitcoin, porque las transacciones de blockchain suelen ser irreversibles. Con un retiro a un sistema de moneda fiduciaria, la institución financiera podría revertir o cancelar la transacción varios días después de que se ejecute inicialmente.
-    - En el caso de un exchange, el actor malicioso también puede retirar un saldo de XRP directamente de nuevo al XRP Ledger.
+   - Los actores maliciosos suelen preferir convertir el saldo a otra criptomoneda como Bitcoin, porque las transacciones de blockchain suelen ser irreversibles. Con un retiro a un sistema de moneda fiduciaria, la institución financiera podría revertir o cancelar la transacción varios días después de que se ejecute inicialmente.
+   - En el caso de un exchange, el actor malicioso también puede retirar un saldo de XRP directamente de nuevo al XRP Ledger.

 En el caso de un comerciante, el orden de las operaciones es ligeramente diferente, pero el concepto es el mismo:

@@ -119,22 +119,21 @@ Utilizar [el campo `delivered_amount`](#the-delivered_amount-field) al procesar
 - Añade chequeos adicionales a la lógica de tu negocio para procesar los retiros. Nunca proceses un retiro si el balance total que tienes en el XRP Ledger no coincide con tus activos y obligaciones esperados.
 - Sigue las directrices "Know Your Customer" y verifica estrictamente las identidades de tus clientes. Puede que reconozcas y bloquees usuarios maliciosos de antemano, o emprender acciones legales contra el actor malicioso que genera exploits a tu sistema.

-
 ## Ver también

 - **Herramientas:**
-    - [Remitente de la transacción](/resources/dev-tools/tx-sender)
+  - [Remitente de la transacción](/resources/dev-tools/tx-sender)
 - **Conceptos:**
-    - [Transacciones](../transactions/index.md)
+  - [Transacciones](../transactions/index.md)
 - **Tutoriales:**
-    - [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md)
-    - [Monitorear pagos recibidos con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
-    - [Usar tipos de pagos especializados](../../tutorials/how-tos/use-specialized-payment-types/index.md)
-    - [Listar XRP en un Exchange](../../use-cases/defi/list-xrp-as-an-exchange.md)
+  - [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md)
+  - [Monitorear pagos recibidos con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+  - [Usar tipos de pagos especializados](../../tutorials/how-tos/use-specialized-payment-types/index.md)
+  - [Listar XRP en un Exchange](../../use-cases/defi/list-xrp-as-an-exchange.md)
 - **Referencias:**
-    - [Transacción de Pago][]
-    - [Metadatos de transacción](../../references/protocol/transactions/metadata.md)
-    - [método account_tx][]
-    - [método tx][]
+  - [Transacción de Pago][]
+  - [Metadatos de transacción](../../references/protocol/transactions/metadata.md)
+  - [método account_tx][]
+  - [método tx][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/payment-channels.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/payment-channels.md
@@ -2,11 +2,12 @@
 html: payment-channels.html
 parent: payment-types.html
 seo:
-    description: Los canales de pago que activan pagos XRP asíncronos rápidos que pueden dividirse en incrementos muy pequeños y liquidarse más después.
+  description: Los canales de pago que activan pagos XRP asíncronos rápidos que pueden dividirse en incrementos muy pequeños y liquidarse más después.
 labels:
  - Canales de pago
  - Smart Contracts
 ---
+
 # Canales de pago

 Los Canales de Pago son una función avanzada para enviar pagos de XRP "asíncronos" que pueden dividirse en incrementos muy pequeños y liquidarse más tarde.
@@ -15,7 +16,6 @@ El XRP para un canal de pago se reserva temporalmente. El remitente crea reclama

 Debido a que las reclamaciones pueden verificarse individualmente pero liquidarse en bloque más adelante, los canales de pago hacen posible realizar transacciones a una velocidad limitada solo por la capacidad de los participantes para crear y verificar las firmas digitales de esas Reclamaciones. Este límite se basa principalmente en la velocidad del hardware de los participantes y la complejidad de los algoritmos de firma. Para obtener la máxima velocidad, utiliza firmas Ed25519, que son más rápidas que las firmas ECDSA secp256k1 predeterminadas del XRP Ledger. La investigación ha [demostrado la capacidad de crear más de 100.000 firmas Ed25519 por segundo y verificar más de 70.000 por segundo](https://ed25519.cr.yp.to/ed25519-20110926.pdf) en hardware estándar en 2011.

-
 ## ¿Por qué usar canales de pago?

 El proceso de usar un canal de pago siempre implica dos partes, un pagador y un beneficiario. El pagador es una persona o institución que utiliza el XRP Ledger y es cliente del beneficiario. El beneficiario es una persona o empresa que recibe XRP como pago por bienes o servicios.
@@ -26,27 +26,25 @@ Los Canales de Pago no especifican intrínsecamente nada sobre lo que puedes com
 - Cosas baratas, donde el coste de procesar una transacción es una parte no trivial del precio
 - Cosas que normalmente se compran en bloque, donde la cantidad exacta deseada no se conoce de antemano

-
 ## Ciclo de vida de un canal de pago

 El siguiente diagrama resume el ciclo de vida de un canal de pago:

-[{% inline-svg file="/docs/img/paychan-flow.svg" /%}](/docs/img/paychan-flow.svg "Diagrama de flujo de un canal de pago")
-
+[{% inline-svg file="/docs/img/paychan-flow.svg" /%}](/docs/img/paychan-flow.svg 'Diagrama de flujo de un canal de pago')

 ## Ver también

 - **Conceptos relacionados:**
-    - [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
+  - [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/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)
 - **Referencias:**
-    - [Método channel_authorize][]
-    - [Método channel_verify][]
-    - [Objeto PayChannel](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)
-    - [Transacción PaymentChannelClaim][]
-    - [Transacción PaymentChannelCreate][]
-    - [Transacción PaymentChannelFund][]
+  - [Método channel_authorize][]
+  - [Método channel_verify][]
+  - [Objeto PayChannel](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)
+  - [Transacción PaymentChannelClaim][]
+  - [Transacción PaymentChannelCreate][]
+  - [Transacción PaymentChannelFund][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md
@@ -2,26 +2,27 @@
 html: robustly-monitoring-for-payments.html
 parent: payment-types.html
 seo:
-    description: Recomendaciones para monitorizar pagos entrantes de una variedad e posibles irregularidades.
+  description: Recomendaciones para monitorizar pagos entrantes de una variedad e posibles irregularidades.
 labels:
  - Tokens
 ---
+
 # Monitoreo robusto de pagos

 Para verificar robustamente los pagos entrantes, los emisores deberían hacer lo siguiente:

-* Mantener un registro de la transacción y el ledger más recientemente procesados. De esta manera, si pierdes temporalmente la conectividad, sabrás hasta dónde retroceder.
-* Verificar el código de resultado de cada pago entrante. Algunos pagos ingresan al ledger para cobrar una tarifa contra el spam, incluso si fallan. Solo las transacciones con el código de resultado `tesSUCCESS` pueden cambiar saldos que no sean de XRP. Solo las transacciones de un ledger validado son definitivas.
-* Mirar los [pagos parciales](partial-payments.md). Los pagos con el flag de pago parcial activado pueden ser condierados "exitosos" si se entrega cualquier cantidad distinta a cero, incluso cantidades minúsculas.
-    * Comprobar la transacción en busca del [campo `delivered_amount`](partial-payments.md#el-campo-delivered_amount). Si está presente, el campo indica cuanto dinero _realmente_ se envió a la dirección `Destination`.
-    * En xrpl.js, puedes usar el [método `xrpl.getBalanceChanges()`](https://js.xrpl.org/modules.html#getBalanceChanges) para ver cuánto recibió cada dirección. En algunos casos, esto puede dividirse en varias partes en diferentes líneas de confianza (trustlines).
-* Algunas transacciones cambian tus balances sin ser pagos directos hacia o desde una de tus direcciones.
+- Mantener un registro de la transacción y el ledger más recientemente procesados. De esta manera, si pierdes temporalmente la conectividad, sabrás hasta dónde retroceder.
+- Verificar el código de resultado de cada pago entrante. Algunos pagos ingresan al ledger para cobrar una tarifa contra el spam, incluso si fallan. Solo las transacciones con el código de resultado `tesSUCCESS` pueden cambiar saldos que no sean de XRP. Solo las transacciones de un ledger validado son definitivas.
+- Mirar los [pagos parciales](partial-payments.md). Los pagos con el flag de pago parcial activado pueden ser condierados "exitosos" si se entrega cualquier cantidad distinta a cero, incluso cantidades minúsculas.
+  - Comprobar la transacción en busca del [campo `delivered_amount`](partial-payments.md#el-campo-delivered_amount). Si está presente, el campo indica cuanto dinero _realmente_ se envió a la dirección `Destination`.
+  - En xrpl.js, puedes usar el [método `xrpl.getBalanceChanges()`](https://js.xrpl.org/modules.html#getBalanceChanges) para ver cuánto recibió cada dirección. En algunos casos, esto puede dividirse en varias partes en diferentes líneas de confianza (trustlines).
+- Algunas transacciones cambian tus balances sin ser pagos directos hacia o desde una de tus direcciones.

 Para simplificar las cosas para tus clientes, te recomendamos aceptar pagos tanto en tu dirección operacional como en tus direcciones de emisoras.

 Como precaución adicional, te recomendamos comparar los balances de tus direcciones emisoras con los fondos de garantía en tu sistema de contabilidad interna en cada nueva versión del ledger del XRP Ledger. Los saldos negativos de la dirección emisora deben coincidir con los activos que has asignado al XRP Ledger fuera de la red. Si ambos no coinciden, deberías suspender el procesamiento de pagos hacia y desde el XRP Ledger hasta que hayas resuelto la discrepancia.

-* Utiliza el método `gateway_balances` para comprobar tus balances.
-* Si tienes un coste de transferencia (transfer fee) establecido, entonces tus obligaciones dentro del XRP Ledger disminuyen ligeramente cada vez que otras direcciones del XRP Ledger transfieran tus tokens entre sí.
+- Utiliza el método `gateway_balances` para comprobar tus balances.
+- Si tienes un coste de transferencia (transfer fee) establecido, entonces tus obligaciones dentro del XRP Ledger disminuyen ligeramente cada vez que otras direcciones del XRP Ledger transfieran tus tokens entre sí.

 Para más detalles en cómo se leen los detalles de transacciones entrantes, visita [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md).
--- a/@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md
@@ -2,10 +2,11 @@
 html: sending-payments-to-customers.html
 parent: payment-types.html
 seo:
-    description: Construye los pagos con cuidado para frustrar a los actores maliciosos.
+  description: Construye los pagos con cuidado para frustrar a los actores maliciosos.
 labels:
  - Tokens
 ---
+
 # Enviar pagos a clientes

 Cuando construyes un sistema automatizado para enviar pagos al XRP Ledger para tus clientes, debes asegurarte de que construyes los pagos cuidadosamente. Los actores maliciosos están constantemente tratando de encontrar formas de engañar a un sistema para que les pague más dinero del que debería.
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md
@@ -2,14 +2,15 @@
 html: autobridging.html
 parent: decentralized-exchange.html
 seo:
-    description: El puente automático conecta automáticamente los libros de órdenes utilizando XRP como intermediario cuando reduce los costes.
+  description: El puente automático conecta automáticamente los libros de órdenes utilizando XRP como intermediario cuando reduce los costes.
 labels:
  - XRP
  - Exchange Descentralizado
 ---
+
 # Puente automático

-Cualquier [Oferta](offers.md) en el [exchange descentralizado](index.md) del XRP Ledger que intercambie dos tokens podría potencialmente utilizar XRP como moneda intermediaria en un libro de órdenes sintético. Esto se debe al _puente automático_, que sirve para mejorar la liquidez en todos los pares de activos utilizando XRP cuando es más barato que intercambiar directamente. Esto funciona debido a la naturaleza de XRP como criptomoneda nativa del  XRP Ledger. La ejecución de la oferta puede utilizar una combinación de ofertas directas y ofertas auto-puenteadas para lograr la mejor tasa de cambio total.
+Cualquier [Oferta](offers.md) en el [exchange descentralizado](index.md) del XRP Ledger que intercambie dos tokens podría potencialmente utilizar XRP como moneda intermediaria en un libro de órdenes sintético. Esto se debe al _puente automático_, que sirve para mejorar la liquidez en todos los pares de activos utilizando XRP cuando es más barato que intercambiar directamente. Esto funciona debido a la naturaleza de XRP como criptomoneda nativa del XRP Ledger. La ejecución de la oferta puede utilizar una combinación de ofertas directas y ofertas auto-puenteadas para lograr la mejor tasa de cambio total.

 Ejemplo: _Anita crea una oferta para vender GBP y comprar BRL. Ella podría encontrar que este mercado poco común tiene pocas ofertas. Hay una oferta con una buena tasa, pero tiene una cantidad insuficiente para satisfacer el intercambio de Anita. Sin embargo, tanto GBP como BRL tienen mercados activos y competitivos para XRP. El sistema de puente automático del XRP Ledger encuentra una forma de completar la oferta de Anita comprando XRP con GBP de un trader, luego vendiendo el XRP a otro trader para comprar BRL. Anita obtiene automáticamente la mejor tasa posible combinando la pequeña oferta en el mercado directo de GBP:BRL con las mejores tasas compuestas creadas emparejando las ofertas GBP:XRP y XRP:BRL._ <!-- SPELLING_IGNORE: gbp -->

--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
@@ -2,13 +2,14 @@
 html: automated-market-makers.html
 parent: decentralized-exchange.html
 seo:
-    title: ¿Qué es un Automated Market Maker (AMM)?
-    description: Los Automated Market Makers (AMMs) son una parte esencial de las criptomonedas, proveen liquidez entre dos pares de activos. Aprende más sobre AMMs y el XRP Ledger.
+  title: ¿Qué es un Automated Market Maker (AMM)?
+  description: Los Automated Market Makers (AMMs) son una parte esencial de las criptomonedas, proveen liquidez entre dos pares de activos. Aprende más sobre AMMs y el XRP Ledger.
 labels:
  - XRP
  - Exchange Descentralizado
  - AMM
 ---
+
 # ¿Qué es un Automated Market Maker (AMM)?

 _(Requiere la [enmienda AMM][] XLS-30)_
@@ -43,9 +44,10 @@ Para evitar el mal uso, se aplican algunas restricciones a los activos utilizado
 - Si el activo es un token cuyo emisor utiliza [Authorized Trust Lines](../fungible-tokens/authorized-trust-lines.md), el creador del AMM debe estar autorizado para poseer esos tokens. Solo los usuarios cuyas líneas de confianza (trustlines) estén autorizadas pueden depositar ese token en el AMM o retirarlo; sin embargo, los usuarios aún pueden depositar o retirar el otro activo.
 - Si la [enmienda Clawback][] está habilitada, el emisor del token no debe haber habilitado la capacidad de recuperar sus tokens.

-
 ## Tokens LP
+
 <!-- TODO: add diagrams showcasing flow of funds -->
+
 Quien crea el AMM se convierte en el primer proveedor de liquidez y recibe Tokens LP que representan el 100% de la propiedad de los activos en el pool del AMM. Pueden canjear algunos o todos esos Tokens LP para retirar activos del AMM en proporción a las cantidades actualmente allí. (Las proporciones cambian con el tiempo a medida que las personas comercian contra el AMM). El AMM no cobra una tarifa al retirar ambos activos.

 Por ejemplo, si creaste un AMM con 5 ETH y 5 USD, y luego alguien cambió 1.26 USD por 1 ETH, el pool ahora tiene 4 ETH y 6.26 USD en él. Puedes gastar la mitad de tus Tokens LP para retirar 2 ETH y 3.13 USD.
@@ -60,7 +62,6 @@ El AMM está diseñado de manera que el pool de activos de un AMM esté vacío s

 Los Tokens LP utilizan un tipo especial de código de moneda en el formato hexadecimal de 160 bits ["no estándar"](../../../references/protocol/data-types/currency-formats.md#nonstandard-currency-codes). Estos códigos tienen los primeros 8 bits `0x03`. El resto del código es un hash SHA-512, truncado a los primeros 152 bits, de los códigos de moneda de los dos activos y sus emisores. (Los activos se colocan en un "orden canónico" con el par de moneda+emisor numéricamente inferior primero). Como resultado, los Tokens LP para un par de activos dado de un AMM tienen un código de moneda predecible y consistente.

-
 ## Tarifas de intercambio

 Las tarifas de intercambio son una fuente de ingresos pasivos para los proveedores de liquidez, y compensan el riesgo cambiario de permitir que otros intercambien activos del pool. Las tarifas de intercambio se pagan al AMM, no directamente a los proveedores de liquidez, pero estos se benefician porque sus Tokens LP se pueden canjear por un porcentaje del pool del AMM.
@@ -75,7 +76,6 @@ A diferencia de cualquier Automated Market Maker anterior, el diseño de AMM del

 Con cualquier AMM, cuando el precio de sus activos cambia significativamente en los mercados externos, los traders pueden usar arbitraje para obtener beneficios del AMM, lo que resulta en una pérdida para los proveedores de liquidez. El mecanismo de subasta tiene como objetivo devolver más de ese valor a los proveedores de liquidez y llevar los precios del AMM más rápidamente de vuelta al equilibrio con los mercados externos.

-
 ## Representación en el Ledger

 En los datos de estado del ledger, un AMM consiste en múltiples [entradas de ledger](../../../references/protocol/ledger-data/ledger-entry-types/index.md):
@@ -84,13 +84,12 @@ En los datos de estado del ledger, un AMM consiste en múltiples [entradas de le

 - Una [entrada AccountRoot][] especial que emite Tokens LP del AMM, y tiene XRP del AMM (si lo tiene).

-    La dirección de esta AccountRoot se elige de forma algo aleatoria cuando se crea el AMM, y es diferente si el AMM se elimina y se vuelve a crear. Esto puede prevenir que las personas financien la cuenta AMM con XRP excesivo por adelantado.
+  La dirección de esta AccountRoot se elige de forma algo aleatoria cuando se crea el AMM, y es diferente si el AMM se elimina y se vuelve a crear. Esto puede prevenir que las personas financien la cuenta AMM con XRP excesivo por adelantado.

 - Las [Trust lines](../fungible-tokens/index.md) a la cuenta especial AMM para los tokens en el pool del AMM.

 Estas entradas de ledger no son propiedad de ninguna cuenta, por lo que el [requisito de reserva](../../accounts/reserves.md) no se aplica a ellas. Sin embargo, para prevenir el spam, la transacción para crear un AMM tiene un [coste de transacción](../../transactions/transaction-cost.md) especial que requiere que el remitente queme una cantidad de XRP mayor de lo habitual.

-
 ## Eliminación

 Un AMM se elimina cuando una [transacción AMMWithdraw][] retira todos los activos de su pool. Esto solo ocurre canjeando todos los Tokens LP pendientes del AMM. La eliminación del AMM incluye la eliminación de todas las entradas del ledger asociadas con él, como:
@@ -102,7 +101,7 @@ Un AMM se elimina cuando una [transacción AMMWithdraw][] retira todos los activ

 Si hay más de 512 trust lines enlazadas a la cuenta del AMM cuando se eliminase, el proceso de retiro tiene éxito y elimina tantas trust lines como puede, pero deja el AMM en el ledger sin activos en su pool.

-Mientras un AMM no tenga activos en su pool, cualquiera puede eliminarlo enviando una [transacción AMMDelete][]; si el número restante de líneas de confianza sigue siendo mayor que el límite, pueden ser necesarias múltiples transacciones AMMDelete para eliminar completamente el AMM. Alternativamente, cualquier persona puede realizar un [depósito especial](../../../references/protocol/transactions/types/ammdeposit.md#empty-amm-special-case) para financiar el AMM como si fuera nuevo. 
+Mientras un AMM no tenga activos en su pool, cualquiera puede eliminarlo enviando una [transacción AMMDelete][]; si el número restante de líneas de confianza sigue siendo mayor que el límite, pueden ser necesarias múltiples transacciones AMMDelete para eliminar completamente el AMM. Alternativamente, cualquier persona puede realizar un [depósito especial](../../../references/protocol/transactions/types/ammdeposit.md#empty-amm-special-case) para financiar el AMM como si fuera nuevo.

 No hay reembolso o incentivo para eliminar un AMM vacío.

--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md
@@ -4,10 +4,11 @@ parent: tokens.html
 metadata:
  indexPage: true
 seo:
-    description: El XRP Ledger contiene un exchange completamente funcional donde los usuarios pueden intercambiar tokens por XRP o entre sí.
+  description: El XRP Ledger contiene un exchange completamente funcional donde los usuarios pueden intercambiar tokens por XRP o entre sí.
 targets:
  - en
 ---
+
 # Exchange descentralizado

 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).
@@ -18,7 +19,7 @@ El XRP Ledger posiblemente tenga el _exchange descentralizado_ más antiguo del

 El exchange descentralizado del XRP Ledger consta de un número ilimitado de pares de divisas, rastreados según la demanda cuando los usuarios realizan intercambios. Un par de divisas puede consistir en XRP y un token o dos tokens diferentes; los tokens siempre se identifican por la combinación de un emisor y un código de moneda. Es posible comerciar entre dos tokens con el mismo código de moneda y diferentes emisores, o el mismo emisor y diferentes códigos de moneda. <!-- STYLE_OVERRIDE: limited number -->

-Como con todos los cambios en el XRP Ledger, necesitas enviar una [transacción](../../transactions/index.md) para realizar un intercambio. Un intercambio en el XRP Ledger se conoce como Oferta u [Offer](offers.md). Una Oferta es efectivamente una [_Orden límite_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) para comprar o vender una cantidad específica de una moneda (XRP o un token) por una cantidad específica de otra. Cuando la red ejecuta una Oferta, si hay otras Ofertas coincidentes para el mismo par de divisas, estas se consumen comenzando con la mejor tasa de cambio primero.
+Como con todos los cambios en el XRP Ledger, necesitas enviar una [transacción](../../transactions/index.md) para realizar un intercambio. Un intercambio en el XRP Ledger se conoce como Oferta u [Offer](offers.md). Una Oferta es efectivamente una [_Orden límite_](<https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order>) para comprar o vender una cantidad específica de una moneda (XRP o un token) por una cantidad específica de otra. Cuando la red ejecuta una Oferta, si hay otras Ofertas coincidentes para el mismo par de divisas, estas se consumen comenzando con la mejor tasa de cambio primero.

 Una Oferta puede llenarse completamente o parcialmente; si no se llena completamente de inmediato, se convierte en un objeto de Oferta pasiva en el ledger para la cantidad restante. Más adelante, otras Ofertas o [pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden coincidir y consumir la Oferta. Debido a esto, las Ofertas pueden ejecutarse a un mejor precio que el solicitado inicialmente, o exactamente al tipo de cambio indicado más tarde (excepto por diferencias menores para tener en cuenta el redondeo).

@@ -28,23 +29,22 @@ Al comerciar con dos tokens, el [puente automático](autobridging.md) mejora las

 ### Ejemplo de intercambio

-[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.svg" /%}](/docs/img/decentralized-exchange-example-trade.svg "Diagrama: Oferta parcialmente completada para comprar un token con XRP.")
+[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.svg" /%}](/docs/img/decentralized-exchange-example-trade.svg 'Diagrama: Oferta parcialmente completada para comprar un token con XRP.')

 El diagrama anterior muestra un ejemplo de intercambio en el exchange descentralizado. En este ejemplo, un trader llamado Tran coloca una Oferta para comprar 100 tokens con el código de moneda FOO emitido por un negocio ficticio llamado WayGate. (Por brevedad, "FOO.WayGate" se refiere a estos tokens.) Tran especifica que está dispuesto a gastar hasta 1000 XRP en total. Cuando la transacción de Tran es procesada, ocurren las siguientes cosas:

 1. La red calcula la tasa de cambio de la Oferta de Tran, dividiendo la cantidad a comprar por la cantidad a pagar.
-0. La red encuentra el libro de órdenes para el reverso de la Oferta de Tran: en este caso, eso significa el libro de órdenes para vender FOO.WayGate y comprar XRP. Este libro de órdenes ya tiene varias Ofertas existentes de otros traders para diferentes cantidades y tasas de cambio.
-0. La Oferta de Tran "consume" Ofertas coincidentes, comenzando con la mejor tasa de cambio y trabajando hacia abajo, hasta que la Oferta de Tran se haya llenado por completo o no haya más Ofertas cuya tasa de cambio sea igual o mejor que la tasa especificada en la Oferta de Tran. En este ejemplo, solo hay disponibles 22 FOO.WayGate a la tasa solicitada o mejor. Las Ofertas consumidas se eliminan del libro de órdenes.
-0. Tran recibe la cantidad de FOO.WayGate que el intercambio pudo adquirir, de los varios traders que previamente habían colocado órdenes para venderlo. Estos tokens van a la [trust line](../fungible-tokens/index.md) de Tran a WayGate para FOO. (Si Tran no tenía esa trust line previamente, se crea automáticamente una).
-0. A cambio, esos traders reciben XRP de Tran de acuerdo con sus tasas de cambio declaradas.
-0. La red calcula el resto de la Oferta de Tran: dado que la Oferta original era para comprar 100 FOO.WayGate y hasta ahora Tran ha recibido 22, el resto es de 78 FOO.WayGate. Usando la tasa de cambio original, eso significa que el resto de la Oferta de Tran ahora es comprar 78 FOO.WayGate por 780 XRP.
-0. El "resto" resultante se coloca en el libro de órdenes para intercambios en la misma dirección que la de Tran: vendiendo XRP y comprando FOO.WayGate.
+2. La red encuentra el libro de órdenes para el reverso de la Oferta de Tran: en este caso, eso significa el libro de órdenes para vender FOO.WayGate y comprar XRP. Este libro de órdenes ya tiene varias Ofertas existentes de otros traders para diferentes cantidades y tasas de cambio.
+3. La Oferta de Tran "consume" Ofertas coincidentes, comenzando con la mejor tasa de cambio y trabajando hacia abajo, hasta que la Oferta de Tran se haya llenado por completo o no haya más Ofertas cuya tasa de cambio sea igual o mejor que la tasa especificada en la Oferta de Tran. En este ejemplo, solo hay disponibles 22 FOO.WayGate a la tasa solicitada o mejor. Las Ofertas consumidas se eliminan del libro de órdenes.
+4. Tran recibe la cantidad de FOO.WayGate que el intercambio pudo adquirir, de los varios traders que previamente habían colocado órdenes para venderlo. Estos tokens van a la [trust line](../fungible-tokens/index.md) de Tran a WayGate para FOO. (Si Tran no tenía esa trust line previamente, se crea automáticamente una).
+5. A cambio, esos traders reciben XRP de Tran de acuerdo con sus tasas de cambio declaradas.
+6. La red calcula el resto de la Oferta de Tran: dado que la Oferta original era para comprar 100 FOO.WayGate y hasta ahora Tran ha recibido 22, el resto es de 78 FOO.WayGate. Usando la tasa de cambio original, eso significa que el resto de la Oferta de Tran ahora es comprar 78 FOO.WayGate por 780 XRP.
+7. El "resto" resultante se coloca en el libro de órdenes para intercambios en la misma dirección que la de Tran: vendiendo XRP y comprando FOO.WayGate.

 Las transacciones posteriores, incluidas aquellas ejecutadas inmediatamente después de las de Tran en el _mismo_ ledger, utilizan los libros de órdenes actualizados para sus intercambios, por lo que pueden consumir parte o toda la Oferta de Tran hasta que se llene por completo o Tran la cancele.

 **Nota**: El orden canónico en el que las transacciones se ejecutan cuando se cierra y valida un ledger no es el mismo que el orden en el que se enviaron esas transacciones. Cuando varias transacciones afectan al mismo libro de órdenes en el mismo ledger, los resultados finales de esas transacciones pueden ser muy diferentes a los resultados tentativos calculados en el momento del envío de la transacción. Para obtener más detalles sobre cuándo los resultados de las transacciones son o no finales, consulta [Finalidad de resultados](../../transactions/finality-of-results/index.md).

-
 ## Limitaciones

 El exchange descentralizado está diseñado con las siguientes limitaciones:
@@ -58,17 +58,16 @@ Como sistema descentralizado, el XRP Ledger no tiene información sobre las pers
 ## Ver también

 - **Conceptos:**
-    - Ver [Ofetas](offers.md) para obtener detalles sobre cómo funcionan los intercambios en el XRP Ledger.
-    - Ver [Tokens](../index.md) para obtener una descripción general de cómo se pueden representar diversos tipos de valor en el XRP Ledger.
+  - Ver [Ofetas](offers.md) para obtener detalles sobre cómo funcionan los intercambios en el XRP Ledger.
+  - Ver [Tokens](../index.md) para obtener una descripción general de cómo se pueden representar diversos tipos de valor en el XRP Ledger.
 - **Referencias:**
-    - [método account_offers][] para buscar Ofertas creadas por una cuenta
-    - [método book_offers][] para buscar Ofertas de compra o venta según un par de divisas dado
-    - [transacción OfferCreate][] para crear una Oferta nueva o reemplazar una Oferta existente
-    - [transacción OfferCancel][] para cancelar una Oferta existente
-    - [objeto Offer][] para la estructura de datos de las Ofertas pasivas en el ledger
-    - [objeto DirectoryNode][] para la estructura de datos que sigue todas las Ofertas para un par de divisas y tarifa de intercambio dados.
+  - [método account_offers][] para buscar Ofertas creadas por una cuenta
+  - [método book_offers][] para buscar Ofertas de compra o venta según un par de divisas dado
+  - [transacción OfferCreate][] para crear una Oferta nueva o reemplazar una Oferta existente
+  - [transacción OfferCancel][] para cancelar una Oferta existente
+  - [objeto Offer][] para la estructura de datos de las Ofertas pasivas en el ledger
+  - [objeto DirectoryNode][] para la estructura de datos que sigue todas las Ofertas para un par de divisas y tarifa de intercambio dados.

 {% raw-partial file="/docs/_snippets/common-links.md" /%}

-
 {% child-pages /%}
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md
@@ -2,10 +2,11 @@
 html: offers.html
 parent: decentralized-exchange.html
 seo:
-    description: Las ofertas son la forma de órdenes de comercio de divisas del XRP Ledger. Comprende su ciclo de vida y propiedades.
+  description: Las ofertas son la forma de órdenes de comercio de divisas del XRP Ledger. Comprende su ciclo de vida y propiedades.
 labels:
  - Exchange Descentralizado
 ---
+
 # Ofertas

 En el [exchange descentralizado](index.md) del XRP Ledger, las órdenes de intercambio se llaman "Ofertas". Las Ofertas pueden intercambiar XRP con [tokens](../index.md), o tokens por otros tokens, incluyendo tokens con el mismo código de moneda pero diferentes emisores. (Los tokens con el mismo código pero diferentes emisores también a veces pueden intercambiarse a través de [rippling](../fungible-tokens/rippling.md).)
@@ -29,7 +30,6 @@ Mientras tengas una Oferta en el ledger, se aparta parte de tu XRP hacia la [res
 - Una Oferta **Completar o Cancelar** no se coloca en el ledger, _y_ se cancela si la cantidad total no se completa cuando se ejecuta inicialmente. Esto es similar a "Inmediata o Cancelar", excepto que _no puede_ completarse parcialmente.
 - Una Oferta **Pasiva** no consume Ofertas coincidentes que tengan el mismo tipo de cambio (en la otra dirección), y en su lugar se coloca directamente en el ledger. Puedes usar esto para crear un peg exacto entre dos activos. Las Ofertas Pasivas aún consumen otras Ofertas que tienen un tipo de cambio _mejor_ en la otra dirección.

-
 ### Requisitos de financiación

 Cuando intentas realizar una Oferta, la transacción se rechaza como "no financiada" si no tienes al menos parte del activo que la operación vendería. Más específicamente:
@@ -50,11 +50,11 @@ Si colocas una Oferta que cruza alguna de tus propias Ofertas que existen en el
 Es posible que una Oferta se vuelva temporal o permanentemente _no financiada_ en los siguientes casos:

 - Si el propietario ya no tiene ningún activo de venta.
-    - La Oferta se vuelve financiada nuevamente cuando el propietario obtiene más de ese activo.
+  - La Oferta se vuelve financiada nuevamente cuando el propietario obtiene más de ese activo.
 - Si el activo en venta es un token en una [trust line congelada](../fungible-tokens/freezes.md).
-    - La Oferta se vuelve financiada nuevamente cuando la trust line ya no está congelada.
+  - La Oferta se vuelve financiada nuevamente cuando la trust line ya no está congelada.
 - Si la Oferta necesita crear una nueva trust line, pero el dueño no tiene suficiente XRP para el aumento de la [reserva](../../accounts/reserves.md). (Ver [Ofertas y confianza](#offers-and-trust).)
-    - La oferta vuelve a estar financiada cuando el propietario obtiene más XRP, o los requisitos de reserva disminuyen.
+  - La oferta vuelve a estar financiada cuando el propietario obtiene más XRP, o los requisitos de reserva disminuyen.
 - Si la Oferta ha expirado. (Ver [Expiración de ofertas](#offer-expiration).)

 Una Oferta no financiada permanece en el ledger hasta que una transacción la elimine. Las formas en que una Oferta puede ser eliminada del ledger incluyen:
@@ -63,7 +63,7 @@ Una Oferta no financiada permanece en el ledger hasta que una transacción la el
 - El propietario cancela explicitamente la Oferta.
 - El propietario cancela implícitamente la Oferta enviando una nueva Oferta que la cruza.
 - La Oferta es encontrada sin financiar o expirada durante el procesamiento de la transacción. Normalmente esto significa que otra Oferta intentó consumirla y no pudo hacerlo.
-    - Esto incluye casos donde la cantidad restante puede ser pagada mediante la Oferta redondeada a cero.
+  - Esto incluye casos donde la cantidad restante puede ser pagada mediante la Oferta redondeada a cero.

 ### Seguimiento de ofertas no financiadas

@@ -71,7 +71,6 @@ Seguir el estado de financiación de todas las Ofertas puede ser computacionalme

 Una aplicación de cliente puede seguir localmente el estado de financiación de las Ofertas. Para hacerlo, primero recupera un libro de órdenes utilizando el [método book_offers][] y verifica el campo `taker_gets_funded` de las Ofertas. Luego, [suscríbete](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md) al flujo de `transactions` y observa los metadatos de transacción para ver qué Ofertas se modifican.

-
 ## Ofertas y confianza

 Los valores límite de las [trust lines](../fungible-tokens/index.md) no afectan a las Ofertas. En otras palabras, puedes usar una Oferta para adquirir más de la cantidad máxima en la que confías en un emisor.
@@ -80,13 +79,11 @@ Sin embargo, mantener tokens aún requiere una trust line con el emisor. Cuando

 Los límites de la trust line te protegen de recibir más de un token como pago de lo que deseas. Las Ofertas pueden superar esos límites porque son una declaración explícita de cuánto del token deseas.

-
 ## Preferencia de Oferta

 Las Ofertas existentes se agrupan por tipo de cambio, que se mide como la relación entre `TakerGets` y `TakerPays`. Las Ofertas con un tipo de cambio más alto se toman preferentemente. (Es decir, la persona que acepta la oferta recibe tanto como sea posible por la cantidad de moneda que paga). Las Ofertas con el mismo tipo de cambio se toman en función de cuál se colocó primero.

-Cuando las Ofertas se ejecutan en el mismo bloque del ledger, el orden en que se ejecutan se determina por el [orden canónico](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Código fuente: Ordenación de transacciones") en el que las transacciones fueron [aplicadas en el ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Código fuente: Aplicando transacciones"). Este comportamiento está diseñado para ser determinista, eficiente y difícil de manipular.
-
+Cuando las Ofertas se ejecutan en el mismo bloque del ledger, el orden en que se ejecutan se determina por el [orden canónico](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp 'Código fuente: Ordenación de transacciones') en el que las transacciones fueron [aplicadas en el ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 'Código fuente: Aplicando transacciones'). Este comportamiento está diseñado para ser determinista, eficiente y difícil de manipular.

 ## Caducidad de la oferta

@@ -98,17 +95,16 @@ Esto es una consecuencia de cómo la red alcanza un acuerdo. Para que toda la re

 **Nota:** Las Ofertas caducadas permanecen en los datos del ledger hasta que una transacción las elimine. Hasta entonces, pueden continuar apareciendo en los datos recuperados a través de la API (por ejemplo, utilizando el [método ledger_entry][]). Las transacciones eliminan automáticamente cualquier Oferta caducada y no financiada que encuentren, generalmente mientras ejecutan Ofertas o pagos de monedas cruzadas que las hubieran igualado o cancelado. La reserva del propietario asociada con una Oferta solo vuelve a estar disponible cuando la Oferta se elimina realmente.

-
 ## Ver también

 - **Conceptos:**
-    - [Tokens](../index.md)
-    - [Paths](../fungible-tokens/paths.md)
+  - [Tokens](../index.md)
+  - [Paths](../fungible-tokens/paths.md)
 - **Referencias:**
-    - [método account_offers][]
-    - [método book_offers][]
-    - [transacción OfferCreate][]
-    - [transacción OfferCancel][]
-    - [Objeto Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
+  - [método account_offers][]
+  - [método book_offers][]
+  - [transacción OfferCreate][]
+  - [transacción OfferCancel][]
+  - [Objeto Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md
@@ -2,11 +2,12 @@
 html: ticksize.html
 parent: decentralized-exchange.html
 seo:
-    description: Los emisores pueden establecer tamaños de ticks personalizados para las monedas para reducir la rotación de libros de pedidos por diferencias minúsculas en los tipos de cambio.
+  description: Los emisores pueden establecer tamaños de ticks personalizados para las monedas para reducir la rotación de libros de pedidos por diferencias minúsculas en los tipos de cambio.
 labels:
  - Exchange Descentralizado
  - Tokens
 ---
+
 # Tamaño de Tick

 Cuando se coloca una Oferta en un libro de órdenes, su tasa de cambio se trunca en base a los valores de `TickSize` establecidos por los emisores de las monedas involucradas en la Oferta. Cuando se negocia XRP y un token, se aplica el `TickSize` del emisor del token. Cuando se negocian dos tokens, la Oferta utiliza el valor de `TickSize` más pequeño (es decir, el que tiene menos dígitos significativos). Si ninguno de los tokens tiene un `TickSize` establecido, se aplica el comportamiento predeterminado.
@@ -21,8 +22,8 @@ Cuando un emisor habilita, deshabilita o cambia el `TickSize`, las Ofertas que s

 - [Dev Blog: Introducción a la enmienda TickSize](https://xrpl.org/blog/2017/ticksize-voting.html#ticksize-amendment-overview)
 - **Referencias:**
-    - [transacción AccountSet][]
-    - [método book_offers][]
-    - [transacción OfferCreate][]
+  - [transacción AccountSet][]
+  - [método book_offers][]
+  - [transacción OfferCreate][]

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/introduction/crypto-wallets.md
+++ b/@l10n/es-ES/docs/introduction/crypto-wallets.md
@@ -2,15 +2,15 @@
 html: crypto-wallets.html
 parent: intro-to-xrpl.html
 seo:
-    description: Las carteras brindan una forma conveniente de administrar tu XRP en el XRP Ledger.
+  description: Las carteras brindan una forma conveniente de administrar tu XRP en el XRP Ledger.
 labels:
  - Blockchain
 ---
+
 # Carteras cripto

 Las carteras cripto brindan una forma de administrar tu cuenta y tus fondos en el XRP Ledger. Hay muchas carteras para elegir. Al final, elegir la cartera adecuada se reduce a tus necesidades y a tus gustos al trabajar con XRP.

-
 ## Carteras con custodia vs carteras sin custodia

 Un factor importante cuando se elige una cartera es si se desea que sea una cartera con custodia o sin custodia.
@@ -29,7 +29,6 @@ Las carteras sin custodia te permiten tener más libertad. Como estás interactu

 Tanto los usuarios de carteras con custodia como los usuarios de carteras sin custodia deben protegerse de usuarios malintencionados que podrían intentar robar tus fondos. Con una cartera con custodia, debes administrar tu nombre de usuario y contraseña en la app o en el sitio web; en una cartera sin custodia, tienes que administrar las claves secretas (secrect keys) de tu cuenta en el libro contable (ledger). En ambos casos, las prácticas de seguridad propias del proveedor de la cartera también son importantes para protegerte de vulnerabilidades como ataques a la cadena de suministro, donde un atacante carga código malicioso en la cartera a través de actualizaciones o dependencias. Sin embargo, las carteras con custodia pueden ser un objetivo mayor para los atacantes, ya que tienen acceso inmediato a los fondos de múltiples usuarios.

-
 ## Carteras de software vs Carteras de hardware

 Otro factor decisivo a la hora de elegir una cartera es elegir entre una cartera de hardware o de software.
@@ -40,10 +39,8 @@ Las carteras de hardware son dispositivos físicos que almacenan tus claves priv

 Las carteras de software por el otro lado, son completamente digitales. Mientras esto las hace mucho más fáciles, también las convierte en el método menos seguro de los dos, pero generalmente vienen con funciones adicionales para mejorar la experiencia. Como última instancia, la decisión entre las dos dependerá de tu nivel de comidad y de lo importante que sea para ti la facilidad de uso.

-
 ## Crear tu propia cartera

 El XRP Ledger es un proyecto de código abierto con librerías de cliente y métodos API disponibles públicamente. Si bien técnicamente se puede interactuar con el ledger utilizando herramientas HTTP/WebSocket, no es práctico para el uso del día a día. Puedes crear tu propia cartera para interactuar con el ledger, pero necesitarás entender exáctamente cómo funcionan las cuentas, transacciones y el ledger juntas antes de comprometerte con esta opción.

-
 Siguiente: [Transacciones y peticiones](transactions-and-requests.md)
--- a/@l10n/es-ES/docs/introduction/index.md
+++ b/@l10n/es-ES/docs/introduction/index.md
@@ -5,8 +5,9 @@ metadata:
  indexPage: true
 top_nav_grouping: Article Types
 ---
+
 # Introducción

-El XRP Ledger es una blockchain que permanentemente registra transacciones digitales de tokens entre cuentas. Las secciones de abajo amplian los conceptos introducidos en esa frase. 
+El XRP Ledger es una blockchain que permanentemente registra transacciones digitales de tokens entre cuentas. Las secciones de abajo amplian los conceptos introducidos en esa frase.

 {% child-pages /%}
--- a/@l10n/es-ES/docs/introduction/software-ecosystem.md
+++ b/@l10n/es-ES/docs/introduction/software-ecosystem.md
@@ -2,10 +2,11 @@
 html: software-ecosystem.html
 parent: introduction.html
 seo:
-    description: Obtén una descripción general de qué es el software XRP Ledger disponible y como funciona en conjunto.
+  description: Obtén una descripción general de qué es el software XRP Ledger disponible y como funciona en conjunto.
 labels:
  - Servidor central
 ---
+
 # Ecosistema software

 El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de software que impulsan y permiten el Internet del Valor. Es imposible listar cada proyecto, herramienta, y negocio que interactua con el XRP Ledger, asi que esta página solo lista algunas categorías y destaca algunos proyectos centrales que están documentados en este sitio web.
@@ -13,7 +14,7 @@ El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de sof

 ## Niveles de stack

- [_Servidores Principales](#servidores-principales) forman la base del XRP Ledger, una red peer-to-peer que transmite y procesa transacciones en todo momento.
+- [\_Servidores Principales](#servidores-principales) forman la base del XRP Ledger, una red peer-to-peer que transmite y procesa transacciones en todo momento.

 - [_Librerías de cliente_](#librerías-cliente) existen en software de alto nivel, donde se importan directamente al código del programa, y contiene métodos para acceder al XRP Ledger.

@@ -21,21 +22,19 @@ El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de sof

 - [_Apps y servicios_](#apps-y-servicios) proporcionan interación con el XRP Ledger a nivel usuario, o proporcionan una base para aplicaciones y servicios de aun más alto nivel.

-
 ### Servidores principales

-La red peer-to-peer en el corazón del XRP Ledger requiere de un servidor altamente confiable y eficiente para hacer cumplir las reglas de consenso y el procesamiento de las transacciones. La Fundación XRP Ledger publica una implementación de referencia de este software de sevidor, llamada [**`rippled`**](../concepts/networks-and-servers/index.md) (pronunciado en inglés como  "ripple-dee"). El servidor está disponible bajo [una licencia permisiva de código abierto](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md), por lo que cualquiera puede inspeccionar y modificar su propia instancia del servidor, y volver a publicar con pocas restricciones.
+La red peer-to-peer en el corazón del XRP Ledger requiere de un servidor altamente confiable y eficiente para hacer cumplir las reglas de consenso y el procesamiento de las transacciones. La Fundación XRP Ledger publica una implementación de referencia de este software de sevidor, llamada [**`rippled`**](../concepts/networks-and-servers/index.md) (pronunciado en inglés como "ripple-dee"). El servidor está disponible bajo [una licencia permisiva de código abierto](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md), por lo que cualquiera puede inspeccionar y modificar su propia instancia del servidor, y volver a publicar con pocas restricciones.

 ![Servidores principales](/docs/img/ecosystem-peer-to-peer.svg)

 Cada servidor central sincroniza con la misma red (a no ser que esté configurado para seguir una [red de test](../concepts/networks-and-servers/parallel-networks.md)) y tiene acceso a todas las comunicaciones a través de la red. Cada servidor de la red guarda una copia completa de lod datos de estado para todo el XRP Ledger, junto con transacciones recientes y un registro de los cambios que esas transacciones han realizado, y cada servidor procesa cada transacción independientemente mientras verifican que el resultado coincide con el resto de la red. Los servidores pueden ser configurados para mantener más [histórico del ledger](../concepts/networks-and-servers/ledger-history.md) y para participar en el proceso de consenso como un [validador](../concepts/networks-and-servers/rippled-server-modes.md#validators).

-Los servidores Core exponen [APIs HTTP / WebSocket](../references/http-websocket-apis/index.md) para que los usuarios busquen datos, administren el servidor, y envíen transacciones. Algunos servidores también ofrecen APIs  HTTP / WebSocket pero no conectan directamente con la red peer-to-peer y no procesan transacciones ni participan en el consenso. Estos servidores, como servidores `rippled` ejecutan en modo Reporting y servidores Clio, que dependen de un servidor central en modo P2P para procesar las transacciones.
-
+Los servidores Core exponen [APIs HTTP / WebSocket](../references/http-websocket-apis/index.md) para que los usuarios busquen datos, administren el servidor, y envíen transacciones. Algunos servidores también ofrecen APIs HTTP / WebSocket pero no conectan directamente con la red peer-to-peer y no procesan transacciones ni participan en el consenso. Estos servidores, como servidores `rippled` ejecutan en modo Reporting y servidores Clio, que dependen de un servidor central en modo P2P para procesar las transacciones.

 ### Librerías cliente

-Las librerias simplifican parte del trabajo básico de acceder al XRP Ledger, normalmente a través de las APIs HTTP / WebSocket. Convierten los datos en formas que son más familiares y convenientes para varios lenguajes de programación e incluyen implementaiones de operaciones básicas. 
+Las librerias simplifican parte del trabajo básico de acceder al XRP Ledger, normalmente a través de las APIs HTTP / WebSocket. Convierten los datos en formas que son más familiares y convenientes para varios lenguajes de programación e incluyen implementaiones de operaciones básicas.

 ![Librerías cliente](/docs/img/ecosystem-client-libraries.svg)

@@ -45,7 +44,6 @@ Muchos servicios middleware utilizan librerías cliente internamente.

 Ver [Librerías Cliente](../references/client-libraries.md) para más información sobre las librerías cliente disponibles actualmente.

-
 ### Middleware

 Los servicios middleware son programas que consumen las APIs del XRP Ledger por un lado y proporcionan sus propias APIs por el otro. Porporcionan una capa de abstracción para facilitar la creación de aplicaciones a mayor nivel proporcionando funcionalidades comunes como servicios.
@@ -54,7 +52,6 @@ Los servicios middleware son programas que consumen las APIs del XRP Ledger por

 A diferencia de las librerías cliente, en donde se crean instancias nuevas y se cierran con el programa que las importa, los servicios middleware generalmente permanecen ejecutándose indefinidamente y pueden tener sus propias bases de datos (bases de datos relacionales SQL o de otro tipo) y archivos de configuración. Algunos están disponibles como servicios en la nube con varios precios o limitaciones de uso.

-
 ### Apps y servicios

 En lo alto del stack es donde suceden las cosas realmente interesantes. Las apps y servicios ofrecen una forma para que usuarios y dispositivos se conecten al XRP Ledger. Los servicios como los exchanges privados, los acuñadores de tokens, marketplaces, interfaces al exchanges descentralizado, y carteras brindan interfaces de usuario para comprar, vender y comerciar varios activos incluyendo XRP y tokens de todo tipo. Existen muchas otras posibilidades, incluyendo servicios adicionales en capas superiores.
@@ -63,4 +60,4 @@ En lo alto del stack es donde suceden las cosas realmente interesantes. Las apps

 Ver [Casos de uso](../use-cases/index.md) para más ejemplos que pueden ser construidos en o encima de esta capa.

-{% raw-partial file="/docs/_snippets/common-links.md" /%}
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/es-ES/docs/introduction/transactions-and-requests.md
+++ b/@l10n/es-ES/docs/introduction/transactions-and-requests.md
@@ -2,7 +2,7 @@
 html: txn-and-requests.html
 parent: intro-to-xrpl.html
 seo:
-    description: Todas las interacciones con el ledger son transacciones o solicitudes.
+  description: Todas las interacciones con el ledger son transacciones o solicitudes.
 labels:
  - Blockchain
 ---
@@ -17,7 +17,7 @@ Utiliza las transacciones para realizar cambios en el ledger, como transferir XR

 - Siempre debes proporcionar el _TransactionType_ y la dirección pública de la _Account_ que realiza la transacción.

- Dos campos obligatorios son la _Fee_ (comisión) de la transacción y el siguiente número de la  _Sequence_ (secuencia) para las transacciones de la cuenta. Estos campos se pueden completar automáticamente.
+- Dos campos obligatorios son la _Fee_ (comisión) de la transacción y el siguiente número de la _Sequence_ (secuencia) para las transacciones de la cuenta. Estos campos se pueden completar automáticamente.

 - Las transacciones también pueden tener campos obligatorios específicos del tipo de transacción. Por ejemplo, una transacción _Payment_ requiere un valor (cantidad) _Amount_ (en _drops_, o millonésimas de un XRP) y una dirección pública _Destination_ (destino) donde los fondos son acreditados.

@@ -34,7 +34,7 @@ Aquí hay un ejemplo de transacción en formato JSON. Esta transacción transfie

 Hay campos opcionales disponibles para todas las transacciones, con campos adicionales disponibles para transacciones específicas. Puedes incluir tantos campos opcionales como necsites, pero no es necesario incluir todos los campos en cada transacción.

-Puedes enviar la transacción al ledger como un comando de JavaScript, Python, línea de comandos, o cualquier servicio compatible. Los servidores rippled proponen las transacciones al XRPL. 
+Puedes enviar la transacción al ledger como un comando de JavaScript, Python, línea de comandos, o cualquier servicio compatible. Los servidores rippled proponen las transacciones al XRPL.

 ![Transacciones propuestas](/docs/img/introduction17-gather-txns.png)

@@ -110,6 +110,7 @@ La solicitud devuelve una gran cantidad de información. Aquí hay un ejemplo de
    }
 }
 ```
+
 Para obtener información sobre los campos de un registro de información de una cuenta, ver [Cuentas](../concepts/accounts/index.md).

 Siguiente: [Ecosistema de software](software-ecosystem.md)
--- a/@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
+++ b/@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
@@ -2,15 +2,15 @@
 html: what-is-the-xrp-ledger.html
 parent: introduction.html
 seo:
-    description: Aprende sobre la blockchain XRP Ledger (XRPL).
+  description: Aprende sobre la blockchain XRP Ledger (XRPL).
 labels:
  - Blockchain
 ---
+
 # ¿Qué es el XRP Ledger?

 El XRP Ledger es una blockchain descentralizada que usa su propia moneda digital para procesar y registrar transacciones financieras.

-
 ## ¿Qué es una blockchain?

 Una blockchain es una lista de registros en continuo creciemiento. La blockchain comienza con un bloque de datos.
@@ -45,7 +45,7 @@ Por diseño, las blockchains son resistentes a la modificación de datos. Cada n

 ![Dos validadores con copias idénticas de la blockchain](/docs/img/introduction9-2-sets-of-3.png)

-Esto crea un libro contable (ledger) abierto y distribuido que registra las transacciones entre partes de manera eficiente, verificable y permanente. 
+Esto crea un libro contable (ledger) abierto y distribuido que registra las transacciones entre partes de manera eficiente, verificable y permanente.

 Una vez registrados, los datos de cualquier bloque no se pueden modificar retroactivamente, a no ser que la mayoría de validadores se pongan de acuerdo en el cambio. Si es así, todo los bloques posteriores se modifican de la misma manera (un hecho muy raro y extremo).

--- a/@l10n/es-ES/docs/introduction/what-is-xrp.md
+++ b/@l10n/es-ES/docs/introduction/what-is-xrp.md
@@ -2,11 +2,12 @@
 html: what-is-xrp.html
 parent: introduction.html
 seo:
-    title: ¿Qué es XRP y por qué es valioso?
-    description: XRP, la criptomoneda respaldada por el XRP Ledger (XRPL), permite transacciones más rápidas y económicas. Descubre cómo opera XRP en una blockchain de código abierto.
+  title: ¿Qué es XRP y por qué es valioso?
+  description: XRP, la criptomoneda respaldada por el XRP Ledger (XRPL), permite transacciones más rápidas y económicas. Descubre cómo opera XRP en una blockchain de código abierto.
 labels:
  - Blockchain
 ---
+
 # ¿Qué es XRP?

 XRP es la criptomoneda respaldada por el XRP Ledger.
@@ -45,31 +46,28 @@ Aunque puede parecer mucho más seguro tener algo "real en la mano, muchas perso

 El valor de las criptomonedas proviene de la confianza que sus poseedores depositan en la moneda. Debido a la naturaleza distribuida de los registros y la protección criptográfica para asegurar los fondos, las criptomonedas podrían considerarse mucho más robustas, seguras, y convenientes que las monedas fiduciarias tradicionales.

-
 ## XRP es una criptomoneda

 El XRP Ledger fue construido entre 2011 y principios de 2012 por Jed McCaleb, Arthur Britto y David Schwartz. En el momento de su creación, había 100 mil millones de XRP. En septiembre de 2012, Jed y Arthur, junto con Chris Larsen formaron Ripple (la compañía, llamada en ese momento OpenCoin Inc.) y decidieron donar 80 mil millones XRP a Ripple a cambio de que Ripple desarrollase en el XRP Ledger.

 ![Cien mil millones con "M"](/docs/img/introduction14-hundred-billion.png)

-Desde entonces, la compañía ha vendido XRP regularmente, lo ha utilizado para fortalecer los mercados de XRP y mejorar la liquidez de la red, e incentivar el desarrollo del ecosistema. En 2017, la compañía colocó [55 mil millones de XRP en escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993)  para asegurar que la cantidad que entra al suministro general [crece de manera predecible](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993)  en el futuro inmediato,. Ripple [sitio de rendimiento del mercado XRP](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) informa cuánto XRP tiene la compañía disponible y cuanto tiene bloqueado en escrow en la actualidad.
+Desde entonces, la compañía ha vendido XRP regularmente, lo ha utilizado para fortalecer los mercados de XRP y mejorar la liquidez de la red, e incentivar el desarrollo del ecosistema. En 2017, la compañía colocó [55 mil millones de XRP en escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) para asegurar que la cantidad que entra al suministro general [crece de manera predecible](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) en el futuro inmediato,. Ripple [sitio de rendimiento del mercado XRP](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) informa cuánto XRP tiene la compañía disponible y cuanto tiene bloqueado en escrow en la actualidad.

 ![Hombre con un XRP](/docs/img/introduction13-x-prefix.png)

-
 ### El nombre

 Originalmente, el XRP Ledger se llamaba "Ripple" por la forma en que la tecnología permitía que los pagos [se propagaran a través de múltiples saltos y monedas](../concepts/tokens/fungible-tokens/rippling.md). Para el activo nativo construido dentro del ledger, los creadores eligieron las siglas "XRP" del término "créditos ripple" o "ripples" y el prefijo X por ser una moneda no nacional según el estandar de la [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html). La compañía se registró como "Ripple Labs". El nombre "XRP" empezó a usarse para referirse al activo en todos los contextos, para evitar confusiones con nombres similares de la tecnología y la compañía, y finalmente la empresa acortó su propio nombre a "Ripple". En mayo de 2018, [la comunidad seleccionó un nuevo símbolo "X"](https://twitter.com/xrpsymbol/status/1006925937571713025) para representar XRP y diferenciarlo del logotipo triskelion con el que se conocía anteriormente tanto a la empresa como al activo digital

-| XRP "X" Logo                           | Ripple triskelion                   |
-|:---------------------------------------|:------------------------------------|
+| XRP "X" Logo                     | Ripple triskelion                              |
+| :------------------------------- | :--------------------------------------------- |
 | !["X" logo](/img/xrp-x-logo.png) | ![Triskelion](/docs/img/ripple-triskelion.png) |

-
 ### Marca comercial

 "XRP" es una marca registrada de la XRPL Foundation en EE.UU. y otros países como China y Estonia.

 La solicitud de marca se registró en la Oficina de Patentes y Marcas de los Estados Unidos (USPTO) en 2013 con OpenCoin Inc y Ripple Labs Inc como cesionarios. En 2022, la asignación de marca fue actualizada y ahora está asignada a MITTETULUNDUSÜHING XRP LEDGER TRUST (“XRPLF”).
- 
+
 Siguiente: [Carteras Cripto](crypto-wallets.md)
--- a/@l10n/es-ES/translations.yaml
+++ b/@l10n/es-ES/translations.yaml
@@ -78,7 +78,7 @@ Contribute to Consensus: Contribuye al consenso
 Apply for funding to build your XRPL project: Aplica para financiar la construcción de tu proyecto XRPL
 Awarded in a single grant: Premiado en una financiación
 Distributed to grant recipients: Distribuido entre los recibidores de la financiación
-Open-source projects funded : Proyectos de código abierto financiados
+Open-source projects funded: Proyectos de código abierto financiados
 Learn More: Leer más
 Showcase your XRPL project, application or product: Muestra tu proyecto XRPL, aplicación o producto
 XRPL Community Spotlight: Destacado en la comunidad XRPL
@@ -153,7 +153,7 @@ Explore, Test, Verify: Explora, prueba, verifica
 Explore Dev Tools: Explora las herramientas de desarrollo
 Browse By Recommended Pages: Explora entre las páginas recomendadas
 Get Free Test XRP: Consigue XRP de prueba gratis
-Generate Testnet Credentials: Genera credenciales de Testnet 
+Generate Testnet Credentials: Genera credenciales de Testnet
 See full documentation index: Consulta el índice de la documentación completa
 Find the XRPL Community Around the World: Encuentra a la comunidad XRPL alrededor del mundo
 Events: Eventos
@@ -281,7 +281,7 @@ Trust for: Confianza para
 Security: Seguridad
 Release Notes: Notas de la versión
 Custody: Custodia
-Infrastructure: Infraestructura 
+Infrastructure: Infraestructura
 Carbon Markets/Sustainability: Mercados de Carbono/Sostenibilidad
 Developer Tooling: Herramientas de desarrollo
 Gaming: Gaming
--- a/@l10n/ja/CODE-OF-CONDUCT.md
+++ b/@l10n/ja/CODE-OF-CONDUCT.md
@@ -8,19 +8,19 @@

 前向きな環境を作り上げることに貢献する行動の例:

-* 友好的で差別のない言葉の使用
-* 異なる観点や経験の尊重
-* 建設的な批判の素直な受け入れ
-* コミュニティーにとっての最善への注力
-* 他のコミュニティーメンバーへの共感の表示
+- 友好的で差別のない言葉の使用
+- 異なる観点や経験の尊重
+- 建設的な批判の素直な受け入れ
+- コミュニティーにとっての最善への注力
+- 他のコミュニティーメンバーへの共感の表示

 前向きな環境を作り上げることに貢献しない行動の例:

-* 性的な意味を含む言葉や画像の使用、望まない性的注目や誘いかけ
-* あおり、侮辱的または軽蔑的なコメント、個人攻撃や政治攻撃
-* 公的または私的な嫌がらせ
-* 住所やメールアドレスなどの個人情報の、明確な許可なしでの公開
-* 職場において不適切であると合理的に考えられる、その他の行為
+- 性的な意味を含む言葉や画像の使用、望まない性的注目や誘いかけ
+- あおり、侮辱的または軽蔑的なコメント、個人攻撃や政治攻撃
+- 公的または私的な嫌がらせ
+- 住所やメールアドレスなどの個人情報の、明確な許可なしでの公開
+- 職場において不適切であると合理的に考えられる、その他の行為

 ## 責任

@@ -43,4 +43,5 @@
 この行動規範は、[コントリビューター行動規範][ホームページ]バージョン1.4（https://www.contributor-covenant.org/version/1/4/code-of-conduct.html）から抜粋したものです。

 [ホームページ]: https://www.contributor-covenant.org
+
 この行動規範に関するよくある質問と回答については、https://www.contributor-covenant.org/faq をご覧ください。
--- a/@l10n/ja/about/faq.md
+++ b/@l10n/ja/about/faq.md
@@ -1,14 +1,16 @@
 ---
 seo:
-    description: XRP Ledger、XRPLエコシステム、コミュニティに関するよくある質問にお答えします。
+  description: XRP Ledger、XRPLエコシステム、コミュニティに関するよくある質問にお答えします。
 subtitle: XRPLについての質問にお答えします
 top_nav_grouping: 概要
 labels:
  - ブロックチェーン
 ---
+
 # よくある質問

 <!--#{ using h4s for questions to keep them out of the right side nav (too cluttered when they display) and to provide appropriate text size for questions. #}-->
+
 #### XRPはリップルと呼ぶのですか？

 いいえ。XRPは**エックスアールピー**と呼びます。日本国内の多くの取引所などはXRPをRippleやリップルなどと表記していることがありますが、それは間違いです。
@@ -19,22 +21,18 @@ labels:
 いいえ。XRPLは分散型のパブリックブロックチェーンです。トランザクション処理やコンセンサスに影響を与えるような変更は、ネットワークバリデータの80％以上の承認が必要です。Rippleはネットワークへの貢献者の一員ですが、その権利は他の貢献者たちと同じです。ネットワークには150以上のバリデータが参加しており、うちデフォルトのユニークノードリスト(UNL)に登録されているものは35以上です。Rippleはこれらのうち[1つのノード](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/)を運営しています。
 ユニークノードリスト(UNL)に関しては[ユニークノードリスト（UNL）とは何ですか?](#ユニークノードリストunlとは何ですか)の項目をご覧ください。

-
 #### プルーフ・オブ・ワーク(PoW)が最善の検証メカニズムではないのですか？

 プルーフ・オブ・ワークは、信頼できる第三者を必要とせずに二重支出の問題を解決する最初のコンセンサンス・メカニズムでした。[XRP Ledgerのコンセンサスメカニズム](../docs/concepts/consensus-protocol/index.md)は、同じ問題をはるかに速く、安く、より良いエネルギー効率で解決します。

-
 #### XRPLではXRP以外の通貨も取引できますか？

 はい。XRPLは米ドル、ユーロ、石油、金、リワードポイントなど、任意の資産をトークン化できるように構築されており、どんな通貨でもXRPL上で発行することができます。成長中のXRPLコミュニティは様々なフィアットトークンや暗号通貨をサポートしており、これを裏付けています。

-
 #### XRPLは決済専用ではないのですか？

 いいえ。当初は決済のユースケース向けに開発されましたが、台帳であるXRP Ledgerとそのネイティブ・デジタルアセットであるXRPの両方は、NFTなどのブロックチェーンの革新的ユースケースで更に人気を集めています。自動マーケットメーカー(AMM)、スマートコントラクト機能Hooks、相互運用サイドチェーンの開発などが現在進行中です。

-
 ## バリデータ（検証者）とユニークノードリスト

 #### トランザクション（取引）のバリデータはどのようなサービスを提供するのですか?
@@ -43,27 +41,22 @@ labels:

 コンセンサスプロセスの詳細は、[コンセンサス](../docs/concepts/consensus-protocol/index.md)をご覧ください。

-
 #### バリデータの実行にはいくらかかりますか?

 バリデータを実行するのに手数料やXRPは必要ありません。メールサーバを稼働するための電気代相当です。

-
 #### ユニークノードリスト（UNL）とは何ですか?

 UNLとは、ある参加者が共謀しないと信じるバリデータのリストです。各サーバ運営者は自分のUNLを選ぶことができますが、通常は信頼できる発行元から提供されたデフォルトを参考にします。(信頼できる発行元からのデフォルトセットはデフォルトUNLまたは _dUNL_ と呼ばれることがあります)。

-
 #### どのUNLを選択すればよいですか?

 バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。しかし、すべてのネットワーク参加者は、自身が信頼できるバリデータを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。

-
 #### RippleがそのUNLの採用を推奨しているなら、それは中央集権的なシステムを形成することにならないのですか?

 いいえ。XRP Ledgerネットワークはオプトイン方式です。各参加者は直接的または間接的に自身のUNLを選択することができます。万が一、Rippleが活動を停止したり、Rippleが悪意を持って行動したりした場合、参加者は自身のUNLを変更してXRP Ledgerを引き続き使用することができます。

-
 #### バリデータにとってインセンティブとなるものは何ですか?

 バリデータを運営する主なインセンティブは、ネットワークの安定的な運用と健全な進化を維持・保護することです。XRP Ledgerの進化を決定するのはバリデータであり、XRP Ledgerを利用する、あるいはXRP Ledgerに依存するビジネスには、ネットワークの信頼性と安定性を確保するインセンティブが内在しています。バリデータはまた、このように貢献することでコミュニティからの評価と信頼を得ることができます。
@@ -72,12 +65,10 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ

 インセンティブがどのようにバリデータの行動を歪めるかの例については、[miner extractable value (MEV)](https://arxiv.org/abs/1904.05234)をご覧ください。

-
 #### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?

 いいえ。トランザクション選択のためにカスタマイズされたバリデータポリシーを金融機関が設定することはできません。バリデータは既存のプロトコルに従う、従わないのいずれかを選択します。ソフトウェアは、プロトコルルールに従わない場合は機能しません。そのため、金融機関が社内の専門知識なしにカスタム実装を求めることは推奨されません。

-
 #### ネットワーク内の20%を超えるノードが他の多数ノードと一致しない場合はどうなりますか? レジャー（台帳）の最終バージョンはどのように選択されますか?

 通常、あるトランザクションの有効性について係争があった場合、多数派が合意に達するまでそのトランザクションは保留されます。しかしネットワークの20％超が多数派と同じプロトコルルールに従わなかった場合、ネットワークは一時的に停止します。参加者が互いに合意を得たいUNLに基づいてUNLを再設定すれば再開できます。この一時的な処理の遅延は二重支出よりも望ましいでしょう。
@@ -88,7 +79,6 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ

 XRP Ledgerのコンセンサスメカニズムが不利な状況でどのように動作するかについては、[攻撃と失敗モードに対するコンセンサスの保護](../docs/concepts/consensus-protocol/consensus-protections.md)をご覧ください。

-
 #### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?

 いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。
@@ -97,7 +87,6 @@ XRP Ledgerのコンセンサスメカニズムが不利な状況でどのよう

 推奨事項やベストプラクティスについては、[バリデータとしての`rippled`の実行](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。

-
 #### デフォルトUNL(dUNL)がネットワークに最も影響力を持つなら、XRPLは中央集権的ではないでしょうか？

 バリデータはdUNLや広く使われているUNLを使わないこともできます。誰でもいつでも自由にUNLを作ることができます。
@@ -106,20 +95,16 @@ XRP Ledgerのコンセンサスメカニズムが不利な状況でどのよう

 しかし、もしあなたのUNLが他の人が使っているUNLと十分に重複していなければ、あなたのサーバが他のネットワークからフォークしてしまう危険性があります。あなたのUNLが他の人が使っているUNLと90％以上重なっていれば、フォークから完全に保護されます。重複が少ない場合、同じチェーンをフォローできるかもしれませんが、重複が少ないほど、ネットワークの接続性が悪いほど、UNLに信頼できないバリデータや悪意のあるバリデータがあるほど、フォークする可能性が高くなります。

-
 ## XRPの役割

-
 #### XRPはどのような目的で利用されますか？

 XRPはXRP Ledgerのネイティブ資産として、これまでのどのデジタルアセットよりも速く、環境に優しく、安価な次世代の決済を実現するために作られました。XRPはまた、スパムから台帳を保護し、XRP Ledgerの分散型取引所で[通貨のブリッジ](../docs/concepts/tokens/decentralized-exchange/autobridging.md)を行うことがユーザにとって有益である場合に、その役割を果たします。時間とともに、XRP Ledgerコミュニティは、XRPの新しい[ユースケース](/about/uses)やXRP Ledgerそのものを発展させてきました。

-
 #### XRP Ledgerにおいて大量のトランザクションに対してはどのように対応しますか?

 XRP Ledgerは、スパム対策として、需要に基づいて[トランザクションコスト](../docs/concepts/transactions/transaction-cost.md)を動的に設定するように設計されています。潜在的なXRPの操作による影響は、時価総額とトランザクション量の増加に伴うネットワークサイズの拡大によって最小限に抑えられます。

-
 #### マネーロンダリングや疑わしい経済活動に対して、どのような標準操作手順が実施されていますか?

 XRP Ledgerネットワークはオープンネットワークであり、すべての取引はオープンに公開されています。
@@ -128,10 +113,8 @@ Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、

 [XRP Forensics / xrplorer](https://xrplorer.com/)は、XRP Ledgerのマネーロンダリング、詐欺、詐欺、不正使用を追跡し、最小限に抑えるための勧告リストを維持しています。取引所やその他のサービス・プロバイダは、金融犯罪を防止し対応するためにこのサービスを利用することができます。

-
 ## セキュリティ上の懸念

-
 #### サードパーティにより提供されたコードは審査プロセスはどのようになっていますか？

 コードへの貢献のプロセスは、開発者が[`rippled`リポジトリ](https://github.com/xrplf/rippled/)のようなソースコードリポジトリに[プルリクエスト](https://docs.github.com/ja/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)を行うことから始まります。
@@ -140,7 +123,6 @@ Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、

 プルリクエストが自動テストに合格し、レビュアーの承認を受けると、信頼できる[リポジトリのメンテナ](https://opensource.guide/best-practices/)が次のベータ版に含めるための手続きを行います。

-
 #### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?

 いいえ、RippleはXRP LedgerまたはXRP Ledgerネットワークを所有も管理もしていません。
@@ -149,7 +131,6 @@ Rippleは、コアとなるXRP Ledgerサーバ（[`rippled`](https://github.com/

 いくつかの団体が推奨バリデータリスト（UNL）を公開しています。2023年7月現在、RippleはデフォルトのUNLにある35のバリデータのうち1つのみを実行しています。

-
 #### XRP Ledgerは検証用のコードベースとユーザソフトウェア用のコードベースを区別していますか?

 XRP Ledgerの[クライアントライブラリ](../docs/references/client-libraries.md)は、ソフトウェア開発者向けのものです。これらのライブラリは、ネットワークを支え、トランザクションを検証する[XRP Ledgerのコアサーバ](../docs/concepts/networks-and-servers/index.md)とは異なるコードベースとリポジトリを持っています。
--- a/@l10n/ja/community/report-a-scam.md
+++ b/@l10n/ja/community/report-a-scam.md
@@ -2,27 +2,28 @@
 html: report-a-scam.html
 parent: contribute.html
 ---
+
 # 詐欺の報告

 発展する業界において、信頼とセキュリティは非常に重要ですが、詐欺はクリプトとブロックチェーンの進歩を妨げ続けています。Xrplorer forensicsチームのようなXRP Ledgerコミュニティ全体の個人やチームは、詐欺を報告するための無料ツールを提供することで、これらの詐欺行為を抑制する手助けをしています。

 ## 報告する
+
 詐欺に遭ったと思ったら、詐欺の手口や詐欺業者について、できるだけ早く、できるだけ多くの情報を集めるようにしてください。どのように行動すべきかは以下の方法を確認してください。

 {% admonition type="warning" name="注意" %}誰もXRP Ledgerのアカウントをフリーズしたり、トランザクションを元に戻したりすることはできません。これはXRP Ledgerブロックチェーンの分散型設計によるものです。{% /admonition %}

 1. [Xrplorerの調査チーム](https://xrplorer.com/forensics/submit)に詐欺業者のウォレットアドレスを提出してください。

-     これにより、不正行為に使用されたアカウントにフラグを立て、他のユーザ、ウォレット、および取引所に対する追加の監視、自動追跡、および警告に含めることができます。
+   これにより、不正行為に使用されたアカウントにフラグを立て、他のユーザ、ウォレット、および取引所に対する追加の監視、自動追跡、および警告に含めることができます。

 2. 最寄りの警察署に通報してください。詐欺業者が捕まれば、お金を取り戻せる場合があります。

 3. 詐欺業者が取引所にXRPを送金した場合は、必ず取引所のサポートチームに連絡してください。取引所は詐欺業者の口座をフリーズすることができます。以下は、いくつかの有名な取引所のサポートリンクです。
-
-    - [Binance](https://www.binance.com/en/support)
-    - [Coinbase](https://help.coinbase.com/)
-    - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
-    - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
+   - [Binance](https://www.binance.com/en/support)
+   - [Coinbase](https://help.coinbase.com/)
+   - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
+   - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)

 4. 詐欺業者がXRP Ledger上でXRPを他のトークンと交換した場合、そのトークンの発行者に連絡してください。発行者は[詐欺業者のトラストラインをフリーズする](../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md)ことができるかもしれません。

--- a/@l10n/ja/docs/_snippets/data_types/address.md
+++ b/@l10n/ja/docs/_snippets/data_types/address.md
@@ -1,10 +1,10 @@
 XRP Ledgerのアカウントは、XRP Ledgerの[base58](../../references/protocol/data-types/base58-encodings.md)フォーマットのアドレスで識別されます。このアドレスはアカウントのマスター[公開鍵](https://en.wikipedia.org/wiki/Public-key_cryptography)から生成され、マスター公開鍵は秘密鍵から生成されます。アドレスはJSON文字列で記述され、以下の特徴があります。

-* 長さは25から35文字
-* 文字`r`から始まる
-* 数字"`0`"、大文字"`O`"、大文字"`I`"、小文字"`l`"を除く英数字
-* 大文字と小文字を区別
-* 4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ2<sup>32</sup>分の1
+- 長さは25から35文字
+- 文字`r`から始まる
+- 数字"`0`"、大文字"`O`"、大文字"`I`"、小文字"`l`"を除く英数字
+- 大文字と小文字を区別
+- 4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ2<sup>32</sup>分の1

 {% admonition type="info" name="注記" %}
 [宛先タグ](../../concepts/transactions/source-and-destination-tags.md)をアドレスに「組み込む」**X**アドレス形式もあります。これらのアドレスは`X`（メインネット用）または`T`（[テストネットワーク](../../concepts/networks-and-servers/parallel-networks.md)用）で始まります。取引所とウォレットは、顧客が知る必要のあるすべてのデータを1つの値で表すためにXアドレスを使用できます。詳細については、[Xアドレスフォーマットサイト](https://xrpaddress.info/)と[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)をご覧ください
--- a/@l10n/ja/docs/_snippets/data_types/hash.md
+++ b/@l10n/ja/docs/_snippets/data_types/hash.md
@@ -2,8 +2,8 @@ XRP Ledger内の多くのオブジェクト、特にトランザクションと

 XRP Ledgerのハッシュ値には、以下の特徴があります。

-* 長さは64文字ちょうどです
-* [16進数](https://en.wikipedia.org/wiki/Hexadecimal)の文字セット: 0-9およびA-Fです。
-* 通常は大文字で記述されます。
+- 長さは64文字ちょうどです
+- [16進数](https://en.wikipedia.org/wiki/Hexadecimal)の文字セット: 0-9およびA-Fです。
+- 通常は大文字で記述されます。

 {% admonition type="info" name="注記" %}SHA-512ハーフは、公式に定義されている _SHA-512/256_ ハッシュ関数とほぼ同等のセキュリティーを持ちます。しかし、XRP LedgerはSHA-512/256より前から利用されているため、既存のSHA-512関数上に実装することも容易にできます。（この記事の時点で、暗号ライブラリーでのSHA-512のサポートはSHA-512/256よりはるかに一般的です。）{% /admonition %}
--- a/@l10n/ja/docs/_snippets/data_types/ledger_index.md
+++ b/@l10n/ja/docs/_snippets/data_types/ledger_index.md
@@ -2,6 +2,6 @@

 レジャーインデックスがレジャーの順番を示すのに対し、[ハッシュ][]値はレジャーの正確なコンテンツを示します。2つのレジャーが同じハッシュ値を持つ場合、それらは必ず同じものです。検証済みレジャーでは、ハッシュ値とレジャーインデックスは等しく有効で、1:1の関係です。しかし、進行中のレジャーに対しては、以下の理由によりその限りでありません。

-* ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なる`rippled`サーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
-* 決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります（ハッシュも異なります）。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
-* 現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。
+- ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なる`rippled`サーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
+- 決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります（ハッシュも異なります）。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
+- 現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。
--- a/@l10n/ja/docs/_snippets/data_types/public_key.md
+++ b/@l10n/ja/docs/_snippets/data_types/public_key.md
@@ -1,8 +1,8 @@
 XRP Ledgerは、以下のようなさまざまな状況で暗号署名を検証するために、公開鍵を使用します。

-* トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
-* `rippled`サーバ間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバが起動する場合に、サーバがランダムに生成する「ノード公開鍵」が使用されます。
-* コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。
+- トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
+- `rippled`サーバ間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバが起動する場合に、サーバがランダムに生成する「ノード公開鍵」が使用されます。
+- コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。

 バリデータ公開鍵とノード公開鍵は、まったく同じフォーマットを使用します。

--- a/@l10n/ja/docs/_snippets/etl-source-object.md
+++ b/@l10n/ja/docs/_snippets/etl-source-object.md
@@ -1,13 +1,14 @@
 ### ETLソースオブジェクト
+
 <!-- このネストされたオブジェクトの定義は、server_stateとserver_infoで共通です。 -->

 レポートモードサーバでは、`etl_sources`フィールドの各メンバは以下のフィールドを持つオブジェクトです。

-| フィールド                    | 型    | 説明         |
-|-----------------------------|-------|-------------|
+| フィールド                  | 型     | 説明                                                                                                                                                                                                                                    |
+| --------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `connected`                 | 真偽値 | `true`の場合、レポートモードサーバがこのP2Pモードサーバに接続していることを示します。`false`の場合、サーバに接続していないことを示します。これは設定ミスやネットワーク障害によるものか、P2Pモードサーバが停止している可能性があります。 |
-| `grpc_port`                 | 文字列 | このレポート モードサーバが接続し、gRPCを介してレジャーデータを取得するように設定されている P2P モード サーバのポート番号。 |
-| `ip`                        | 文字列 | P2PモードサーバのIPアドレス（IPv4またはIPv6）。 |
-| `last_message_arrival_time` | 文字列 | レポートモードサーバがこのP2Pサーバからメッセージを受信した最新の時刻を示すISO 8601タイムスタンプ。 |
-| `validated_ledgers_range`   | 文字列 | `complete_ledgers`と同じ形式で、このP2Pモードサーバが利用可能であると報告する、有効なレジャーのバージョンの範囲。 |
-| `websocket_port`            | 文字列 | このレポートモードサーバが、レポートモードから直接提供できないWebSocketリクエストを転送するように設定されているP2Pサーバのポート番号。 |
+| `grpc_port`                 | 文字列 | このレポート モードサーバが接続し、gRPCを介してレジャーデータを取得するように設定されている P2P モード サーバのポート番号。                                                                                                             |
+| `ip`                        | 文字列 | P2PモードサーバのIPアドレス（IPv4またはIPv6）。                                                                                                                                                                                         |
+| `last_message_arrival_time` | 文字列 | レポートモードサーバがこのP2Pサーバからメッセージを受信した最新の時刻を示すISO 8601タイムスタンプ。                                                                                                                                     |
+| `validated_ledgers_range`   | 文字列 | `complete_ledgers`と同じ形式で、このP2Pモードサーバが利用可能であると報告する、有効なレジャーのバージョンの範囲。                                                                                                                       |
+| `websocket_port`            | 文字列 | このレポートモードサーバが、レポートモードから直接提供できないWebSocketリクエストを転送するように設定されているP2Pサーバのポート番号。                                                                                                  |
--- a/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
+++ b/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
@@ -1,4 +1,4 @@
-<!-- Interactive tutorials are hard-coded to Testnet for now due to Redocly 
+<!-- Interactive tutorials are hard-coded to Testnet for now due to Redocly
     limitations. They'll be replaced with new-style tutorials next anyway.
     Localized step names don't currently work due to problems with unicode
     in regexes. -->
@@ -6,11 +6,12 @@
 {% interactive-block label=default($label, "Connect") steps=$frontmatter.steps %}

 <button id="connect-button" class="btn btn-primary" data-wsurl="wss://s.altnet.rippletest.net:51233" data-explorer="https://testnet.xrpl.org">Testnetに接続する</button>
+
 <div>
  <strong>接続ステータス：</strong>
  <span id="connection-status">接続されていません</span>

-  {% loading-icon /%}
+{% loading-icon /%}

 </div>

--- a/@l10n/ja/docs/_snippets/interactive-tutorials/generate-step.md
+++ b/@l10n/ja/docs/_snippets/interactive-tutorials/generate-step.md
@@ -2,6 +2,7 @@

 <button id="generate-creds-button" class="btn btn-primary" data-fauceturl="https://faucet.altnet.rippletest.net/accounts">Testnetの暗号鍵を作成する</button>
 {% loading-icon message="暗号鍵を作成しています…" /%}
+
 <div class="output-area"></div>

 {% /interactive-block %}
--- a/@l10n/ja/docs/_snippets/issuing-and-operational-addresses-intro.md
+++ b/@l10n/ja/docs/_snippets/issuing-and-operational-addresses-intro.md
@@ -1,5 +1,5 @@
 XRP Ledgerでは、金融機関は秘密鍵の漏えいに関連するリスクを最小限に抑えるために、複数のXRP Ledgerアドレスを使用するのが一般的です。業界標準では、以下のような役割分担をしています。

-* 1つの**発行アドレス**。「コールドウォレット」とも呼ばれます。このアドレスは、レジャーでの金融機関の会計上の関係の中心となるものですが、トランザクションの送信は可能な限り少なく抑えます。
-* 1つ以上の**運用アドレス**。「ホットウォレット」とも呼ばれます。インターネットに接続した自動システムが、これらのアドレスへの秘密鍵を使用して、顧客やパートナーへの送金といった日常業務を実施します。
-* オプションの**待機アドレス**。「ウォームウォレット」とも呼ばれます。信頼できる人間のオペレーターが、これらのアドレスを使用して運用アドレスに送金します。
+- 1つの**発行アドレス**。「コールドウォレット」とも呼ばれます。このアドレスは、レジャーでの金融機関の会計上の関係の中心となるものですが、トランザクションの送信は可能な限り少なく抑えます。
+- 1つ以上の**運用アドレス**。「ホットウォレット」とも呼ばれます。インターネットに接続した自動システムが、これらのアドレスへの秘密鍵を使用して、顧客やパートナーへの送金といった日常業務を実施します。
+- オプションの**待機アドレス**。「ウォームウォレット」とも呼ばれます。信頼できる人間のオペレーターが、これらのアドレスを使用して運用アドレスに送金します。
--- a/@l10n/ja/docs/_snippets/peer_reservation_object.md
+++ b/@l10n/ja/docs/_snippets/peer_reservation_object.md
@@ -1,4 +1,4 @@
-| `Field`       | 型     | 説明                                                |
-|:--------------|:-------|:----------------------------------------------------|
-| `node`        | 文字列  | この予約の対象となるピアサーバの[ノード公開鍵][]（[base58][]）。 |
-| `description` | 文字列  | _（省略される場合があります）_ このピアリザベーションの説明（ある場合）。 |
+| `Field`       | 型     | 説明                                                                      |
+| :------------ | :----- | :------------------------------------------------------------------------ |
+| `node`        | 文字列 | この予約の対象となるピアサーバの[ノード公開鍵][]（[base58][]）。          |
+| `description` | 文字列 | _（省略される場合があります）_ このピアリザベーションの説明（ある場合）。 |
--- a/@l10n/ja/docs/_snippets/port-descriptor-object.md
+++ b/@l10n/ja/docs/_snippets/port-descriptor-object.md
@@ -1,11 +1,12 @@
 ### ポート記述子オブジェクト
+
 <!-- このネストされたオブジェクトの定義は、server_stateとserver_infoで共通です。 -->

 `ports`配列の各メンバーは以下のフィールドを持つオブジェクトです。

-| フィールド   | 値          | 説明         |
-|------------|-------------|-------------|
-| `port`     | 文字列 - 数値 | サーバがリッスンしているポート番号。 |
+| フィールド | 値            | 説明                                                                                                                                                                                                                                                                                                         |
+| ---------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `port`     | 文字列 - 数値 | サーバがリッスンしているポート番号。                                                                                                                                                                                                                                                                         |
 | `protocol` | 文字列の配列  | このポートに接続されているプロトコルの一覧。有効なプロトコルには、JSON-RPCの`http`または`https`、WebSocketの`ws`、`ws2`、`wss`、`wss2`、[gRPC](../infrastructure/configuration/configure-grpc.md)の`grpc`、[XRP Ledgerピアプロトコル](../concepts/networks-and-servers/peer-protocol.md)の`peer`があります。 |

 {% admonition type="info" name="注記" %}ネットワークインフラによっては、ここで報告されるポートやプロトコルが、外部のネットワークからサーバに到達する方法と一致しないことがあります。例えば、TLSがロードバランサやプロキシで終了する場合、サーバはあるポートで`http`と報告するかもしれませんが、外部からはポート443の`https`でしか到達できないかもしれません。{% /admonition %}
--- a/@l10n/ja/docs/_snippets/string-number-formatting.md
+++ b/@l10n/ja/docs/_snippets/string-number-formatting.md
@@ -1,8 +1,8 @@
 XRP LedgerのAPIでは、[XRP](../introduction/what-is-xrp.md)と[トークン](../concepts/tokens/index.md)の両方で、通貨の金額を数値で表現するために、JSONのネイティブの数値ではなく文字列を使用します。これは、JSONパーサーが自動的にすべてのJSON数値を浮動小数点形式で表現しようとする可能性がある場合に、精度の低下を防ぐためです。String値の中では、数値はネイティブのJSON数値と同じ方法で処理されます。

-* 10進数
-* ゼロの接頭辞なし
-* 小数点として`.`を含むことができます。例えば、½は`0.5`と表されます
-* 負の金額は`-`から始まります
-* `E`または`e`は10の累乗（科学的記数法）を表します。例えば`1.2E5`は1.2×10<sup>5</sup>つまり`120000`と同じです。負の指数も可能です。
-* カンマ(`,`)は使用しません。
+- 10進数
+- ゼロの接頭辞なし
+- 小数点として`.`を含むことができます。例えば、½は`0.5`と表されます
+- 負の金額は`-`から始まります
+- `E`または`e`は10の累乗（科学的記数法）を表します。例えば`1.2E5`は1.2×10<sup>5</sup>つまり`120000`と同じです。負の指数も可能です。
+- カンマ(`,`)は使用しません。
--- a/@l10n/ja/docs/_snippets/tx-metadata-field-table.md
+++ b/@l10n/ja/docs/_snippets/tx-metadata-field-table.md
@@ -1,7 +1,7 @@
-| フィールド                                 | 値               | 説明    |
-|:--------------------------------------|:--------------------|:---------------|
-| `AffectedNodes`                       | 配列               | このトランザクションで作成、削除、または修正された[レジャーオブジェクト](../references/protocol/ledger-data/ledger-entry-types/index.md)のリストと、個々のオブジェクトに対する具体的な変更内容。 |
-| `DeliveredAmount`                     | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | **廃止予定。**`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。 |
-| `TransactionIndex`                    | 符号なし整数    | トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。（例えば、値が`2`の場合、そのレジャーの3番目のトランザクションであったことを意味します）。 |
-| `TransactionResult`                   | 文字列              | トランザクションが成功したか、どのような理由で失敗したかを示す[結果コード](../references/protocol/transactions/transaction-results/index.md)。 |
+| フィールド                                                                             | 値                                                                           | 説明                                                                                                                                                                                                                       |
+| :------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `AffectedNodes`                                                                        | 配列                                                                         | このトランザクションで作成、削除、または修正された[レジャーオブジェクト](../references/protocol/ledger-data/ledger-entry-types/index.md)のリストと、個々のオブジェクトに対する具体的な変更内容。                           |
+| `DeliveredAmount`                                                                      | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | **廃止予定。**`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。                                                                                                                             |
+| `TransactionIndex`                                                                     | 符号なし整数                                                                 | トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。（例えば、値が`2`の場合、そのレジャーの3番目のトランザクションであったことを意味します）。                                  |
+| `TransactionResult`                                                                    | 文字列                                                                       | トランザクションが成功したか、どのような理由で失敗したかを示す[結果コード](../references/protocol/transactions/transaction-results/index.md)。                                                                             |
 | [`delivered_amount`](../references/protocol/transactions/metadata.md#delivered_amount) | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | `Destination`アカウントが実際に受取った通貨額。このフィールドは、トランザクションが[Partial Payments](../concepts/payment-types/partial-payments.md)であるかどうかにかかわらず、送金された金額を特定するために使用します。 |
--- a/@l10n/ja/docs/concepts/accounts/account-types.md
+++ b/@l10n/ja/docs/concepts/accounts/account-types.md
@@ -2,21 +2,21 @@
 html: account-types.html
 parent: accounts.html
 seo:
-    description: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
+  description: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
 labels:
  - トークン
  - セキュリティ
 ---
+
 # アカウントの種類

 {% partial file="/@l10n/ja/docs/_snippets/issuing-and-operational-addresses-intro.md" /%}

-
 ## 資金のライフサイクル

 トークン発行者がこのような役割を分担すると、以下の図のように資金が一方向に流れるようになります。

-[{% inline-svg file="/docs/img/issued-currency-funds-flow.ja.svg" /%}](/docs/img/issued-currency-funds-flow.ja.svg "図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー")
+[{% inline-svg file="/docs/img/issued-currency-funds-flow.ja.svg" /%}](/docs/img/issued-currency-funds-flow.ja.svg '図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー')

 発行アドレスは、待機アドレスに支払いを送信することでトークンを作成します。これらのトークンは(多くの場合)債務を表すため、発行アドレスの観点からはマイナスの価値を持ちます。同じトークンは、待機アドレスの観点も含めると、他の観点からはプラスの価値を持ちます。

@@ -42,7 +42,6 @@ labels:

 金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行することができます。ただし、[送金手数料](../tokens/fungible-tokens/transfer-fees.md)のパーセンテージや[Global Freeze](../tokens/fungible-tokens/freezes.md)の状態など、1つのアドレスから発行される全ての(代替可能)トークンに等しく適用される設定もあります。トークンの種類ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。

-
 ## 運用アドレス

 運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わって支払いを行います。トランザクションに自動的に署名するには、運用アドレスの秘密鍵をインターネットに接続されたサーバに保管する必要があります。(秘密鍵は暗号化して保管できますが、サーバがトランザクションに署名する際に秘密鍵を復号化する必要があります。)顧客やパートナーは、運用アドレスへのトラストラインを作成しませんし、作成すべきではありません。
@@ -66,18 +65,17 @@ labels:

 待機アドレスの秘密鍵が漏えいした場合、その影響は運用アドレスの場合と同じです。悪意のある第三者は、待機アドレスが保有するすべての残高を盗むことができ、金融機関は顧客やパートナーが何もしなくても、新しい待機アドレスに切り替えることができます。

-
 ## 関連項目

 - **コンセプト:**
-    - [アカウント](index.md)
-    - [暗号鍵](cryptographic-keys.md)
+  - [アカウント](index.md)
+  - [暗号鍵](cryptographic-keys.md)
 - **チュートリアル:**
-    - [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
-    - [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+  - [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+  - [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
 - **リファレンス:**
-    - [account_infoメソッド][]
-    - [SetRegularKeyトランザクション][]
-    - [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+  - [account_infoメソッド][]
+  - [SetRegularKeyトランザクション][]
+  - [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/addresses.md
+++ b/@l10n/ja/docs/concepts/accounts/addresses.md
@@ -2,10 +2,11 @@
 html: addresses.html
 parent: accounts.html
 seo:
-    description: アドレスは、base58フォーマットを使用して、XRP Ledgerのアカウントを一意に識別します。
+  description: アドレスは、base58フォーマットを使用して、XRP Ledgerのアカウントを一意に識別します。
 labels:
  - アカウント
 ---
+
 # アドレス

 {% partial file="/@l10n/ja/docs/_snippets/data_types/address.md" /%}
@@ -14,19 +15,17 @@ labels:

 キーペアの生成を始めとする有効なアドレスの作成は、厳密には数学的な作業です。キーペアの生成とアドレスの計算は、XRP Ledgerや他のいかなる第三者とも通信することなく、完全にオフラインで行うことができます。公開鍵からアドレスへの変換には一方向ハッシュ関数が使用されるため、公開鍵とアドレスの一致を確認することは可能ですが、アドレスのみから公開鍵を導き出すことは不可能です。(これが署名付きトランザクションに公開鍵と送信者のアドレスを含める理由の一部です)。

-
 ## 特別なアドレス

 XRP Ledgerでは、特別な意味や歴史的な役割を持つアドレスがあります。多くの場合、これらは"ブラックホール"アドレスであり、そのアドレスは既知の秘密鍵に由来するものではありません。アドレスから秘密鍵を推測することは事実上不可能であるため、ブラックホールアドレスが保有するXRPは永遠に失われます。

-| アドレス                       | 名称 | 意味 | ブラック ホール? |
-|-------------------------------|-----|-----|----------------|
-| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | 値0を[base58][]形式にエンコードしたXRP Ledgerのアドレス。ピアツーピア通信では、このアドレスは、XRPの発行者として`rippled`で使用されます。 | はい |
-| `rrrrrrrrrrrrrrrrrrrrBZbvji`  | ACCOUNT\_ONE | 値1を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleStateエントリ](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。 | はい |
-| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | ジェネシスアカウント | `rippled`で(スタンドアロンモードなど)新しいジェネシスレジャーが一から開始される場合、このアカウントはすべてのXRPを保持します。このアドレスは、シード値`masterpassphrase`から生成されており、この値は[ハードコーディング](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
-| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Namesの登録用ブラックホール | 以前、Ripple社は、Ripple Namesを登録するために、このアカウントにXRPを送金するようユーザに求めていました。| はい |
-| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
-
+| アドレス                             | 名称                               | 意味                                                                                                                                                                                                                                                                                                                                                         | ブラック ホール? |
+| ------------------------------------ | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- |
+| `rrrrrrrrrrrrrrrrrrrrrhoLvTp`        | ACCOUNT_ZERO                       | 値0を[base58][]形式にエンコードしたXRP Ledgerのアドレス。ピアツーピア通信では、このアドレスは、XRPの発行者として`rippled`で使用されます。                                                                                                                                                                                                                    | はい             |
+| `rrrrrrrrrrrrrrrrrrrrBZbvji`         | ACCOUNT_ONE                        | 値1を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleStateエントリ](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。                                                                                                      | はい             |
+| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | ジェネシスアカウント               | `rippled`で(スタンドアロンモードなど)新しいジェネシスレジャーが一から開始される場合、このアカウントはすべてのXRPを保持します。このアドレスは、シード値`masterpassphrase`から生成されており、この値は[ハードコーディング](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ           |
+| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ`        | Ripple Namesの登録用ブラックホール | 以前、Ripple社は、Ripple Namesを登録するために、このアカウントにXRPを送金するようユーザに求めていました。                                                                                                                                                                                                                                                    | はい             |
+| `rrrrrrrrrrrrrrrrrrrn5RM1rHd`        | NaNアドレス                        | 以前のバージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。                                                                                  | はい             |

 ## アドレスのエンコード

@@ -38,58 +37,58 @@ XRP Ledgerのアドレスは、[base58][]形式の _ディクショナリ_ `rpsh

 次の図は、キーとアドレスの関係を示しています

-[{% inline-svg file="/docs/img/address-encoding.ja.svg" /%}](/docs/img/address-encoding.ja.svg "マスター公開鍵 + タイプ接頭辞 → アカウントID + チェックサム → アドレス")
+[{% inline-svg file="/docs/img/address-encoding.ja.svg" /%}](/docs/img/address-encoding.ja.svg 'マスター公開鍵 + タイプ接頭辞 → アカウントID + チェックサム → アドレス')

 公開鍵からXRP Ledgerアドレスを計算する式は次の通りです。完全なサンプルコードついては、[`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/_code-samples/address_encoding/js/encode_address.js)をご覧ください。パスフレーズまたはシード値から公開鍵を導出するプロセスについては、[鍵の導出](cryptographic-keys.md#鍵導出)をご覧ください。

 1. 次の必須アルゴリズムをインポートします。SHA-256、RIPEMD160、base58。base58のディクショナリを設定します。

-    ```
-    'use strict';
-    const assert = require('assert');
-    const crypto = require('crypto');
-    const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
-    const base58 = require('base-x')(R_B58_DICT);
+   ```
+   'use strict';
+   const assert = require('assert');
+   const crypto = require('crypto');
+   const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
+   const base58 = require('base-x')(R_B58_DICT);

-    assert(crypto.getHashes().includes('sha256'));
-    assert(crypto.getHashes().includes('ripemd160'));
-    ```
+   assert(crypto.getHashes().includes('sha256'));
+   assert(crypto.getHashes().includes('ripemd160'));
+   ```

 2. 33バイトのECDSA secp256k1公開鍵、または32バイトのEd25519公開鍵で始めます。Ed25519キーの場合は、キーの前にバイト文字`0xED`を付与します。

-    ```
-    const pubkey_hex =
-      'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
-    const pubkey = Buffer.from(pubkey_hex, 'hex');
-    assert(pubkey.length == 33);
-    ```
+   ```
+   const pubkey_hex =
+     'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
+   const pubkey = Buffer.from(pubkey_hex, 'hex');
+   assert(pubkey.length == 33);
+   ```

 3. 公開鍵のSHA-256ハッシュの[RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD)ハッシュを計算します。この値は「Account ID」です。

-    ```
-    const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
-    const pubkey_outer_hash = crypto.createHash('ripemd160');
-    pubkey_outer_hash.update(pubkey_inner_hash.digest());
-    const account_id = pubkey_outer_hash.digest();
-    ```
+   ```
+   const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
+   const pubkey_outer_hash = crypto.createHash('ripemd160');
+   pubkey_outer_hash.update(pubkey_inner_hash.digest());
+   const account_id = pubkey_outer_hash.digest();
+   ```

 4. アカウントIDのSHA-256ハッシュのSHA-256ハッシュを計算します。最初の4バイトを使用します。この値が「チェックサム」です。

-    ```
-    const address_type_prefix = Buffer.from([0x00]);
-    const payload = Buffer.concat([address_type_prefix, account_id]);
-    const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
-    const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
-    const checksum =  chksum_hash2.slice(0,4);
-    ```
+   ```
+   const address_type_prefix = Buffer.from([0x00]);
+   const payload = Buffer.concat([address_type_prefix, account_id]);
+   const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
+   const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
+   const checksum =  chksum_hash2.slice(0,4);
+   ```

 5. ペイロードとチェックサムを連結します。連結バッファーのbase58値を計算します。この結果が、アドレスになります。

-    ```
-    const dataToEncode = Buffer.concat([payload, checksum]);
-    const address = base58.encode(dataToEncode);
-    console.log(address);
-    // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
-    ```
+   ```
+   const dataToEncode = Buffer.concat([payload, checksum]);
+   const address = base58.encode(dataToEncode);
+   console.log(address);
+   // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
+   ```

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
+++ b/@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
@@ -2,11 +2,12 @@
 html: cryptographic-keys.html
 parent: accounts.html
 seo:
-    description: 暗号鍵を使用してトランザクションを承認し、XRP Ledgerがトランザクションを実行できるようにします。
+  description: 暗号鍵を使用してトランザクションを承認し、XRP Ledgerがトランザクションを実行できるようにします。
 labels:
  - セキュリティ
  - スマートコントラクト
 ---
+
 # 暗号鍵

 XRP Ledgerでは、[トランザクション](../transactions/index.md)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
@@ -21,14 +22,13 @@ XRP Ledgerでは、[トランザクション](../transactions/index.md)による

 注：ツールによってデフォルト値が異なります。多くのクライアントライブラリ（xrpl.jsなど）は、デフォルトの暗号化アルゴリズムとしてEd25519を使用していますが、rippledの管理者向けRPCコマンドである[wallet_propose](../../references/http-websocket-apis/admin-api-methods/key-generation-methods/wallet_propose.md)は、デフォルトとしてsecp256k1を使用しています。つまり、アルゴリズムを明示的に指定しない限り、同じシードから別のツールを使用してウォレットを生成すると、異なるアドレスが生成される可能性があります。

-
 ## キーの構成要素

 暗号鍵ペアは、鍵の導出プロセスを通じて数学的に関連づけられる**秘密鍵**と**公開鍵**のことです。秘密鍵は、強力なランダム性によって決定されなければなりません。[暗号化署名アルゴリズム](#署名アルゴリズム)は、鍵の導出プロセスを定義し、暗号鍵となり得る数値の制限を設定します。

 XRP Ledgerを扱う場合、パスフレーズ、シード、アカウントID、アドレスなど、いくつかの関連する値を使用することもあります。

-[{% inline-svg file="/docs/img/cryptographic-keys.ja.svg" /%}](/docs/img/cryptographic-keys.ja.svg "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス")
+[{% inline-svg file="/docs/img/cryptographic-keys.ja.svg" /%}](/docs/img/cryptographic-keys.ja.svg 'Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス')
 _図: 暗号鍵の値の関係を簡略化した図_

 パスフレーズ、シード、秘密鍵は**秘密情報**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
@@ -61,7 +61,6 @@ _秘密鍵_ は、デジタル署名を作成するために使用される値

 XRP Ledgerのトランザクションには、ネットワークがトランザクションの署名を検証できるように、公開鍵が含まれている必要があります。公開鍵は有効な署名を作成するために使用することはできないので、公開しても問題はありません。

-
 ### アカウントIDとアドレス

 **アカウントID**は、[アカウント](index.md)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
@@ -81,7 +80,6 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ

 [wallet_proposeメソッド][]の`key_type`フィールドは、使用する暗号化署名アルゴリズムを指します。

-
 ## マスターキーペア

 マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](addresses.md#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
@@ -94,8 +92,6 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ

 マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。

-
-
 ### 特殊な権限

 **マスターキーペアのみ**が、ある特定の処理を行うトランザクションを承認することができます。
@@ -110,7 +106,6 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ

 レギュラーキーや[マルチシグ](multi-signing.md)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](deleting-accounts.md)を行うことも可能です。

-
 ## レギュラーキーペア

 XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセカンダリキーペアを許可することができます。そうすると、[マスターキーペア](#マスターキーペア)とレギュラーキーのどちらかを使ってトランザクションを承認することができるようになります。レギュラーキーペアは、アカウントの他の部分を変更することなく、いつでも削除または変更することができます。
@@ -123,28 +118,25 @@ XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセ

 [SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)をご覧ください

-
 ## 署名アルゴリズム

 暗号鍵ペアは常に特定の署名アルゴリズムに関連付けられています。署名アルゴリズムは、秘密鍵と公開鍵の間の数学的関係を定義します。暗号化署名アルゴリズムには、現在の暗号技術では、秘密鍵を使用して対応する公開鍵を「簡単に」計算できるものの、公開鍵から対応する秘密鍵を計算することは実質的に不可能であるという特性があります。

 XRP Ledgerでは次の暗号化署名アルゴリズムがサポートされています。

-| キータイプ | アルゴリズム | 説明 |
-|-------------|-----------|---|
-| `secp256k1` | 楕円曲線[secp256k1](https://en.bitcoin.it/wiki/Secp256k1)を使用する[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) | これはBitcoinで使用されているスキームです。XRP Ledgerではデフォルトでこのキータイプが使用されます。 |
-| `ed25519` | 楕円曲線[Ed25519](https://ed25519.cr.yp.to/)を使用する[EdDSA](https://tools.ietf.org/html/rfc8032) | パフォーマンスに優れ、その他の便利な特性を備えた新しいアルゴリズムです。Ed25519公開鍵はsecp256k1鍵よりも1バイト短いため、`rippled`ではEd25519公開鍵の先頭に`0xED`バイトが追加されます。これにより、両方の公開鍵タイプは33バイトになります。 |
+| キータイプ  | アルゴリズム                                                                                                                                         | 説明                                                                                                                                                                                                                                        |
+| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `secp256k1` | 楕円曲線[secp256k1](https://en.bitcoin.it/wiki/Secp256k1)を使用する[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) | これはBitcoinで使用されているスキームです。XRP Ledgerではデフォルトでこのキータイプが使用されます。                                                                                                                                         |
+| `ed25519`   | 楕円曲線[Ed25519](https://ed25519.cr.yp.to/)を使用する[EdDSA](https://tools.ietf.org/html/rfc8032)                                                   | パフォーマンスに優れ、その他の便利な特性を備えた新しいアルゴリズムです。Ed25519公開鍵はsecp256k1鍵よりも1バイト短いため、`rippled`ではEd25519公開鍵の先頭に`0xED`バイトが追加されます。これにより、両方の公開鍵タイプは33バイトになります。 |

 [wallet_proposeメソッド][]を使用してキーペアを生成するときには、キーの生成に使用する暗号化署名アルゴリズムを選択するため`key_type`を指定できます。デフォルト以外のキータイプを生成した場合は、トランザクションに署名する際に`key_type`も指定する必要があります。

 XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](addresses.md#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。

-
 ### 将来のアルゴリズム

 今後、暗号技術の発展に対応するため、XRP Ledgerには新しい暗号化署名アルゴリズムが必要になるでしょう。例えば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピュータの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合、XRP Ledger開発者は容易に解読できない暗号化署名アルゴリズムを追加できます。2019年半ばの時点で、確実な第一選択肢となる「耐量子」署名アルゴリズムはなく、量子コンピュータはまだ脅威となるほど実用的ではないため、現時点では特定のアルゴリズムを追加する予定はありません。

-
 ## 鍵導出

 キーペアを導出するプロセスは、署名アルゴリズムによって異なります。いずれの場合も、キーは長さが16バイト（128ビット）の _シード_ 値から生成されます。シード値は完全にランダムにする（推奨）か、[SHA-512ハッシュ][ハッシュ]を取得して最初の16バイトを保持することで特定のパスフレーズから導出することができます（[SHA-512Half][]と同様ですが、出力の256ビットではなく128ビットのみを保持します）。
@@ -154,37 +146,39 @@ XRP Ledgerでは、サポートされているさまざまなタイプのキー
 ここで説明する鍵導出プロセスは、さまざまなプログラミング言語で複数の場所に実装されています。

 - C++: `rippled`コードベース:
-    - [シード定義](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
-    - [汎用キー & Ed25519鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
-    - [secp256k1鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+  - [シード定義](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
+  - [汎用キー & Ed25519鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+  - [secp256k1鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
 - Python 3: {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}このリポジトリのコードサンプルセクション{% /repo-link %}
 - JavaScript: [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs)パッケージ

 ### Ed25519鍵導出
+
 [[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")

-[{% inline-svg file="/docs/img/key-derivation-ed25519.ja.svg" /%}](/docs/img/key-derivation-ed25519.ja.svg "パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵")
+[{% inline-svg file="/docs/img/key-derivation-ed25519.ja.svg" /%}](/docs/img/key-derivation-ed25519.ja.svg 'パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵')

 1. シード値の[SHA-512Half][]を計算します。32バイトの秘密鍵が導出されます。

-    {% admonition type="success" name="ヒント" %}32バイトの数値はすべて、有効なEd25519秘密鍵です。ただし、秘密鍵として使用する上で安全なのは、十分ランダムに選択された数値のみです。{% /admonition %}
+   {% admonition type="success" name="ヒント" %}32バイトの数値はすべて、有効なEd25519秘密鍵です。ただし、秘密鍵として使用する上で安全なのは、十分ランダムに選択された数値のみです。{% /admonition %}

 2. Ed25519公開鍵を計算するには、[Ed25519](https://ed25519.cr.yp.to/software.html)の標準公開鍵を導出して、32バイトの公開鍵を導出します。

-    {% admonition type="warning" name="注意" %}暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519やsecp256k1が実装されています。{% /admonition %}
+   {% admonition type="warning" name="注意" %}暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519やsecp256k1が実装されています。{% /admonition %}

 3. Ed25519公開鍵を示すには、32バイトの公開鍵の前にシングルバイトのプレフィクス`0xED`を付加し、33バイトにします。

-    トランザクションに署名するコードを実装している場合は、プレフィクス`0xED`を削除し、実際の署名プロセスに32バイトキーを使用します。
+   トランザクションに署名するコードを実装している場合は、プレフィクス`0xED`を削除し、実際の署名プロセスに32バイトキーを使用します。

 4. アカウントの公開鍵を[base58][]にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。

-    バリデータの一時キーにEd25519を使用することはできません。
+   バリデータの一時キーにEd25519を使用することはできません。

 ### secp256k1鍵導出
+
 [[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")

-[{% inline-svg file="/docs/img/key-derivation-secp256k1.ja.svg" /%}](/docs/img/key-derivation-secp256k1.ja.svg "パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア")
+[{% inline-svg file="/docs/img/key-derivation-secp256k1.ja.svg" /%}](/docs/img/key-derivation-secp256k1.ja.svg 'パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア')

 XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よりも多くの手順が含まれる理由は次のとおりです。

@@ -194,68 +188,64 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
 シード値からXRP Ledgerのsecp256k1アカウントキーペアを導出する手順は次のとおりです。

 1. 次のように、シード値から「ルートキーペア」を計算します。
+   1. 以下を順番に連結して、合計20バイトにします。
+      - シード値（16バイト）
+      - 「ルートシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。ルートシーケンスの開始値として0を使用します。

-    1. 以下を順番に連結して、合計20バイトにします。
-        - シード値（16バイト）
-        - 「ルートシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。ルートシーケンスの開始値として0を使用します。
+   2. 連結された（シード+ルートシーケンス）値の[SHA-512Half][]を計算します。

-    2. 連結された（シード+ルートシーケンス）値の[SHA-512Half][]を計算します。
+   3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")

-    3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
+      有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。

-        有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。
+   4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、ルート公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）

-    4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、ルート公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
-
-    {% admonition type="success" name="ヒント" %}バリデータではこのルートキーペアを使用します。バリデータのキーペアを計算する場合は、ここで停止できます。この2つのタイプの公開鍵を区別するには、バリデータの公開鍵の[base58][]シリアル化でプレフィクス`0x1c`を使用します。{% /admonition %}
+   {% admonition type="success" name="ヒント" %}バリデータではこのルートキーペアを使用します。バリデータのキーペアを計算する場合は、ここで停止できます。この2つのタイプの公開鍵を区別するには、バリデータの公開鍵の[base58][]シリアル化でプレフィクス`0x1c`を使用します。{% /admonition %}

 2. ルート公開鍵を33バイトの圧縮形式に変換します。

-    ECDSA公開鍵の非圧縮形式は、32バイト整数のペア（X座標とY座標）で構成されます。圧縮形式は、X座標と1バイトのプレフィクスのみで構成されます。Y座標が偶数の場合は`0x02`、Y座標が奇数の場合は`0x03`です。
+   ECDSA公開鍵の非圧縮形式は、32バイト整数のペア（X座標とY座標）で構成されます。圧縮形式は、X座標と1バイトのプレフィクスのみで構成されます。Y座標が偶数の場合は`0x02`、Y座標が奇数の場合は`0x03`です。

   非圧縮形式の公開鍵を圧縮形式に変換するには、`openssl`コマンドラインツールを使用します。例えば、非圧縮の公開鍵がファイル`ec-pub.pem`にある場合は、次のような圧縮形式を出力できます。

-    ```
-    $ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
-    ```
+   ```
+   $ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
+   ```

 3. 次のように、圧縮されたルート公開鍵から「仲介銀行（機関）キーペア」を導出します。
+   1. 以下を順番に連結して、合計40バイトにします。
+      - 圧縮されたルート公開鍵（33バイト）
+      - `0x00000000000000000000000000000000`(4バイトのゼロ)（この値は、同じファミリーの異なるメンバーの導出に使用することを目的としていましたが、実際には値0のみが使用されます。）
+      - 「キーシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。キーシーケンスの開始値として0を使用します。

-    1. 以下を順番に連結して、合計40バイトにします。
-        - 圧縮されたルート公開鍵（33バイト）
-        - `0x00000000000000000000000000000000`(4バイトのゼロ)（この値は、同じファミリーの異なるメンバーの導出に使用することを目的としていましたが、実際には値0のみが使用されます。）
-        - 「キーシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。キーシーケンスの開始値として0を使用します。
+   2. 連結された値の[SHA-512Half][]を計算します。

-    2. 連結された値の[SHA-512Half][]を計算します。
+   3. 結果が有効なsecp256k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。

-    3. 結果が有効なsecp256k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。
-
-    4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、仲介銀行（機関）公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
+   4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、仲介銀行（機関）公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）

 4. 仲介銀行（機関）公開鍵をルート公開鍵に追加して、マスター公開鍵ペアを導出します。同様に、仲介銀行（機関）秘密鍵をルート秘密鍵に追加して秘密鍵を導出します。
+   - ECDSA秘密鍵は非常に大きな整数値であるため、secp256k1グループ順序を法として2つの秘密鍵を合計することで、2つの秘密鍵の合計を計算できます。

-    - ECDSA秘密鍵は非常に大きな整数値であるため、secp256k1グループ順序を法として2つの秘密鍵を合計することで、2つの秘密鍵の合計を計算できます。
-
-    - ECDSA公開鍵は楕円曲線上の点であるため、楕円曲線の数値を使用して点の合計値を計算する必要があります。
+   - ECDSA公開鍵は楕円曲線上の点であるため、楕円曲線の数値を使用して点の合計値を計算する必要があります。

 5. 以前と同様に、マスター公開鍵を33バイトの圧縮形式に変換します。

 6. アカウントの公開鍵を[base58][]形式にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。

-    アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.md#アドレスのエンコード)をご覧ください。
-
+   アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.md#アドレスのエンコード)をご覧ください。

 ## 関連項目

 - **コンセプト:**
-    - [発行アドレスと運用アドレス](account-types.md)
+  - [発行アドレスと運用アドレス](account-types.md)
 - **チュートリアル:**
-    - [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
-    - [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+  - [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+  - [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
 - **リファレンス:**
-    - [SetRegularKeyトランザクション][]
-    - [AccountRootレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
-    - [wallet_proposeメソッド][]
-    - [account_infoメソッド][]
+  - [SetRegularKeyトランザクション][]
+  - [AccountRootレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+  - [wallet_proposeメソッド][]
+  - [account_infoメソッド][]

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/deleting-accounts.md
+++ b/@l10n/ja/docs/concepts/accounts/deleting-accounts.md
@@ -2,10 +2,11 @@
 html: deleting-accounts.html
 parent: accounts.html
 seo:
-    description: XRP Ledgerのアカウントの削除について。
+  description: XRP Ledgerのアカウントの削除について。
 labels:
  - アカウント
 ---
+
 # アカウントの削除

 アカウントの所有者は[AccountDeleteトランザクション][]を送信することで、レジャーからアカウントと関連するエントリを削除し、アカウントの残りのXRP残高のほとんどを別のアカウントに送ることができます。アカウントの無駄な作成と削除を抑止するため、アカウントの削除には[トランザクションコスト](../transactions/transaction-cost.md)として通常よりも多くのXRPをバーンする必要があります。
@@ -13,22 +14,19 @@ labels:
 いくつかの種類のレジャーエントリを保有している場合、アカウントの削除がブロックされます。たとえば、(代替可能)トークンの発行者は、そのトークンの発行残高がゼロでなければ、削除することはできません。
 アカウントは削除した後、通常の[アカウントの作成方法](index.md#creating-accounts)によって再作成できます。削除後に再作成されたアカウントと、初めて作成されたアカウントに違いはありません。

-
-
 ## 要件

 アカウントを削除するには、次の条件を満たす必要があります。

 - アカウントの`Sequence`番号に256を加えた値が、現在の[レジャーインデックス][]未満であること。
 - アカウントが次の[レジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/index.md)のいずれも(送金元または受取人として)保有していないこと。
-    - `Escrow`
-    - `PayChannel`
-    - `RippleState`
-    - `Check`
+  - `Escrow`
+  - `PayChannel`
+  - `RippleState`
+  - `Check`
 - アカウントがレジャー内に所有するオブジェクトが1000個未満であること。
 - トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.md)(現在2XRP)に相当する特別な[トランザクションコスト][]を支払う必要があります。

-
 ## 削除コスト

 {% admonition type="warning" name="注意" %}アカウントの削除要件を満たしていないためにトランザクションが失敗した場合でも、[AccountDeleteトランザクション][]のトランザクションコストは、トランザクションが検証済みレジャーに含まれる場合常に発生します。アカウントを削除できなかった場合に高いトランザクションコストを支払う可能性を減らすには、AccountDeleteトランザクションを送信するときに`fail_hard`オプションを使用してください。{% /admonition %}
--- a/@l10n/ja/docs/concepts/accounts/depositauth.md
+++ b/@l10n/ja/docs/concepts/accounts/depositauth.md
@@ -1,11 +1,12 @@
 ---
 seo:
-    description: DepositAuth設定をすると、アカウントは着信ペイメントをデフォルトでブロックします。
+  description: DepositAuth設定をすると、アカウントは着信ペイメントをデフォルトでブロックします。
 labels:
-    - セキュリティ
-    - 支払い
-outdated_translation: true　
+  - セキュリティ
+  - 支払い
+outdated_translation: true
 ---
+
 # Deposit Authorization

 Deposit Authorizationは、XRP Ledgerの[アカウント](index.md)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。Deposit Authorizationのアカウントは、次の2つの方法でのみ入金することができます。
@@ -40,22 +41,22 @@ Deposit Authorizationを最大限に活用するため、以下の実施を推
 Deposit Authorizationが有効化されているアカウントの特徴は次のとおりです。

 - [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
-    - 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。{% amendment-disclaimer name="DepositPreauth" /%}
-    - アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
+  - 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。{% amendment-disclaimer name="DepositPreauth" /%}
+  - アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
 - **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
-    - PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
-    - PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
+  - PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
+  - PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
 - **以下に該当する場合にのみ**[EscrowFinishトランザクション][]からXRPを受領できます。
-    - EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
-    - EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
+  - EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
+  - EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
 - [CheckCash][]トランザクションを送信してXRPまたはトークンを受領**できます**。 {% amendment-disclaimer name="Checks" /%}
 - [OfferCreateトランザクション][]を送信してXRPまたはトークンを受領**できます**。
-    - 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPとトークンのリマインダーを受信する**ことがあります**。
+  - 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPとトークンのリマインダーを受信する**ことがあります**。
 - アカウントが[NoRippleフラグ](../tokens/fungible-tokens/rippling.md)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインのトークンを受領**できます**。このようなトランザクションの送金先にすることはできません。
 - 一般的に、以下のすべての条件に該当する場合は、XRP LedgerのアカウントはXRP LedgerでXRP以外の通貨を受領**できません**。（このルールは、DepositAuthフラグに特有のものではありません。）
-    - アカウントにより、ゼロ以外の限度を指定したトラストラインが作成されていない。
-    - アカウントが、その他のアカウントにより作成されたトラストラインで通貨を発行していない。
-    - アカウントがまだオファーを出していない。
+  - アカウントにより、ゼロ以外の限度を指定したトラストラインが作成されていない。
+  - アカウントが、その他のアカウントにより作成されたトラストラインで通貨を発行していない。
+  - アカウントがまだオファーを出していない。

 以下の表に、トランザクションタイプ別にDepositAuthが有効または無効な状態での入金の可否をまとめました。

@@ -64,8 +65,6 @@ Deposit Authorizationが有効化されているアカウントの特徴は次

 {% partial file="/docs/_snippets/depositauth-semantics-table.md" /%}

-
-
 ## Deposit Authorizationの有効化または無効化

 アカウントのDeposit Authorizationを有効にするには、`SetFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。アカウントのDeposit Authorizationを無効にするには、`ClearFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。AccountSetフラグについての詳細は、[AccountSetフラグ](../../references/protocol/transactions/types/accountset.md)をご覧ください。
@@ -103,7 +102,6 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
 - 送金先アカウントがDeposit Authorizationを必要としているかどうか。（承認を必要としていない場合は、すべての送金元アカウントが承認済みとみなされます。）
 - 送金元アカウントに対し、送金先への送金が事前承認されているかどうか。

-
 ## 関連項目

 - [DepositPreauthトランザクション][]リファレンス。
@@ -115,7 +113,6 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
 - [Partial Payment](../payment-types/partial-payments.md)により、アカウントは不要な支払を返金できます。この際、[送金手数料](../tokens/fungible-tokens/transfer-fees.md)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
 <!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->

-
 [DepositPreauth Amendment]: /resources/known-amendments.md#depositpreauth

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/index.md
+++ b/@l10n/ja/docs/concepts/accounts/index.md
@@ -2,18 +2,18 @@
 html: accounts.html
 parent: concepts.html
 seo:
-    description: XRP Ledgerのアカウントについて説明します。アカウントはトランザクションを送信でき、XRPを保有できます。
+  description: XRP Ledgerのアカウントについて説明します。アカウントはトランザクションを送信でき、XRPを保有できます。
 labels:
  - アカウント
  - 支払い
 ---
+
 # アカウント

 XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクション]アカウントの主な要素は次のとおりです。

 アカウントは、アドレス、XRPの残高、シーケンス番号、トランザクション履歴から構成されます。トランザクションを送信するためには、所有者はアカウントに紐付く1つ以上の暗号鍵ペアを必要とします。

-
 ## アカウントの構成

 アカウントの種等な構成要素は次の通りです。
@@ -23,15 +23,14 @@ XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクショ
 - **シーケンス番号**。このアカウントから送信されるトランザクションがすべて、正しい順序で、それぞれ1回のみ適用されるようにします。トランザクションを実行するには、トランザクションのシーケンス番号と送金元のシーケンス番号が一致する必要があります。その後も、トランザクションが適用されている限り、アカウントのシーケンス番号は1ずつ増加します。（関連項目: [基本的なデータタイプ: アカウントシーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)）
 - このアカウントと残高に影響を及ぼした**トランザクションの履歴**。
 - [トランザクションの承認](../transactions/index.md#トランザクションの承認)方法。
-    - アカウント固有のマスターキーのペア。（無効にできますが、変更はできません。）
-    - ローテーションして使用できる「レギュラー」キーペア。
-    - [マルチシグ](multi-signing.md)の署名者のリスト。(アカウントのコアデータとは別に保存されます。)
+  - アカウント固有のマスターキーのペア。（無効にできますが、変更はできません。）
+  - ローテーションして使用できる「レギュラー」キーペア。
+  - [マルチシグ](multi-signing.md)の署名者のリスト。(アカウントのコアデータとは別に保存されます。)

 アカウントのコアデータは、[AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)レジャーエントリに保存されます。アカウントは、他の複数のタイプのレジャーエントリの所有者(または部分的な所有者)になることもできます。

 {% admonition type="success" name="ヒント" %}XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピュータ上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。{% /admonition %}

-
 ### アカウントの作成

 「アカウント作成」専用のトランザクションはありません。Paymentトランザクションでまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.md)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントへの _資金提供_ と呼ばれ、レジャーに[AccountRootエントリ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
@@ -43,27 +42,24 @@ XRP Ledgerでアカウントを取得する一般的な方法は次のとおり
 1. ランダム性の強いソースからキーペアを生成し、そのキーペアのアドレスを計算します。（例えば、[wallet_proposeメソッド][]を使用して計算することができます。）

 2. XRP Ledgerにアカウントをすでに持っているユーザに、生成したアドレスにXRPを送信してもらいます。
+   - 例えば、一般的な取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを出金することができます。

-    - 例えば、一般的な取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを出金することができます。
-
-        {% admonition type="warning" name="注意" %}自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.md)（現在は10XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。{% /admonition %}
-
-
+     {% admonition type="warning" name="注意" %}自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.md)（現在は10XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。{% /admonition %}

 ## 関連項目

 - **コンセプト:**
-    - [準備金](reserves.md)
-    - [暗号鍵](cryptographic-keys.md)
-   - [発行アドレスと運用アドレス](account-types.md)
+  - [準備金](reserves.md)
+  - [暗号鍵](cryptographic-keys.md)
+  - [発行アドレスと運用アドレス](account-types.md)
 - **リファレンス:**
-    - [account_infoメソッド][]
-    - [wallet_proposeメソッド][]
-   - [AccountSetトランザクション][]
-    - [Paymentトランザクション][]
+  - [account_infoメソッド][]
+  - [wallet_proposeメソッド][]
+  - [AccountSetトランザクション][]
+  - [Paymentトランザクション][]
  - [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
 - **チュートリアル:**
-    - [アカウント設定の管理（カテゴリ）](../../tutorials/how-tos/manage-account-settings/index.md)
-    - [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
+  - [アカウント設定の管理（カテゴリ）](../../tutorials/how-tos/manage-account-settings/index.md)
+  - [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/multi-signing.md
+++ b/@l10n/ja/docs/concepts/accounts/multi-signing.md
@@ -2,21 +2,22 @@
 html: multi-signing.html
 parent: accounts.html
 seo:
-    description: マルチシグを使用することで、トランザクション送信時のセキュリティが強化されます。
+  description: マルチシグを使用することで、トランザクション送信時のセキュリティが強化されます。
 labels:
  - スマートコントラクト
  - セキュリティ
 ---
+
 # マルチシグ

 マルチシグは、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](../transactions/index.md#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチシグ、[マスターキーペア](cryptographic-keys.md#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.md#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）

 マルチシグには次のメリットがあります。

-* 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
-* 複数のユーザ間で1つのアドレスの管理を共有できます。この場合、各ユーザが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
-* あなたのアドレスからトランザクションを送信できる権限を、複数ユーザのグループに委任できます。委任を受けた各ユーザは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
-* その他のメリットもあります。
+- 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
+- 複数のユーザ間で1つのアドレスの管理を共有できます。この場合、各ユーザが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
+- あなたのアドレスからトランザクションを送信できる権限を、複数ユーザのグループに委任できます。委任を受けた各ユーザは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
+- その他のメリットもあります。

 ## 署名者リスト

@@ -58,29 +59,29 @@ CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人の

 マルチシグトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。

-* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を所有する必要があります。この方法については、[マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。
-* トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
-* トランザクションに、署名の配列が指定されている[`Signers`フィールド](../../references/protocol/transactions/common-fields.md#signersフィールド)を含める必要があります。
-* `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
-* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、`SignerList`の`quorum`以上である必要があります。
-* [トランザクションコスト](../transactions/transaction-cost.md)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
-* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド)は実行できません。
-* `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。）
+- トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を所有する必要があります。この方法については、[マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。
+- トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
+- トランザクションに、署名の配列が指定されている[`Signers`フィールド](../../references/protocol/transactions/common-fields.md#signersフィールド)を含める必要があります。
+- `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
+- 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、`SignerList`の`quorum`以上である必要があります。
+- [トランザクションコスト](../transactions/transaction-cost.md)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
+- トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド)は実行できません。
+- `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。）

 詳細は、[マルチシグの設定](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。

 ## 関連項目

 - **チュートリアル:**
-    - [マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
-    - [マルチシグトランザクションを送信する](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
+  - [マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
+  - [マルチシグトランザクションを送信する](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
 - **コンセプト:**
-    - [暗号鍵](cryptographic-keys.md)
-    - [マルチシグトランザクションの特別なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)
+  - [暗号鍵](cryptographic-keys.md)
+  - [マルチシグトランザクションの特別なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)
 - **リファレンス:**
-    - [SignerListSetトランザクション][]
-    - [SignerListオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
-    - [sign_forメソッド][]
-    - [submit_multisignedメソッド][]
+  - [SignerListSetトランザクション][]
+  - [SignerListオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
+  - [sign_forメソッド][]
+  - [submit_multisignedメソッド][]

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/reserves.md
+++ b/@l10n/ja/docs/concepts/accounts/reserves.md
@@ -2,12 +2,13 @@
 html: reserves.html
 parent: accounts.html
 seo:
-    description: XRP Ledgerのアカウントでは、レジャーデータ内のスパムを減らすためにXRPの準備金が必要です。
+  description: XRP Ledgerのアカウントでは、レジャーデータ内のスパムを減らすためにXRPの準備金が必要です。
 labels:
  - 手数料
  - アカウント
 top_nav_grouping: 人気ページ
 ---
+
 # 準備金

 XRP Ledgerでは、スパムや悪意のある使用によって、共有グローバル台帳(レジャー)が過度に大きくならないように、XRPを用いた _準備金_ の仕組みを採用しています。現在一般に市販されているのマシンで、処理中の現行レジャーを常にRAMに保存でき、全履歴がディスクに収まるように、技術の向上に合わせて台帳サイズが大きくなるのを制限することが目的です。
@@ -20,8 +21,8 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ

 準備金は2つの部分に分けられます。

-* **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。
-* **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。アイテムごとのコストは「増分準備金」とも呼ばれます。
+- **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。
+- **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。アイテムごとのコストは「増分準備金」とも呼ばれます。

 メインネットにおける現在の準備金要件は次の通りです。

@@ -47,16 +48,15 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ

 アプリケーションは、[server_infoメソッド][]または[server_stateメソッド][]を使用して、現在の基本準備金と増分準備金の値を調べることができます。

-| メソッド                 | 単位          | 基本準備金のフィールド                  | 増分準備金のフィールド                |
-|-------------------------|--------------|-------------------------------------|------------------------------------|
-| [server_infoメソッド][]  | 10進数のXRP値  | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
-| [server_stateメソッド][] | 整数のdrop値   | `validated_ledger.reserve_base`     | `validated_ledger.reserve_inc`     |
+| メソッド                 | 単位          | 基本準備金のフィールド              | 増分準備金のフィールド             |
+| ------------------------ | ------------- | ----------------------------------- | ---------------------------------- |
+| [server_infoメソッド][]  | 10進数のXRP値 | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
+| [server_stateメソッド][] | 整数のdrop値  | `validated_ledger.reserve_base`     | `validated_ledger.reserve_inc`     |

 アカウントの所有者準備金を決定するには、増分準備金にアカウントが所有するオブジェクトの数を掛けます。アカウントが所有しているオブジェクトの数を調べるには、[account_infoメソッド][]を呼び出し、`account_data.OwnerCount`を取得します。

 アドレスの必要となる合計準備金を計算するには、`OwnerCount`に`reserve_inc_xrp`を掛け、次に`reserve_base_xrp`を加えます。[この計算をPythonで行うデモ](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17)があります。

-
 ## 必要準備金を下回る

 トランザクション処理中、[トランザクションコスト](../transactions/transaction-cost.md)によって、送信元アドレスのXRP残高の一部がバーンされます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
@@ -65,7 +65,6 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ

 {% admonition type="success" name="ヒント" %}アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)や[レジャー内のオファーエントリ](../../references/protocol/ledger-data/ledger-entry-types/offer.md)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。{% /admonition %}

-
 ## 準備金要件の変更

 XRP Ledgerには、準備金要件を調整する仕組みがあります。このような調整は、例えばXRPの価値の長期的な変化、汎用レベルのハードウェアの性能の向上、サーバソフトウェアの実装の効率化などを考慮することができます。いかなる変更も、コンセンサスプロセスによる合意が必要です。詳細は[手数料の投票](../consensus-protocol/fee-voting.md)をご覧ください。
--- a/@l10n/ja/docs/concepts/accounts/tickets.md
+++ b/@l10n/ja/docs/concepts/accounts/tickets.md
@@ -1,10 +1,11 @@
 ---
 seo:
-    description: トランザクションを非連続的な順序で送信する
+  description: トランザクションを非連続的な順序で送信する
 labels:
-    - アカウント
-    - トランザクション送信
+  - アカウント
+  - トランザクション送信
 ---
+
 # Ticket

 XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.md)などが挙げられます。
@@ -23,18 +24,17 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引

 チケットでは、これらの問題を解決するために、通常の順番とは別に、後からでも（ただし、それぞれ1回まで）使用可能なシーケンス番号を用意しています。

-
 ## チケットは予約済みのシーケンス番号

 チケットとは、あるシーケンス番号が後に使用されるために確保されたという記録です。アカウントは、まず[TicketCreateトランザクション][]を送信して、1つまたは複数のシーケンス番号をチケットとして確保します。これにより、[台帳の状態データ](../ledgers/index.md)に、予約された各シーケンス番号について[Ticketオブジェクト][]の形で記録が残されます。

 チケットには、チケット作成時に設定されたシーケンス番号が使用されます。例えば、あなたのアカウントの現在のシーケンス番号が101で、3枚のチケットを作成した場合、それらのチケットにはチケットシーケンス番号102、103、104が付けられます。これにより、あなたのアカウントのシーケンス番号は105になります。

-[{% inline-svg file="/docs/img/ticket-creation.ja.svg" /%}](/docs/img/ticket-creation.ja.svg "図: 3つのTicketの作成")
+[{% inline-svg file="/docs/img/ticket-creation.ja.svg" /%}](/docs/img/ticket-creation.ja.svg '図: 3つのTicketの作成')

 後から、シーケンス番号の代わりに特定のチケットを使用してトランザクションを送信することができます。これにより、元帳の状態データから対応するチケットが削除され、アカウントの通常のシーケンス番号は変更されません。また、チケットを使用せずに、通常のシーケンス番号を使用してトランザクションを送信することもできます。利用可能なチケットは、いつでもどのような順番でも使用できますが、各チケットは1回しか使用できません。

-[{% inline-svg file="/docs/img/ticket-usage.ja.svg" /%}](/docs/img/ticket-usage.ja.svg "図: 103のTicketを利用")
+[{% inline-svg file="/docs/img/ticket-usage.ja.svg" /%}](/docs/img/ticket-usage.ja.svg '図: 103のTicketを利用')

 上記の例では、シーケンス番号105または作成した3つのチケットのいずれかを使用してトランザクションを送信できます。チケット103を使ってトランザクションを送信すると、それによってチケット103は元帳から削除されます。その後の次のトランザクションでは、シーケンス番号105、チケット102、またはチケット104を使用できます。

@@ -57,15 +57,14 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引

 ## 関連項目

-
 - **Concepts:**
-    - [マルチシグ](multi-signing.md)
+  - [マルチシグ](multi-signing.md)
 - **Tutorials:**
-    - [チケットを使用する](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
+  - [チケットを使用する](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
 - **References:**
-    - [TicketCreateトランザクション][]
-    - [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
-    - [Ticket オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
-    - [account_objectsメソッド][]
+  - [TicketCreateトランザクション][]
+  - [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
+  - [Ticket オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
+  - [account_objectsメソッド][]

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
@@ -2,10 +2,11 @@
 html: consensus-principles-and-rules.html
 parent: consensus.html
 seo:
-    description: XRP Ledgerは世界規模の決済システムで、ユーザはメールを送るときのようにスムーズに国境を越えて送金することができます。
+  description: XRP Ledgerは世界規模の決済システムで、ユーザはメールを送るときのようにスムーズに国境を越えて送金することができます。
 labels:
  - ブロックチェーン
 ---
+
 # コンセンサスの原理とルール

 XRP Ledgerは世界規模の決済システムで、ユーザはメールを送るときのようにスムーズに国境を越えて送金することができます。Bitcoinなどの他のピアツーピア決済ネットワークと同様に、XRP Ledgerでは分散型コンピュータネットワークを介したピアツーピア取引の決済が可能です。他のデジタル通貨プロトコルとは異なり、XRP LedgerではXRP（XRP Ledgerのネイティブ資産）の他にユーザが選択した通貨（法定通貨、デジタル通貨、その他の価値形態など）建てでトランザクションを実行できます。
@@ -20,7 +21,6 @@ XRP Ledgerのテクノロジーにより、ほぼリアルタイムでの決済

 暗号化システムであるため、XRP Ledgerアカウントの所有者は _暗号ID_ により識別されます。暗号IDは、公開鍵/秘密鍵のペアに相当します。トランザクションは、暗号IDに一致する暗号署名によって承認されます。すべてのサーバでは、同一の確定的な既知のルールに基づいてすべてのトランザクションが処理されます。最終的な目標は、ネットワーク内のすべてのサーバがまったく同じレジャー状態の完全なコピーを保有できるようにし、1つの中央機関がトランザクションを調停する必要がないようにすることです。

-
 ## 二重支払いの問題

 「二重支払い」の問題は、どのような決済システムの運用においても根本的な課題となります。この問題は、ある場所でお金を支払うときに、別の場所ではそのお金を支払うことができないという要件に起因しています。一般的には、2つのトランザクションがあり、いずれかのトランザクションが有効で、両方が同時に有効になることがない場合にこの問題が発生します。
@@ -33,7 +33,6 @@ Aliceが「同じ」$10をCharlieとBobの両方に送金できてしまう場

 XRP Ledgerなどの分散型台帳技術では中央機関が存在せず、二重支払いの問題を他の方法で解決する必要があります。

-
 # コンセンサスの仕組み

 ## 問題の単純化
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-protections.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-protections.md
@@ -2,10 +2,11 @@
 html: consensus-protections.html
 parent: consensus.html
 seo:
-    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
+  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
 labels:
  - ブロックチェーン
 ---
+
 # 攻撃および障害モードに対するコンセンサスの保護

 XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
@@ -30,7 +31,6 @@ _バリデータ_ とは、新しいレジャーバージョンの決定プロ

 無効なトランザクションを承認する唯一の方法は、80%以上の信頼できるバリデータがそのトランザクションを承認し、その結果に合意することです。（無効なトランザクションには、すでに使用された資金を送金するトランザクションや、ネットワークのルールに違反するトランザクションなどがあります。）つまり、信頼できるバリデータの過半数が _共謀する_ 必要があります。多数の信頼できるバリデータが世界各地域で異なる人々や企業により運用されている状況では、意図的にこれを達成することは非常に困難です。

-
 ## ソフトウェアの脆弱性

 あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。XRP Ledgerの開発者はこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
@@ -41,7 +41,6 @@ _バリデータ_ とは、新しいレジャーバージョンの決定プロ
 - セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
 - 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与する[Bug Bountyプログラム](https://ripple.com/bug-bounty/)。

-
 ## シビル攻撃

 _[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量の偽IDを使ってネットワークのコントロールを試みる攻撃です。XRP Ledgerでは、シビル攻撃は多数のバリデータを操作して、他のバリデータにこれらのバリデータを信頼するように仕向ける形で攻撃をしかける可能性があります。このような攻撃は理論上は可能ですが、バリデータが信頼を得るには人間による介入が必要であるため、実際には非常に困難です。
@@ -50,12 +49,10 @@ _[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量

 この信頼は自動的に形成されるものではありません。したがってシビル攻撃を成功させるには、ターゲットとなる人物や企業が、攻撃者のバリデータを信頼してXRP Ledgerサーバを再設定するように仕向けるという難しい作業をこなさなければなりません。ある人物または企業がだまされてXRP Ledgerサーバを再設定したとしても、自らの設定を変更していない他の人物や企業に対する影響は最小限となります。

-
 ## 51%攻撃

 「51%攻撃」とは、特定の当事者が全採掘能力または投票能力の50%を超える割合を支配しているブロックチェーンに対する攻撃です。（厳密には、50%を _わずかでも_ 超えていれば十分であるため、この攻撃の名前は多少間違っています。）XRP Ledgerは、コンセンサスメカニズムに採掘を採用していないため、51%攻撃に対し脆弱ではありません。これに最も類似するXRP Ledgerへの攻撃には[シビル攻撃](#シビル攻撃)がありますが、この攻撃を実際に実施することは困難です。

-
 ## バリデータ重複要件

 XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。そのため、業界やコミュニティによって運営されている信頼できる、よくメンテナンスされたサーバを含むことを意味する、推奨バリデータの署名されたリストがあります。
@@ -66,7 +63,6 @@ XRP Ledgerのすべての参加者が何を検証済みとみなすかについ

 コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.md)ページをご覧ください。

-
 ## 関連項目

 - コンセンサスの**入門レベルの概要**については、[コンセンサスについて](index.md)をご覧ください。
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-research.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-research.md
@@ -2,16 +2,17 @@
 html: consensus-research.html
 parent: consensus.html
 seo:
-    description: コンセンサスアルゴリズムに関する学術論文と関連研究。
+  description: コンセンサスアルゴリズムに関する学術論文と関連研究。
 labels:
  - ブロックチェーン
 ---
+
 # コンセンサスの研究

 Rippleでは、XRP Ledgerのコンセンサスプロトコルの理論上の制限と実際の制限の両方についての研究を進め、この分野にてさまざまなアイデアを探究しています。以下の表に、Rippleが発表した学術論文の一覧を示します。

-| 日付 | タイトル | 著者 | 概要 |
-|---|---|---|---|
-| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | コンセンサスUNLの柔軟性を高める新しいアトミックブロードキャストアルゴリズム、Cobaltの紹介。 |
-| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | XRP Ledgerのコンセンサスアルゴリズムとその安全性および活性の特性に関する最新の詳細な分析。 |
-| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | XRP Ledgerで採用されているコンセンサスアルゴリズムの紹介。 |
+| 日付       | タイトル                                                                                            | 著者                     | 概要                                                                                        |
+| ---------- | --------------------------------------------------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------- |
+| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240)                         | MacBrough                | コンセンサスUNLの柔軟性を高める新しいアトミックブロードキャストアルゴリズム、Cobaltの紹介。 |
+| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242)                   | Chase, MacBrough         | XRP Ledgerのコンセンサスアルゴリズムとその安全性および活性の特性に関する最新の詳細な分析。  |
+| 2014       | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | XRP Ledgerで採用されているコンセンサスアルゴリズムの紹介。                                  |
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-structure.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-structure.md
@@ -2,10 +2,11 @@
 html: consensus-structure.html
 parent: consensus.html
 seo:
-    description: XRP Ledgerにおけるコンセンサスの役割について理解を深めましょう。
+  description: XRP Ledgerにおけるコンセンサスの役割について理解を深めましょう。
 labels:
  - ブロックチェーン
 ---
+
 # コンセンサス

 _著者: Dave Cohen、David Schwartz、Arthur Britto_
@@ -14,7 +15,6 @@ _著者: Dave Cohen、David Schwartz、Arthur Britto_

 XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger APIの動作や、その動作によってもたされる影響を知っておくために、このプロセスを理解することが重要です。

-
 ## まえがき

 ピアツーピアサーバのXRP Ledgerネットワークは世界で共有されている台帳であり、ここから、アプリケーションはこの台帳の内容の状態に関して信頼できる情報を得ることができます。この状態に関する情報には以下の内容が含まれます。
@@ -98,7 +98,6 @@ _図5: バリデータによるトランザクションセットの提案と修

 ネットワーク内の各サーバは、それぞれ個別にローカルに検証を行います。

-
 #### 検証の計算と共有

 コンセンサスプロセスが完了すると、各サーバは合意済みの一連のトランザクションから新しいレジャーを個別に計算します。各サーバは、同じ規則に従って結果を次のように計算します。
@@ -141,7 +140,6 @@ _図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが

 検証について圧倒的多数の合意が得られると、サーバは検証済みの新しいレジャー、レジャーインデックスN+1との作業に入ることができます。最後のラウンドに含まれなかった候補トランザクションと、その間に送信された新しいトランザクションに対して、コンセンサスと検証プロセスが繰り返されます<a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>。

-
 ## 要点

 XRP Ledgerに送信されたトランザクションはすぐには処理されません。一定期間、各トランザクションは候補状態になります。
@@ -187,10 +185,6 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
  - [Validator_list_sitesメソッド][]
  - [Validatorsメソッド][]

-
-
-
-
 ## 脚注

 <a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – [**tec**結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を持つトランザクションでは、要求されたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPの[トランザクションコスト](../transactions/transaction-cost.md)が消却されます。同じ送信者によって同時刻に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントの[シーケンス番号](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を都度増やしてゆきます。`tec`クラスの結果を持つトランザクションは、期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
--- a/@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
@@ -1,10 +1,11 @@
 ---
 seo:
-    description: バリデータが手数料(トランザクションコストおよび準備預金)に投票する方法。
+  description: バリデータが手数料(トランザクションコストおよび準備預金)に投票する方法。
 labels:
  - 手数料
  - XRP
 ---
+
 # 手数料投票

 手数料投票は、XRP Ledgerの使用料、具体的には基本[トランザクションコスト](../transactions/transaction-cost.md)および[準備金要件](../accounts/reserves.md)を調整するためのシステムです。この手数料の目的は、ネットワークをスパムから保護することにあります。そのため、手数料の投票による決定は、より多くのユーザやユースケースにネットワークを利用可能にするという目的と、ネットワークを悪用や過剰利用から保護するという目的の、競合する優先事項を考慮する必要があります。XRPの価値やネットワークノードのコストおよび機能の長期的な変化に適応するために、定期的な変更が必要です。
@@ -15,11 +16,11 @@ labels:

 設定できるパラメーターは次の通りです。

-| パラメーター        | 説明 | 推奨される値 |
-|-------------------|-------------|-------------------|
-| `reference_fee`   | **リファレンストランザクションのコスト**。これは、リファレンストランザクション（最も安価なトランザクション）を送信するためにバーンしなければならないXRPの量（1 XRP = 100万ドロップ）です。実際のトランザクションコストは、個々のサーバの負荷に応じて動的に調整される、この値の倍数です。 | `10` (0.000010 XRP)  |
-| `account_reserve` | **基本アカウント準備金**。これは、アカウントが保持しなければならないXRPの量（1 XRP = 100万ドロップ）です。これは、新しいアカウントを作成するための最小要件でもあります。 | `1000000` （{% $env.PUBLIC_BASE_RESERVE %}） |
-| `owner_reserve`   | **所有者準備金の増加量**。これは、アカウントがレジャー内で所有する各オブジェクトに対して保持しなければならないXRPの量（1 XRP = 100万ドロップ）です。 | `200000` （{% $env.PUBLIC_OWNER_RESERVE %}） |
+| パラメーター      | 説明                                                                                                                                                                                                                                                                                     | 推奨される値                                 |
+| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
+| `reference_fee`   | **リファレンストランザクションのコスト**。これは、リファレンストランザクション（最も安価なトランザクション）を送信するためにバーンしなければならないXRPの量（1 XRP = 100万ドロップ）です。実際のトランザクションコストは、個々のサーバの負荷に応じて動的に調整される、この値の倍数です。 | `10` (0.000010 XRP)                          |
+| `account_reserve` | **基本アカウント準備金**。これは、アカウントが保持しなければならないXRPの量（1 XRP = 100万ドロップ）です。これは、新しいアカウントを作成するための最小要件でもあります。                                                                                                                 | `1000000` （{% $env.PUBLIC_BASE_RESERVE %}） |
+| `owner_reserve`   | **所有者準備金の増加量**。これは、アカウントがレジャー内で所有する各オブジェクトに対して保持しなければならないXRPの量（1 XRP = 100万ドロップ）です。                                                                                                                                     | `200000` （{% $env.PUBLIC_OWNER_RESERVE %}） |

 <!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->

@@ -44,10 +45,10 @@ labels:

 まとめ:

-* **フラグレジャー-1**: バリデータが投票を送信します。
-* **フラグレジャー**: バリデータが投票を集計し、どのSetFeeの内容を含めるか決定します（存在する場合）。
-* **フラグレジャー+1**: バリデータは、SetFee疑似トランザクションを各自の提案レジャーに挿入します。
-* **フラグレジャー+2**: SetFee疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。
+- **フラグレジャー-1**: バリデータが投票を送信します。
+- **フラグレジャー**: バリデータが投票を集計し、どのSetFeeの内容を含めるか決定します（存在する場合）。
+- **フラグレジャー+1**: バリデータは、SetFee疑似トランザクションを各自の提案レジャーに挿入します。
+- **フラグレジャー+2**: SetFee疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。

 ## 手数料の最大値

@@ -64,16 +65,16 @@ labels:
 ## See Also

 - **コンセプト:**
-    - [Amendment](../networks-and-servers/amendments.md)
-    - [トランザクションコスト](../transactions/transaction-cost.md)
-    - [準備金](../accounts/reserves.md)
-    - [トランザクションキュー](../transactions/transaction-queue.md)
+  - [Amendment](../networks-and-servers/amendments.md)
+  - [トランザクションコスト](../transactions/transaction-cost.md)
+  - [準備金](../accounts/reserves.md)
+  - [トランザクションキュー](../transactions/transaction-queue.md)
 - **チュートリアル:**
-    - [rippledの設定](../../infrastructure/configuration/index.md)
+  - [rippledの設定](../../infrastructure/configuration/index.md)
 - **リファレンス:**
-    - [feeメソッド][]
-    - [server_infoメソッド][]
-    - [FeeSettingsオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
-    - [SetFee疑似トランザクション][]
+  - [feeメソッド][]
+  - [server_infoメソッド][]
+  - [FeeSettingsオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
+  - [SetFee疑似トランザクション][]

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/index.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/index.md
@@ -2,15 +2,15 @@
 html: consensus.html
 parent: concepts.html
 seo:
-    description: XRP Ledgerのコンセンサスメカニズムについて基本的な理解を深めましょう。
+  description: XRP Ledgerのコンセンサスメカニズムについて基本的な理解を深めましょう。
 labels:
  - ブロックチェーン
 top_nav_grouping: 人気ページ
 ---
+
 # コンセンサスプロトコル

- _コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。
-
+_コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。

 ## コンセンサスプロトコルの特性

@@ -30,7 +30,6 @@ top_nav_grouping: 人気ページ

 コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.md)をご覧ください。

-
 ## レジャー（台帳）履歴

 XRP Ledgerは、「レジャーバージョン」、または略して「レジャー」と呼ばれるブロックで取引を処理します。レジャーの各バージョンには、次の3つの部分が含まれています。
@@ -40,13 +39,13 @@ XRP Ledgerは、「レジャーバージョン」、または略して「レジ
 - レジャーインデックスや、その内容を一意に識別する[暗号化ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)、およびこのレジャーを構築するための基盤として使用された親レジャーに関する情報など、現行のレジャーバージョンに関するメタデータ。

 [![図1: レジャーバージョンの構造（取引、状態、およびメタデータを含む）](/docs/img/anatomy-of-a-ledger-simplified.ja.png)](/docs/img/anatomy-of-a-ledger-simplified.ja.png)
+
 <!--{# Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/ #}-->

 レジャーの各バージョンには _レジャーインデックス_ としての番号が付けられており、インデックスが1つ前のレジャーバージョンを基に新たな情報を追加する形で作成されています。一番最初まで遡ると、レジャーインデックスが1の _ジェネシスレジャー_ と呼ばれる出発点に戻ります。[¹](#footnote-1)これにより、Bitcoinや他のブロックチェーン技術と同様に、すべての取引とその結果についての公開履歴が形成されます。多くのブロックチェーン技術とは異なり、XRP Ledgerの新しい「ブロック」には現在の状態がすべて含まれているため、現在起こっている内容を把握するために履歴全体を収集する必要はありません。[²](#footnote-2)

 XRP Ledger コンセンサスプロトコルの主な役割は、前のレジャーに適用する一連の新しい取引に合意し、それらを明確に定義された順序で適用した上で、全員が同じ結果を得たことを確認することです。これが正常に行われると、レジャーバージョンは _検証済み_ 、および確定したとみなされます。続いて、次のレジャーバージョンが構築されます。

-
 ## 信頼に基づく検証

 XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバ](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
@@ -59,7 +58,7 @@ XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな

 XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.md)をご覧ください。

----
+---

 ## 脚注

--- a/@l10n/ja/docs/concepts/consensus-protocol/invariant-checking.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/invariant-checking.md
@@ -2,11 +2,12 @@
 html: invariant-checking.html
 parent: consensus.html
 seo:
-    description: 不変性チェックとは何か、なぜ存在するのか、どのように機能するのか、どのような不変性チェックが有効なのかを理解することができます。
+  description: 不変性チェックとは何か、なぜ存在するのか、どのように機能するのか、どのような不変性チェックが有効なのかを理解することができます。
 labels:
  - ブロックチェーン
  - セキュリティ
 ---
+
 # 不変性チェック

 不変性チェックは、XRP Ledgerの安全機能です。これは、通常のトランザクション処理とは別に、すべての取引において特定の「不変量」が真であることを保証する一連のチェックで構成されています。
@@ -15,7 +16,6 @@ labels:

 不変性はトリガーされるべきではありませんが、まだ発見されていない、あるいは作成されてもいないバグからXRP Ledgerの整合性を確保するものです。

-
 ## なぜ存在するのか

 - XRP Ledgerのソースコードは複雑かつ膨大であり、コードが誤って実行される可能性が高いです。
@@ -25,15 +25,12 @@ labels:

 不正なトランザクションの処理は、XRP Ledgerの信頼という価値を損なうことになります。不変性チェックは、信頼性という機能を付加するため、XRP Ledger 全体に価値を提供します。

-
-
 ## 仕組み

 不変性チェッカーは、各トランザクションの後にリアルタイムで自動的に実行される第2層のコードです。トランザクションの結果がレジャーにコミットされる前に、不変性チェッカーはそれらの変更が正しいかどうかを検証します。もしトランザクションの結果がXRP Ledgerの厳格なルールに沿わない場合、不変性チェッカーはそのトランザクションを拒否します。このように拒否されたトランザクションは結果コード `tecINVARIANT_FAILED` を持ち、何の効果もなくレジャーに含まれます。

 トランザクションを `tec` クラスのコードでレジャーに含めるには、何らかの最小限の処理が必要です。この最小限の処理でも不変条件に沿わない場合、トランザクションは `tefINVARIANT_FAILED` というコードで失敗し、レジャーには一切含まれません。

-
 ## 有効な不変条件

 XRP Ledgerは、各トランザクションについて、以下のすべての不変条件をチェックします。
@@ -74,79 +71,68 @@ XRP Ledgerは、各トランザクションについて、以下のすべての

 - [有効な新規アカウントルート](#有効な新規アカウントルート)

-
 ### トランザクション手数料チェック

 - **不変条件:**
-    - [トランザクションコスト](../transactions/transaction-cost.md)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。
-
+  - [トランザクションコスト](../transactions/transaction-cost.md)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。

 ### XRPは作成されません

 - **不変条件:**
-    - トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](../transactions/transaction-cost.md)。
-
+  - トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](../transactions/transaction-cost.md)。

 ### アカウントルートが削除されていない

 - **不変条件:**
-    - [アカウント](../accounts/index.md)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
-    - AccountDelete が成功すると、常にちょうど1つのアカウントが削除されます。
-
+  - [アカウント](../accounts/index.md)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
+  - AccountDelete が成功すると、常にちょうど1つのアカウントが削除されます。

 ### XRPの残高確認

 - **不変条件:**
-    - アカウントのXRP残高はXRPの形式である必要があり、0未満または1000億XRPを超えることはできません。
-
+  - アカウントのXRP残高はXRPの形式である必要があり、0未満または1000億XRPを超えることはできません。

 ### レジャーエントリ形式の一致

 - **不変条件:**
-    - 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](../../references/protocol/ledger-data/ledger-entry-types/index.md)である必要があります。
-
+  - 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](../../references/protocol/ledger-data/ledger-entry-types/index.md)である必要があります。

 ### XRPのトラストラインはありません

 - **不変条件:**
-    - XRPを使用した[トラストライン](../tokens/fungible-tokens/index.md)は作成できません。
-
+  - XRPを使用した[トラストライン](../tokens/fungible-tokens/index.md)は作成できません。

 ### 不正なオファーでない

 - **不変条件:**
-    - [オファー](../../references/protocol/ledger-data/ledger-entry-types/offer.md)は負でない金額でなければならず、XRP同士であってはいけません。
-
+  - [オファー](../../references/protocol/ledger-data/ledger-entry-types/offer.md)は負でない金額でなければならず、XRP同士であってはいけません。

 ### 0のエスクローでない

 - **不変条件:**
-    - [エスクロー](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)エントリは、0XRP以上1000億XRP未満を保有している必要があります。
-
+  - [エスクロー](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)エントリは、0XRP以上1000億XRP未満を保有している必要があります。

 ### 有効な新規アカウントルート

 - **不変条件:**
-    - 新しい[アカウントルート](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)は、支払いの結果でなければなりません。
-    - 新しいアカウントルートは、正しい開始[シーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を持たなければなりません。
-    - 1つのトランザクションで複数の新しい[アカウント](../accounts/index.md)を作成してはいけません。
-
+  - 新しい[アカウントルート](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)は、支払いの結果でなければなりません。
+  - 新しいアカウントルートは、正しい開始[シーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を持たなければなりません。
+  - 1つのトランザクションで複数の新しい[アカウント](../accounts/index.md)を作成してはいけません。

 ## 関連項目

 - **ブログ:**
-    - [レジャーの保護: 不変性チェック](https://xrpl.org/blog/2017/invariant-checking.html)
+  - [レジャーの保護: 不変性チェック](https://xrpl.org/blog/2017/invariant-checking.html)

 - **リポジトリ:**
-    - [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)
-
+  - [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)

 - **その他:**
-    - [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)
-    - [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
+  - [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)
+  - [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/negative-unl.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/negative-unl.md
@@ -2,10 +2,11 @@
 html: negative-unl.html
 parent: consensus.html
 seo:
-    description: ネガティブUNLが部分的な停止時に台帳の耐障害性を向上させることを理解する。
+  description: ネガティブUNLが部分的な停止時に台帳の耐障害性を向上させることを理解する。
 labels:
  - ブロックチェーン
 ---
+
 # ネガティブUNL

 _([NegativeUNL Amendment](/resources/known-amendments.md#negativeunl)によって追加されました。)_
@@ -42,7 +43,6 @@ XRP Ledgerプロトコルの各サーバは、UNL（Unique Node List）と呼ば

 ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。

-
 ### 信頼性評価

 ネットワーク上の各サーバは、共謀しないように信頼するバリデータのリストであるUNLを持っています。(デフォルトでは、サーバの正確なUNLはリップル社が公表している推奨バリデータリストに基づいて暗黙的に設定されます)。各サーバは、信頼できるバリデータの「信頼性」を1つの指標で追跡します。それは、直近256件のレジャーのうち、バリデータの検証投票がサーバの考えるコンセンサスと一致した割合です。言い換えれば
@@ -63,8 +63,6 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2

 {% admonition type="success" name="ヒント" %}バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じてどの程度うまく伝わるかを考慮できないので、外部のサーバからの測定値よりも信頼性が低い。{% /admonition %}

-
-
 ### ネガティブUNLの変更

 レジャーバージョンが256で均等に割り切れる場合、_フラグレジャー_ とみなされます。ネガティブUNLはフラグレジャーでのみ変更可能です。(フラグレジャーは、XRP Ledgerメインネットで約15分に1回発生します。トランザクション量の少ないテストネットワークでは、もっと低頻度な場合があります)
@@ -73,32 +71,30 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2

 1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。

-    {% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}
+   {% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}

 2. ネガティブUNLが満杯でない場合、各サーバは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
 3. ネガティブUNLが空でない場合、各サーバはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
-    - バリデータの信頼度が80%を超えている。
-    - 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
+   - バリデータの信頼度が80%を超えている。
+   - 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
 4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。

 ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。

 ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)に追跡される。

-
 ### ネガティブUNLの制限

 ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバはネガティブUNL上のバリデータ数がサーバの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが"満杯"になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。

-
 ### 複数のバリデータ候補から選択する

 信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバはどのバリデータを追加するかを選択しなければならない。複数の候補がある場合、サーバは以下のメカニズムでどの候補を提案するかを選択する。

 1. 親レジャーバージョンのレジャーハッシュを取得する。
-0. 各バリデータ候補の公開鍵を取得する。
-0. 候補のバリデータと親レジャーのハッシュの排他的論理和(XOR)を計算する。
-0. XOR演算の結果のうち、数値が最も小さいバリデータを提案する。
+2. 各バリデータ候補の公開鍵を取得する。
+3. 候補のバリデータと親レジャーのハッシュの排他的論理和(XOR)を計算する。
+4. XOR演算の結果のうち、数値が最も小さいバリデータを提案する。

 あるフラグレジャーのネガティブUNLから削除される候補が複数ある場合、サーバは同じメカニズムでそれらの中から選択します。

@@ -108,7 +104,6 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
 - 信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、 サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、合意が得られる可能性が高い。
 - レジャーバージョンごとに同じ結果が出るとは限りません。もしネガティブUNLへのある変更案が合意に至らなかったとしても、ネットワークは毎回その1つのバリデータの追加や削除を試みて失敗し続けることはない。ネットワークは、後のフラグ付きレジャーで別の候補をネガティブUNLに追加・削除することを試みることができる。

-
 ### 検証のフィルタリング

 [コンセンサスプロセスの検証ステップ](consensus-structure.md#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
@@ -123,55 +118,53 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2

 1. サーバのUNLが38人の信頼できるバリデータで構成されているとすると、80%の定足数は38人のうち少なくとも31人の信頼できるバリデータである。

-[{% inline-svg file="/docs/img/negative-unl-01.ja.svg" /%}](/docs/img/negative-unl-01.ja.svg "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。")
+[{% inline-svg file="/docs/img/negative-unl-01.ja.svg" /%}](/docs/img/negative-unl-01.ja.svg 'Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。')

 2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデータのうち少なくとも31人の定足数で可決され、レジャー _N_ はUnsteadyBを無効化する予定で有効になった。

-[{% inline-svg file="/docs/img/negative-unl-02.ja.svg" /%}](/docs/img/negative-unl-02.ja.svg "Diagram: UnsteadyBは無効になる予定。")
-
+[{% inline-svg file="/docs/img/negative-unl-02.ja.svg" /%}](/docs/img/negative-unl-02.ja.svg 'Diagram: UnsteadyBは無効になる予定。')

 3. レジャー _N+1_ から _N+256_ については、コンセンサスプロセスをそのまま継続する。

 4. 次のフラグレジャー _N+256_ では、UnsteadyBはレジャーの「予定」から「無効」リストへ自動的に移動する。また、MissingAがまだオフラインであるため、検証者の総意として、次のフラグレジャーでMissingAを無効化する予定とする。

-[{% inline-svg file="/docs/img/negative-unl-04.ja.svg" /%}](/docs/img/negative-unl-04.ja.svg "UnsteadyBが無効化され、MissingAも無効化される予定。")
+[{% inline-svg file="/docs/img/negative-unl-04.ja.svg" /%}](/docs/img/negative-unl-04.ja.svg 'UnsteadyBが無効化され、MissingAも無効化される予定。')

 5. レジャー _N+257_ から _N+512_ について、定足数は37名中30名となった。

 6. UnsteadyBがレジャー _N+270_ でオンラインに復帰。レジャー _N+270_ から _N+511_ に対してネットワークの他の部分と一致する検証票を送信し、信頼性スコアが80%以上となる。

-[{% inline-svg file="/docs/img/negative-unl-06.ja.svg" /%}](/docs/img/negative-unl-06.ja.svg "Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。")
+[{% inline-svg file="/docs/img/negative-unl-06.ja.svg" /%}](/docs/img/negative-unl-06.ja.svg 'Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。')

 7. 次のフラグレジャー _N+256_ では、予定通りMissingAが自動的に無効リストに移される。一方、UnsteadyBは信頼性スコアが向上したため、検証者の総意としてネガティブUNLから削除される予定である。

-[{% inline-svg file="/docs/img/negative-unl-07.ja.svg" /%}](/docs/img/negative-unl-07.ja.svg "Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。")
+[{% inline-svg file="/docs/img/negative-unl-07.ja.svg" /%}](/docs/img/negative-unl-07.ja.svg 'Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。')

 8. レジャー _N+513_ から _N+768_ の場合、定足数は36人中29人である。MissingAがオフラインの間、UnsteadyBは安定的に検証結果を送り続ける。

 9. フラグレジャー _N+768_ では、予定通りUnsteadyBが無効リストから自動的に削除されています。

-[{% inline-svg file="/docs/img/negative-unl-09.ja.svg" /%}](/docs/img/negative-unl-09.ja.svg "Diagram: UnsteadyBを無効リストから削除。")
+[{% inline-svg file="/docs/img/negative-unl-09.ja.svg" /%}](/docs/img/negative-unl-09.ja.svg 'Diagram: UnsteadyBを無効リストから削除。')

 10. 最終的に、あなたはMissingAがおそらく戻ってこないと判断し、あなたのサーバの設定されたUNLからそれを削除します。あなたのサーバはそれ以降、各フラグレジャーからMissingAをネガティブUNLから削除することを提案し始める。

-[{% inline-svg file="/docs/img/negative-unl-10.ja.svg" /%}](/docs/img/negative-unl-10.ja.svg "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。　")
+[{% inline-svg file="/docs/img/negative-unl-10.ja.svg" /%}](/docs/img/negative-unl-10.ja.svg 'Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。　')

 11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者はネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。

-[{% inline-svg file="/docs/img/negative-unl-11.ja.svg" /%}](/docs/img/negative-unl-11.ja.svg "Diagram: MissingAをネガティブUNLから削除。")
-
+[{% inline-svg file="/docs/img/negative-unl-11.ja.svg" /%}](/docs/img/negative-unl-11.ja.svg 'Diagram: MissingAをネガティブUNLから削除。')

 ### 関連項目

 - **コンセンサス:**
-    - [コンセンサスプロトコル](index.md)
+  - [コンセンサスプロトコル](index.md)
 - **チュートリアル:**
-    - [Testnetや別の並列ネットワークへ接続する](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
-    - [バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+  - [Testnetや別の並列ネットワークへ接続する](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
+  - [バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
 - **リファレンス:**
-    - [negativeUNL オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
-    - [UNLModify pseudo-transaction][]
-    - [ledger_entryメソッド][]
-    - [consensus_infoメソッド][]
+  - [negativeUNL オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
+  - [UNLModify pseudo-transaction][]
+  - [ledger_entryメソッド][]
+  - [consensus_infoメソッド][]

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/decentralized-storage/credentials.md
+++ b/@l10n/ja/docs/concepts/decentralized-storage/credentials.md
@@ -4,7 +4,6 @@ Credentials(資格情報)機能は、プライバシーと分散化を尊重し

 Credentials標準の設計は、[W3C Verifiable Credentials標準](https://www.w3.org/TR/vc-data-model-2.0/)から着想を得ています。XRP Ledgerのコンテキストで意味をなす範囲で互換性を持たせることを意図しています。データ構造とフォーマットには若干の違いがあります。例えば、資格情報の対象はURLではなくXRP Ledgerアドレスによって識別されます。

-
 ## 概要

 _Credentials_ は、レジャーに保存可能な署名付きの声明であり、ユーザのアイデンティティ、法的地位、またはその他の状態を証明することができます。この機能には、XRP Ledger上での資格情報の発行、保存、検証が含まれ、同時にユーザのプライバシーニーズもサポートします。
@@ -31,9 +30,9 @@ XRP Ledgerに保存された資格情報は、特にDID(分散型識別子)と

 資格情報の典型的な利用フローには、以下の例で説明するように、異なる役割を持つ3つの関係者が関与します。

-* Verityは、法的コンプライアンスを確保するために、適切にKYCされたアカウントとのみ相互作用したい規制対象ビジネスです。これによりVerityは _認証者_ となります。なぜなら、どのアカウントが彼らと相互作用できる(認可される)かを設定するからです。
-* Isabelは、アカウントを審査し、アカウントが本人であることを証明する資格情報を発行する資格情報発行者です。
-* Aliceは、Verityと相互作用したいユーザです。
+- Verityは、法的コンプライアンスを確保するために、適切にKYCされたアカウントとのみ相互作用したい規制対象ビジネスです。これによりVerityは _認証者_ となります。なぜなら、どのアカウントが彼らと相互作用できる(認可される)かを設定するからです。
+- Isabelは、アカウントを審査し、アカウントが本人であることを証明する資格情報を発行する資格情報発行者です。
+- Aliceは、Verityと相互作用したいユーザです。

 3者全てにXRP Ledgerアカウントが必要です。フローは以下のように進みます。

--- a/@l10n/ja/docs/concepts/decentralized-storage/decentralized-identifiers.md
+++ b/@l10n/ja/docs/concepts/decentralized-storage/decentralized-identifiers.md
@@ -1,9 +1,10 @@
 ---
 seo:
-    description: 分散型IDは、検証可能な分散型デジタルIDを可能にします。
+  description: 分散型IDは、検証可能な分散型デジタルIDを可能にします。
 labels:
  - DID
 ---
+
 # 分散型ID

 分散型ID(DID)は、検証可能なデジタルIDを可能にするWorld Wide Web Consortium(W3C)によって定義された新しいタイプの識別子です。DIDはDID所有者の完全な管理下にあり、中央管理レジストリ、IDプロバイダ、認証局から独立しています。
@@ -14,7 +15,7 @@ DIDの主な基本原則は以下の通りです。

 - **検証可能な資格情報(Verifiable Credentials):** 誰でもDIDを作成し、その情報を偽造することができます。DIDの真正性を証明するために、ユーザは暗号的に安全で改ざんできない検証可能な資格情報(Verifiable Credentials/VC)を提供しなければなりません。

-    DIDエコシステムには3つの当事者がいます。_ユーザ_、_発行者_、_検証者_ です。ユーザはDIDを管理しますが、オフラインで情報を検証するには信頼できる _発行者_ が必要です。_発行者_ は検証可能な資格情報を提供し、ユーザはそれをユーザの身元を確認する必要がある _検証者_ に渡します。DIDエコシステムの詳細については、こちらをご覧ください。[エコシステムの概要](https://www.w3.org/TR/vc-data-model/#ecosystem-overview)
+  DIDエコシステムには3つの当事者がいます。_ユーザ_、_発行者_、_検証者_ です。ユーザはDIDを管理しますが、オフラインで情報を検証するには信頼できる _発行者_ が必要です。_発行者_ は検証可能な資格情報を提供し、ユーザはそれをユーザの身元を確認する必要がある _検証者_ に渡します。DIDエコシステムの詳細については、こちらをご覧ください。[エコシステムの概要](https://www.w3.org/TR/vc-data-model/#ecosystem-overview)

 - **相互運用性:** DIDは、W3CのDID規格を認識するあらゆるソリューションに対してオープンです。つまり、DIDは様々なデジタルトランザクションやインタラクションの認証や信頼の確立に使用することができます。

@@ -29,7 +30,6 @@ DIDの主な基本原則は以下の通りです。
 3. ユーザは、デジタル上のタスクのために、自分のDIDとVCを検証者に提供します。
 4. 検証者はDIDをそのドキュメントに変換し、VCを使用してその真正性を検証します。

-
 ## DIDドキュメント

 DIDドキュメントには、記述された対象の身元を暗号的に検証するために必要な情報が含まれます。サブジェクトは、人、組織、または物であってもかまいません。たとえば、DIDドキュメントには、DIDサブジェクトが自身を認証し、DIDの関連を証明するために使用できる暗号化公開鍵を含めることができます。
@@ -41,30 +41,28 @@ XRP Ledgerでは、DIDをDIDドキュメントに関連付ける方法がいく
 1. IPFSやSTORJのような他の分散ストレージネットワークに保存されているドキュメントを指す`DID`オブジェクトの`URI`フィールドにドキュメントへの参照を保存します。
 2. 最小限のDIDドキュメントを`DID`オブジェクトの`DIDDocument`フィールドに格納します。
 3. DIDとその他の利用可能な公開情報から生成された最小限の _暗黙的な_ DIDドキュメントを使用します。
-    {% admonition type="info" name="注記" %}より単純なユースケースでは、署名と単純な認証トークンのみが必要な場合があります。レジャー上に明示的にDIDドキュメントが存在しない場合、代わりに暗黙的なドキュメントが使用されます。たとえば、`did:xrpl:1：0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020`の暗黙のDIDドキュメントでは、単一のキー`0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020`だけでDIDドキュメントの変更を承認したり、DIDの名前で署名に署名したりできます。{% /admonition %}
-
+   {% admonition type="info" name="注記" %}より単純なユースケースでは、署名と単純な認証トークンのみが必要な場合があります。レジャー上に明示的にDIDドキュメントが存在しない場合、代わりに暗黙的なドキュメントが使用されます。たとえば、`did:xrpl:1：0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020`の暗黙のDIDドキュメントでは、単一のキー`0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020`だけでDIDドキュメントの変更を承認したり、DIDの名前で署名に署名したりできます。{% /admonition %}

 ### XRPL DIDドキュメントの例

 ```json
 {
-    "@context": "https://w3id.org/did/v1",
-    "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-    "publicKey": [
-        {
-            "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
-            "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
-            "curve": "secp256k1",
-            "expires": 15674657,
-            "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
-        }
-    ]
+  "@context": "https://w3id.org/did/v1",
+  "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "publicKey": [
+    {
+      "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
+      "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
+      "curve": "secp256k1",
+      "expires": 15674657,
+      "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
+    }
+  ]
 }
 ```

 DIDドキュメントの主要なプロパティの詳細については[Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/#core-properties)をご覧ください。

-
 ## プライバシーとセキュリティの懸念

 - XRPLアカウントの秘密鍵を管理する人は誰でも、DIDとそれが解決するDIDドキュメントへの参照を管理します。秘密鍵が漏洩しないように注意してください。
--- a/@l10n/ja/docs/concepts/decentralized-storage/index.md
+++ b/@l10n/ja/docs/concepts/decentralized-storage/index.md
@@ -2,9 +2,9 @@
 metadata:
  indexPage: true
 ---
+
 # 分散型ストレージ

 XRP Ledgerにオフチェーンからの特定の種類の情報を保存出来ます。

-
 {% child-pages /%}
--- a/@l10n/ja/docs/concepts/decentralized-storage/price-oracles.md
+++ b/@l10n/ja/docs/concepts/decentralized-storage/price-oracles.md
@@ -12,7 +12,6 @@ _([PriceOracle Amendment][])_

 {% /admonition %}

-
 ## オラクルの仕組み

 ほとんどのオラクルブロックチェーンのやり取りは、次のような仕組みになっています。
@@ -23,7 +22,6 @@ _([PriceOracle Amendment][])_

 このプロセスは逆方向にも機能し、トランザクション情報を外部システムにプッシュすることも可能です。

-
 ## XRP Ledgerの価格オラクル

 XRPLの価格オラクルはネイティブのオンチェーンオラクルであり、XRP LedgerのネイティブDeFi機能を強化します。オフチェーン価格オラクルは、そのデータをXRPLオラクルに送信し、XRPLオラクルはオンチェーンにその情報を保存します。これにより、分散型アプリケーションは価格データについてXRPLオラクルに問い合わせることが可能になります。複数のXRPLオラクルに問い合わせることで、リスクと不正確性を最小限に抑えることができます。
@@ -33,9 +31,9 @@ XRPLの価格オラクルはネイティブのオンチェーンオラクルで
 ## 関連項目

 - **リファレンス:**
-    - [get_aggregate_priceメソッド][]
-    - [Oracleエントリ][]
-    - [OracleDeleteトランザクション][]
-    - [OracleSetトランザクション][]
+  - [get_aggregate_priceメソッド][]
+  - [Oracleエントリ][]
+  - [OracleDeleteトランザクション][]
+  - [OracleSetトランザクション][]

 {% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/index.md
+++ b/@l10n/ja/docs/concepts/index.md
@@ -5,9 +5,9 @@ top_nav_grouping: カテゴリ
 metadata:
  indexPage: true
 ---
+
 # コンセプト

 XRP Ledgerの基本的な部分の背景に「何があるか」、「なぜなのか」を学びましょう。

-
 {% child-pages /%}
--- a/@l10n/ja/docs/concepts/ledgers/index.md
+++ b/@l10n/ja/docs/concepts/ledgers/index.md
@@ -2,16 +2,17 @@
 html: ledgers.html
 parent: concepts.html
 seo:
-    description: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー(レジャーバージョン)で構成されています。これらのレジャーの構造と内容について説明します。
+  description: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー(レジャーバージョン)で構成されています。これらのレジャーの構造と内容について説明します。
 labels:
  - ブロックチェーン
  - データ保持
 ---
+
 # レジャー

 XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャー)です。個々の参加者は、単一の機関に台帳の管理を任せることなく、台帳の正当性を信頼することができます。XRP Ledgerプロトコルは、非常に特殊なルールに従ってのみ更新可能な台帳データベースを管理することで、これを実現しています。ピアツーピアネットワークのサーバは台帳データベースの完全なコピーを保持し、ネットワークは候補となるトランザクションを配信し、[コンセンサスプロセス](../consensus-protocol/index.md)に従ってブロック単位で適用されます。

-[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます")
+[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg '図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます')

 共有グローバル台帳は、レジャーバージョンまたは単に _レジャー_ と呼ばれる一連のブロックから構成されます。すべてのレジャーバージョンには、台帳の正しい順序を識別する[レジャーインデックス][]があります。永続的にクローズされる各台帳には、固有の識別ハッシュ値も存在します。

@@ -19,13 +20,11 @@ XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャ

 1つのレジャーバージョンはいくつかの要素から構成されています。

-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。")
-
-* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
-* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](../../references/protocol/transactions/index.md)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
-* **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/index.md)。
-
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg 'レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。')

+- **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
+- **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](../../references/protocol/transactions/index.md)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
+- **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/index.md)。

 ## 関連項目

--- a/@l10n/ja/docs/concepts/ledgers/ledger-close-times.md
+++ b/@l10n/ja/docs/concepts/ledgers/ledger-close-times.md
@@ -2,10 +2,11 @@
 html: ledger-close-times.html
 parent: ledgers.html
 seo:
-    description: XRP Ledgerが、レジャーバージョンごとに一意の閉鎖時刻を計算する方法。
+  description: XRP Ledgerが、レジャーバージョンごとに一意の閉鎖時刻を計算する方法。
 labels:
  - ブロックチェーン
 ---
+
 # レジャーの閉鎖時刻

 レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。
--- a/@l10n/ja/docs/concepts/ledgers/ledger-structure.md
+++ b/@l10n/ja/docs/concepts/ledgers/ledger-structure.md
@@ -2,8 +2,9 @@
 html: ledger-structure.html
 parent: ledgers.html
 seo:
-    description: 個別のレジャーブロックの要素を詳しく見てみましょう。
+  description: 個別のレジャーブロックの要素を詳しく見てみましょう。
 ---
+
 # レジャーの構成要素

 XRP Ledgerはブロックチェーンであり、データブロックの履歴を順番に並べたものです。XRP Ledgerブロックチェーンのブロックは、 _レジャーバージョン_ または略して _レジャー_ と呼ばれます。
@@ -12,12 +13,11 @@ XRP Ledgerはブロックチェーンであり、データブロックの履歴

 各レジャーバージョンには、 _状態データ_ 、 _トランザクションセット_ 、メタデータを含む _ヘッダー_ が含まれます。

-[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg "図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。")
-
+[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg '図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。')

 ## 状態データ

-[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg "図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。")
+[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg '図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。')

 _状態データ_ とは、そのレジャーバージョンにおけるすべてのアカウント、残高、設定、その他の情報のスナップショットを表します。サーバがネットワークに接続すると、最初に行うことの1つは、新しいトランザクションを処理し、現在の状態に関するクエリに答えることができるように、現在の状態データの完全なセットをダウンロードすることです。ネットワーク内のすべてのサーバが状態データの完全なコピーを持っているため、すべてのデータは公開され、どのコピーも同じように有効です。

@@ -25,7 +25,7 @@ _状態データ_ とは、そのレジャーバージョンにおけるすべ

 ## トランザクションセット

-[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg "図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ")
+[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg '図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ')

 レジャーに加えられたすべての変更は、トランザクションの結果です。各レジャーバージョンには、特定の順序で新たに適用されたトランザクションのグループである _トランザクションセット_ が含まれています。あるレジャーのトランザクションセットを前のレジャーバージョンの状態データに適用すると、結果としてそのレジャーの状態データが得られます。

@@ -34,34 +34,32 @@ _状態データ_ とは、そのレジャーバージョンにおけるすべ
 - 送信者がレジャーに何を指示したかを示す _トランザクションの内容_ 。
 - トランザクションがどのように処理され、レジャーの状態データにどのような影響を与えたかを正確に示す _トランザクションのメタデータ_ 。

-
 ## レジャーヘッダー

 _レジャーヘッダー_ は、レジャーバージョンの概略を示すデータのブロックです。レポートの表紙のように、レジャーバージョンを一意に識別し、その内容を記載し、他の注意事項とともに作成時刻を表しています。レジャーヘッダーには以下の情報が含まれます。

 <!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->

- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg "") チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg "") レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg "") 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg "") このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg "") このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg "") このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg "") その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。
+- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg) チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
+- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg) レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
+- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg) 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
+- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg) このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
+- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg) このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
+- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg) このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
+- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg) その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。

 レジャーのトランザクションセットと状態データのサイズは無制限ですが、レジャーヘッダーは常に固定サイズです。レジャーヘッダーの正確なデータとバイナリ形式については、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)をご覧ください。

-
 ## バリデーションの状況

-[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg "Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。")
+[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg 'Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。')

 サーバの Unique Node List のバリデータのコンセンサスがレジャーバージョンの内容に合意すると、そのレジャーバージョンは検証済みであり、変更不可であるとみなされます。レジャーの内容は、後続のトランザクションが新しいレジャーバージョンを作成し、チェーンを更新することによってのみ変更できます。

 レジャーバージョンが新しく作成された時点では、まだ未検証です。候補となるトランザクションが異なるサーバに到着するタイミングが異なるため、ネットワークはチェーンの次のステップとなる複数の異なるレジャーバージョンを構築し、提案する可能性があります。[コンセンサスプロトコル](../consensus-protocol/index.md)は、そのうちのどれを有効化するかを決定します。(検証済みのレジャーバージョンに存在しなかったトランザクション候補は、通常、次のレジャーバージョンのトランザクションセットに含まれます)。

-
 ## レジャーインデックスとレジャーハッシュ
+
 レジャーバージョンを識別する方法には、 _レジャーインデックス_ と _レジャーハッシュ_ の2種類があります。この2つのフィールドはどちらもレジャーを識別しますが、その目的は異なります。レジャーインデックスはチェーン内でのレジャーの位置を表し、レジャーハッシュはレジャーの内容を表します。

 異なるチェーンのレジャーは、レジャーインデックスは同じでもハッシュが異なることがあります。また、検証されていないレジャーバージョンを扱う場合、インデックスが同じでも内容が異なるため、ハッシュが異なる複数のレジャー候補が存在する可能性があります。
--- a/Show More
+++ b/Show More