rm reference to pre-refactor escrow code sample

Update community page content and links

.env

@@ -0,0 +1,4 @@
+PUBLIC_GITHUB_FORK=https://github.com/XRPLF/xrpl-dev-portal
+PUBLIC_GITHUB_BRANCH=master
+PUBLIC_OWNER_RESERVE=0.2 XRP
+PUBLIC_BASE_RESERVE=1 XRP

.github/workflows/link-checker-pr.yml

@@ -1,75 +0,0 @@
-name: Link Checker (PR Build)
-
-on:
-  # Note: DO NOT change this to "pull request_target" since that grants
-  # permission for PRs from random forks to modify the repo itself!
-  pull_request:
-    types: [opened, edited, synchronize]
-
-jobs:
-  build:
-    name: "Build and Check Links"
-    runs-on: ubuntu-latest
-
-    steps:
-    - uses: actions/checkout@v3
-
-    - name: Set up Python ${{ matrix.python-version }}
-      uses: actions/setup-python@v4
-      with:
-        python-version: "3.9"
-
-    - name: Install dependencies
-      run: |
-        python -m pip install --upgrade pip
-        pip install dactyl lxml
-
-    - name: Check for Conflict Markers
-      run: |
-        tool/conflictmarkers.sh
-
-    - name: Build docs
-      run: |
-        echo '{"github_forkurl": "https://github.com/${{ github.event.pull_request.head.repo.full_name }}", "github_branch": "${{ github.head_ref }}", "github_pr_id": "${{ github.event.number }}", "is_pr_build": true}' > dactyl_vars.json
-        tool/build_all_langs.sh --vars dactyl_vars.json
-
-    - name: Run Dactyl Link Checker
-      continue-on-error: true
-      id: linkcheck
-      run: |
-        dactyl_link_checker -o -q > linkreport.txt
-
-    - name: Assemble Link Report
-      run: |
-        sed -i '1,/---------------------------------------/d' linkreport.txt
-        echo 'LINKREPORT<<EOF' >> $GITHUB_ENV
-        head -c 65300 linkreport.txt >> $GITHUB_ENV
-        echo 'EOF' >> $GITHUB_ENV
-        cat linkreport.txt
-
-    - name: Run Style Checker
-      continue-on-error: true
-      run: dactyl_style_checker -q > out/style_report.txt
-
-    # This only works with PRs that are in-repo, not from forks.
-    # TODO: delete folders from gh-pages when PRs are closed
-    - name: Deploy to gh-pages
-      if: ${{ !github.event.pull_request.head.repo.fork }}
-      uses: peaceiris/actions-gh-pages@v3
-      with:
-        github_token: ${{ secrets.GITHUB_TOKEN }}
-        publish_dir: ./out
-        destination_dir: ./pr-preview/${{ github.head_ref }}
-
-    - name: Summarize Output
-      if: ${{ !github.event.pull_request.head.repo.fork }}
-      uses: thollander/actions-comment-pull-request@v1
-      with:
-        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        message: "${{ env.LINKREPORT }}\n\nPreview: https://${{ github.repository_owner }}.github.io/${{ github.event.pull_request.base.repo.name }}/pr-preview/${{ github.head_ref }}/\n\n[Style Report](https://${{ github.repository_owner }}.github.io/${{ github.event.pull_request.base.repo.name }}/pr-preview/${{ github.head_ref }}/style_report.txt)"
-
-      # Workaround for https://github.com/actions/toolkit/issues/399
-      # to mark the CI as failed if the link checker found broken links.
-    - name: Mark Failure
-      if: steps.linkcheck.outcome != steps.linkcheck.conclusion
-      run: exit 1

.gitignore

@@ -3,10 +3,11 @@ node_modules/
 .DS_Store
 __pycache__
 out/
-package-lock.json
 yarn-error.log
 /.idea
+*.iml
 .venv/
+_code-samples/*/js/package-lock.json
 
 # PHP
 composer.lock

@l10n/es-ES/CODE_OF_CONDUCT.md

@@ -0,0 +1,48 @@
+# Código de conducta del pacto de contribuidores
+
+## Nuestro compromiso
+
+Con el fin de fomentar un ambiente abierto y acogedor, nosotros, como contribuidores y mantenedores, nos comprometemos a hacer de la participación en nuestro proyecto y nuestra comunidad una experiencia libre de acoso para todos, independientemente de, entre otras, características como la edad, tamaño corporal, discapacidad, origen étnico, características sexuales, identidad y expresión de género, nivel de experiencia, educación, estatus socioeconómico, nacionalidad, apariencia personal, raza, religión o identidad y orientación sexual.
+
+## Nuestros estándares
+
+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
+
+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
+
+## Nuestras responsabilidades
+
+Los mantenedores del proyecto son responsables de aclarar los estándares de comportamiento aceptable y se espera que tomen acciones correctivas justas y apropiadas en respuesta a cualquier caso de comportamiento inaceptable.
+
+Los mantenedores del proyecto tienen el derecho y la responsaiblidad de eliminar, editar o rechazar comentarios, commits, código, ediciones de wiki, problemas y otras contribuciones que no estén alineadas con este Código de Conducta, o de expulsar temporal o definitivamente a cualquier colaborador por otros comportamientos que consideren inapropiados, amenazantes, ofensivos, dañinos o que viole de cualquier modo este Código de Conducta.
+
+## Alcance
+
+Este Código de Conducta aplica en todos los espacios del proyecto y también aplica cuando un individuo está representando el proyecto o su comunidad en espacios públicos. Ejemplos de representación de un proyecto o la comunidad incluye usar un correo electrónico oficial del proyecto, publicaciones a través de una cuenta oficial de redes sociales o actuar como representante asignado en un evento en línea o en la vida real. La representación de un proyecto debe ser definida y aclarada con más detalle por los mantenedores del proyecto.
+
+## Aplicación
+
+Los casos de comportamiento abusivo, acoso, o de cualquier otro modo inaceptable se pueden informar contactando con el equipo del proyecto al correo <ripplex@ripple.com>. Todas las quejas serán revisadas e investigadas y resultarán en una resupuesta que se considere adecuada y necesaria a las circunstancias. El equipo del proyecto está obligado a mantener la confidencialidad con respecto al informador del incidente. Podría darse el caso de publicar más detalles sobre políticas de comportamiento específicas.
+
+Los mantenedores de proyecto que no sigan o hagan cumplir el Código de conducta de buena fe podrían enfrentarse a repercusiones temporales o definitivas según lo determinen otros miembros que lideren el proyecto.
+
+## Atribución
+
+Este Código de Conducta está adaptado de el [Pacto del Contribuidores][inicio], versión 1.4, disponible en https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[inicio]: https://www.contributor-covenant.org
+
+Para respuestas a preguntas comunes sobre este código de conducta, visita
+https://www.contributor-covenant.org/faq

@l10n/es-ES/CONTRIBUTING.md

@@ -0,0 +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).

@l10n/es-ES/about/faq.md

@@ -0,0 +1,151 @@
+---
+seo:
+    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. #}-->
+
+#### ¿Es XRPL una blockchain privada, propiedad de Ripple?
+
+No, el XRP Ledger es una blockchain pública y descentralizada. Cualquier cambio que impactase al proceso de las transacciones o al consenso necesita ser aprobado por al menos el 80%% de la red. Ripple es un contribuidor de la red, pero sus derechos son los mismos que los de otros contruibuidores. En términos de validación, hay más de 150 validadores en la red con más de 35 en la Lista de Nodos Únicos (ver [“¿Qué son las Listas de Nodos Únicos (UNLs en inglés)?” abajo](#what-are-unique-node-lists-unls)) — Ripple mantiene [solo 1](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/) de esos nodos.
+
+#### ¿No es la Prueba de Trabajo (Proof of Work) el mejor mecanísmo de validación?
+
+La Prueba de Trabajo (PoW en inglés) fue el primer mecanismo para resolver el problema del doble gasto sin requerir a un tercero de confianza. [El mecanismo de consenso del XRP Ledger](../docs/concepts/consensus-protocol/index.md) resuelve el mismo problema de una manera mucho más rápida, barata y energéticamente más eficiente.
+
+#### ¿Cómo puede ser una blockchain sostenible?
+
+Se sabe abiertamente que el consumo de energia de Bitcoin, a partir de 2021, es equivalente al utilizado por Argentina, mucha de la electricidad que usan los mineros de Bitcoin procede de fuentes contaminantes. El XRP Ledger confirma transacciones a través del mecanismo de “[consenso](../docs/concepts/consensus-protocol/index.md)” - el cual no desperdicia energía como lo hace la prueba de trabajo - y aprovecha las compensaciones de carbono para ser [una de la primeras blokchains verdaderamente neutral en carbono](https://ripple.com/ripple-press/ripple-leads-sustainability-agenda-to-achieve-carbon-neutrality-by-2030/).
+
+#### ¿Pueden otras divisas que no sean XRP ser intercambiadas a través del XRPL?
+
+Sí, el XRP Ledger fue creado específicamente para poder tokenizar activos arbitrarios, como el USD, EUR, petróleo, oro, puntos de fidelización, y más. Cualquier divisa puede ser emitida en el XRP Ledger. Esto se ilustra en la creciente comunidad que respalda una variedad de tokens cripto y fiat.
+
+#### ¿No es XRPL solo para pagos?
+
+Aunque XRPL inicialmente se desarrolló para casos de uso de pagos, tanto el libro mayor como el activo nativo digital XRP se han ido popularizando para un rango de casos de uso innovadores como los NFTs. Nuevas propuestas de estándares para un creador de mercados automatizado (en inglés, AMM), la enmienda de los "hooks" para la funcionalidad de contratos inteligentes, y puentes entre cadenas están siendo desarrollados.
+
+## Validadores y Listas de Nodos Únicos
+
+#### ¿Qué servicio brindan los validadores de transacciones?
+
+Todos los nodos garantizan que las transacciones cumplen los requisitos del protocolo y, por lo tanto, son "válidas". El servicio que proveen los validadores de manera única es agrupar administrativamente las transacciones en unidades ordenadas, acordando uno de esos órdenes específicamente para prevenir el doble gasto. <!-- STYLE_OVERRIDE: therefore -->
+
+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.
+
+Si ejecutas un servidor XRP Ledger para participar en la red, el costo y el esfuerzo adicionales para ejecutar un validador son mínimos. Esto significa que no son necesarios incentivos adicionales, como las recompensas mineras en Bitcoin. Ripple evita pagar XRP como recompensa por operar un validador para que dichos incentivos no deformen el comportamiento de los validadores.
+
+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.
+
+En el proceso de determinar la versión autoritativa de un ledger, puede haber varias versiones internas temporales. Estas versiones internas ocurren naturalmente en sistemas distribuidos porque no todos los nodos reciben transacciones en el mismo orden. El comportamiento análogo en Bitcoin es cuando dos servidores ven cada uno una cadena más larga diferente porque dos bloques fueron extraídos aproximadamente al mismo tiempo.
+
+Sin embargo, sólo puede haber una última versión del ledger _validated_ en un momento dado; otras versiones son irrelevantes e inofensivas.
+
+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.
+
+Los publicadores de UNL predeterminados individuales establecen sus propias políticas sobre cuándo agregar o eliminar validadores de sus listas de recomendaciones.
+
+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 -->
+
+La red XRP Ledger es una red abierta y todas las transacciones son públicamente visibles.
+
+Ripple se compromete a monitorear e informar cualquier indicador AML en la red XRP Ledger, así como a informar actividades sospechosas a FinCEN, según corresponda.
+
+[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.
+
+Este pull request activa pruebas unitarias y de integración automatizadas, así como revisiones de código por parte de varios desarrolladores que, por lo general, tienen experiencia significativa en el área de código a la que afecta al pull request.
+
+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.
+
+Ripple contribuye a una implementación de referencia del nucleo del servidor de XRP Ledger ([`rippled`](https://github.com/xrplf/rippled)) y emplea un equipo de ingenieros que contribuyen al código base de código abierto. Ripple publica periodicamente paquetes binarios precompilados. Cualquiera puede [descargar y compilar el software desde la fuente](../docs/infrastructure/installation/index.md).
+
+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.

@l10n/es-ES/about/privacy-policy.md

@@ -0,0 +1,126 @@
+---
+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.
+---
+# Política de privacidad de XRPL.org
+
+Última actualización: 20 de enero, 2023
+
+MTU XRP Ledger Trust (“MTU XRP Ledger Trust”, "Nosotros"", "Nuestro") respeta la necesidad de privacidad de los usuarios, y esta Política de Privacidad describe la recopilación, uso y divulgación de tu información cuando usas este servicio.
+
+## Definiciones
+
+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.
+
+## Recopilación y uso de tus datos
+
+### Tipos de datos recopilados
+
+**Datos de Uso** se recopilan automáticamente al utilizar este Servicio. Los Datos de Uso pueden incluir información como la dirección de Protocolo de Internet de Tu Dispositivo (por ejemplo, dirección IP), tipo de navegador, versión del navegador, las páginas de nuestro Servicio que Tu visitas, la hora y fecha de Tu visita, el tiempo que pasa en esas páginas, identificadores de dispositivos únicos y otros datos de diagnóstico.
+
+Cuando accedes al Servicio a través de un dispositivo móvil, Nosotros podemos recopilar cierta información automáticamente, incluido, entre otros, el tipo de dispositivo móvil que Tu utilizas, TU ID único de dispositivo móvil, la dirección IP de Tu dispositivo móvil, Tu sistema operativo móvil, el tipo de navegador de Internet móvil que Tu utilizas, identificadores de dispositivos únicos y otros datos de diagnóstico.
+
+Nosotros también podemos recopilar información que Tu navegador envía cada vez que visita Nuestro Servicio o cuando accedes al Servicio a través de un dispositivo móvil.
+
+## Tecnologías de seguimiento y cookies
+
+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).
+
+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.
+
+## Use of Your Usage Data
+
+La Compañía puede utilizar Datos de Uso para los siguientes propósitos:
+
+**Proporcionar o mantener nuestro Servicio**, incluyendo el monitoreo del uso de nuestro Servicio.
+**Para gestionar Tus peticiones:** Para atender y gestionar Tus solicitudes por Nosotros.
+
+**Para otros propositos:** Podemos utilizar Tus Datos de Uso para otros propósitos, tales como el análisis de datos, identificar tendencias de uso, determinar la eficacia de nuestras campañas publicitarias y para evaluar y mejorar nuestro Servicio y Tu experiencia.
+
+Puede que compartamos Tus Datos de Uso en las siguientes situaciones:
+
+**Con Proveedores de servicios:** Podemos compartir Tus Datos de Uso con Proveedores de servicios para monitorear y analizar el uso de Nuestro Servicio.
+
+**Con socios comerciales:** Podemos compartir Tus Datos de Uso con Nuestros socios comerciales que proporcionan contenido en este sitio web.
+
+**Con Tu consentimiento:** Podemos divulgar Tus Datos de Uso para cualquier otro propósito con Tu consentimiento.
+
+## Retención de Tus Datos de Uso
+
+La Compañía retendrá Tus Datos de Uso solo durante el tiempo que sea necesario para los fines establecidos en esta Política de Privacidad. Conservaremos y utilizaremos Tus Datos de Uso en la medida necesaria para cumplir con nuestras obligaciones legales (por ejemplo, si estamos obligados a conservar tus datos para cumplir con las leyes aplicables, fortalecer la seguridad o mejorar la funcionalidad de Nuestro Servicio, resolver disputas y hacer cumplir nuestros acuerdos y políticas legales.
+
+## Transferencia de Tus Datos de Uso
+
+Tus Datos de Uso son procesados en las oficinas operativas de la Compañía y en cualquier otro lugar donde se encuentren las partes involucradas del procesamiento. Esto significa que esta información puede ser transferida a — y mantenida en — computadoras ubicadas fuera de Tu estado, provincia, país u otra jurisdicción gubernamental donde las leyes de protección de datos pueden diferir de las de Tu jurisdicción.
+
+Tu consentimiento a esta Política de Privacidad seguido de Tu envío de dicha información representa Tu acuerdo con esa transferencia.
+
+## Divulgación de Tus Datos de Uso
+
+## Aplicación de la ley
+
+Bajo ciertas circunstancias, La Compañía puede estar obligada a divulgar Tus Datos de Uso si es requerido por la ley o en respuesta a peticiones válidas de autoridades públicas (por ejemplo, un tribunal o un agencia gubernamental).
+
+## Otros requisitos legales
+
+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
+
+## Seguridad de Tus Datos Personales
+
+La seguridad de Tus Datos es importante para Nosotros, pero recuerda que ningún método de transmisión por Internet o método de almacenamiento electrónico es 100% seguro. Si bien nos esforzamos por utilizar medios comercialmente aceptables para proteger Tus Datos, no podemos garantizar su seguridad absoluta.
+
+## Privacidad de los niños
+
+Nuestro Servicio no se dirige a nadie menor de 13 años. No recopilamos de manera consciente información de identificación personal de nadie menor de 13 años. Si Tu eres padre/madre o tutor y sabes que Tu hijo nos ha proporcionado Datos Personales, por favor, contáctanos. Si nos damos cuenta de que hemos recopilado Datos Personales de alguien menor de 13 años sin verificación del consentimiento de los padres, tomamos medidas para eliminar esa información de Nuestros servidores.
+
+Si necesitamos basarnos en el consentimiento como base legal para procesar Tu información y Tu país requiere consentimiento de un padre, podemos requerir el consentimiento de Tus padres antes de recopilar y usar esa información.
+
+## Enlaces a otros sitios web
+
+Nuestro Servicio puede contener enlaces a otros sitios web que no son operados por Nosotros. Si haces clic en un enlace de un tercero, serás dirigido a ese sitio web de terceros. Te recomendamos encarecidamente que revises la Política de Privacidad de cada sitio que visites.
+
+No tenemos control sobre, y no asumimos responsabilidad por el contenido, políticas de privacidad o prácticas de sitios o servicios de terceros.
+
+## Cambios en esta Política de Privacidad
+
+Podemos actualizar Nuestra Política de Privacidad de vez en cuando. Te notificaremos cualquier cambio publicando la nueva Política de Privacidad en esta página. Te proporcionaremos un aviso destacado en Nuestro Servicio, antes de que el cambio entre en vigor y actualizaremos la fecha de "Última actualización" en la parte superior de esta Política de Privacidad.
+
+Te recomendamos que revises esta Política de Privacidad periódicamente para ver si hay cambios. Los cambios a esta Política de Privacidad son efectivos cuando se publican en esta página.
+
+## Contáctanos
+
+Si tienes alguna pregunta sobre nuestra Política de Privacidad, puedes contactarnos:
+
+MTU XRP Ledger Trust
+
+**Oficina en Regd**  
+15, Ringtee  
+Kuressaare  
+Estonia 93815
+
+**Oficina en Tallinn**  
+802, Lõõtsa tn 5  
+Tallinn  
+Estonia 11415
+
+**Por correo electrónico:** info@xrplf.org

@l10n/es-ES/community/report-a-scam.md

@@ -0,0 +1,31 @@
+---
+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. 
+
+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)
+
+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.
+
+Para más detalles sobre reportar estafadores, consultar [Ayuda de Xrplorer Forensics](https://xrplorer.com/forensics/help).
+
+Para pedir ayuda de la comunidad de XRP Ledger, también puedes probar el [foro XRPChat](https://xrpchat.com).

@l10n/es-ES/docs/concepts/accounts/account-types.md

@@ -0,0 +1,84 @@
+---
+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.
+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.")
+
+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.
+
+Las direcciones de reserva, que son operadas por personas reales, envían esos tokens a direcciones operacionales. Este paso permite que la dirección emisora sea utilizada lo menos posible después de este punto, mientras tienen al menos algunos tokens disponibles en espera.
+
+Las direcciones operacionales, las cuales son operadas por sistemas automatizados, envían pagos a otras contrapartes, como proveedores de liquidez, socios y otros clientes. Esas contrapartes pueden enviar fondos libremente entre ellas varias veces.
+
+Como siempre, los pagos con tokens deben moverse a través de líneas de confianza (trust lines) del emisor.
+
+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.
+
+A diferencia de una caja fuerte, la dirección emisora puede recibir pagos directamente de clientes o socios. Como todas las transacciones en el XRP Ledger son públicas, los sistemas automatizados pueden observar los pagos a la dirección emisora sin necseisdad de una clave secreta.
+
+### Dirección emisora comprometida
+
+Si un actor malicioso descubre la clave secreta de la dirección emisora de una institución, ese actor puede crear nuevos tokens y enviarlos a usuarios o intercambiarlos en el exchange descentralizado. Esto puede hacer hacer a un emisor de stablecoin insolvente. Puede resultar dificil para la institución financiera distinguir los tokens obtenidos legítimanente y canjearlos de manera justa. Si una institución pierde el control de la dirección emisora, la institución debe crear una nueva dirección emisora, y todos los usuarios que tenían una trust line a la dirección emisora antigua, deben crear un nueva trust line a la nueva dirección.
+
+### Múltiples direcciones de emisión
+
+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/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.
+
+Cada dirección operacional tiene un balance limitado de tokens y XRP. Cuando el balance de una dirección operacional disminuye, la institución financiera la recarga enviando un pago desde la dirección emisora o desde la dirección de reserva.
+
+### Direciones operacionales comprometidas
+
+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.
+
+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.
+
+Como con las direcciones operacionales, una direccion de reserva debe tener una relación contable con la dirección emisora, y no con los clientes o socios. Todas las precauciones que aplican a las direcciones operacionales también aplican a las direcciones de reserva.
+
+### Dirección de reserva comprometida
+
+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)
+- **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)
+- **Referencias:**
+    - [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" /%}

@l10n/es-ES/docs/concepts/accounts/addresses.md

@@ -0,0 +1,96 @@
+---
+html: addresses.html
+parent: accounts.html
+seo:
+    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" /%}
+
+Cualquier dirección válida puede [convertirse en una cuenta en el XRP Ledger](index.md#creacion-de-cuentas) al recibir fondos. Puedes utilizar una cuenta que no ha recibido fondos para representar una [clave normal, regular key en inglés](cryptographic-keys.md) o ser miembro de una [lista de firmantes](multi-signing.md). Solo una cuenta que ha recibido fondos puede ser el remitente de una transacción.
+
+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í |
+
+
+## Codificación de una dirección
+
+**Consejo:** ¡Estos detalles técnicos son solo relevantse para personas que crean librerias de software de bajo nivel para la compatibilidad con el XRP Ledger!
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Fuente")
+
+Las direcciones XRP Ledger están codificadas utilizando [base58][] con el _diccionario_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Como el XRP Ledger codifica varios tipos de claves con base58, antepone los datos codificados con un-byte de "prefijo de tipo" (también conocido como "prefijo de versión") para distinguirlos. El prefijo de tipo hace que las direcciones normalmente comiencen con diferentes letras en formato base58.
+
+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")
+
+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.
+
+        ```
+        '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'));
+        ```
+
+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 =
+          'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
+        const pubkey = Buffer.from(pubkey_hex, 'hex');
+        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".
+
+        ```
+        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. 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]);
+        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. 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]);
+        const address = base58.encode(dataToEncode);
+        console.log(address);
+        // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
+        ```
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md

@@ -0,0 +1,259 @@
+---
+html: cryptographic-keys.html
+parent: accounts.html
+seo:
+    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.
+
+Para realizar una firma digital, utilizas un par de claves criptográficas asociadas con la cuenta de envío de la transacción. Un par de claves se puede generar utilizando cualquiera de los [algoritmos de firma criptorgráfica](#algoritmos-de-firma) soportados por el XRP Ledger. Un par de claves puede ser utilizado como [par de claves maestras](#par-de-claves-maestras), [par de claves normales](#par-de-claves-normales) o un miembro de una [lista de firmantes](multi-signing.md), sin importar qué algoritmo se ha utilizado para generarlo.
+
+**Atención:** Es importante mantener una seguridad adecuada sobre tus claves criptográficas. Las firmas digitales son la única forma de autorizar transacciones en el XRP Ledger, y no hay administrador privilegiado que pueda deshacer o revertir cualquier transacción tras haber sido aplicadas. Si alguien más conoce la semilla o la clave privada de tu cuenta del XRP Ledger, esa persona puede crear firmas digitales para autorizar cualquier transacción al igual que tú.
+
+## Generación de claves
+
+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")
+_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.
+
+La clave pública, el ID de cuenta, y dirección son información pública. Puede haber situaciones en las que puedes conservar la clave pública para ti mismo, pero en algún momento necesites publicarla como parte de una transacción para que el XRP Ledger pueda verificar la firma y el proceso de la transacción.
+
+Para más detalles técnicos y como la derivación de clave funciona, ver [Derivación de claves](#derivación-de-claves).
+
+### 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 -->
+
+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 
+
+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.
+
+El valor semilla es una información secreta, por lo que debes que protegerla con mucho cuidado. Cualquiera que conozca el valor semilla de una dirección tiene control total sobre la dirección.
+
+### Clave privada
+
+La _clave privada_ es un valor utilizado para crear una firma digital. La mayoría de software XRP Ledger no muestra explicitamente la clave privada, y [deriva la clave privada](#derivación-de-claves) desde el valor semilla cuando es necesario. Es técnicamente posible guardar la clave privada en vez de la semilla para usarla con el fin de firmar transacciones directamente, pero no es algo común.
+
+Como la semilla, la clave privada es información secreta, por lo que debes protegerla con mucho cuidado. Cualquiera que conozca la clave privada de la dirección tiene control total sobre la dirección.
+
+### Clave pública
+
+La _clave pública_ es un valor utilizado para verificar la autenticidad de una firma digital. La clave pública se deriva de una clave privada como parte de la derivación de clave. En la respuesta de un [método wallet_propose][], ambas, la `public_key` y `public_key_hex` representan el mismo valor de clave pública.
+
+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:
+
+- 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.
+
+El checksum en ambos formatos está ahi para que los resultados con pequeños cambios resulte en una dirección inválida, en lugar de cambiarla para que haga referencia a una cuenta diferente, pero aún potencialmente válida. De esta forma, si cometes un error tipográfico u ocurre un error de tranmisión, no enviarás dinero al lugar equivocado.
+
+Es importante saber que no todos los IDs de cuenta (o direcciones) se refieren a cuentas en el ledger. Derivar claves y direcciones es una operación puramente matemática. Para que una cuenta tenga un registro en el XRP Ledger, es necesario [recibir un pago en XRP](index.md#creating-accounts) que cumpla su [requisito de reservas](reserves.md). Una cuenta no puede enviar ninguna transacción hasta que se haya recibido fondos.
+
+Incluso si una ID de cuenta o dirección no se refiere a una cuenta con fodos, _puedes_ usar ese ID de cuenta o la dirección para representar un [par de claves](#par-de-claves-normales) o un [miembro de una lista de firmantes](multi-signing.md).
+
+### Tipo de clave
+
+El XRP Ledger soporta más de un [algoritmo de firma criptográfica](#algoritmos-de-firma). Cualquier par de claves determinado es únicamente válida para un algoritmo de firma criptográfica específico. Algunas claves privadas pueden técnicamente ser claves válidas para más de un algoritmo, pero esas claves privadas tendrían distintas claves públicas para cada algoritmo, y no deberías reutilizar las claves privadas.
+
+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.
+
+El [metodo wallet_propose][] es una forma de generar el par de claves maestras. La respuesta de este método muestra la semilla de la cuenta, dirección, y la clave pública maestra juntos. Para ver otros métodos para configurar pares de claves maestras, consultar [Firma segura](../transactions/secure-signing.md).
+
+**Atención:** Si un actor malicioso conoce tu clave privada maestra (o semilla), tendrá control completo sobre tu cuenta, a no ser que tu par de claves maestras se inhabilite. Puedes tomar todo tu dinero de la cuenta posee y causar un daño irreparable. ¡Trata tus valores secretos con cuidado!
+
+Dado que cambiar el par de claves maestras es imposible, debes cuidarlo en proporción al valor de lo que posea. Una buena práctica es [guardar tu par de claves maestras offline](../../tutorials/how-tos/manage-account-settings/offline-account-setup.md) y configurar un par de claves normales para firmar transacciones en tu cuenta. Al mantener el par de claves maestras activadas pero offline, puedes estar razonablemente seguro de que nadie puede acceder a él a través de Internet, pero aun así deberías encontrarlo en caso de una emergencia.
+
+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:
+
+- Enviar la primera transacción de una cuenta, porque las cuentas no se pueden inicializar de otra manera que [autorizando transacciones](../transactions/index.md#authorizing-transactions).
+
+- Deshabilitar el par de claves maestras.
+
+- Renunciar permanentemente a la posibilidad de [congelar](../tokens/fungible-tokens/freezes.md#no-freeze).
+
+- Enviar una [transacción de reestablecimiento de clave](../transactions/transaction-cost.md#key-reset-transaction) especial con una transacción de 0 XRP de coste.
+
+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.
+
+Un par de claves normales pueden autorizar la mayoría de tipos de transacciones que una par de claves maestras puede, con [ciertas excepciones](#pemrisos-especiales). Por ejemplo, un par de claves nomales _puede_ autorizar una transacción para cambiar el par de claves normales.
+
+Una buena práctica de seguridad es guardar tu clave privada maestra en algun sitio offline, y usar un par de claves normales la mayor parte del tiempo. Como precaución, puedes cambiar el par de claves normales regularmente. Si un usuario malicioso descubre tu clave privada normal, puedes tomar el par de claves maestras de tu escondite offline y usarlo para cambiar o eliminar el par de claves normales. De este modo, puedes volver a retomar el control de la cuenta. Incluso si no eres demasiado rápido para parar al usuario malicioso de robar tu dinero, al menos no tendrás necesidad de moverte a una nueva cuenta y tener que recrear tu configuración y relaciones desde el principio.
+
+El par de claves normales tiene el mismo formato que el par de claves maestras. Las generas de la misma forma (por ejemplo, usando el [método wallet_propose][]). La única diferencia es que el par de claves normales es que el par no está intrínsicamente vinculado a la cuenta para la que firma transacciones. Es posible (pero no es buena idea) utilizar el par de claves maestras de una cuenta como lel par de claves normales para otra cuenta.
+
+La [transacción SetRegularKey][] asigna o cambia el par de claves normales de una cuenta. Para un tutorial de asignación o cambio de un par de claves normales, ver [Asignar par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md).
+
+
+## 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. |
+
+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.
+
+
+### 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).
+
+### Código de ejemplo
+
+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)
+- 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")
+
+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.
+
+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.
+
+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.
+
+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.
+
+### 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")
+
+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:
+
+- No todos los números 32-byte son válidos para claves secretas secp256k1.
+- La implementación de referencia en XRP Ledger tiene un marco incompleto y no usado para derivar una familia de claves públicas desde un valor semilla único inicial.
+
+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. 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.
+
+    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`.
+
+    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.
+
+    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.
+
+    Puedes convertir una clave pública sin comprimir a la forma comprimida desde la herramienta de línea de comandos `openssl`. Por ejemplo, si la clave pública está en el fichero `ec-pub.pem`, puedes sacar el formato comprimido de esta manera:
+
+        ```
+        $ 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í:
+
+    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.
+
+    2. Calcula el [SHA-512Half][] del valor concatenado.
+
+    3. Si el resultado noes euna clave secreta válida secp256k1, incrementa la secuencia clave en 1 y reiniciala derivación de la cuenta desde el par de claves intermedio de la cuenta.
+
+    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).
+
+    - 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.
+
+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)
+- **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)
+- **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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md

@@ -0,0 +1,79 @@
+---
+html: decentralized-identifiers.html
+parent: accounts.html
+seo:
+    description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
+status: not_enabled
+labels:
+  - DID
+---
+# Identificadores descentralizados
+
+_(REquiere de la [enmienda DID][] {% not-enabled /%})_
+
+Un identificador descentralizado (DID) es un nuevo tipo de identificador definido por el World Wide Web Consortium (W3C) que permite identidades digitales verificables. Los DIDs están completamente bajo el control del dueño del DID, independientemente de cualquier registro centralizado, proveedor de identidad, o autoridad certificada.
+
+Los principios clave de un DID son:
+
+- **Descentralizacion:** No hay una agencia emisora central que controla el DID, lo que permite al propietario actualizar, resolver o desactivarlo.
+
+- **Criptográficamente verificable:** Los DIDs son verificados a través de pruebas criptográficas, lo que los hace a prueba de manipulaciones y seguros.
+
+- **Interoperabilidad:** Los DIDs están abiertos a cualquier solución que reconozca el estandar W3C DID. Esto quiere decir que un DID puede ser utilizado para autenticar y establecer confianza en varias transacciones digitales e interacciones.
+
+**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.
+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.
+
+**Nota:** Los documentos DID suelen serializarse en una representación JSON o JSON-LD.
+
+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.
+
+
+### 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..."
+        }
+    ]
+}
+```
+
+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.
+- Puedes incluir cualquier contenido en un documento DID, pero deberías limitarlo a métodos de verificación y puntos de servicio. Como los DIDs en XRPL pueden ser resueltos por cualquiera, no deberías introducir ninguna información personal.
+- IPFS permite a cualquiera almacenar contenido en los nodos de una red distribuida. Un error común es que cualquiera puede editar ese contenido; sin embargo, la capacidad de direccionamiento del contenido de IPFS significa que cualquier contenido editado tendrá una dirección diferente a la original. Mientras que cualquier entidad puede copiar un documento DID anclado a los campos `DIDDocument` o `URI` de una cuenta XRPL, no pueden cambiar el documento en sí a menos que controlen la clave privada que creó el objeto `DID`.
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md

@@ -0,0 +1,37 @@
+---
+seo:
+    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).
+
+Algún tipo de entradas asociadas al ledger bloquean a una cuenta de ser eliminada. Por ejemplo, el emisor de un token fungible no puede ser borrad mientras cualquiera teng un saldo distinto a cero de ese token como balance.
+
+Una vez una cuenta ha sido eliminada, puede ser recreada en el eldger a través de un método normal de [creación de cuentas](index.md#creating-accounts). Una cuenta que ha sido eliminada y re-creada no es diferente de una cuenta que ha sido creada por primera vez.
+
+## Requisitos
+
+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`
+- 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 %}).
+
+## Coste de eliminación
+
+**Atención:** El coste de transacción de la [transacción AccountDelete][] siempre aplica cuando la transacción está incluida en un ledger validado, incluso si la transacción falla porque la cuenta no reune los requisitos para ser eliminada. Para reducir las posibilidades de pagar un coste de transacción alto si la cuenta no puede ser eliminada, utiliza la opción `fail_hard` cuando envíes una transacción AccountDelete.
+
+A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la cadena del ledger público de XRP Ledger contiene el estado completo del ledger, lo cual incrementa en tamaño con cada cuenta nueva. Por esa razón, no deberías crear nuevas cuentas XRP Ledger si no tienes necesidad. Puedes recuperar parte de los {% $env.PUBLIC_BASE_RESERVE %} de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos {% $env.PUBLIC_OWNER_RESERVE %} haciéndolo.
+
+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" /%}

@l10n/es-ES/docs/concepts/accounts/depositauth.md

@@ -0,0 +1,119 @@
+---
+html: depositauth.html
+parent: accounts.html
+seo:
+    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][].)_
+
+La Autorización para depositar es una configuración opcional de la [cuenta](index.md) en el XRP Ledger. Si se activa, La Autorización para depositar, bloquea todas las transferencias de desconocidos, incluidas las transferencias de XRP o [tokens](../tokens/index.md). Una cuenta con Autorización para depositar solo puede recibir valor de dos maneras:
+
+- Desde cuentas que tiene [preautorizadas](#preautorización).
+- Enviando una transacción para recibir los fondos. Por ejemplo, una cuenta con Autorización para depositar puede finalizar un [Escrow](../payment-types/escrow.md) que fue iniciado por un desconocido.
+
+Por defecto, las cuentas nuevas tienen DepositAuth desactivado y pueden recibir XRP de cualquiera.
+
+## Trasfondo
+
+Las regulaciones y licencias para servicios financieros pueden requerir a un negocio o entidad que deba conocer al remitente de todas las transacciones que recibe. Esto presenta un desafio en un sistema descentralizado como el XRP Ledger donde participantes son identificados con pseudónimos que son libremente generados y el comportamiento predeterminado es que cualquier dirección puede pagar a otra.
+
+La marca (flag) de Deposit Authorization introduce una opción para aquellos que utilizan el XRP Ledger para cumplir con las regulaciones sin cambiar la naturaleza fundamental del ledger descentralizado. Con La Autorización para depositar activada, una cuenta solo puede recibir fondos explícitamente aprobados enviando una transacción. El dueño de la uenta utilizando Deposit Authorization puede realizar la diligencia necesaria para identificar al remitente de cualquier fondo _antes_ de enviar la transacción que cuasa que la cuenta reciba el dinero.
+
+Cuando tienes la opción Deposit Authorization activada, puedes recibir dinero de [Checks](/resources/known-amendments.md#checks), [Escrow](../payment-types/escrow.md), y [Payment Channels](/resources/known-amendments.md#paychan). En esas transacciones de tipo "dos pasos", primero el origen manda una transacción para autorizar los fondos, después el destinatario manda una transacción que autoriza recibir esos fondos.
+
+Para recibir dinero de [transacciones Payment][] cuando tienes la opción Deposit Authorization activada, debes [preautorizar](#preautorización) los remitentes de esos Payments. _(Añadido por la [enmienda DepositPreauth][].)_
+
+## Uso recomendado
+
+Para conseguir un efecto total de Deposit Authorization, Ripple recomienda además hacer lo siguiente:
+
+- Siempre mantener un balance en XRP superior al mínimo del [requisito de reserva](reserves.md).
+- Mantener la marca (flag) Default Ripple en su estado por defecto (desactivada). No actives [rippling](../tokens/fungible-tokens/rippling.md) en ninguna trust lines. Cuando envíes [transacciones TrustSet][], siempre utiliza el [flag `tfSetNoRipple`](../../references/protocol/transactions/types/trustset.md).
+- No crees [Offers](../../references/protocol/transactions/types/offercreate.md). Es imposible conocer de antemano que ofertas coincidentes serán utilizadas para ejecutar dicha operación. <!-- STYLE_OVERRIDE: will -->
+
+## Precisión en la semántica
+
+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.
+- 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][])_
+- 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][])_
+- **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 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 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).
+
+## Comprobar cuando una cuenta tiene DepositAuth activado
+
+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.
+
+## Preautorización
+
+_(Añadido por la [enmienda DepositPreauth][].)_
+
+Las cuentas con DepositAuth activado pueden _preautorizar_ ciertos remitentes, para permitir pagos desde esos remitentes sean realizados aunque DepositAuth esté activado. Eseto permite a remitentes específicos enviar directamente fondos sin que el que vaya recibirlos tenga que tomar una acción para cada transacción individualmente. La preautorización no es obligatoria para usar DepositAuth, pero puede hacer ciertas opereaciones más sencillas.
+
+La preautorización es agnóstica en cuanto a divisas. No puede preautorizar cuentas para solo una moneda específicamente.
+
+Para preautorizar a un remitente en particular, envía una [transacción DepositPreauth][] con la dirección de otra cuenta para preautorizar en el campo `Authorize`. Para revocar la preautorización, facilita la dirección de la otra cuenta en el campo `Unauthorize`. Especifica tu propia dirección en el campo `Account` como de normal. Puedes preautorizar o desautorizar cuentas incluso si acutalmente no tienes activado DepositAuth; el estado preautorización que seleccionas para otras cuentas se guarda, pero no tiene efecto a no ser que actives DepositAuth. Una cuenta no puede preautorizarse a si misma. Las preautorizaciones son unidireccionales, y no tienen efecto en pagos que van en la otra dirección.
+
+Preautorizar otra cuenta añade un [objeto DepositPreauth](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md) al ledger, el cual incrementa la [reserva del propietario](reserves.md#owner-reserves) de la cuenta que provee la autorización. Su la cuenta revoca la preautorización, elimina el objeto y hace decrecer las reservas del propietario.
+
+Una vez que la transacción DepositPreauth ha sido procesada, la cuenta autorizada puede enviar fondos a tu cuenta, incluso si tienes DepositAuth activado, usando cualquiera de los siguientes tipos de transacción:
+
+- [Payment][]
+- [EscrowFinish][]
+- [PaymentChannelClaim][]
+
+Las preautorización no tiene efecto sobre las otras formas de enviar dinero a una cuenta con DepositAuth activado. Ver [Precisión en la semántica](#precise-semantics) para las reglas exactas.
+
+### Comprobar la autorización
+
+Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta autorizada para despositar en otra cuenta. Este método comprueba dos cosas: <!-- STYLE_OVERRIDE: is authorized to -->
+
+- 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][].
+- El [tipo de objeto del ledger DepositPreauth](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md).
+- El [método deposit_authorized][] de la [API `rippled`](../../references/http-websocket-apis/index.md).
+- La característica [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md) (`RequireAuth` flag) limita que contrapartes pueden poseer divisas no-XRP en la cuenta.
+- El flag `DisallowXRP` indica que una cuenta no puede recibir XRP. Es una protencción más suave que Deposit Authorization, y no la aplica el XRP Ledger. (Las aplicaciones cliente deberían respetar este flag o al menos avisar de ello.)
+- El flag `RequireDest` indica que una cuenta solo puede recibir cantidades de divisas si se especifica un [Destination Tag](../transactions/source-and-destination-tags.md). Esto protege a usuarios de olvidar incluir el propósito del pago, pero no protege a los destinatarios de remitentes desconocidos que pueden añadir destination tags arbitrarios.
+- [Pagos parciales](../payment-types/partial-payments.md) provee una forma para que cuentas puedan devolver pagos no deseados restando los [costes de transferencia](../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" /%}

@l10n/es-ES/docs/concepts/accounts/index.md

@@ -0,0 +1,69 @@
+---
+html: accounts.html
+parent: concepts.html
+seo:
+    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:
+
+- 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.)
+
+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.
+
+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.
+
+        **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)
+- **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)
+- **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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/accounts/multi-signing.md

@@ -0,0 +1,86 @@
+---
+html: multi-signing.html
+parent: accounts.html
+seo:
+    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.)
+
+Los beneficios del multi-signing incluyen:
+
+- Puedes requerir claves de distintos dispositivos, por lo que un actor malicioso deberá comprometer múltiples dispositivos para enviar transacciones en tu nombre.
+- Puedes compartir la custodia de una cuenta entre varias personas, cada una de las cuales tiene una de las varias claves necesarias para enviar transacciones desde esa dirección.
+- Puedes delegar el poder de enviar transacciones desde una dirección a un grupo de personas, puedes controlar tu dirección si no estás disponible o no puedes firmar normalmente.
+
+## Las listas de firmantes
+
+Antes de poder hacer multi-sign, debes crear una lista de direcciones que pueden firmar por ti.
+
+La [transacción SignerListSet][] define una _lista de firmantes_, un conjunto de direcciones que pueden autorizar una transacción desde tu dirección. Puedes incluir de 1 a 32 direcciones en la lista de firmantes. La lista no puede incluir tu dirección y no se puede duplicar las entradas. Puedes controlar cuantas firmas son necesarias, en que combinaciones, utilizando las opciones _Signer Weight_ (Peso de firmante) y _Quorum_ en la lista.
+
+_(Actualizado por la [enmienda ExpandedSignerList][].)_
+
+### Peso del firmante
+
+Asignas un peso a cada firmantes de la lista. El peso representa la autoridad del firmante relativa a otros firmantes de la lista. Mientras más alto el valor, más autoridad. Los pesos individuales no pueden exceder 2<sup>16</sup>-1.
+
+### Cuórum
+
+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.
+
+Para un caso de uso de una cuenta compartida, deberías crear una lista con un cuórum de 1, luego dar a todos los participantes un peso de 1. Una sola aprobación de uno de los participantes es necesario para aprobar una transacción.
+
+Para una cuenta muy importante, puedes configurar un cuórum de 3, con 3 partiicpantes que tienen un peso de 1. Todos los participantes deben estar de acuerdo y aprobar su transacción.
+
+Otra cuenta también podría tener un cuórum de 3. Asignas a tu CEO un peso de 3, 3 vicepresidentes un peso de 2 a cada uno, y 3 directores un peso de 1 a cada uno. Para aprobar una transacción en esta cuenta se requiere la aprobación de los 3 directores (peso total de 3), 1 vicepresidente y 1 director (peso total de 3), 2 vicepresidentes (peso total de 4), o del CEO (peso total de 3). <!-- STYLE_OVERRIDE: vice -->
+
+En cada uno de los tres ejemplos anteriores, deshabilitarías la clave maestra sin configurar la clave normal, así la única forma de [autorizar transactiones](../transactions/index.md#authorizing-transactions) es el multi-signing.
+
+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.)
+
+## 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)
+- **Conceptos:**
+    - [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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/accounts/reserves.md

@@ -0,0 +1,81 @@
+---
+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.
+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.
+
+Para tener una cuenta, una dirección debe tener una cantidad mínima de XRP en el ledger global compartido. Para financiar una nueva dirección, debes recibir el suficiente XRP en la dirección para coincidir con el requisito de reserva. No puedes enviar el XRP reservado a otros, pero puedes recuperar parte del XRP si [eliminas la cuenta](deleting-accounts.md).
+
+El requisito de reserva cambia de tanto en tanto debido al proceso de [Votación de fees](../consensus-protocol/fee-voting.md), donde los validadores pueden estar de acuerdo con nuevas configuraciones de reservas.
+
+## Reserva base y reserva de propietario
+
+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_.
+
+Los requerimientos de reserva actuales en Mainnet son:
+
+- Reserva base: **{% $env.PUBLIC_BASE_RESERVE %}**
+- Reserva de propietario: **{% $env.PUBLIC_OWNER_RESERVE %}** por artículo
+
+Reservas en otras redes pueden variar.
+
+## Reservas de propietario
+
+Muchos objetos en el ledger (entradas en el ledger) pertenecen a una cuenta en particular. Normalmente, el propietario es una cuenta que ha creado el objeto. Cada objeto aumenta el requisito de reserva total en la reserva de propietario. Cuando los objetos son eliminados del ledger, ya no cuentan para el requisito de reserva.
+
+Los objetos que cuentan para el requisito de de reserva de su propietario son: [Cheques](../payment-types/checks.md), [Preatutorizaciones para depositar](depositauth.md#preauthorization), [Escrows](../payment-types/escrow.md), [Ofertas NFT](../tokens/nfts/trading.md), [Páginas NFT](../tokens/nfts/index.md), [Ofertas](../../references/protocol/ledger-data/ledger-entry-types/offer.md), [Canales de pago](../payment-types/payment-channels.md), [Listas de firmantes](multi-signing.md), [Tickets](tickets.md), y [Trust Lines](../tokens/fungible-tokens/index.md).
+
+Algunos casos especiales:
+
+- Non-Fungible Tokens (NFTs) están agrupados en páginas que contienen hasta 32 NFTs en cada una, y la reserva de propietario aplica por página más que por NFT. Debido al mecanismo para dividir y combinar páginas, la cantidad de NFTs almacenados por página puede variar. Ver también: [Reserva para objetos NFTokenPage](../../references/protocol/ledger-data/ledger-entry-types/nftokenpage.md#nftokenpage-reserve).
+- Trust lines (entradas `RippleState`) son compartidas entre dos cuentas. La reserva del propietario puede aplicar a una o ambas. La mayoría de veces, el poseedor del token debe una reserva y el emisor no. Ver también: [RippleState: Contribuyendo a las reservas de propietario](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#contributing-to-the-owner-reserve).
+- Listas de firmantes creadas antes de la [enmienda MultiSignReserve][] activada en abril de 2019 cuentacon múltiples objetos. Ver también: [Listas de firmantes y reservas](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md#signer-lists-and-reserves).
+- Un [Directorio de propietario](../../references/protocol/ledger-data/ledger-entry-types/directorynode.md) es una entrada del ledger que lista todos los objetos relacionados a una cuenta, incluyendo toods los objetos que la cuenta posee. Sin embargo, el directorio del propietario en sí no cuenta para la reserva.
+
+### Buscando las reservas
+
+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`     |
+
+Para determinar las reservas de propietario de una cuenta, hay que multiplicar la reserva incremental por el número de objetos que la cuenta posee. Para mirar el número de objetos que una cuenta posee, llama al [método account_info][] y toma `account_data.OwnerCount`.
+
+Para calcular el requisito total de direcciones, multiplica `OwnerCount` por `reserve_inc_xrp`, y luego suma `reserve_base_xrp`. [Aquí tienes una demostración](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17) del cálculo en Python.
+
+
+## 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.
+
+Cuando tu cuenta posee menos XRP XRP que el requisito actual de reserva, no puedes enviar XRP a otros, o crear nuevos objetos que incremente el requisito de reserva de la cuenta. Aun así, la cuenta continua existiendo en el ledger y puedes enviar transacciones que no hagan esas cosas, siempre que tengas suficiente XRP para pagar el coste de transacción. Puedes volver a superar el requisito de reserva recibiendo suficiente XRP, o si el requisito de reserva decrece debajo de la cantidad que tiene.
+
+**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.
+
+## Ver también
+
+- [método account_objects][]
+- [Objeto AccountRoot][]
+- [Votación de Fee](../consensus-protocol/fee-voting.md)
+- [Pseudo-transacción SetFee][]
+- [Tutorial: Calcular y mostrar los requisitos de reserva (Python)](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#3-display-an-account)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/accounts/tickets.md

@@ -0,0 +1,73 @@
+---
+html: tickets.html
+parent: accounts.html
+seo:
+    description: Envía transacciones en un orden no secuencial.
+labels:
+  - Cuentas
+  - Enviar transacciones
+---
+# Tickets
+
+_(Añadido por la [enmienda TicketBatch][].)_
+
+Un Ticket en el XRP Ledger es una forma de reservar un [número secuencia][Sequence Number] para una transacción que no se envía de inmediato. Los tickets permiten que transacciones sean enviadas fuera del orden de secuencia normal. Un caso de uso de esto es permitir [transacciones multi-signed](multi-signing.md) donde tomará un tiempo recolectar las firmas necesarias: mientras se recogen las firmas para una transacción que utiliza un Ticket, puedes enviar otras transacciones.
+
+## Transfondo
+
+Las [transacciones](../transactions/index.md) tienen números de secuencia para que una transacción determinada no pueda ejecutarse más que una vez. Los números de secuencia también se aseguran de que la transacción dada sea única: si envías la misma cantidad de dinero a la misma persona varias veces, el número de secuencia es un detalle que se garantiza que será diferente cada vez. Finalmente, los números de secuencia brindan una una forma felegante de ordenar las transacciones de forma consistente, incluso si algunas de ellas llegan desordenadas cuando se envían desordenadas a través de la red.
+
+Sin embargo, hay situaciones donde los números de secuencia son demasiado limitantes. Por ejemplo:
+
+- Dos o más usuarios comparten acceso a una cuenta, cada una con la habilidad de enviar transacciones independientemente. Si esos usuarios intentan enviar transacciones al mismo tiempo sin coordinarse primero, cada uno de ellos puede utilizar el mismo número de secuencia para diferentes transacciones, y sólo uno lo conseguirá.
+- Puede que quieras preparar y firmar una transacción por adelantado, luego guardarla en algún sitio seguro para que se pueda ejecutar en algún momento del futuro si ciertos eventos ocurren. Sin embargo, si quieres continuar usando la cuenta de forma normal mientras tanto, no sabes que número de secuencia apartar para la transacción. <!-- STYLE_OVERRIDE: will -->
+- Cuando [múltiples personas deben firmar una transacción](multi-signing.md) para hacerla válida, puede ser dificil planificar más de una transacción a la vez. Si numeras las transacciones con números de secuencia separados, no puedes enviar transacciones numeradas más tarde hasta que todo el mundo haya firmado las transacciones anteriores; pero si usas el mismo número de secuencia para cada transacción pendiente, solo una de ellas podrá ocurrir.
+
+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")
+
+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.")
+
+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.
+
+**Atención:** Cada Ticket cuenta como un objeto separado para la [reserva de propietario](reserves.md), así que debes apartar {% $env.PUBLIC_OWNER_RESERVE %} por cada Ticket. (El XRP vuelve a estar disponible una vez que se haya utilizado el Ticket.) Este coste puede subir rápidamente si creas un grán número de Tickets a la vez.
+
+Como con los números de secuencia, enviar una transacción consume el Ticket _si y solo si_ la transacción es confirmada por [consenso](../consensus-protocol/index.md). Sin embargo, las transacciones que fallan en hacer lo que intentaban pueden ser confirmadas por el consenso con los [códigos de resultado de clase`tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).
+
+Para conocer qué Tickets tiene una cuenta disponibles, utiliza los [métodos account_objects][].
+
+## Limitaciones
+
+Cualquier cuenta puede crear y utilizar Tickets en cualquier tipo de transacciones. Sin embargo, puede haber algunas restricciones:
+
+- Cada Ticket puede ser utilizado solo una vez. Es posible tener múltiples transacciones diferentes candidatas que podrían usar el mismo Ticket Secuencia, pero solo uno de esos candidatos será validado por el consenso.
+- Una cuenta no puede tener más de 250 Tickets en el ledger a la vez. No puedes crear más de 250 Tickets a la vez, tampoco.
+- _Puedes_ usar un Ticket para crear más Tickets. Si lo haces, el Ticket utilizado no cuenta para el número total de Tickets que puedes tener a la vez.
+- Cada Ticket cuenta para la [reserva de propietario](reserves.md), por lo que debes apartar {% $env.PUBLIC_OWNER_RESERVE %} por cada Ticket que no has usado todavía. El XRP vuelve a estar disponible para ti despues de utilizar el Ticket.
+- Dentro de un ledger individual, las transacciones que usan Tickets se ejecutan después que otras transacciones desde el mismo remitente. Si una cuenta tiene múltiples transacciones utilizando Tickets en la misma versión del ledger, esos Tickets se ejecutan en orden desde el Ticket con la secuencia más baja hasta la más alta. (Para más información, ver la documentación del [orden canónico](../consensus-protocol/consensus-structure.md#calculate-and-share-validations) del consenso.)
+- Para "cancelar" un Ticket, usa el Ticket para [realizar una operación no operativa](../transactions/finality-of-results/canceling-a-transaction.md) [transacción AccountSet][]. Esto elimina el Ticket y tu no tienes que cumplir con los requisitos de reserva.
+
+## Ver también
+
+
+- **Conceptos:**
+    - [Multi-Signing](multi-signing.md)
+- **Tutoriales:**
+    - [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 ][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md

@@ -0,0 +1,131 @@
+---
+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.
+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).
+
+La tencología del XRP Ledger permite liquidaciones casi en tiempo real (de tres a seis segundos) y contiene un exchange descentralizado, donde los pagos automáticamente usan las ordenes de intercambio de divisas más baratas para conectar divisas.
+
+## Transfondo
+
+### Mecánicas
+
+Principalmente, el XRP Ledger es una base de datos compartida que registra información como cuentas, balances, y ofertas para comerciar con activos. Las instrucciones firmadas llamadas "transacciones" generan cambios como la creación de cuentas, generación de pagos, y comerciar activos.
+
+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.
+
+Supongamos que Alice, Bob, y Charlie están usando un sistema de pagos, y Alice tiene un balance de 10$. Para que el sistema de pagos sea útil, Alice debe ser capaz de enviar sus 10$ a Bob, o a Charlie. Sin embargo, si Alice intenta enviar 10$ a Bob y también envía 10$ a Charlie al mismo tiempo, ahí es donde el problema del doble gasto aparece.
+
+Si Alice puede enviar los "mismos" 10$ a ambos Charlie y Bob, el sistema de pagos dejará de ser útil. El sistema de pagos necesita una forma de elegir que transacción debería suceder y cual debería fallar, de una forma que todos los participantes estén de acuerdo en que transacción ha ocurrido. Cualquiera de esas transacciones son igual de válidas por si mismas. Sin embargo, los distintos participantes pueden tener una diferente visión de que transacción llegó antes en el sistema de pagos.
+
+Convencionalmente, los sistemas de pagos resuelven el problema del doble gasto teniendo una autoridad central que rastrea y aprueba transaciones. Por ejemplo, un banco decide compensar un cheque en función del saldo disponible del emisor, del cual el banco es el único custodio. En tal sistema, todos los participantes siguen las deicisiones de la autoridad central.
+
+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
+
+Gran parte del problema del doble gasto puede ser resuelto por unas reglas bien conocidas como prohibir a una cuenta que gaste fondos que no tiene. De hecho, el problema del doble gasto se puede reducir a poner transacciones en orden.
+
+Considerando el ejemplo de Alice intentando enviar los mismos 10$ a ambos Bob y Charlie. Si el pago se sabe que es el primero, entonces todo el mundo estará de acuerdo de que ella tiene los fondos para pagar a Bob. Si el pago a Charlie se sabe que es el segundo, entonces cualquiera estará de acuerdo de que ella no tiene esos fondos para Charlie porque el dinero ya ha sido enviado a Bob.
+
+También podemos ordenar transacciones por reglas deterministas. Porque las transacciones son colecciones de información digital, es trivial par aun ordenador ordenarlas.
+
+Esto sería suficiente para solventar el problema del doble gasto sin una autoridad central, pero requeriría tener cada transacción que ocurriese (para así poder ordenarlas) antes de poder estar seguros de los resultados de cualquier transacción. Obviamente, no es práctico. <!-- STYLE_OVERRIDE: obviously -->
+
+Si pudiesemos recopilar transacciones en grupos y acordar esas agrupaciones, podríamos ordenar las transacciones de ese grupo. Siempre que cada participante esté de acuerdo en qué transacciones se procesarán como una unidad, pueden usar reglas deterministas para resolver el problema del doble gasto sin necesidad de una autoridad central. Cada uno de los participantes clasifica las transacciones y las aplica de forma determinista siguiendo las reglas conocidas. El XRP Ledger resuelve el problema del doble gasto exáctamente de esta manera.
+
+El XRP Ledger permite que múltiples transacciones conflictivas estén en el grupo acordado. El grupo de transacciones es ejecutado de acuerdo a unas reglas deterministas, por lo que la transacción que ocurra primero según las reglas de clasificación tendrá éxito y la transacción conflictiva que ocurra en segundo lugar fallará.
+
+### Reglas de consenso
+
+La función principal del consenso es que los participantes en el proceso acuerden qué transacciones se procesarán como grupo para resolver el problema del doble gasto. Hay cuatro razones por las que este acuerdo es más fácil de conseguir de lo que cabría esperar:
+
+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.
+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.
+
+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.
+
+Para prevenir que el consenso se atasque cerca del 50% y para reducir el superposición requerida para una convergencia confiable, el umbral requerido para incluir una transacción incrementa con el tiempo. Inicialmente, los participantes continuan acordando incluir una transacción si el 50% o más del resto de participantes está de acuerdo. Si los participantes discrepan, ellos incrementan este umbral, primero a 60% y luego más mayor, hasta que todas las transacciones discutidas son eliminadas del conjunto actual. Cualquier transacción eliminada de este modo se apartan a la siguiente versión de un ledger.
+
+Cuando un participante ve a una sobremayoría que está de acuerdo en el conjunto de transacciones que van a ser procesadas, declara que un consenso ha sido alcanzado.
+
+### 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.
+
+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 -->
+
+En otras palabras, para que el proceso de consenso pueda finalizar, algún participante debe declarar que el consenso se ha alcanzado en un conjunto de transacciones incluso aunque cualquier otro participante teóricamente puede todavía ser capaz de cambiar el conjunto acordado de transacciones.
+
+Imagina un grupod e personas en una habitación intentando acordar qué puerta deberían utilizar para salir. No importa cuanto discutan los participantes, en algún momento, _alguien_ tiene que ser el primero en pasar por la puerta, incluso aunque las personas después de esta persona puede todavía cambiar su opinión y salir por otra puerta.
+
+La probabilidad de este tipo de fallo puede ser muy baja, pero no se puede reducir a cero. El balance de ingeniería es tal que llevar esta probabilidad por debajo por debajo de uno entre mil hacer el consenso significamente más lento, y menos tolerable a fallos de endpoint o de red.
+
+### Cómo maneja los fallos de consenso el XRP Ledger
+
+Después de que una ronda de consenso se complete, cada participante aplica el conjunto de transacciones que cree que se ha agregado. Esto resulta en la contrucción de lo que ellos creen que será el próximo estado del ledger que debería ser.
+
+Los participantes que también son validadores publican entonces una huella criptográfica para el siguiente ledger. Llamamos a esa huella un "voto de validación". Si la ronda de consenso ocurre, la gran mayoría de validadores honestos deberían publicar la misma huella.
+
+Después, los participantes recolectan estos votos de validación. Con los votos de validación, pueden determinar si la ronda de consenso anterior resultó en una supermayoría de participantes acordando el conjunto de datos o no.
+
+Luego, los participantes se encontrarán a si mismos en uno de estos tres casos, en orden de probabilidad:
+
+1. Contruyeron el mismo ledger que la mayoría ha acordado. En este caso, pueden considerar que ese ledger está validado y se puede confiar en su contenido.
+2. Construyeron un ledger diferente al acordado por la supermayoría. En este caso, deben construir y aceptar el ledger de la supermayoría. Esto suele indicar que han declarado conenso antes y otros participantes cambiaron después de eso. Deben "saltar" al ledger de la supermayoría para continuar la operación.
+3. Si la supermayoría no está clara de las validaciones recibidas. En este caso, la ronda de consenso previa se ha malgastado y una nueva ronda debe ocurrir antes de que ningún ledger sea validado.
+
+Por supuesto, el caso 1 es el más común. El caso 2 no daña a la red en absoluto. Un pequeño porcentaje de participantes podría caer en el caso 2 cada ronda, y la red podría funcionar sin problemas. Incluso esos participantes pueden reconocer que no han construido el mismo ledger que la supermayoría, por lo que saben que no reportarán sus resultados hasta el final cuando estén de acuerdo con la supermayoría.
+
+El caso 3 resulta en la red perdiendo unos segundos en los que podría haber avanzado, pero esto es extremadamente raro. En este caso, la siguiente ronda de consenso es mucho menos probable que falle porque los desacuerdos están resueltos en el proceso de consenso y solo los descauerdos restantes pueden provocar un fallo.
+
+En raras ocasiones, la red como conjunto falla para progresar hacia adelante por unos segundos. A cambio, los tiempos de confirmaciones de transacciones son bajos.
+
+## Filosofía
+
+Una forma de confiar es la habilidad del sistema de proveer resultados incluso en situaciones donde algunos componentes han fallado, algunos participante son maliciosos, y así. Mientras esto es importante, hay otra forma de confiar que es mucho más importante en los sistemas de pagos criptográficos - la habilidad de un sistema para producir resultados en los que se puede confiar. Eso ocurre, cuando un sistema nos reporta un resultado es confiable, debemo ser capaces de confiar en ese resultado.
+
+Los sistemas del mundo real, sin embargo, se enfrentan a condiciones operacionales en que ambos tipos de confiabilidad puede ser comprometida. Esto incluye fallos de hardware, fallos de comunicación, incluso participantes deshonestos. Parte de la filosofía del diseño del XRP Ledger es detectar condiciones donde la confianza de resultados está dañada y hay que reportarlos, en vez de facilitar resultados en los que no se debe confiar.
+
+El algoritmo de consenso del XRP Ledger provee una alternativa robusta a sistemas de prueba de trabajo (proof of work), sin consumir recursos computacionales innecesariamente. Los fallos bizantinos son posibles, y ocurren, pero la consecuencia son solo retrasos menores. En todos los casos, el algoritmo de consenso de XRP Ledger informa que los resultados son confiables solo cuando de hecho lo son.
+
+## 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)
+- **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)
+- **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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md

@@ -0,0 +1,72 @@
+---
+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.
+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.
+
+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.
+
+## Validadodes individuales con mal comportamiento
+
+Los _validadores_ son servidores que contribuyen activamente al proceso de decidir cada nueva versión del ledger. Los validadores tienen una influencia sobre servidores configurados para confiar en ellos (incluso indiréctamente). El consenso continua incluso si algunos validadores se comportan mal, incluyendo una larga variedad de casos de fallo, tales como:
+
+- No estar disponibles o sobrecargados.
+- Estar parcialmente desconectados de la red, por lo que sus mensajes solo alcanzan a un subgrupo de participantes sin retraso.
+- Comportarse intencionadamente para defraudar a otros o parar la red.
+- Comportarse maliciosamente como resultado de la presión de factores externos, como amenzadas de un gobierno opresivo.
+- Enviar accidentalmente mensajes confusos o malformados debido a un error o una software desactualizado.
+
+En general, el consenso puede continuar sin problemas mientras solo un pequeño porcentaje (menos del 20%) de los validadores confiables tengan mal comportamiento en un mismo momento. (Para las matemáticas que hay detrás y los porcentajes exactos, ver la última [Investigración del consenso](consensus-research.md).)
+
+Si más del 20% de los validadores son inalcanzables o no se comportan adecuadamente, la red falla al intentar consenso. Durante este tiempo, nuevas transacciones pueden ser tentativamente procesadas, pero las nuevas versiones del ledger no pueden ser validadas, así que los resultados finales de esas transacciones no son ciertos. En esta situación, se convierte en inmediatamente obvio que el XRP Ledger no se encuentra bien, lo que provocaría una intervención de participantes humanos que pueden decidir entre esperar, o reconfigurar el conjuntos de validadores confiables.
+
+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:
+
+- Un [código fuente open-source](https://github.com/XRPLF/rippled/), por lo que cualquier miembro del público puede revisar, compilar, e independientemente probar el software relevante.
+- Un proceso de revisión de código exhaustivo y sólido para todos los cambios de los repositorios oficiales del XRP Ledger.
+- Las firmas digitales de desarrolladores muy conocidos en todas las publicaciones y paquetes de software.
+- 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.)
+
+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.
+
+Por defecto, los servidores XRP Ledger están configurados para utilizar sitios de listas de validadores mantenidas por la XRPL Foundation y Ripple. Los sitios proveen una lista de validadores recomendados (también conocidos como la _Lista de Nodos Únicos_ recomendada, o UNL), la cual se actualiza periódicamente. Los servidores configurados de esta forma confian en todos los validadores de la última versión de la lista, lo cual asegura un 100% de superposición con otros que usan la misma lista. La configuración por defecto incluye claves públicas para verificar la autenticidad de los contenidos de esos sitios. Los servidores de la red peer-to-peer XRP Ledger también comparten las actualizaciones firmadas de la lista entre ellos, reduciendo potenciales puntos de fallo.
+
+Técnicamente, si ejecutas un servidor, puedes configurar tu propia lista o explicitamente elegir validadores en los que confiar de forma individual, pero esto no se recomienda. Si el conjunto de validadores que has elegido no tiene suficiente superposición con otros, tu servidor podría divergir del resto de la red, y podrías perder dinero por culpa del estado divergente de tu servidor.
+
+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).
+- Para una explicación del **diseño de decisiones y transfondo** detrás del protocolo de consenso, cer [Principios y reglas del consenso](consensus-principles-and-rules.md).
+- Para **investigaciones academicas** explorando las propiedades y limitaciones del protocolo, ver [Investigación del consenso](consensus-research.md).

@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md

@@ -0,0 +1,19 @@
+---
+html: consensus-research.html
+parent: consensus.html
+seo:
+    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. |
+
+<!-- SPELLING_IGNORE: bft, liveness -->

@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md

@@ -0,0 +1,215 @@
+---
+html: consensus-structure.html
+parent: consensus.html
+seo:
+    description: Entender el rol del consenso en el XRP Ledger.
+labels:
+  - Blockchain
+---
+# Estructura de consenso
+
+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:
+
+- Configuración de cada [cuenta](../accounts/index.md)
+- Balances de XRP y [tokens](../tokens/index.md)
+- Ofertas en el exchange distribuido
+- Configuraciones de red, como los [costes de transacción](../transactions/transaction-cost.md) y las cantidades de [reserva](../accounts/reserves.md)
+- Una marca de tiempo (timestamp)
+
+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")
+
+_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")
+
+_Figure 2: Histórico del XRP Ledger_
+
+Una versión de ledger tiene dos identificadores. Un identificador es su _ledger index_ o índice del ledger. Las versiones de ledger son numeradas incrementalmente. Por ejemplo, si la versión del ledger actual tiene un ledger index de 100, el previo tiene un ledger index 99 y el siguiente ledger tendrá index 101. El otro identificador es un _ledger hash_, el cual es una huella digital de los contenidos del ledger.
+
+A medida que los servidores proponen trnsacciones para aplicar en el ledger, pueden crear varias versiones del ledger con contenidos ligeramente diferentes. Estas versiones candidatas del ledger tienen el mismo ledger index pero diferentes ledger hashes. De los muchas candidatas, solo una puede ser validada. Todas las otras versiones ledger candidatas son descartadas. Por lo tanto, hay exactamente un ledger hash validado para cada ledger index en el histórico.
+
+Los cambios a nivel de usuario son el resultado de transacciones. Ejemplos de [transacciones](../../references/protocol/transactions/index.md) incluyen pagos, cambios de la configuración de cuenta o trust lines, y ofertas para intercambiar. Cada transacción autoriza uno o más cambios en el ledger, y está firmada criptográficmente por el dueño de la cuenta. Las transacciones son la única manera para autorizar cambios de una cuenta, o para cambiar algo más en el ledger.
+
+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")
+
+_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>
+
+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.
+
+Hay otras clases de códigos de resultado además de **`tes`** y **`tec`**. Cualquier otras clases de códigos de resultados indican fallos provisionales devueltos por las llamadas API. Solo los códigos **`tes`** y **`tec`** aparecen en los ledgers. Las transacciones que no aparecen incluidas en ledger no pueden tener efecto en el estado del ledger (incluyendo balances XRP), pero transacciones que son provisionalmente fallidas pueden acabar sucediendo.
+
+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.
+
+## 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")
+
+_Figura 4: Participantes en el Protocolo XRP Ledger_
+
+Los servidores que reciben, transmiten y procesan transacciones pueden ser servidores de seguimiento o validadores. Las funciones principales de los servidores de seguimiento incluyen distribución de transacciones de clientes y responder a consultas sobre el ledger. Los servidores de validación realizan las mismas funciones que los servidores de seguimiento y también contribuyen a avanzar en el histórico del ledger. <a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>.
+
+Cuando se aceptan transacciones enviadas por aplicaciones de cliente, cada servidor de seguimiento utiliza el último ledger validado como punto de inicio. Las transacciones aceptadas son candidatas. Los servidores envían sus transacciones candidatas a sus pares, permitiendo a las transacciones candidatas propagarse a través de la red. Idealmente, cada transacción candidata debería ser conocida por todos los servidores, permitiendo a cada uno considerar el mismo conjunto de transacciones a aplicar al último ledger validado. Sin embargo, como las transacciones tardan tiempo en propagarse, los servidores no trabajan con el mismo conjunto de transacciones candidatas todas las veces. Para tener en cuenta esto, el XRP Ledger utiliza un proceso llamado consenso para asegurar que las mismas transacciones son procesadas y los ledger validados son consistentes a través de la red peer-to-peer XRP Ledger.
+
+### Consenso
+
+Los servidores de la red comparten información sobre transacciones candidatas. A través del proceso de consenso, los validadores agregan en un subconjunto de transacciones candidatas para ser consideradas en el siguiente ledger. El consenso es un proceso iterativo en el cual los servidores transmiten propuestas, o conjuntos de transacciones candidatas. Los servidores comunican y actualizan las propuestas hasta que haya supermayoría <a href="#footnote_4" id="from_footnote_4"><sup>4</sup></a> de los validadores elegidos que acuerdan el mismo conjuntos de 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")
+
+_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._
+
+Las transacciones candidatas que no están incluidas en la propuesta acordada siguen siendo transacciones candidatas. Pueden ser consideradas otra vez en la nueva versión del ledger. Normalmente, una transacción que ha sido omitida en una versión del ledger se incluye en la siguiente versión del ledger.
+
+En algunas circunstancias, una transacción puede fallar para conseguir alcanzar consenso indefinidamente. Una de esas circunstancias es si la red incrementa el [coste de transacción](../transactions/transaction-cost.md) requerido a un valor superior al que proporciona la transacción. La transacción podría ser exitosa si las comisiones se reducen en algún momento futuro. Para asegurar que una transacción tenga éxito o falle dentro de una limitada cantidad de tiempo, las transacciones se pueden preparar para caducar si no son procesadas por un determinado ledger index. Para más información, ver [Envío de transacciones confiables](../transactions/reliable-transaction-submission.md).
+
+### Validación
+
+La validación es la segunda etapa del proceso de consenso general, que verifica que los servidores tienen los mismos resultados y declara la versión final del ledger. En raras ocasiones, la primera etapa del [consenso puede fallar](consensus-principles-and-rules.md#consensus-can-fail); la validación proporciona una confirmación posterior para que los servidores puedan reconocer esto y actuar en consecuencia.
+
+La validación puede dividirse en aproximadamente dos partes:
+
+- Calcular la versión de ledger resultante del conjunto de transacciones acordado.
+- Comparar resultados y declarar validada la versión del ledger si suficientes validadores confiables están de acuerdo.
+
+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:
+
+1. Empezar con el ledger validado anterior.
+
+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.
+
+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>
+
+    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.
+
+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")
+
+_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._
+
+#### Comparar resultados
+
+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")
+
+_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._
+
+Los servidores de la red reconocen una instancia ledger como validada cuando una supermayoría de pares han firmado y difundido el mismo hash de validación <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>. Más adelante, las transacciones son aplicadas a este ahora ledger validado y actualizado con el ledger index N+1.
+
+En casos donde el servidor se encuentra en una minoría, habiendo generado un ledger que difiere de sus pares, el servidor ignora el ledger que ha generado <a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>. Regenera el ledger correcto, o recupera el ledger correcto según sea necesario.
+
+Si la red no logra un acuerdo de supermayoría sobre las validaciones, esto implica que el volumen de transacciones era muy alto o la latencia de la red es demasiado grande para que el proceso de consenso para producir propuestas consistentes. En este caso, los servidores repiten el proceso de consenso con una nueva versión del ledger. A medida que pasa el tiempo desde el consenso comenzó, es cada vez más probable que la mayoría de los servidores haya recibido el mismo conjunto de transacciones candidatas, ya que cada ronda de consenso reduce el desacuerdo. El XRP Ledger ajusta dinámicamente los [costes de transacciones](../transactions/transaction-cost.md) y el tiempo de espera para el consenso en respuesta a estas condiciones.
+
+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.
+
+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.
+- 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 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.
+
+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.
+
+## 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)
+- **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)
+- **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][]
+
+
+
+
+
+## Pies de notas
+
+<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – Transacciones con [códigos de resultado **tec**](../../references/protocol/transactions/transaction-results/tec-codes.md) no proporcionan la acción solicitada, pero tienen efecto en el ledger. Para prevenir el abuso de la red y pagar por el coste de distribución de la transacción, destruyen el XRP del [coste de la transacción](../transactions/transaction-cost.md). Para no bloquear otras transacciones enviadas por el mismo remitente al mismo tiempo, se incrementa el [sequence number](../../references/protocol/data-types/basic-data-types.md#account-sequence) de la cuenta emisora. Transacciones con el tipo resultado `tec` a veces también realizan mantenimiento como borrar objetos caducados u ofertas de mercado sin fondos.
+
+<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – Por ejemplo, consideramos un escenario donde Alice tiene 100$, y envía todo a Bob. Si una aplicación primero envía esa transacción de pago, entonces inmediatamente tras comprobar el balance de Alice, la API devuelve 0$. Este valor está basado en el resultado provisional de una transacción candidata. Hay circunstancias en las cuales el pago falla y el balance de Alice se mantiene a 100$ (o, debido a otras transacciones, se convierte en otra cantidad). El único método para conocer con certeza que el pago de Alice a Bob ha ocurrido es comprobar el estado de la tranacción hasta que está en el ledger validado y además el código de resultado es **`tesSUCCESS`**. Si la transacción está en un ledger validado con cualquier otro código resultado, el pago ha fallado.
+
+<a href="#from_footnote_3" id="footnote_3"><sup>3</sup></a> – Hablando estríctamente, los validadores son un subconjunto de servidores de seguimiento. Proporcionan las mismas características y adicionalmente envían mensajes de "validación". Los servidores de seguimiento pueden clasificarse según si mantienen el histórico del ledger parcial o completo.
+
+<a href="#from_footnote_4" id="footnote_4"><sup>4</sup></a> – Transacciones que fallan en pasar la ronda de consenso cuando el porcentaje de pares que reconoce la transacción cae por debajo del umbral. Cada ronda es un proceso iterativo. Al principio de la primera ronda, al menos el 50% de pares deben estar de acuerdo. El umbral final para la ronda de consenso es un 80% de acuerdo. Estos valores específicos estan sujetos a cambio.
+
+<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_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 href="#from_footnote_8" id="footnote_8"><sup>8</sup></a> – En la práctica, el servidor detecta que está en una minoría antes de recibir las validaciones de todos los pares. Lo sabe cuando recibe validaciones no coincidentes de más del 20% de pares que su validación no puede alcanzar el 80% del umbral. En ese momento, puede empezar a recalcular su ledger.
+
+<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – En la práctica, el XRP Ledger corre más eficientemente empezando una nueva ronda de consenso al mismo timepo, antes de que la validación se haya completado.
+
+<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – Un servidor `rippled` puede responder a las peticiones API incluso sin tener un histórico del ledger completo. Interrupciones en el servicio o en la conectividad de la red puede llevar a ledgers perdidos, o a lagunas, en el histórico del ledger del servidor. Con el tiempo, si se configura así, `rippled` llena los vacíos en su histórico. Cuando prueba transacciones perdidas, es importante verificar contra un servidor con ledgers completos continuos desde que la transacción que se ha enviado hasta su `LastLedgerSequence`. Utiliza el [método server_info][] para determinar qué ledgers están disponibles para un servidor en partícular.
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md

@@ -0,0 +1,69 @@
+---
+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).
+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.
+
+Los operadores de [validadores `rippled`](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md) pueden configurar sus preferencias para el coste de transacción y los requisitos de reserva en el apartado de `[voting]` del fichero `rippled.cfg`.
+
+**Atención:** Los requisitos insuficientes, en caso de ser adoptados por un consenso de validadores confiables, podrían exponer a la red peer-to-peer XRP Ledger a ataques de denegación de servicio.
+
+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 %}) |
+
+<!-- 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.
+
+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.
+
+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.
+
+## 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 |
+
+
+## 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)
+- **Tutoriales:**
+    - [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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/consensus-protocol/index.md

@@ -0,0 +1,72 @@
+---
+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.
+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:
+
+- Todos los que utilizan el XRP Ledger pueden ponerse de acuerdo en el último estado, y qué operaciones se han producido y en qué orden.
+- Todas las transacciones válidas son procesadas sin necesidad de un operador central o sin tener un único punto de fallo.
+- El ledger puede progresar incluso si algunos participantes se incorporan, se marchan o tienen un comportamiento inapropiado.
+- Si demasiados participantes son incontactables o se comportan inadecuadamente, la red fallará a la hora de progresar en vez de divergir o confirmar transacciones inválidas.
+- Confirmar transacciones no requiere un uso de recursos competitivos o malgastados, como en muchos otros sistemas blockchains.
+
+Estas propiedades se resumen a veces en los siguientes principios, en orden de prioridad: **Correción, Acuerdo, Progreso**.
+
+Este protocolo sigue evolucionando, al igual que nuestro conocimiento de sus límites y posibles casos de fallo. Para investigaciones academicas del protocolo en sí, ver [Investigación del consenso](consensus-research.md).
+
+## Trasfondo
+
+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:
+
+- El estado actual de todos los balances y objetos guardados en el 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")
+
+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")
+
+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
+
+1. <a id="footnote-1"></a> Debido a un percance ocurrido al inicio de la historia de XRP Ledger, [se perdieron los ledgers del 1 al 32569](http://web.archive.org/web/20171211225452/https://forum.ripple.com/viewtopic.php?f=2&t=3613). (Esta pérdida representa aproximadamente la primera semana de la historia del ledger.) Por lo tanto, el ledger #32570 es el ledger más antiguo disponible. Porque el estado del XRP Ledger se guarda en cada versión de cada ledger, el ledger puede continuar sin la historia perdida. Las nuevas redes de prueba seguirán empezando con el índice del ledger 1.
+
+2. <a id="footnote-2"></a> En Bitcoin, el estado actual a veces se llama conjunto de "UTXOs" (salidas de transacción no gastadas). A diferencia que el XRP Ledger, un servidor Bitcoin debe descargar el histórico completo de transacciones para conocer el conjunto completo de UTXOs y procesar nuevas transacciones. Desde 2018, ha habido varias propuestas para modificar el mecanismo de consenso de Bitcoin para periódicamente resumir las últimas UTXOs para que los nuevos servidores no necesiten hacerlo. Ethereum utiliza un enfoque similar al del XRP Ledger, con un resumen del estado actual (conocido como _state root_) en cada bloque, pero la sincronización tarda más en Ethereum porque almacena más información en su estado de datos. <!-- SPELLING_IGNORE: utxos -->
+
+3. <a id="footnote-3"></a> Un servidor no necesita una conexión directa con sus validadores de confianza para escucharlos. La red peer-to-peer del XRP Ledger utiliza un _protocolo de cotilleo_ donde los servidores se identifican entre ellos con una clave pública y transmiten mensajes firmados digitalmente por otros.

@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md

@@ -0,0 +1,172 @@
+---
+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.
+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.
+
+Como muchas características de seguridad, todos esperamos que la comprobación de invariantes nunca necesite hacer nada. Sin embargo, puede ser útil entender las invariantes del XRP Ledger porque definen los límites estrictos del procesamiento de transacciones en el XRP Ledger, y reconocer el problema en el improbable caso que una transacción falle porque ha violado una comprobación de invariantes.
+
+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.
+- El coste de la ejecutar incorrectamente una transacción es alto y no es aceptable bajo ningún estándar.
+
+Específicamente, la ejecución de transacciones incorrectas podría crear datos inválidos o corruptos que luego hagan que servidores en la red fallen consistentemente en un estado "imposible" que pudiese detener toda la red.
+
+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:
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "Fuente")
+
+- [Comprobación de coste de transacción](#comprobación-de-coste-de-transacción)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "Fuente")
+
+- [XRP no creado](#xrp-no-creado)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "Fuente")
+
+- [Account Roots no eliminadas](#account-roots-no-eliminadas)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "Fuente")
+
+- [Comprobaciones de balance XRP](#comprobaciones-de-balance-XRP)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "Fuente")
+
+- [Coincidencia de tipos de entradas ledger](#coincidencia-de-tipos-de-entradas-de-ledger)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "Fuente")
+
+- [No XRP Trust Lines](#no-xrp-trust-lines)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "Fuente")
+
+- [No malas ofertas](#no-malas-ofertas)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "Fuente")
+
+- [No escrow cero](#no-escrow-cero)
+
+[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "Fuente")
+
+- [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.
+
+
+### 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).
+
+
+### 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.
+
+
+### 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.
+
+
+### 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).
+
+
+### 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.
+
+
+### 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.
+
+
+### 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.
+
+
+### 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).
+
+### 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.
+
+### 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.
+
+## Ver también
+
+- **Blog:**
+    - [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)
+
+
+- **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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md

@@ -0,0 +1,178 @@
+---
+html: negative-unl.html
+parent: consensus.html
+seo:
+    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)._
+
+La _UNL negativa_ es una característica del [protocolo de consenso](index.md) del XRP Ledger que mejora la _viveza_, la habilidad de la red a seguir progresando hacia adelante durante una interrupción parcial. Utilizando la UNL negativa, los servidores ajustan sus UNLs efectivas en función de los validadores que están actualmente en línea y operativos, de modo que una nueva [versión ledger](../ledgers/index.md) puede ser declarada _validada_ incluso si varios validadores confiables están offline.
+
+La UNL negativa no tiene impacto en cómo la red procesa los resultados de las transacciones o en los resultados de las transacciones, excepto que mejora la habilidad de la red para declarar resultados finales durante algunos tipos de interrupciones parciales.
+
+## Transfondo
+
+Cada servidor en el protocolo XRP Ledger tiene su propia UNL (Lista de Nodos Únicos), una lista de validadores en los que se confía para no colisionar, y cada servidor decide independientemente cuándo se valida una versión del ledger basándose en el consenso cuando suficientes de sus validadores confiables están de acuerdo en una nueva versión del ledger. (La configuración predeterminada utiliza una UNL recomendada, firmada por Ripple, que consiste en validadores que Ripple considera suficientemente únicos, confiables e independientes). El requisito del cuórum estándar es que al menos el 80% de los validadores confiables deben estar de acuerdo.
+
+Si más del 20% de los validadores confiables se desconectan o no pueden comunicarse con el resto de la red, la red deja de validar nuevos ledgers porque no puede alcanzar un cuórum. Esta es una elección de diseño para garantizar que los resultados de las transacciones no puedan cambiarse después de que se declaren definitivos. Durante dicha situación, los servidores restantes seguirían en línea y podrían proporcionar datos de transacciones pasadas y tentativas, pero no podrían confirmar el resultado final, inmutable, de nuevas transacciones.
+
+Sin embargo, esto significa que la red podría dejar de avanzar si algunos validadores ampliamente confiables se desconectaran. A partir del 6 de octubre de 2020, hay 34 validadores en la UNL recomendada de Ripple, por lo que la red dejaría de avanzar si 7 o más de ellos estuvieran desconectados. Además, si uno o dos validadores están desconectados por un período prolongado, la red tiene menos margen para el desacuerdo entre los validadores restantes, lo que puede hacer que tarde más en alcanzar un consenso.
+
+## Resumen
+
+No es razonable esperar que un conjunto diverso de validadores mantenga un tiempo de actividad del 100%: muchas cosas pueden hacer que un validador se vuelva temporalmente indisponible, como: mantenimiento de hardware, actualizaciones de software, problemas de conectividad a Internet, ataques dirigidos, errores humanos, fallos de hardware y circunstancias externas como desastres naturales.
+
+La "UNL negativa" es una **lista de validadores de confianza que se cree que están desconectados o con mal funcionamiento**, según lo declarado por un consenso de los validadores restantes. Los validadores en la UNL negativa son ignorados para determinar si una nueva versión del ledger ha alcanzado un consenso.
+
+Cuando un validador que está en la UNL negativa vuelve a estar en línea y envía votos de validación consistentes, los validadores restantes lo eliminan de la UNL negativa después de un tiempo corto.
+
+En casos donde los validadores se desconecten uno o dos a la vez, los validadores restantes pueden usar la UNL negativa para ajustar gradualmente sus UNL efectivas, de modo que la red solo necesite el 80% de los validadores _en línea_ para alcanzar un cuórum. Para evitar que la red se fragmente, el cuórum tiene un mínimo estricto del 60% de los validadores _totales_.
+
+Si más del 20% de los validadores de repente se desconectan todos a la vez, los servidores restantes no pueden alcanzar el quórum necesario para validar un nuevo ledger, por lo que no se podrían validar nuevos ledgers. Sin embargo, esos servidores aún pueden avanzar tentativamente a través de rondas de consenso sucesivas. Con el tiempo, los validadores restantes continuarían aplicando cambios a la UNL negativa a los ledgers tentativos y ajustarían sus UNL efectivas; eventualmente, si la situación persiste, la red podría reanudar la validación completa de ledgers utilizando la UNL negativa ajustado de las versiones de ledgers tentativas.
+
+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:
+
+> Fiabilidad = V<sub>a</sub> ÷ 256
+
+V<sub>a</sub> es el número total de votos de validación recibidos de un validador en los últimos 256 ledgers que coincidieron con la vista de consenso del servidor.
+
+Esta métrica de fiabilidad mide la disponibilidad de un validador _y_ el comportamiento de ese validador. Un validador debería tener una puntuación de fiabilidad alta si está sincronizado con el resto de la red y sigue las mismas reglas de protocolo que el servidor que lo califica. La puntuación de fiabilidad de un validador puede verse afectada por cualquiera de las siguientes razones:
+
+- Los votos de validación del validador no están llegando al servidor debido a una mala conectividad de red entre ellos.
+- El validador deja de funcionar o se sobrecarga.
+- El validador no sigue las mismas reglas de protocolo que el servidor, por diversas razones. Las posibilidades incluyen una mala configuración, errores de software, seguir intencionalmente una [red distinta](../networks-and-servers/parallel-networks.md), o un comportamiento malicioso.
+
+Si la fiabilidad de un validador es **inferior al 50%**, es candidato para ser agregado al Negative UNL. Para ser eliminado de la UNL negativa, la fiabilidad de un validador debe ser **superior al 80%**.
+
+Cada servidor, incluidos los validadores, calcula de forma independiente las puntuaciones de fiabilidad para todos sus validadores confiables. Diferentes servidores pueden llegar a diferentes conclusiones sobre la fiabilidad de un validador, ya sea porque los votos de ese validador llegaron a un servidor y no al otro, o porque desacordaban sobre ledgers específicos con más o menos frecuencia. Para añadir o eliminar un validador en la UNL negativa, se debe lograr un consenso de los validadores confiables sobre si un validador en particular está por encima o por debajo del umbral de fiabilidad.
+
+**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).
+
+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/pseudo-transaction-types.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).
+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/pseudo-transaction-types.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.
+
+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.
+
+Este mecanismo tiene varias propiedades útiles:
+
+- Utiliza información que está fácilmente disponible para todos los servidores y se puede calcular rápidamente.
+- 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.
+
+**Nota:** La UNL negativa ajusta el número _total_ de validadores de confianza a partir del cual se calcula el cuórum, no el cuórum directamente. El cuórum es un porcentaje pero el número de votos es un número entero, por lo que reducir el total de validadores de confianza no siempre cambia el número de votos requeridos para alcanzar un cuórum. Por ejemplo, si hay 15 validadores en total, el 80% es exactamente 12 validadores. Si reduces el total a 14 validadores, el 80% es 11.2 validadores, lo que significa que aún se requieren 12 validadores para alcanzar un cuórum.
+
+La UNL negativa no tiene impacto en otras partes del proceso de consenso, como la elección de qué transacciones incluir en el conjunto de transacciones propuestas. Esos pasos siempre se basan en la UNL configurada, y los umbrales se basan en cuántos validadores de confianza están participando activamente en la ronda de consenso. Incluso un validador que esté en la UNL negativa puede participar en el proceso de consenso.
+
+### Ejemplo
+
+El siguiente ejemplo demuestra cómo afecta la UNL negativa al proceso de consenso:
+
+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.")
+
+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.")
+
+
+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.")
+
+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.")
+
+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.")
+
+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.")
+
+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.")
+
+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.")
+
+
+## Ver también
+
+- **Conceptos:**
+    - [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)
+- **Referencias:**
+    - [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" /%}

@l10n/es-ES/docs/concepts/ledgers/index.md

@@ -0,0 +1,35 @@
+---
+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.
+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.")
+
+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.
+
+En cualquier momento, cada servidor XRP Ledger tiene un ledger _abierto_ en progreso, un número de ledgers _cerrados_ pendientes, y un histórico de ledgers _validados_ que son inmutables.
+
+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.
+
+
+
+## Ver también
+
+- Para más información sobre las cabeceras de ledger, IDs de objetos del ledger, y tipos de objetos del ledger, ver [Formatos de datos del ledger](../../references/protocol/ledger-data/index.md)
+- Para información de cómo los servidores rastrean el historial de cambios del estado del ledger, ver [Historia del ledger](../networks-and-servers/ledger-history.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md

@@ -0,0 +1,41 @@
+---
+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.
+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 -->
+
+Dado que las nuevas versiones de ledgers se suelen cerrar cada 3 a 5 segundos, estas reglas resultan en un patrón laxo donde el tiempo de cierre de los ledgers termina en :00, :01, :02, :10, :11, :20, :21, y demás. Los tiempos terminados en 2 son menos comunes y los tiempos terminados en 3 son muy raros, pero ambos pueden ocurrir aleatoriamente cuando más ledgers aleatoriamente cierran en ventanas de 10 segundos.
+
+Generalmente hablando, el ledger no puede realizar medidas basadas en el tiempo que la resolución del tiempo de cierre. Por ejemplo, para comprobar si un objeto ha pasado su fecha de caducidad, se utiliza la regla para compararlo con el tiempo de cierre del ledger padre. (El tiempo de cierre de un ledger no es conocido todavía cuando está ejecutando transacciones para introducir en ese ledger.) Esto quiere decir que, por ejemplo, un [Escrow](../payment-types/escrow.md) podría finalizar satisfactoriamente en un momento de la vida real que es 10 segundos después de la caducidad basada en el tiempo especificado en el objeto del Escrow.
+
+### Ejemplo
+
+Los siguientes ejemplos muestran el comportamiento de redondeo en los tiempos de cierre del ledger, desde la perspectiva de un validador por ejemplo, siguiendo un ledger con el tiempo de cierre **12:00:00**:
+
+**Ronda actual de consenso**
+
+1. Un validador observa que eran las **12:00:03** cuando el ledger cierra y entra en consenso. El validador incluye este tiempo de cierre en sus propuestas.
+2. El validador observa que la mayoría de otros validadores (en su UNL) propusieron un tiempo de cierre de 12:00:02, y otro ha propuesto un tiempo de cierre de 12:00:03. Esto cambia su tiempo de cierre propuesto para que coincida con el del consenso de **12:00:02**.
+3. El validador redondea su valor al intervalo de tiempo de cierre más cercano, resultando en **12:00:00**.
+4. Como 12:00:00 no es mayor que el tiempo de cierre del ledger anterior, el validador ajusta el tiempo de cierre para ser exactamente 1 segundo después del tiempo de cierre del anterior ledger. El resultado es un tiempo de cierre ajustado a **12:00:01**.
+5. El validador construye el ledger con estos detalles, calcula el hash resultante, y confirma en el paso de validación lo que otros hicieron del mismo modo.
+
+Los servidores que no validan hacen todos los mismos pasos, exceptuando que no proponen sus tiempos de cierre registrados al resto de la red.
+
+**Siguiente ronda de consenso**
+
+1. El siguiente ledger entra en consenso a las **12:00:04** de acuerdo con la mayoría de los validadores.
+2. Esto vuelve a redondear hacia abajo otra vez, a un tiempo de cierre de **12:00:00**.
+3. Como no es mayor al anterior tiempo de cierre del ledger anterior de las 12:00:01, el tiempo de cierre ajustado es **12:00:02**.
+
+**La siguiente ronda después de esa**
+
+1. El siguiente ledger entra en consenso a las **12:00:05** de acuerdo con la mayoría de validadores.
+2. Esto se redondea hacia arriba, según la resolución de tiempo de cierre, a las **12:00:10**.
+3. Como el valor es mayor que el tiempo de cierre del ledger anterior, no necesita ser ajustado. **12:00:10** se convierte en la hora de cierre oficial.

@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md

@@ -0,0 +1,70 @@
+---
+html: ledger-structure.html
+parent: ledgers.html
+seo:
+    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.
+
+El protocolo de consenso toma la última versión del ledger como punto de partida, forma un acuerdo entre los validadores sobre un conjunto de transacciones para aplicar a continuación, después confirma que todo el mundo obtuvo los mismos resultados aplicando esas transacciones. Cuando esto ocurre satisfactoriamente, el resultado es una nueva versión de un ledger _validado_. Desde aquí, el proceso se repite para construir la próxima versión del ledger.
+
+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.")
+
+
+## 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.")
+
+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.
+
+Los datos de estado consisten en objetos individuales llamados _entradas de ledger_, almacenados en un formato de árbol. Cada entrada del ledger tiene un ID único 256-bit que puedes usar para buscar en el árbol de estado.
+
+## 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.")
+
+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.
+
+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.
+
+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í.")
+
+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.
+
+Ledgers de diferentes cadenas pueden tener el mismo índice ledger pero distintos hashes. Además, al tratar con versiones del ledger no validadas, puede haber múltiples ledgers candidatos con el mismo índice pero contenidos diferentes y, por lo tanto, hashes diferentes.
+
+Dos ledgers con el mismo hash ledger son siempre completamente idénticos.

@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md

@@ -0,0 +1,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.
+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 |
+
+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.

@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md

@@ -0,0 +1,88 @@
+---
+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.
+labels:
+  - Blockchain
+---
+# Enmiendas
+
+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.
+
+**Nota:** Las correcciones de errores que cambian los procesos de transacción también requieren enmiendas.
+
+<!-- TODO: Move this to an amendment tutorial.
+Every amendment has a unique identifying hex value and a short name. The short name is for readability only; servers can use different names to describe the same amendement ID, and the names aren't guaranteed to be unique. The amendment ID should be the SHA-512Half hash of the amendment's short name.
+-->
+
+## Proceso de enmienda
+
+El apartado [Código de contribución al XRP Ledger](/resources/contribute-code/index.md) describe el flujo de trabajo para desarrollar una enmienda desde una idea hasta su activación en el XRP Ledger.
+
+Después de que el código para una enmienda se incluye en una versión de software o software release, el proceso para habilitarlo ocurre dentro de la red del XRP Ledger, que verifica el estado de las enmiendas en cada _flag_ ledger (generalmente cada 15 minutos).
+
+Cada 256º ledger se llama **flag** ledger. El flag ledger no tiene contenidos especiales, pero el proceso de enmienda ocurre alrededor suyo.
+
+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.
+
+    **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.
+
+**Nota:** El voto por defecto cambia entre las publicaciones del software. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Actualizado en: rippled 1.8.1{% /badge %}
+
+Las enmiendas deben mantener dos semanas el apoyo de más del 80% de los validadores confiables para activarse. Si el apoyo baja por debajo del 80%, la enmienda es temporalmente rechazada , y el periodo de dos semanas se reinicia. Las enmiendas pueden ganar y perder una mayoría cualquier cantidad de veces antes de que se habiliten permanentemente.
+
+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.
+
+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.
+
+Puedes debloquear servidores bloqueados por enmienda actualizando a la última versión de `rippled`.
+
+### Servidores Clio bloqueados por enmienda
+
+Los servidores Clio pueden bloquearse por enmienda si se encuentran un tipo de campo desconocido mientras cargan los datos del ledger. Esto ocurre si el campo es más nuevo que la dependencia de `libxrpl` usada cuando se construye Clio. Para desbloquear tu servidor Clio, actualiza a la última release de Clio que se publicó con un `libxrpl` compatible.
+
+## Retiro de enmiendas
+
+Cuando las enmiendas son activadas, el código fuente de comportamientos previos a la enmienda permanece en `rippled`. Mientras hay casos de uso para mantener el código antiguo, como la reconstrucción de resultados de los ledgers para verificación, el seguimiento de enmiendas y código heredado agrega complejidad con el tiempo.
+
+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)
+- **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)
+- **Referencias:**
+    - [Enmiendas conocidas](/resources/known-amendments.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md

@@ -0,0 +1,29 @@
+---
+html: clustering.html
+parent: networks-and-servers.html
+seo:
+    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:
+
+- Los servidores `rippled` clusterizados comparten el trabajo critográfico. Si un servidor ha verificado la autenticidad del mensaje, los otros servidores en el cluster confian en él y no lo vuelven a verificar.
+- Los servidores clusterizados comparten información sobre pares y clientes API que están comportandose mal o abusando de la red. Esto dificulta atacar todos los servidores del cluster a la vez.
+- Los servidores clusterizados siempre propagan las transacciones a través del cluster, incluso si la transacción no cumple con el coste de transacción actual basada en la carga en alguno de ellos.
+
+Si estás ejecutando un validador como un [par privado](peer-protocol.md#pares-privados), Ripple recomienda utilizar un cluster de servidores `rippled` como servidores proxy.
+
+## 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)
+- **Referencias:**
+    - [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" /%}

@l10n/es-ES/docs/concepts/networks-and-servers/index.md

@@ -0,0 +1,41 @@
+---
+html: networks-and-servers.html
+parent: concepts.html
+seo:
+    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:
+
+- El servidor principal, `rippled`, ejecuta la red peer-to-peer la cual procesa transacciones y alcanza un consenso en sus resultados.
+- El servidor API, [Clio](the-clio-server.md), proporciona potentes interfaces para obtener o consultar datos desde el ledger.
+
+Cualquiera puede ejecutar instancias de uno o ambos de estos tipos de servidores basado en sus necesidades.
+
+## 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.
+
+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.
+
+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.
+
+Finalmente, si ejecutas un servidor de validación, puedes utilizar un servidor común como proxy a la red pública mientras mantienes tu servidor de vaalidación en una red privada la cual es solo accesible desde el mundo exterior desde tu servidor común. Esto hace más difícil comprometer la integridad de tu servidor de validación.
+
+## Características y temas del servidor
+
+<!-- provided by the auto-generated table of children -->
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
+
+
+{% child-pages /%}

@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md

@@ -0,0 +1,88 @@
+---
+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.
+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.
+
+Los servidores en la red peer-to-peer XRP Ledger comparten transacciones y otros datos entre sí como parte del proceso de consenso. Cada servidor construye de forma independiente una nueva versión del ledger y compara los resultados con sus validadores de confianza para asegurar la consistencia. (Si un consenso de validadores de confianza no está de acuerdo con los resultados de un servidor, ese servidor recupera los datos necesarios de sus pares para lograr consistencia.) Los servidores pueden descargar datos más antiguos de sus pares para completar huecos en su historial disponible. La estructura del ledger utiliza [hashes](../../references/protocol/data-types/basic-data-types.md#hashes) criptográficos de los datos para que cualquier servidor pueda verificar la integridad y consistencia de los datos.
+
+## Bases de datos
+
+Los servidores mantienen datos del estado del ledger y transacciones en un almacén de clave-valor llamada almacén del ledger o _ledger store_. Además, `rippled` mantiene algunos archivos de base de datos SQLite para un acceso más flexible a cosas como el historial de transacciones y para rastrear ciertos cambios de configuración.
+
+Normalmente, es seguro eliminar todos los archivos de base de datos de un servidor `rippled` cuando ese servidor no está en funcionamiento. (Es posible que quieras hacer esto, por ejemplo, si cambias la configuración de almacenamiento del servidor o si estás cambiando de una red de prueba a la red de producción).
+
+## Historial disponible
+
+Por diseño, todos los datos y transacciones en el XRP Ledger son públicos y cualquiera puede buscar o consultar cualquier cosa. Sin embargo, tu servidor solo puede buscar datos que tenga disponibles localmente. Si intentas buscar una versión del ledger o una transacción que tu servidor no tenga disponible, tu servidor responderá que no puede encontrar esos datos. Otros servidores que tengan el historial necesario pueden responder con éxito a la misma consulta. Si tienes un negocio que utiliza datos del XRP Ledger, debes tener cuidado de cuánto historial tiene disponible tu servidor.
+
+El [método server_info][] reporta cuántas versiones del ledger tiene disponibles en el campo `complete_ledgers`.
+
+## Recuperar el histórico
+
+Cuando un servidor del XRP Ledger se inicia, su primera prioridad es obtener una copia completa del último ledger validado. A partir de ahí, se mantiene al día con los avances en el progreso del ledger. El servidor completa cualquier agujero en su historial del ledger que ocurra después de sincronizar y puede rellenar el historial desde antes de que se sincronizara. (Los huecos en el historial del ledger pueden ocurrir si un servidor temporalmente se vuelve demasiado ocupado para mantenerse al día con la red, pierde su conexión de red u experimenta otros problemas temporales).Cuando descarga el historial del ledger, el servidor solicita los datos faltantes a sus [servidores pares](peer-protocol.md), y verifica la integridad de los datos utilizando [hashes][Hash] criptográficos.
+
+Rellenar el histórico es uno de las prioridades más bajas del servidor, por lo que puede llevar mucho tiempo completar el historíal faltante, especialmente si el servidor está ocupado o si las especificaciones del hardware y la red no son lo suficientemente buenas. Para recomendaciones en especificaciones de hardware, ver [Planificación de capacidad](../../infrastructure/installation/capacity-planning.md). Completar el histórico también requiere que al menos uno de los pares directos del servidor tenga el histórico en cuestión. Para más información de cómo administrar las conexiones peer-to-peer de tu servidor, consulta [Configurar Peering](../../infrastructure/configuration/peering/index.md).
+
+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**.
+
+La XRP Ledger Foundation proporciona acceso a un cojunto de servidores full history operados por miembros de la comunidad (ver [xrplcluster.com](https://xrplcluster.com) para más detalles).
+Ripple también proporciona un conjunto de servidores full-history públicos como un servicio público en `s2.ripple.com`. <!-- SPELLING_IGNORE: xrplcluster -->
+
+Los proveedores de servidores Full History se reservan el derecho de bloquear acceso a aquellos que abusen de los rescursos, o generen una carga desproporcionada a los sistemas.
+
+**Consejo:** A diferencia de algunas redes de criptomonedas, los servidores en el XRP Ledger no necesitan un full history para conocer el estado actual y mantenerse a día con las transacciones actuales.
+
+Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
+
+## Fragmentación del historial
+
+Una alternativa para almacenar todo el histórico completo del XRP Ledger en una única máquina cara es configurar muchos servidores para que cada uno almacene una parte del histórico completo del ledger. La función [Fragmentación del histórico](../../infrastructure/configuration/data-retention/history-sharding.md) hace esto posible, almacenando rangos del histórico del ledger en áreas de almacenamiento separadas llamadas almacenes de fragmentación o _shard store_. Cuando un servidor par solicita datos específicos (como se describe en [fetching history](#recuperar-el-histórico) arriba), un servidor puede responder usando datos de su ledger store o shard store.
+
+Online deletion **no** borra desde un shard store. Sin embargo, si configuras online deletion para mantener al menos 32768 versiones de ledger en el ledger store de tu servidor, tu servidor puede copiar shards completos desde el ledger store al shard store antes de borrarlos automáticamente del ledger store.
+
+Para más información, ver [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md).
+
+
+## Ver también
+
+- **Conceptos:**
+    - [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 History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md

@@ -0,0 +1,52 @@
+---
+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.
+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. |
+
+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)
+- **Conceptos:**
+    - [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)
+- **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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md

@@ -0,0 +1,174 @@
+---
+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í.
+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.
+
+El protocolo de pares es el modo principal de comunicación entre servidores en el XRP Ledger. Toda la información sobre el comportamiento, progreso, y conectividad en el XRP Ledger pasa a través del protocolo de pares. Ejemplos de comunicación peer-to-peer incluyen todos los siguientes:
+
+- Solicitar una conexión a otros servidores en la red peer-to-peer, o anunciar que hay huecos de conexión disponibles.
+- Compartir transacciones candidatas con el resto de la red.
+- Solicitar datos de ledger de ledgers históricos, o proporcionar esos datos.
+- Proponer una conjunto de transacciones para el consenso, o compartir el resultado calculado de aplicar el conjunto de transacciones de consenso.
+
+Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/XRPLF/rippled).)
+
+## Descubrimiento de pares
+
+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. 
+
+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.)
+
+Idealmente, el servidor debería poder enviar _y_ recibir conexiones en el puerto de pares. Debes [redireccionar el puerto utilizado por el protocolo de pares a través de tu firewall](../../infrastructure/configuration/peering/forward-ports-for-peering.md) para el servidor `rippled`.
+
+IANA [ha asignado el puerto **2459**](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2459) para el protocolo de pares del XRP Ledger, pero para la compatibilidad con sistemas antiguos, el [fichero de configuración por defecto de `rippled`](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg) escucha las conexiones entrantes de pares con el **port 51235** en todas las interfaces de la red. Si ejecutas un servidor, puedes configurar qué puerto(s) escucha tu servidor utilizando el fichero `rippled.cfg`.
+
+Ejemplo:
+
+```
+[port_peer]
+port = 2459
+ip = 0.0.0.0
+protocol = peer
+```
+
+El puerto del protocolo de pares también sirve para [métodos especiales del puerto de pares](../../references/http-websocket-apis/peer-port-methods/index.md).
+
+## Par de claves de nodo
+
+Cuando un servidor se inicia por primera vez, genera un _par de claves de nodo_ para usarlo para identificarse en las comunicaciones del protocolo de pares. El servidor utiliza su clave para firmar todas sus comunicaciones del protocolo de pares. Esto hace posible identificar y verificar de manera confiable la integridad de los mensajes de otro servidor en la red peer-to-peer incluso si los mensajes de ese servidor están siendo transmitidos por pares no confiables.
+
+El par de claves de nodo se guarda en la base de datos y se reutiliza cuando el servidor se reinicia. Si eliminas las bases de datos del servidor, crea un nuevo par de claves de nodo, lo que efectivamente le hace iniciar con una identidad diferente. Para reutilizar el mismo par de claves incluso si las bases de datos se eliminan, puedes configurar el servidor en el apartado `[node_seed]`. Para generar un valor adecuado para usar en el apartado `[node_seed]`, utiliza el [método validation_create][].
+
+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:
+
+- Utiliza **Pares fijos** para permanecer siempre conectado a pares específicos basado en sus direcciones IP. Esto solo funciona si los pares tienen direcciones IP fijas. Usa el apartado `[ips_fixed]` para configurar pares fijos. Esto es una parte necesaria para [clustering](clustering.md) o [pares privados](#pares-privados). Los pares fijos están definidos en el fichero de configuración, pero los cambios solo se aplican una vez se reinicia el servidor. Los pares fijos son más útiles para mantener servidores conectados si esos servidores son administrados por la misma persona u organización.
+- Utiliza **Reservas de pares** para priorizar pares específicos. Si tu servidor tiene una reserva de pares para un par específico, entonces tu servidor siempre acepta peticiones de conexión desde ese par incluso si tu servidor está ya en su número máximo de pares conectados. (Esto puede causar que tu servidor _supere_ el número máximo de pares.) Identificas a un par reservado por su [par de claves de nodo](#par-de-claves-de-nodo), así puedes hacerlo incluso para pares con una direcciones IP dinamicas. Las reservas de pares son configurados a través de comandos de administrador y guardados en las bases de datos del servidor, por lo que se pueden ajustar mientras el servidor está online y son salvados durante los reinicios. Las reservas de pares más útiles para conectarse a servidor administrados por diferentes personas u organización. <!-- STYLE_OVERRIDE: prioritize -->
+
+En los siguientes casos, un servidor `rippled` no se conecta a pares no confiables:
+
+- 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.
+
+**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.
+
+Configurar un servidor como un servidor privado tiene varios efectos:
+
+- El servidor no hace conexiones salientes a otros servidores en la red peer-to-peer a menos que se haya configurado explícitamente para conectarse a esos servidores.
+- 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.
+
+    **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
+
+Para ser parte del XRP Ledger, un servidor `rippled` debe estar conectado al resto de la red abierta peer-to-peer. A grandes rasgos, hay tres categorías de configuraciones para cómo un servidor `rippled` se conecta a la red:
+
+- Usando **pares descubiertos**. El servidor se conecta a cualquier servidor no confiable que encuentre y permanece conectado siempre que esos servidores se comporten adecuadamente. (Por ejemplo, no solicitan demasiados datos, sus conexiones de red son estables y parecen estar siguiendo la misma [red](parallel-networks.md).) Esto es lo predeterminado.
+- Como un **servidor privado utilizando proxies** ejecutado por la misma persona u organización. Los proxies son servidores stock `rippled` (también conectados a pares descubiertos) que mantienen una conexión de emparejamiento fija con el servidor privado.
+- Como un **servidor privado utilizando hubs públicos**. Esto es similar a utilizar proxies, pero depende de terceros específicos.
+
+Los pros y contras de cada configuración son los siguientes:
+
+
+<table>
+<thead><tr>
+<th>Configuración</th> <th>Pros</th> <th>Contras</th>
+</tr></thead>
+<tbody>
+<tr><th>Pares descubiertos</th>
+  <td><ul>
+    <li><p>La configuración más simple, con una carga de mantenimiento baja.</p></li>
+    <li><p>Crea la oportunidad para una gran cantidad de conexiones directas de pares. Tener más pares directos tiene varios beneficios. Tu servidor puede <a href="ledger-history#recuperar-el-histórico">recuperar histórico</a> de múltiples pares en paralelo, tanto al sincronizar como al rellenar el histórico. Como no todos los pares mantienen el histórico completo, tener acceso a una gama más amplia de datos históricos.</p></li>
+    <li><p>Reduce la posibilidad de desconexión de la red porque tu servidor puede reemplazar los pares desconectados con otros nuevos.</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>No te permite seleccionar los pares de tu servidor, lo que significa que no tienes idea de si tus pares pueden decidir actuar maliciosamente. Aunque los servidores `rippled` están diseñados para protegerse contra pares maliciosos, siempre existe el riesgo de que los pares maliciosos puedan atacar fallos en el software para afectar a tu servidor.</p></li>
+    <li><p>Los pares de tu servidor pueden desconectarse o cambiar a menudo.</p></li>
+  </ul></td>
+</tr>
+<tr><th>Servidor privado utilizando proxies</th>
+  <td><ul>
+    <li><p>Configuración más segura y confiable cuando se implementa correctamente.</p></li>
+    <li><p>Tan confiable y redundante como quieras hacerla.</p></li>
+    <li><p>Puedes optimizar el rendimiento del servidor privado con <a href="clustering">clustering</a>.</p></li>
+    <li><p>Te permite crear tantas conexiones directas de pares como desees. Tu servidor privado puede <a href="ledger-history#recuperar-el-histórico">obtener histórico</a> desde múltipes pares en paralelo. Dado que administras los pares, también puedes controlar cuanto histórico del ledger cada par puede mantener.</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>Carga de mantenimiento y costos más altos debido a la ejecución de múltiples servidores.</p></li>
+    <li><p>No elimina por completo la posibilidad de interrupciones en la conexión de pares. No importa cuántos proxies ejecutes, si todos existen en el mismo rack de servidores, entonces una interrupción de red o de luz puede afectar a todos ellos.</p></li>
+  </ul></td>
+</tr>
+<tr><th>Servidor privado utilizando hubs públicos</th>
+  <td><ul>
+    <li><p>Carga de mantenimiento baja con una pequeña cantidad de configuración.</p></li>
+    <li><p>Proporciona acceso a conexiones seguras a la red.</p></li>
+    <li><p>En comparación con la conexión utilizando proxies, es menos probable que cause que tu servidor privado se desconecte de la red debido a una interrupción simultánea de pares.</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>Depende de terceros con una alta reputación para mantenerse confiable.</p></li>
+    <li>
+      <p>Puede hacer que tu servidor se desconecte de la red si los hubs públicos en los que confías están demasiado ocupados. Debido a la naturaleza de los hubs públicos, son los más populares y es posible que no puedan mantener una conexión estable abierta para todos.</p>
+      <p>Para evitar este problema, usa más hubs públicos; cuanto más, mejor. También puede ayudar usar hubs no predeterminados, que son menos propensos a estar ocupados.</p>
+    </li>
+  </ul></td>
+</tr>
+</tbody>
+</table>
+
+### Configurando un servidor privado
+
+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)
+- **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)
+- **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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md

@@ -0,0 +1,97 @@
+---
+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.
+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.
+- [**Modo Reporting**](#modo-reporting) - Un modo especializado para servir consultas API desde una base de datos relacional. No participa en la red peer-to-peer, por lo que necesitas ejecutar un servidor en modo P2P y conectarle el servidor modo reporting usando una conexión gRPC de confianza. 
+- [**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.
+
+Los servidores en Modo P2P también pueden configurarse para proporcionar funcionalidades adicionales. Un servidor ejecutando en Modo P2P con un archivo de configuración mínimamente modificado también se llama un servidor de stock o _stock server_. Otras configuraciones incluyen:
+
+- [Validador](#validadores)
+- [Servidor API](#servidores-api)
+- [Hubs públicos](#hubs-publicos)
+
+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.
+
+
+### Hubs públicos
+
+Un servidor hub es un servidor en Modo P2P con muchas [conexiones del protocolo de pares](peer-protocol.md) a otros servidores. Los servidores hub, especialmente los _hubs públicos_ que permiten conexiones desde Internet abierto, ayudan a la red del XRP Ledger a mantener una conectividad eficiente. Los hubs públicos exitosos encarnan las siguientes características:
+
+- Buen ancho de banda.
+
+- Conexiones con muchos pares confiables.
+
+- Capacidad para transmitir mensajes de maneja confiable.
+
+Para configurar tu servidor como un hub, aumenta el número máximo de pares permitidos y asegúrate de haber [redireccionado los puertos apropiados](../../infrastructure/configuration/peering/forward-ports-for-peering.md) a través de tu firewall y enrutador de NAT (traducción de dirección de red) según corresponda.
+
+### Validadores
+
+La robustez del XRP Ledger depende de una red interconectada de _validadores_ que confían mutuamente en algunos otros validadores para _no colisionar_. Además de procesar cada transacción y calcular el estado del ledger exactamente como otros servidores en Modo P2P, los validadores participan activamente en el [protocolo de consenso](../consensus-protocol/index.md). Si tú o tu organización dependen del XRP Ledger, es de tu interés contribuir al proceso de consenso ejecutando _un_ servidor como validador.
+
+La validación utiliza solo una pequeña cantidad de recursos informáticos, pero no hay mucho beneficio para una sola entidad u organización en ejecutar varios validadores porque hacerlo no proporciona más protecciones contra las colisiones. Cada validador se identifica con un par de claves criptográficas único que debe ser gestionado cuidadosamente; múltiples validadores no deben compartir un par de claves. Por estas razones, la validación está desactivada de forma predeterminada.
+
+Puedes habilitar de forma segura la validación en un servidor que también se utiliza para otros fines; este tipo de configuración se llama un _servidor multiuso_. Alternativamente, puedes ejecutar un _validador dedicado_ que no realice otras tareas, posiblemente en un [cluster](clustering.md) con otros servidores `rippled` en Modo P2P.
+
+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 reporting
+
+
+El modo reporting es un modo especializado para servir solicitudes API de manera más eficiente. En este modo, el servidor obtiene los datos del ledger validados más recientes a través de [gRPC](../../infrastructure/configuration/configure-grpc.md) desde un servidor `rippled` separado en Modo P2P, luego carga esos datos en una base de datos relacional ([PostgreSQL](https://www.postgresql.org/)). El servidor en modo reporting no participa directamente en la red peer-to-peer, aunque puede reenviar solicitudes como el envío de transacciones al servidor en Modo P2P que utiliza.
+
+Varios servidores en modo reporting pueden compartir acceso a una base de datos PostgreSQL y a un clúster [Apache Cassandra](https://cassandra.apache.org/) para servir una gran cantidad de historial sin que cada servidor necesite una copia redundante de todos los datos. Los servidores en modo reporting proporcionan estos datos a través de las mismas [`rippled` APIs](../../references/http-websocket-apis/index.md) con algunos cambios leves para adaptarse a las diferencias en cómo almacenan los datos subyacentes.
+
+Especialmente, los servidores en modo reporting no informan sobre datos pendientes de validación del ledger o transacciones no validadas. Esta limitación es relevante para ciertos casos de uso que dependen de un acceso rápido a datos en flujo, como realizar arbitraje en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).
+
+<!-- TODO: link setup steps for Reporting Mode when those are ready -->
+
+
+## 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:
+
+- [Probar los efectos de enmiendas](../../infrastructure/testing-and-auditing/test-amendments.md) antes de que esas enmiendas hayan entrado en efecto en toda la red descentralizada.
+- [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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md

@@ -0,0 +1,51 @@
+---
+html: the-clio-server.html
+parent: networks-and-servers.html
+seo:
+    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.
+
+Un servidor Clio no se conecta a la red peer-to-peer. En su lugar, extrae datos de un servidor `rippled` especifico que está conectado a la red P2P. Al manejar las llamadas API de manera eficiente, los servidores Clio pueden ayudar a reducir la carga en los servidores `rippled` que se ejecutan en modo P2P.
+
+Clio almacena datos históricos del ledger y transacciones validadas en un formato eficiente de espacio, utilizando hasta 4 veces menos espacio que `rippled`. Clio utiliza Cassandra o ScyllaDB, lo que permite una capacidad de lectura escalable. Multiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio sin necesidad de almacenamiento o cálculo de datos redundantes o computación
+
+Clio requiere acceso a un servidor `rippled`, que pueda ejecutarse en la misma máquina que Clio o por separado.
+
+Mientras que Clio ofrece las [APIs HTTP / WebSocket](../../references/http-websocket-apis/index.md) completas, por defecto, solo devuelve datos validados. Para cualquier solicitud que requiera acceso a la red P2P, Clio reenvía automáticamente la solicitud al servidor `rippled` en la red P2P y devuelve la respuesta.
+
+## ¿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. 
+
+* 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`.
+
+* 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?")
+
+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.
+
+Cuando un servidor Clio recibe una solicitud API, busca datos en estos almacenes de datos. Para solicitudes que requieren datos de la red P2P, el servidor Clio reenvía la solicitud a un servidor P2P y luego pasa la respuesta de vuelta al cliente.
+
+Clio **siempre** reenvía a `rippled` si alguna de las siguientes condiciones es verdadera:
+
+- `ledger_index` está establecido a `current` o `closed`.
+- `accounts`, `queue` o `full` están establecidos en `true` para la API de `ledger`.
+- `queue` está establecido en `true` para la API de `account_info`.
+- El método solicitado de API (`"command"`) es `submit`, `submit_multisigned`, `fee`, `ledger_closed`, `ledger_current`, `ripple_path_find`, `manifest`, `channel_authorize` o `channel_verify`.
+
+## Ver también
+
+- [Código fuente Clio](https://github.com/XRPLF/clio)
+- **Tutoriales:**
+    - [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)

@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md

@@ -0,0 +1,77 @@
+---
+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.
+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 %}
+
+El XRP Ledger está diseñado para ser resistente a la censura. En apoyo a este diseño, el XRP Ledger proporciona un detector automatizado de censura de transacciones que está disponible en todos los servidores `rippled`, permitiendo que todos los participantes vean si la censura está afectando a la red.
+
+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:
+
+1. El detector agrega todas las transacciones en la propuesta de consenso inicial del servidor al rastreador.
+
+2. Al cierre de la ronda de consenso, el detector elimina todas las transacciones incluidas en el ledger validado resultante del rastreador.
+
+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.
+
+    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
+
+Esto es un ejemplo de mensaje de advertencia emitido por el detector de censura de transacciones de que la transacción E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 permaneciese en el rastreador por 15 ledgers, desde el ledger 18851530 hasta el ledger 18851545.
+
+```text
+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.
+
+```text
+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.
+
+Aquí hay algunos escenarios que podrían causar que el detector emita mensajes de falsos positivos:
+
+- Tu servidor está ejecutando una compilación con código diferente al resto de la red. Esto puede hacer que tu servidor aplique transacciones de manera diferente, lo que resulta en falsos positivos. Si bien este tipo de falsos positivos es poco probable en general, es crucial que ejecutes una versión compatible del servidor principal del XRP Ledger.
+
+- Tu servidor está fuera de sincronización con la red y aún no lo ha notado.
+
+- 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/).
+
+
+## Ver también
+
+- **Conceptos:**
+    - [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)
+- **Referencias:**
+    - [Resultados de transacciones](../../references/protocol/transactions/transaction-results/index.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md

@@ -0,0 +1,19 @@
+---
+html: bouncing-payments.html
+parent: payment-types.html
+seo:
+    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.
+
+El primer requisito para devolver pagos es [monitorizar de manera robusta los pagos entrantes](robustly-monitoring-for-payments.md). ¡No querrás devolver accidentalmente a un cliente más de lo que te ha enviado! (Esto es particularmente importante si tu proceso de devolución está automatizado.) Usuarios maliciosos pueden tomar ventaja de una integración inocente al enviar [pagos parciales](partial-payments.md#exploit-de-pagos-parciales).
+
+En segundo lugar, deberías enviar los pagos devueltos como Pagos Parciales (partial payments). Dado que terceras partes pueden manipular el coste de los caminos entre direcciones, los Pagos Parciales te permiten desprenderte de la cantidad completa sin preocuparte por los tipos de cambio dentro del XRP Ledger. Deberías publicar tu política de devolución de pagos como parte de tus términos de uso. Envía el pago devuelto desde una dirección operacional o una dirección de reserva.
+
+Para enviar un Pago Parcial, activa el [flag `tfPartialPayment`](../../references/protocol/transactions/types/payment.md#flags-de-pago) en la transacción. Introduce la cantidad en el campo `Amount` con la cantidad que recibiste y omite el campo `SendMax`. Deberías utilizar el valor `SourceTag` del pago entrante como el `DestinationTag` de tu pago de devolución.
+
+Para prevenir que dos sistemas estén devolviendo pagos uno al otro indefinidamente, puedes establecer un nuevo Source Tag para el pago de devolución saliente. Si recibes un pago inesperado cuyo Destination Tag coincide con el Source Tag de una devolución que enviaste, no lo rechaces nuevamente.

@l10n/es-ES/docs/concepts/payment-types/checks.md

@@ -0,0 +1,66 @@
+---
+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.
+labels:
+  - Cheques
+  - Pagos
+  - Tokens
+---
+# 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.
+
+Los Cheques del XRP Ledger pueden tener tiempos de vencimiento después de los cuales ya no pueden ser cobrados. Si el destinatario no cobra con éxito el Cheque antes de que expire, el Cheque ya no se podrá cobrar, pero el objeto permanece en el XRP Ledger hasta que alguien lo cancele. Cualquiera puede cancelar el Cheque después de que expire. Solo el remitente y el destinatario pueden cancelar el Cheque antes de que expire. El objeto del Cheque se elimina del ledger cuando el remitente cobra con éxito el cheque o alguien lo cancela.
+
+## Casos de uso
+
+- Los Cheques permiten a las personas intercambiar fondos utilizando un proceso familiar y aceptado por la industria bancaria.
+
+- Si tu destinatario previsto utiliza autorización de deposito, [Deposit Authorization](../accounts/depositauth.md) para bloquear pagos directos de extraños, un cheque es una buena alternativa.
+
+- 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.
+
+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.
+
+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][]
+- [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)
+- [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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md

@@ -0,0 +1,42 @@
+---
+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.
+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)
+- **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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md

@@ -0,0 +1,49 @@
+---
+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.
+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.
+
+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.
+
+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.
+    
+
+## 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)
+- **Referencias:**
+    - [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" /%}

@l10n/es-ES/docs/concepts/payment-types/escrow.md

@@ -0,0 +1,96 @@
+---
+html: escrow.html
+parent: payment-types.html
+seo:
+    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.
+
+El XRP Ledger lleva el escrow un paso más allá, reemplazando al tercero con un sistema automatizado integrado en el ledger. Un escrow bloquea el XRP, que no puede ser utilizado o destruido hasta que se cumplan las condiciones.
+
+## Tipos de escrow
+
+El XRP Ledger soporta tres tipos de escrow:
+
+- **Escrow basado en el tiempo:** Los fondos solo están disponibles después de que haya pasado cierta cantidad de tiempo.
+- **Escrow condicional:** Este escrow se crea con una condición correspondiente y un cumplimiento. La condición sirve como un bloqueo en los fondos y no se liberará hasta que se proporcione la clave de cumplimiento correcta.
+- **Escrow combinado:** Este escrow combina las características de un escrow basado en el tiempo y uno condicional. El escrow es completamente inaccesible hasta que pase el tiempo especificado, después de lo cual los fondos pueden ser liberados proporcionando el cumplimiento correcto.
+
+## 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.
+
+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.
+
+## Estados del escrow
+
+El siguiente diagrama muestra los estados por los que puede pasar un escrow:
+
+[![El diagrama de estados muestra al escrow pasar desde  Retenido → Preparado/Condicionalmente preparado → Caducado](/docs/img/escrow-states.png)](/docs/img/escrow-states.png)
+
+El diagrama muestra tres casos diferentes para tres posibles combinaciones de los escrows de tiempo "terminar trás" (campo `FinishAfter`), cripto-condición (campo `Condition`), y tiempo de caducidad (campo `CancelAfter`):
+
+- **Escrow basado en el tiempo (izquierda):** Con solo un tiempo de finalización, el escrow se crea en el estado **Retenido**. Después de que haya pasado un tiempo especificado, se convierte en **Preparado** y cualquiera puede finalizarlo. Si el escrow tiene una fecha de caducidad y nadie finaliza el escrow antes de que el tiempo pase, entonces el escrow pasa a estar **Caducado**. En el estado de caducado, un escrow no puede finalizarse, y cualquiera puede cancelarlo. Si el escrow no tiene un campo `CancelAfter`, nunca caduca y nunca puede cancelarse.
+
+- **Escrow combinado (centro):** Si el escrow especifica tanto como una criptocondición (campo `Condition`) _y_ una fecha "terminar tras" (campo `FinishAfter`), el escrow es **Retenido** hasta que la fecha "terminar-tras" ha pasado. Luego se convierte en **Condicionalmente preparado**, y puede finalizarlo si se suministra el cumplimiento correcto de la criptocondición. Si el escrow tiene una fecha de caducidad (campo `CancelAfter`), y nadie lo completa antes de que pase ese tiempo, entonces el escrow se convierte en **Caducado**. En el estado de caducado, un escrow no se puede finalizar, y cualquiera puede cancelarlo. Si el escrow no tiene un campo `CancelAfter`, nunca caducará y no podrá ser cancelado.
+
+- **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`.
+- 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.
+
+El coste de transacción adicional requerido es proporcional al tamaño de la condición introducida. Si la transacción es multi-firma o [multi-signed](../accounts/multi-signing.md), el coste de la multi-firma es añadido al coste de la introducción de la condición.
+
+Actualmente, un EscrowFinish con introducción requiere un mínimo de coste de transacción de **330 [drops de XRP](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts) más 10 drops por cada 16 bytes del tamaño de la introducción**.
+
+**Nota:** La fórmula de arriba está basada en la asunción de que el coste de referencia de la transacción es 10 drops de XRP.
+
+Si el [coste de votar](../consensus-protocol/fee-voting.md) cambia el valor de `reference_fee`, la fórmula escala basado en el nuevo coste de referencia. La fórmula general de una transacción EscrowFinish con un crypto-cumplimiento es como sigue:
+
+```
+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][]
+- [Referencia Ledger](../../references/protocol/ledger-data/index.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/).
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/payment-types/index.md

@@ -0,0 +1,16 @@
+---
+html: payment-types.html
+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í.
+---
+# 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 /%}

@l10n/es-ES/docs/concepts/payment-types/partial-payments.md

@@ -0,0 +1,140 @@
+---
+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.
+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ó.
+
+Si un Pago no habilita el flag de Pago Parcial, el campo `Amount` de una [transacción Payment][] en el XRP Ledger especifica la cantidad a entregar después de cobrar por tasas de cambio y [costes de transferencia](../tokens/transfer-fees.md). El flag de Pago Parcial ([`tfPartialPayment`](../../references/protocol/transactions/types/payment.md#payment-flags)) permite que un pago tenga éxito al reducir la cantidad recibida en lugar de aumentar la cantidad enviada. Los pagos parciales son útiles para [devolver pagos](bouncing-payments.md) sin incurrir en costos adicionales para uno mismo.
+
+La cantidad de XRP utilizada para el [coste de transacción](../transactions/transaction-cost.md) siempre se deduce de la cuenta del remitente, independientemente del tipo de transacción. Este coste de transacción, o comisión, no se incluye en la `Amount`.
+
+Los pagos parciales se pueden utilizar para explotar integraciones ingenuas con el XRP Ledger para robar dinero de exchanges y gateways. La sección [Explotación de Pagos Parciales](#exploit-de-pagos-parciales) de este documento describe cómo funciona esta explotación y cómo puedes evitarla.
+
+## Semántica
+
+### Sin pagos parciales
+
+Al enviar un Pago que no utiliza el flag de Pago Parcial, el campo `Amount` de la transacción especifica la cantidad exacta a entregar, y el campo `SendMax` especifica la cantidad máxima y la divisa a enviar. Si un pago no puede entregar la cantidad completa de `Amount` sin exceder el parámetro `SendMax`, o si la cantidad completa no se puede entregar por cualquier otro motivo, la transacción falla. Si el campo `SendMax` se omite de las instrucciones de la transacción, se considera igual a la `Amount`. En este caso, el pago solo puede tener éxito si la cantidad total de las tarifas es 0.
+
+En otras palabras:
+
+```
+Cantidad + (costes) = (cantidad enviada) ≤ SendMax
+```
+
+En esta fórmula, "costes" o fees se refiere a [costes de transferencia](../tokens/transfer-fees.md) y tipos de cambio de las divisas. La "cantidad enviada" y la cantidad enviada (`Amount`) pueden estar denominadas en distintas divisas y convertirse por la consumición de Ofertas en el exchange descentralizado del XRP Ledger.
+
+**Nota:** El campo `Fee` de la transacción se refiere al [coste de transacción](../transactions/transaction-cost.md) en XRP, que se destruye para enviar la transacción a la red. El coste de transacción exacto especificado se carga siempr al remitente y se separa completamente de los cálculos de costes para cualquier tipo de pago.
+
+### Con pagos parciales
+
+Cuando se envía un Pago que tiene habilitado el flag de Pago Parcial, el campo `Amount` de la transacción especifica una cantidad máxima a entregar. Los pagos parciales pueden tener éxito al enviar _parte_ del valor previsto a pesar de limitaciones que incluyen costes, falta de liquidez, falta de espacio en las líneas de confianza (trustlines) de la cuenta receptora, u otras razones.
+
+El campo opcional `DeliverMin` especifica una cantidad mínima a entregar. El campo `SendMax` funciona de la misma manera que con los pagos no parciales. La transacción de pago parcial tiene éxito si entrega cualquier cantidad igual o mayor que el campo `DeliverMin` sin exceder la cantidad `SendMax`. Si el campo `DeliverMin` no está especificado, un pago parcial puede tener éxito al entregar cualquier cantidad positiva.
+
+En otras palabras:
+
+```
+Cantidad ≥ (Cantidad enviada) = SendMax - (Costes) ≥ DeliverMin > 0
+```
+
+### Limitaciones de los pagos parciales
+
+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.
+
+[código de resultado]: ../../references/protocol/transactions/transaction-results/index.md
+
+### El campo `delivered_amount`
+
+Para ayudar a entender cuánto entregó realmente un pago parcial, los metadatos de una transacción de Pago exitosa incluyen un campo `delivered_amount`. Este campo describe la cantidad realmente entregada, en el [mismo formato](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts) que el campo `Amount`.
+
+Para pagos no parciales, el campo `delivered_amount` de los metadatos de la transacción es igual al campo `Amount` de la transacción. Cuando un pago entrega [tokens](../tokens/index.md), el campo `delivered_amount` puede ser ligeramente diferente al campo `Amount` debido al redondeo.
+
+La cantidad entregada **no está disponible** para transacciones que cumplen **ambos** de los siguientes criterios:
+
+- Es un pago parcial
+- Está incluido en un ledger validado anterior al 20 de enero de 2014
+
+Si ambas condiciones son verdaderas, entonces `delivered_amount` contiene el valor del string `unavailable` en lugar de una cantidad real. Si esto ocurre, solo puedes determinar la cantidad entregada real leyendo los `AffectedNodes` en los metadatos de la transacción. Si la transacción entregó tokens y el `issuer` del `Amount` es la misma cuenta que la dirección `Destination`, la cantidad entregada puede dividirse entre varios miembros de `AffectedNodes` que representan líneas de confianza (trustlines) con distintas contrapartes.
+
+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` |
+
+[WebSocket]: ../../references/http-websocket-apis/index.md
+[JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
+
+## Exploit de pagos parciales
+
+Si la integración de una institución financiera con el XRP Ledger asume que el campo `Amount` de un Pago es siempre la cantidad completa entregada, actores maliciosos podrían aprovechar esa suposición para robar dinero de la institución. Este exploit puede utilizarse contra pasarelas, exchanges o comerciantes siempre que el software de esas instituciones no procese los pagos parciales correctamente.
+
+**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.
+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.
+
+En el caso de un comerciante, el orden de las operaciones es ligeramente diferente, pero el concepto es el mismo:
+
+1. El actor malicioso solicita comprar una gran cantidad de bienes o servicios.
+2. El comerciante vulnerable factura al actor malicioso por el precio de esos bienes o servicios.
+3. El actor malicioso envía una transacción de Pago al comerciante. Esta transacción tiene un campo `Amount` grande y tiene el flag **`tfPartialPayment`** activado.
+4. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero entrega solo una cantidad muy pequeña de la divisa especificada.
+5. El comerciante vulnerable lee el campo `Amount` de la transacción sin mirar el campo `Flags` o el campo de los metadatos `delivered_amount`.
+6. El comerciante vulnerable trata la factura como pagada y proporciona los bienes o servicios al actor malicioso, a pesar de recibir solo una mucho menor `delivered_amount` en el XRP Ledger.
+7. El actor malicioso utiliza, revende, o se marcha con los bienes y servicios antes de que el comerciantes note la discrepancia.
+
+### Mitigaciones adicionales
+
+Utilizar [el campo `delivered_amount`](#the-delivered_amount-field) al procesar transacciones entrantes es suficiente para evitar este exploit. Aún así, prácticas de negocio proactivas adicionales también pueden evitar o mitigar la probabilidad de esta o exploits similares. Por ejemplo:
+
+- 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)
+- **Conceptos:**
+    - [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)
+- **Referencias:**
+    - [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" /%}

@l10n/es-ES/docs/concepts/payment-types/payment-channels.md

@@ -0,0 +1,52 @@
+---
+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.
+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.
+
+El XRP para un canal de pago se reserva temporalmente. El remitente crea reclamaciones o _Claims_ contra el canal, que el destinatario verifica sin enviar una transacción al XRP Ledger o esperar a que se apruebe una nueva versión del ledger por [consenso](../consensus-protocol/index.md). (Este es un proceso _asíncrono_ porque ocurre separado del patrón habitual de obtener transacciones aprobadas por consenso). En cualquier momento, el destinatario puede _canjear_ una reclamación (Claim) para recibir una cantidad de XRP autorizada por esa _Claim_. Liquidar una _Claim_ de esta manera utiliza una transacción estándar del XRP Ledger, como parte del proceso de consenso habitual. Esta única transacción puede abarcar cualquier cantidad de transacciones garantizadas por _Claims_ más pequeñas.
+
+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.
+
+Los Canales de Pago no especifican intrínsecamente nada sobre lo que puedes comprar y vender con ellos. Sin embargo, los tipos de bienes y servicios que son adecuados para los canales de pago son:
+
+- Cosas que pueden transmitirse casi instantaneamente, como artículos digitales
+- 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")
+
+
+## Ver también
+
+- **Conceptos relacionados:**
+    - [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
+- **Tutoriales y casos de uso:**
+    - [Utilizar canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
+    - [Abrir un canal de pago para activar una red de intercambio](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/open-a-payment-channel-to-enable-an-inter-exchange-network.md)
+- **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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md

@@ -0,0 +1,27 @@
+---
+html: robustly-monitoring-for-payments.html
+parent: payment-types.html
+seo:
+    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.
+
+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í.
+
+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).

@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md

@@ -0,0 +1,24 @@
+---
+html: sending-payments-to-customers.html
+parent: payment-types.html
+seo:
+    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.
+
+Generalmente, al enviar stablecoins, utilizas una [transacción Payment][]. Algunos detalles son diferentes dependiendo de si estás emitiendo tokens por primera vez o transfiriéndolos desde una cartera activa a un cliente. Cosas a tener en cuenta incluyen:
+
+- Siempre especifica tu dirección emisora como el emisor del token. De lo contrario, podrías usar accidentalmente rutas (paths) que entreguen la misma divisa emitida por otras direcciones.
+- Antes de enviar un pago al XRP Ledger, comprueba el coste del pago. Un pago desde tu dirección operacional a un cliente no debe costar más que la cantidad de destino más cualquier coste de transferencia que hayas establecido.
+- Cuando emites nuevos tokens desde tu dirección emisora, debes omitir el campo `SendMax`. De lo contrario, los usuarios malintencionados pueden configurar sus ajustes para que emitas la cantidad completa de `SendMax` en lugar de solo la `Amount` de destino prevista.
+- Cuando envías tokens _desde una cartera caliente_, debes especificar `SendMax` si tienes un coste de transferencia distinto de cero. En este caso, establece el campo `SendMax` en la cantidad especificada en el campo `Amount` más el coste de transferencia. (Puede que desees redondear ligeramente hacia arriba, en caso de que la precisión de tus cálculos no coincida exactamente con la del XRP Ledger). Por ejemplo, si envías una transacción cuyo campo `Amount` especifica 99.47 USD, y tu coste de transferencia es del 0.25%, deberías establecer el campo `SendMax` en 124.3375, o 124.34 USD si redondeas hacia arriba.
+- Omitir el campo `Paths`. Este campo es innecesario cuando se envía directamente desde el emisor, o desde una cartera caliente siempre y cuando los tokens que se envían y los que se reciben tengan el mismo código de divisa y emisor, es decir, sean la misma stablecoin. El campo `Paths` está destinado a [Pagos entre divisas](cross-currency-payments.md) y a pagos multi-salto (rippling) más largos. Si realizas una búsqueda de rutas (paths) de manera ingenua y adjuntas las rutas a tu transacción, tu pago puede tomar un camino indirecto más costoso en lugar de fallar si el camino directo no está disponible; los usuarios malintencionados incluso pueden configurar esto.
+- Si recibes un código de resultado `tecPATH_DRY`, esto suele indicar que el cliente no tiene configurada la línea de confianza (trustline) necesaria, o que los ajustes de rippling de tu emisor no están configurados correctamente.
+
+Para un tutorial detallado sobre cómo emitir un token en el XRP Ledger, ya sea una stablecoin u otro tipo, visita [Emitir un token fungible](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md).
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md

@@ -0,0 +1,26 @@
+---
+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.
+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.
+
+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 -->
+
+El puente automático ocurre automáticamente en cualquier [transacción OfferCreate][]. Las [transacciones de Payment](../../../references/protocol/transactions/types/payment.md) _no_ usan auto-puente por defecto, pero path-finding pueden encontrar [rutas o paths](../fungible-tokens/paths.md) que tengan el mismo efecto.
+
+## Ver también
+
+- [Dev Blog: Introducción al Autopuente](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) <!-- SPELLING_IGNORE: autobridging -->
+
+- [Preferencia de oferta](offers.md#offer-preference)
+
+- [Rutas de pago](../fungible-tokens/paths.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md

@@ -0,0 +1,109 @@
+---
+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.
+labels:
+  - XRP
+  - Exchange Descentralizado
+  - AMM
+---
+# ¿Qué es un Automated Market Maker (AMM)?
+
+_(Requiere la [enmienda AMM][] XLS-30)_
+
+Los Creadores de Mercado Automatizados o Automated Market Maker (AMMs) son contratos inteligentes que proporcionan liquidez en el exchange descentralizado del XRP Ledger. Cada AMM posee un pool de dos activos y permite a los usuarios intercambiar entre ellos a una tasa de cambio establecida por una fórmula.
+
+Para cualquier par de activos dado, puede haber hasta un AMM en el ledger. Cualquiera puede crear el AMM para un par de activos si aún no existe, o depositar en un AMM existente. Aquellos que depositan activos en un AMM se llaman proveedores de liquidez o _liquidity providers_ (LPs) y reciben "Tokens LP" del AMM. Los Tokens LP permiten a los proveedores de liquidez:
+
+- Canjear sus Tokens LP por una parte de los activos en el pool del AMM, incluidas las tarifas recolectadas.
+- Votar para cambiar la configuración de tarifas del AMM. Los votos están ponderados en función de cuántos Tokens LP poseen los votantes.
+- Pujar con algunos de sus Tokens LP para recibir un descuento temporal en las tarifas de intercambio del AMM.
+
+Cuando el flujo de fondos entre los dos activos en un pool es relativamente activo y equilibrado, las tarifas proporcionan una fuente de ingresos pasivos para los proveedores de liquidez. Sin embargo, cuando el precio relativo entre los activos cambia, los proveedores de liquidez pueden sufrir una pérdida en el [riesgo de divisa](https://www.investopedia.com/terms/c/currencyrisk.asp).
+
+## ¿Cómo funciona el AMM?
+
+Un AMM posee dos activos diferentes: como máximo, uno de estos puede ser XRP, y uno o ambos pueden ser [tokens](../index.md). Los tokens con diferentes emisores se consideran activos diferentes para este propósito. Esto significa que puede haber un AMM para dos tokens con el mismo código de moneda pero diferentes emisores ("FOO emitido por WayGate" es diferente de "FOO emitido por StableFoo"), o el mismo emisor pero diferentes códigos de moneda. El orden no importa; el AMM para FOO.WayGate a XRP es el mismo que para XRP a FOO.WayGate.
+
+Cuando los usuarios desean comerciar en el exchange descentralizado, sus [Ofertas](offers.md) y [Pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden utilizar automáticamente los AMMs para completar el intercambio. Una sola transacción podría ejecutarse mediante la coincidencia de Ofertas, AMMs o una combinación de ambos, dependiendo de lo que sea más económico.
+
+Un AMM establece su tasa de cambio en función del saldo de activos en el pool. Cuando intercambias contra un AMM, la tasa de cambio se ajusta según cuánto tu intercambio desequilibre el saldo de activos que el AMM posee. A medida que su suministro de un activo disminuye, el precio de ese activo sube; a medida que su suministro de un activo aumenta, el precio de ese activo baja. Un AMM ofrece tasas de cambio generalmente mejores cuando tiene cantidades más grandes en general en su pool. Esto se debe a que cualquier intercambio dado causa un cambio más pequeño en el equilibrio de los activos del AMM. Cuanto más desequilibre un intercambio el suministro de los dos activos del AMM, más extrema se vuelve la tasa de cambio.
+
+El AMM también cobra una tarifa de intercambio porcentual además de la tasa de cambio.
+
+El XRP Ledger implementa un AMM de _media geométrica_ con un parámetro de peso de 0.5, por lo que funciona como un creador de mercado de _producto constante_. Para obtener una explicación detallada de la fórmula AMM de _producto constante_ y la economía de los AMMs en general, consulta [Introducción a los Automated Market Makers de Kris Machowski](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/).
+
+### Restricciones sobre los activos
+
+Para evitar el mal uso, se aplican algunas restricciones a los activos utilizados en un AMM. Si intentas crear un AMM con un activo que no cumple con estas restricciones, la transacción falla. Las reglas son las siguientes:
+
+- El activo no debe ser un Token LP de otro AMM.
+- 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.
+
+Cualquiera puede depositar activos en un AMM existente. Cuando se hace, se reciben nuevos Tokens LP según lo que depositaron. La cantidad que un proveedor de liquidez puede retirar de un AMM se basa en la proporción de los Tokens LP del AMM que poseen en comparación con el número total de Tokens LP pendientes.
+
+Los Tokens LP son como otros tokens en el XRP Ledger, por lo que puedes usarlos en muchos [tipos de pagos](../../payment-types/index.md) o intercambiarlos en el exchange descentralizado. (Para recibir Tokens LP como pago, debes configurar una [trust line](../fungible-tokens/index.md) con un límite distinto de cero con la cuenta del AMM como emisor). Sin embargo, _solo_ puedes enviar Tokens LP directamente al AMM (canjeándolos) usando el tipo de transacción [AMMWithdraw][], no a través de otros tipos de pagos. Del mismo modo, solo puedes enviar activos al pool del AMM a través del tipo de transacción [AMMDeposit][].
+
+El AMM está diseñado de manera que el pool de activos de un AMM esté vacío si y solo si el AMM no tiene Tokens LP pendientes. Esta situación solo puede ocurrir como resultado de una transacción [AMMWithdraw][]; cuando ocurre, el AMM se elimina automáticamente.
+
+### Códigos de moneda de Tokens LP
+
+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.
+
+Los proveedores de liquidez pueden votar para establecer la tarifa del 0% al 1%, en incrementos de 0.001%. Los proveedores de liquidez tienen un incentivo para establecer las tarifas de intercambio a una tasa adecuada: si las tarifas son demasiado altas, los intercambios usarán libros de pedidos para obtener una mejor tasa; si las tarifas son demasiado bajas, los proveedores de liquidez no obtienen ningún beneficio por contribuir al pool. <!-- STYLE_OVERRIDE: will --> Cada AMM da a sus proveedores de liquidez el poder de votar sobre sus tarifas, en proporción a la cantidad de Tokens LP que poseen esos proveedores de liquidez.
+
+Para votar, un proveedor de liquidez envía una [transacción AMMVote][]. Cada vez que alguien realiza una nueva votación, el AMM recalcula su tarifa para ser un promedio de las últimas votaciones ponderadas por la cantidad de Tokens LP que poseen esos votantes. Se pueden contar hasta 8 votos de proveedores de liquidez de esta manera; si más proveedores de liquidez intentan votar, solo se contarán los 8 mejores votos (por la mayor cantidad de Tokens LP que poseen). Aunque la participación de los proveedores de liquidez en Tokens LP puede cambiar rápidamente por muchas razones (como el comercio de esos tokens usando [Ofertas](offers.md)), las tarifas de intercambio solo se recalculan cuando alguien realiza una nueva votación (incluso si esa votación no está entre los 8 mejores).
+
+### Slot de subasta
+
+A diferencia de cualquier Automated Market Maker anterior, el diseño de AMM del XRP Ledger tiene un _slot de subasta_ en la que un proveedor de liquidez puede pujar para obtener un descuento en la tarifa de intercambio durante un período de 24 horas. La oferta debe pagarse en Tokens LP, que se devuelven al AMM. No más de una cuenta puede tener el slot de subasta al mismo tiempo, pero el ofertante puede nombrar hasta 4 cuentas adicionales para también recibir el descuento. No hay una oferta mínima, pero si el slot está ocupado actualmente, debes superar al titular actual del slot para desplazarlos. Si alguien te desplaza, recuperas parte de tu oferta según el tiempo restante. Mientras mantengas un slot de subasta activo, pagas una tarifa de intercambio con descuento igual a 1/10 (una décima parte) de la tarifa de intercambio normal al realizar operaciones contra ese AMM.
+
+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):
+
+- Una [entrada AMM][] que describe el creador de mercado automatizado en sí mismo.
+
+- 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.
+
+- 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:
+
+- AMM
+- AccountRoot
+- Trust lines para los Tokens LP del AMM. Estas trust lines tendrían un saldo de 0 pero pueden tener otros detalles como el límite, establecido en un valor no predeterminado.
+- Las Trust lines para los tokens que estaban en el pool del AMM.
+
+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. 
+
+No hay reembolso o incentivo para eliminar un AMM vacío.
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md

@@ -0,0 +1,74 @@
+---
+html: decentralized-exchange.html
+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í.
+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).
+
+**Atención**: Cualquiera puede [emitir un token](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) con el código de moneda o símbolo de ticker que desee y venderlo en el exchange descentralizado. Siempre realiza una debida diligencia antes de comprar un token y presta atención al emisor. De lo contrario, podrías entregar algo de valor y recibir tokens sin valor a cambio.
+
+## Estructura
+
+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.
+
+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).
+
+Las Ofertas pueden cancelarse manual o automáticamente después de ser colocadas. Para obtener detalles sobre esto y otras propiedades de las Ofertas, consulta [Ofertas](offers.md).
+
+Al comerciar con dos tokens, el [puente automático](autobridging.md) mejora las tasas de cambio y la liquidez al intercambiar automáticamente token por XRP y XRP por token cuando hacerlo es más barato que intercambiar directamente token por token.
+
+### 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.")
+
+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.
+
+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:
+
+Debido a que los intercambios se ejecutan solo cada vez que se cierra un nuevo ledger (aproximadamente cada 3-5 segundos), el XRP Ledger no es adecuado para el [trading de alta frecuencia](https://en.wikipedia.org/wiki/High-frequency_trading). El orden en el que las transacciones se ejecutan dentro de un ledger está diseñado para ser impredecible, para desalentar el [front-running](https://en.wikipedia.org/wiki/Front_running).
+
+El XRP Ledger no representa nativamente conceptos como órdenes de mercado, órdenes de stop o trading con apalancamiento. Algunos de estos pueden ser posibles con el uso creativo de tokens personalizados y propiedades de Oferta.
+
+Como sistema descentralizado, el XRP Ledger no tiene información sobre las personas y organizaciones reales detrás de las [cuentas](../../accounts/index.md) involucradas en el trading. El Ledger en sí no puede implementar restricciones sobre quién puede o no puede participar en el trading, y los usuarios y emisores deben tener cuidado de seguir todas las leyes relevantes para regular el trading de tokens que representan varios tipos de activos subyacentes. Funciones como [congelamientos](../fungible-tokens/freezes.md) y [trust lines autorizadas](../fungible-tokens/authorized-trust-lines.md) están destinadas a ayudar a los emisores a cumplir con las leyes y regulaciones relevantes.
+
+## 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.
+- **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.
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
+
+
+{% child-pages /%}

@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md

@@ -0,0 +1,114 @@
+---
+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.
+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).)
+
+- Para crear una Oferta, envía una [transacción OfferCreate][].
+- Las Ofertas que no se completan totalmente inmediatamente se convierten en [objetos Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md) en los datos del ledger. Ofertas posteriores o Pagos pueden consumir el objeto Oferta desde el ledger.
+- [Pagos entre divisas](../../payment-types/cross-currency-payments.md) consumen Ofertas para proveer liquidez, nunca crean objetos de Oferta en el ledger.
+
+## Ciclo de vida para una Oferta
+
+Una [transacción OfferCreate][] es una instrucción para realizar un intercambio, ya sea entre dos tokens, o un token y XRP. Cada transacción de este tipo contiene una cantidad de compra (`TakerPays`) y una cantidad de venta (`TakerGets`). Cuando se procesa la transacción, consume automáticamente Ofertas coincidentes o cruzadas en la medida de lo posible. Si eso no llena completamente la nueva Oferta, entonces el resto se convierte en un objeto de Oferta en el ledger.
+
+El objeto de Oferta espera en el ledger hasta que otras Ofertas o pagos entre divisas lo consumen completamente. La cuenta que colocó la Oferta se llama el _propietario_ de la Oferta. Puedes cancelar tus propias Ofertas en cualquier momento, usando la [transacción OfferCancel][] dedicada, o como opción de la [transacción OfferCreate][].
+
+Mientras tengas una Oferta en el ledger, se aparta parte de tu XRP hacia la [reserva de propietario](../../accounts/reserves.md). Cuando se elimina la Oferta, por cualquier motivo, ese XRP se libera nuevamente.
+
+### Variaciones
+
+- **Compra vs. Venta**: Por defecto, las Ofertas son Ofertas de "compra" y se consideran completamente llenas cuando has adquirido la cantidad total de "compra" (`TakerPays`). (Puedes gastar menos de lo esperado mientras recibes la cantidad especificada.) En contraste, una Oferta de "venta" solo se considera completamente llena cuando has gastado la cantidad total de "venta" (`TakerGets`). (Puedes recibir más de lo esperado mientras gastas la cantidad especificada.) Esto solo es relevante si la Oferta se ejecuta _inicialmente_ a un tipo de cambio mejor que el solicitado: después de que la Oferta se coloca en el ledger, solo se ejecuta _exactamente_ al tipo de cambio solicitado.
+- Una Oferta **Inmediata o Cancelar** no se coloca en el ledger, por lo que solo intercambia hasta la cantidad que coincide con Ofertas existentes en el momento en que se procesa la transacción.
+- 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:
+
+**Para vender un token,** debes:
+
+- Tener una cantidad positiva de ese token, _o_
+- Ser el emisor del token.
+
+Sin embargo, no necesitas tener la cantidad completa especificada en la Oferta. Colocar una Oferta no bloquea tus fondos, por lo que puedes colocar múltiples Ofertas para vender los mismos tokens (o XRP), o colocar una Oferta y esperar obtener suficientes tokens o XRP para financiarla completamente más adelante.
+
+**Para vender XRP**, debes tener suficiente XRP para cumplir con todos los [requisitos de reserva](../../accounts/reserves.md), incluida la reserva para que el objeto de Oferta se coloque en el ledger y para la trust line para mantener el token que estás comprando. Mientras tengas XRP restante después de apartar la cantidad de reserva, puedes colocar la Oferta.
+
+Cuando otra Oferta coincide con la tuya, ambas Ofertas se ejecutan en la medida en que los fondos de sus propietarios lo permitan en ese momento. Si hay Ofertas coincidentes y te quedas sin fondos antes de que la tuya se finalice por completo, el resto de tu Oferta se cancela. Una Oferta no puede hacer que tu saldo de un token sea negativo, a menos que seas el emisor de ese token. (Si eres el emisor, puedes usar Ofertas para emitir nuevos tokens hasta el monto total especificado en tus Ofertas; los tokens que emites se representan como saldos negativos desde tu perspectiva.)
+
+Si colocas una Oferta que cruza alguna de tus propias Ofertas que existen en el ledger, las Ofertas antiguas cruzadas se cancelan automáticamente independientemente de las cantidades involucradas.
+
+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.
+- 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.
+- 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.
+- 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:
+
+- Una Oferta coincidente o [Pago entre divisas](../../payment-types/cross-currency-payments.md) que consuman completamente la Oferta.
+- 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.
+
+### Seguimiento de ofertas no financiadas
+
+Seguir el estado de financiación de todas las Ofertas puede ser computacionalmente exigente. En particular, las direcciones que están operando activamente pueden tener un gran número de Ofertas abiertas. Un solo balance puede afectar el estado de financiación de muchas Ofertas. Debido a esto, el XRP Ledger no encuentra y elimina _proactivamente_ Ofertas no financiadas o expiradas.
+
+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.
+
+Sin embargo, mantener tokens aún requiere una trust line con el emisor. Cuando una Oferta se consume, automáticamente crea cualquier trust line necesaria, estableciendo sus límites en 0. Debido a que [las trust lines aumentan la reserva que una cuenta debe mantener](../../accounts/reserves.md), cualquier Oferta que requiera una nueva trust line también requiere que la dirección tenga suficiente XRP para cumplir con la reserva de esa trust line.
+
+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.
+
+
+## Caducidad de la oferta
+
+Cuando colocas una Oferta, puedes opcionalmente añadirle un tiempo de caducidad. Por defecto, las Ofertas no caducan. No puedes crear una nueva Oferta que ya esté caducada.
+
+Los tiempos de caducidad se especifican hasta el segundo, pero el momento exacto en el que una Oferta caduca en el mundo real es menos preciso. Una Oferta caduca si tiene una hora de caducidad que es _anterior o igual al_ momento de cierre del ledger anterior. De lo contrario, la Oferta aún puede ejecutarse, incluso si el momento real es posterior a la caducidad de la Oferta. En otras palabras, una Oferta sigue "activa" si su hora de caducidad es posterior al momento de cierre del último ledger validado, independientemente de lo que diga tu reloj.
+
+Esto es una consecuencia de cómo la red alcanza un acuerdo. Para que toda la red peer-to-peer alcance un consenso, todos los servidores deben estar de acuerdo en qué Ofertas han caducado al ejecutar transacciones. Los servidores individuales pueden tener pequeñas diferencias en su configuración interna de reloj, por lo que podrían no llegar a las mismas conclusiones sobre qué Ofertas han caducado si cada uno usara el tiempo "actual". El momento de cierre de un ledger no se conoce hasta después de que las transacciones en ese ledger se hayan ejecutado, por lo que los servidores utilizan el momento oficial de cierre del ledger _anterior_ en su lugar. Los [tiempos de cierre de los ledgers se redondean](../../ledgers/ledger-close-times.md), lo que aumenta aún más la diferencia potencial entre el tiempo real y el tiempo utilizado para determinar si una Oferta ha caducado.
+
+**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)
+- **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)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md

@@ -0,0 +1,28 @@
+---
+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.
+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.
+
+El valor de `TickSize` trunca la cantidad de _dígitos significativos_ en la tasa de cambio de una oferta cuando se coloca en un libro de órdenes. Los emisores pueden establecer `TickSize` como un número entero de `3` a `15` usando una [transacción AccountSet][]. La tasa de cambio se representa como dígitos significativos y un exponente; el `TickSize` no afecta al exponente. Esto permite que el XRP Ledger represente tasas de cambio entre activos que varían considerablemente en valor (por ejemplo, una moneda altamente inflada en comparación con un activo raro). Cuanto menor sea el `TickSize` que establezca un emisor, mayor será el incremento que los traders deben ofrecer para considerarse una tasa de cambio más alta que las Ofertas existentes.
+
+El `TickSize` no afecta a la parte de una Oferta que se puede ejecutar inmediatamente. (Por esa razón, las transacciones OfferCreate con `tfImmediateOrCancel` no se ven afectadas por los valores de `TickSize`.) Si la Oferta no puede ejecutarse completamente, el motor de procesamiento de transacciones calcula la tasa de cambio y la trunca en base a `TickSize`. Luego, el motor redondea la cantidad restante de la Oferta desde el lado "menos importante" para que coincida con la tasa de cambio truncada. Para una transacción OfferCreate predeterminada (una Oferta de "compra"), la cantidad de `TakerPays` (la cantidad que se compra) se redondea. Si se activa la bandera `tfSell` (una Oferta de "venta"), la cantidad de `TakerGets` (la cantidad que se vende) se redondea.
+
+Cuando un emisor habilita, deshabilita o cambia el `TickSize`, las Ofertas que se colocaron bajo la configuración anterior no se ven afectadas.
+
+## Ver también
+
+- [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][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@l10n/es-ES/docs/introduction/crypto-wallets.md

@@ -0,0 +1,49 @@
+---
+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.
+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.
+
+Una cartera con custodia significa que un tercero tiene tus fondos, normalmente en una cuenta que ellos manejan en el XRP Ledger. Una cartera con custodia puede considerarse como un banco, donde confias que otra entidad mantenga tu dinero seguro. Muchos exchanges centralizados ofrecen carteras con custodia, por lo que cuando creas una cuenta con ellos y usas su app, técnicamente no tienes una cuenta en el libro contable (ledger).
+
+Para los pagos del día a día, esto puede ser preferible, ya que este tipo de carteras son fáciles de usar: si te olvidas de tu contraseña, puedes resetearla. Además, si no tienes una cuenta propia en el XRP Ledger, el requisito de tener una reserva en la cuenta no te aplica. El custodio actua como intermediario ante cualquier problema que encuentres en el XRP Ledger, y puede ofrecerte asistencia si no estás seguro de como hacer algo.
+
+![Carteras con custodia vs carteras sin custodia](/docs/img/introduction15-custodial-non-custodial.png)
+
+Una cartera sin custodia, como [Xaman](https://Xaman.app/), es aquella donde tienes las claves secretas (secret keys) de tu cuenta. Esto significa que eres el último reponsable de la administración de la seguridad de tu cuenta.
+
+**Atención:** Si pierdes tus claves, perderás el acceso a tu cuenta del XRP Ledger y no hay opciones de recupereación.
+
+Las carteras sin custodia te permiten tener más libertad. Como estás interactuando directamente con el XRP LEdger, puedes manejar cualquier tipo de transacción que tu quieras sin que nadie restrinja tus opciones. Si el libro contable (ledger) lo permite, lo puedes hacer. Las carteras sin custodia no requieren confiar tu dinero a una institución, lo que permite alejarte de los factores del mercado fuera de tu control.
+
+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.
+
+Las carteras de hardware son dispositivos físicos que almacenan tus claves privadas/secretas. El beneficio principal de usar carteras de hardware es que puedes proteger tu información desconectándola de Internet cuando no se esté usando; Las carteras de hardware aíslan totalmente sus claves de ordenadores y teléfonos inteligentes más faciles de hackear.
+
+![Carteras de Hardware vs. Software](/docs/img/introduction16-hardware-software.png)
+
+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)

@l10n/es-ES/docs/introduction/index.md

@@ -0,0 +1,12 @@
+---
+html: introduction.html
+parent: docs.html
+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. 
+
+{% child-pages /%}

@l10n/es-ES/docs/introduction/software-ecosystem.md

@@ -0,0 +1,66 @@
+---
+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.
+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.
+![El ecosistema XRPL](/docs/img/ecosystem-apps-and-services.svg)
+
+## 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.
+
+- [_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.
+
+- [_Middleware_](#middleware) proporciona acceso indirecto a los datos del XRP Ledger. Las aplicaciones en esta capa suelen tener su propio almacenamiento y procesamiento de datos.
+
+- [_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.
+
+![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.
+
+
+### 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. 
+
+![Librerías cliente](/docs/img/ecosystem-client-libraries.svg)
+
+Una característica prinicpal de la mayoría de las librerías cliente es la firma de transacciones localmente, así los usuarios no tienen que enviar sus claves privadas a través de la red.
+
+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.
+
+![Middleware](/docs/img/ecosystem-middleware.svg)
+
+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.
+
+![Apps y servicios](/docs/img/ecosystem-apps-and-services.svg)
+
+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" /%}

@l10n/es-ES/docs/introduction/transactions-and-requests.md

@@ -0,0 +1,115 @@
+---
+html: txn-and-requests.html
+parent: intro-to-xrpl.html
+seo:
+    description: Todas las interacciones con el ledger son transacciones o solicitudes.
+labels:
+  - Blockchain
+---
+
+## Transacciones y solicitudes
+
+La mayoría de interacciones con el XRP Ledger implican enviar una transacción que realiza cambios en el ledger o enviar una solicitud de información al ledger. También puedes subscribirte para monitorear constantemente notificaciones de interés.
+
+## ¿Cómo funcionan las transacciones?
+
+Utiliza las transacciones para realizar cambios en el ledger, como transferir XRP y otros tokens entre cuentas; acuñar (minting) y quemar (burn) NFTs; y crear, aceptar y cancelar ofertas. Para ejecutar una transacción, envías un comando al XRP Ledger y esperas la confirmación de que la transacción se ha completado. El formato de sintaxis del comando es el mismo para cada transacción.
+
+- 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.
+
+- 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.
+
+Aquí hay un ejemplo de transacción en formato JSON. Esta transacción transfiere 1 XRP de la cuenta _rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn_ a la cuenta destino _ra5nK24KXen9AHvsdFTKHSANinZseWnPcX_.
+
+```json
+{
+  "TransactionType": "Payment",
+  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "Amount": "1000000",
+  "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
+}
+```
+
+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. 
+
+![Transacciones propuestas](/docs/img/introduction17-gather-txns.png)
+
+Cuando el 80% de los validadores aprueban un conjunto actual de transacciones propuestas, se registran como parte del ledger permanente. Los servidores rippled devuelven los resultados de la transacción que enviaste.
+
+Para más información sobre Transacciones, ver [Transacciones](../concepts/transactions/index.md).
+
+## ¿Cómo funcionan las solicitudes?
+
+Las solicitudes son utilizadas para obtener información del ledger, pero no realizan cambios en el ledger. La información está disponible para cualquiera que quiera consultarla, por lo que no hay necesidad de iniciar sesión con la información de tu cuenta.
+
+Los campos que envías pueden variar según el tipo de información que solicitas. Normalmente tienen varios campos opcionales, pero solo unos pocos son campos obligatorios.
+
+Cuando envías tu solicitud, puede ser procesada por un servidor rippled o por un servidor Clio, un servidor dedicado para responder solicitudes.
+
+![Servidor Clio](/docs/img/introduction19-clio.png)
+
+Los servidores Clio quitan parte de la carga a los servidores rippled en el XRPL para mejorar la velocidad de procesamiento y la confiabilidad.
+
+Esto es un ejemplo de solicitud en formato JSON. Esta solicitud obtiene la información de la cuenta actual para el número de cuenta que facilitas.
+
+```json
+{
+  "command": "account_info",
+  "account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn"
+}
+```
+
+La solicitud devuelve una gran cantidad de información. Aquí hay un ejemplo de respuesta para la información de la cuenta solicitada en formato JSON.
+
+```json
+{
+    "result": {
+        "account_data": {
+            "Account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
+            "Balance": "999999999960",
+            "Flags": 8388608,
+            "LedgerEntryType": "AccountRoot",
+            "OwnerCount": 0,
+            "PreviousTxnID": "4294BEBE5B569A18C0A2702387C9B1E7146DC3A5850C1E87204951C6FDAA4C42",
+            "PreviousTxnLgrSeq": 3,
+            "Sequence": 6,
+            "index": "92FA6A9FC8EA6018D5D16532D7795C91BFB0831355BDFDA177E86C8BF997985F"
+        },
+        "ledger_current_index": 4,
+        "queue_data": {
+            "auth_change_queued": true,
+            "highest_sequence": 10,
+            "lowest_sequence": 6,
+            "max_spend_drops_total": "500",
+            "transactions": [
+                {
+                    "auth_change": false,
+                    "fee": "100",
+                    "fee_level": "2560",
+                    "max_spend_drops": "100",
+                    "seq": 6
+                },
+                ... (recortado por la longitud) ...
+                {
+                    "LastLedgerSequence": 10,
+                    "auth_change": true,
+                    "fee": "100",
+                    "fee_level": "2560",
+                    "max_spend_drops": "100",
+                    "seq": 10
+                }
+            ],
+            "txn_count": 5
+        },
+        "status": "success",
+        "validated": false
+    }
+}
+```
+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)

@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md

@@ -0,0 +1,70 @@
+---
+html: what-is-the-xrp-ledger.html
+parent: introduction.html
+seo:
+    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.
+
+![Un bloque de datos](/docs/img/introduction2-data-block.png)
+
+Un grupo de nodos validadores confiables llega a un consenso de que los datos son válidos.
+
+![Nodos validadores](/docs/img/introduction3-validators.png)
+
+El bloque se identifica de forma única con un número hash criptográfico, muy elaborado, complejo, generado por un ordenador, que tiene 64 caracteres hexadecimales.
+
+![Hash criptográfico](/docs/img/introduction4-hash.png)
+
+El bloque también se identifica con una marca de tiempo (timestamp) con su hora de creación.
+
+![Timestamp](/docs/img/introduction5-time-stamp.png)
+
+Cada nodo validador obtiene su propia copia del bloque de datos. No existe una única autoridad central. Todas las copias son igualmente válidas.
+
+![Validadores con copias válidas](/docs/img/introduction6-valid-copies.png)
+
+Cada bloque contiene un puntero hash como enlace al bloque anterior. También tiene una marca de tiempo (timestamp), nuevos datos, y su propio número hash único.
+
+![Puntero hash](/docs/img/introduction7-two-blocks.png)
+
+Utilizando esta estructura, cada bloque tiene una posición clara en la cadena, enlazandose al bloque de datos anterior. Esto crea una cadena de bloques inmutable. Siempre puedes verificar toda la información actual en la cadena rastreando los bloques anteriores.
+
+![Tres bloques de datos](/docs/img/introduction8-3-blocks.png)
+
+Por diseño, las blockchains son resistentes a la modificación de datos. Cada nodo del libro contable (ledger) obtiene una copia exacta de la blockchain.
+
+![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. 
+
+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).
+
+### ¿Cómo funciona el proceso de consenso federado?
+
+La mayoría de los servidores rippled en XRPL monitorean o proponen transacciones. Un importante subconjunto de servidores se ejecutan como validadores. Estos servidores confiables acumulan listas de nuevas transacciones en una nueva posible instancia del libro contable (ledger) (un nuevo bloque en la blokchain).
+
+![Recopilación de transacciones](/docs/img/introduction17-gather-txns.png)
+
+Los validadores comparten sus listas con el resto de validadores. Los validadores incorporan los cambios propuetos entre sí y distribuyen una nueva versión de la propuesta del libro contable (ledger).
+
+![80% de consenso](/docs/img/introduction18-80-percent-consensus.png)
+
+Cuando el 80% de los validadores acuerdan un conjunto de transacciones, crean una nueva instancia del libro contable (ledger) al final de la cadena y empiezan el proceso otra vez. Este proceso de consenso tarda entre 4 y 6 segundos. Puedes monitorizar cómo se crean las instancias del libro contable (ledger) en tiempo real visitando [https://livenet.xrpl.org/](https://livenet.xrpl.org/).
+
+### ¿Qué redes están disponibles?
+
+El XRPL está abierto a cualquiera que quiera configurar su propia instancia de servidor rippled y conectarse. El nodo puede monitorizar la red, realizar transacciones, o convertirse en validador. La red XRPL activa se denomina normalmente como _Mainnet_.
+
+Para los desarrolladores o nuevos usuarios que quieran probar las características de XRPL sin invertir sus propios fondos, existen dos entornos para desarrolladores, _Testnet_ y _Devnet_. Los usuarios pueden crear una cuenta con 1.000 XRP (falsos) y conectarse a cualquiera de los entornos para interactuar con el XRPL.
+
+Siguiente: [¿Qué es XRP?](what-is-xrp.md)

@l10n/es-ES/docs/introduction/what-is-xrp.md

@@ -0,0 +1,75 @@
+---
+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.
+labels:
+  - Blockchain
+---
+# ¿Qué es XRP?
+
+XRP es la criptomoneda respaldada por el XRP Ledger.
+
+## ¿Qué es una criptomoneda?
+
+Una criptomoneda es una moneda virtual o digital que está protegida por criptografía y que es rastreada usando la blockchain. La seguridad y la integridad de las criptomonedas hace casi imposible falsificarlas o generar un doble gasto.
+
+![XRP en la blockchain](/docs/img/introduction10-xrp-on-chain.png)
+
+Critopmonedas, monedas digitales, y activos digitales, todos caen en la misma categoría general. Las criptomonedas son:
+
+- nativas digitalmente (quiere decir que se crearon para internet)
+- programables
+- rápidas de transferir a un coste bajo
+- abiertas y trasparentes
+- no están restringidas por fronteras o gobiernos (por lo que no necesita cuentas nostro que tengan fondos en otro país)
+- no están sujetas a falsificación
+- no requieren una cuenta bancaria o infraestructura para liquidar los pagos.
+
+![Ventajas de las criptomonedas](/docs/img/introduction11-all-the-things.png)
+
+Las criptomonedas son _tokens fungibles_. _Fungible_ significa que tu puedes reemplazar un token por otro token de mismo valor. El franqueo es un ejemplo de un token fungible: si cuesta 50 céntimos enviar una carta, puedes utilizar 2 sellos de 25 centimos o 5 de 10 centimos para el envío, porque el franqueo de sellos es fungible (consistente en valor relativo e intercambiable).
+
+Las criptomonedas además son descentralizadas. No hay una entidad central que dobierna la moneda. Una vez que la transacción está en la blockchain no se puede cambiar. Es dificil censurar una criptomoneda: mientras que el sistema sea los suficientemente descentralizado, nadie puede dar marcha atrás transacciones, congelar balances, o impedir que alguien pueda utilizar un activo digital descentralizado. Las reglas no cambian sin una coordinación significativa entre todos los participantes.
+
+Las criptomonedas son atractivas para inversores y desarrolladores porque ninguna entidad por sí sola puede "tirar del cable" y hacerlas desaparecer.
+
+## ¿Pero por qué es valioso?
+
+![Ventajas de las criptomonedas](/docs/img/introduction12-diamond.png)
+
+Puede parecer raro que las criptomonedas se basen únicamente en datos informáticos, y no en ninguna tipo de bien tangible como un metal precioso. Tradicionalmente, las monedas se han basado en ganado, conchas de mar, metales raros, piedras u otro objeto físico. Pero estos elementos tienen valor solo porque hubo un acuerdo entre personas de una cultura.
+
+Aunque puede parecer mucho más seguro tener algo "real en la mano, muchas personas no distinguirán el oro real del falso, o la circonita cúbica de un diamante auténtico. El papel moneda puede ser falsificado. Puedes olvidar que tienes un billete de 10$ en tu bolsillo y arruinarlo al lavarlo. Es costoso almacenar y transportar de manera segura artículos valiosos para pagar.
+
+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.
+
+![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                   |
+|:---------------------------------------|:------------------------------------|
+| !["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)

@l10n/es-ES/translations.yaml

@@ -0,0 +1,306 @@
+navbar.about: Acerca de
+navbar.docs: Docs
+navbar.resources: Recursos
+navbar.community: Comunidad
+footer.about: Acerca de
+footer.docs: Docs
+footer.resources: Recursos
+footer.community: Comunidad
+sidebar.docs: Docs
+sidebar.docs.tutorials: Tutoriales
+sidebar.docs.references: Referencias
+sidebars.resources: Recursos
+sidebar.resources.codesamples: Ejemplos de código
+topnav.docs.title: Documentación
+topnav.docs.description: Sumérgete en la tecnología XRP Ledger y empieza a integrar
+topnav.resources.current-status: Estado actual
+topnav.resources.explorer: Explorador del ledger
+topnav.community.title: Contribuye a la comunidad XRPL
+topnav.community.description: Únete a la conversación
+Open Source.: Código abierto
+Jump to top of page: Saltar arriba
+Edit page: Editar página
+Search: Buscar
+Search site...: Buscar sitio...
+Search for articles, training, and code samples...: Buscar artículos, entrenamientos, ejemplos de código...
+Become an XRP Ledger Campus Ambassador: Conviertete en un Embajador de Campus XRP Ledger
+Join the Student Cohort: Únete al grupo de estudiantes
+XRPL Campus Ambassadors: Embajadores de Campus XRPL
+Current Students: Estudiantes actuales
+Why become an XRPL Campus Ambassador?: ¿Por qué convertirse en un Embajador de Campus?
+Benefits: Beneficios
+Join a global cohort of students empowering others to build on the XRPL.: Únete al grupo global de estudiantes animando a otros a construir en el XRPL.
+Exclusive Opportunities: Oportunidades exclusivasa
+Education: Educación
+Tutorials and workshops from leading XRPL and blockchain developers: Tutoriales y workshops de desarrolladores líderes de la blockchain XRPL
+Swag: Estilo
+New XRPL swag for Ambassadors and swag to share with other students: Nuevo estilo XRPL para embajadores y estilo para compartir con otros estudiantes
+Mentorship: Mentorías
+Career Acceleration: Aceleración de tu carrera
+Stipend: Paga
+Should You Apply?: ¿Debería aplicar?
+Eligibility for XRPL Campus Ambassadors: Requisitos para embajadores de campus XRPL
+A Leader: Un lider
+Active: Activo
+Curious: Curioso
+Eager to learn more about technical blockchain topics and the XRPL: Con ganas de aprender más sobre los temas técnicos de blockchain y XRPL
+Passionate: Apasionado
+Creative: Creativo
+Ability to think outside the box to grow the XRPL student community: Habilidad para pensar de forma distinta para hacer crecer la comunidad de estudiantes del XRPL
+Process to become a Campus Ambassador: Proceso para convertirse en embajador de campus
+How it Works: Cómo funciona
+Apply now to become an XRPL Campus Ambassador.: Aplica ahora para convertirte en embajador de campus XRPL
+Apply: Aplicar
+Submit an application to be considered for the Campus Ambassador program.: Envía una aplicación para ser considerado por el programa de embajador del campus.
+Interview: Entrevista
+Join: Únete
+Learn: Aprender
+Apply for Fall 2023: Aplicar para otoño de 2023
+Join a global cohort of Student Ambassadors: Únete al grupo global de estudiantes embajadores
+Global Community: Comunidad global
+Stay connected to the XRPL Campus Ambassadors: Mantente en contacto con embajadores de campus XRPL
+Connect: Conecta
+MeetUp: Quedadas
+Attend an XRPL Meetup in your local area: Acude a quedadas XRPL en tu zona
+Dev.to Blog: Blog Dev.to
+Read more about the activity of the XRPL Ambassadors: Lee más sobre la actividad de embajadores XRPL
+Join the conversation on the XRPL Developer Discord: Únete a la conversación del Discord de desarrolladores XRPL
+Start Building with Example Code: Empiza a construir con ejemplos de código
+Code Samples: Ejemplos de código
+Browse sample code for building common use cases on the XRP Ledger: Navega entre los códigos de ejemplo para construir casos de uso comunes en el XRP Ledger
+Contribute Code Samples: Contribuye con ejemplos de código
+Help the XRPL community by submitting your<br> own code samples: Ayuda a la comunidad XRPL añadiendo tus propios ejemplos de código
+The XRPL Community: La comunidad XRPL
+Find the community on the platforms below: Encuentra a la comunidad en la plataforma de abajo.
+Join the Conversation: Entra en la conversación
+Run an XRP Ledger network node: Ejecuta un nodo de la red XRP Ledger
+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
+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
+Submit Your Projects: Envía tus proyectos
+Read the Blog: Leer el blog
+Check out global events across the XRPL community: Consulta eventos globales alrededor de la comunidad XRPL
+XRPL Events: Eventos XRPL
+View All Events: Ver todos los eventos
+Discover your next career opportunity in the XRPL community: Descrube tu próxima oportunidad de carrera en la comunidad XRPL
+Review guidelines for using XRPL design assets: Revisa las guías para usar los activos de diseño XRPL
+XRPL Assets: Activos XRPL
+Download the PDF and Assets: Descargar el PDF y los activos
+A community-driven resource for all things XRPL.org: XRPとXRP Un recurso para todas las cosas dirigido por la comunidad XRPL.org
+Contribute to XRPL.org: Contribuye con XRPL.org
+Read Contributor Guidelines: Leer la guía de contribución
+Dev Tools: Herramientas de desarrollo
+Explorers: Exploradores
+API Access: Acceso a APIs
+Other: Otro
+Have an Idea For a Tool?: ¿Tienes una idea para una herramienta?
+Open a pull Request: Abre un pull request
+Full documentation index: Índice completo de la documentación
+See Everything: Ver todo
+XRP Ledger Developer Resources: Recursos para desarrolladores XRPL
+Documentation: Documentación
+rippled API Reference: API rippled de referencia
+XRP Faucet: Grifo XRP
+Getting Started with Python: Comienza con Python
+Websocket API Tool: Herramienta API Websocket
+XRP Ledger Explorer: Explorador XRP Ledger
+Advanced Payment Features: Características de pago avanzadas
+Governance and the Amendment Process: Gobierno y proceso de enmiendas
+Federated Sidechains: Sidechains federadas
+On-Chain Finance: Finanzas On-Chain
+Trade on the decentralized exchange: Comercia en el exchange descentralizado
+Make payments: Haz pagos
+Use specialized payment types: Utiliza tipos de pago especializados
+Tokens: Tokens
+Non-fungible Tokens: Tokens No Fungibles
+Issue a stablecoin: Emitir una stablecoin
+Assign an authorized minter: Asignar un acuñador autorizado
+Payments: Pagos
+Peer to peer payments: Pagos Peer to peer
+Cross-currency payments: Pagos entre divisas
+Escrows: Escrows
+Intro to XRP Ledger: Intro to XRP Ledger
+Accounts: Cuentas
+Decentralized Exchange: Exchange descentralizado
+Tokenization: Tokenización
+Faucets: Grifo XRP
+Get credentials and test-XRP for XRP Ledger Testnet or Devnet.: Consigue credenciales y XRP de prueba para la Testnet o Devnet de XRP Ledger
+WebSocket Tool: Herramienta Websocket
+Send sample requests and get responses from the rippled API.: Envía peticiones de ejemplo y recibe respuestas desde la API rippled
+Transaction Sender: Enviador de transacciones
+Concepts: Conceptos
+Read the Docs: Leer los documentos
+Tutorials: Tutoriales
+Get step-by-step guidance to perform common tasks with the XRP Ledger.: Consigue guías paso a paso para tareas comunes con el XRP Ledger
+View Tutorials: Ver tutoriales
+References: Referencias
+View References: Ver referencias
+Use Cases: Casos de uso
+Getting Started: Empezar
+Quickstart to XRP Ledger: Inicio rápido de XRP Ledger
+An introduction to fundamental aspects of the XRP Ledger.: Una introducción a los aspectos fundamentales del XRP Ledger
+Get Started: Empieza
+Watch Full Series: Ver serie completa
+Interact with the XRP Ledger in a language of your choice: Interactua con el XRP Ledger en un lenguaje de tu elección
+Explore SDKs: Explora SDKs
+Intermediate Learning Sources: Fuentes de aprendizaje intermedio
+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 
+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
+The XRPL Developer Summit: El encuentro de desarrolladores XRPL
+Save the Date: Guarda la fecha
+Upcoming Events: Eventos próximos
+Explore past community-hosted events: Explora eventos pasados organizados por la comunidad
+Past Events: Eventos anteriores
+Sorry, this page is not available in your language.: Lo siento, esta página no está disponible en tu idioma
+XRPL Developer Funding Programs: Programas de financiación de desarrolladores XRPL
+Project Resources: Recursos para proyectos
+Explore funding opportunities for developers and teams: Explora oportunidades de financiación para desarrolladores y equipos
+Funding Overview: Vistazo de financiaciones
+XRPL Hackathons: Hackatones XRPL
+Join an Event: Únete a un evento
+See Upcoming Events: Consulta eventos próximos
+Best for: Lo mejor para
+Software developers and teams building directly on the XRP Ledger: Desarrolladores y equipos de software construyen directamente en el XRP Ledger
+Required: Necesario
+Some coding experience: Algo de experiencia
+Level: Nivel
+XRPL beginner to advanced developers: Desarrolladores de iniciados a avanzados
+Funding Levels: Niveles de financiación
+Prize money and awards: Dinero y premios
+Fund Your Project: Financia tu proyecto
+Past awardees include: Los premios pasados incluyen
+Visit XRPL Grants: Visita las financiaciones de XRPL
+XRPL intermediate to advanced developers: Desarrolladores de nivel intermedio a avanzados
+$10,000 - $200,000: 10.000$ ~ 200.000$
+XRPL Accelerator: Acelerador XRPL
+Advance your project: Avanza tu proyecto
+View XRPL Accelerator: Consulta el acelerador XRPL
+$50,000 (grant) + pitch for venture funding: 50.000$(premio) más pitch para venture funding
+Provide a Better Alternative to Bitcoin: Ofrece una mejor alternativa a Bitcoin
+XRPL's Origin: Origen de XRPL
+XRPL Launches its Native Currency, XRP: XRPL lanza su divisa nativa, XRP
+OpenCoin Rebranded to Ripple Labs: OpenCoin renombrada como Ripple Labs
+XRPL Foundation Launched: Se lanza XRPL Foundation
+The Blockchain<br class=\until-sm\/> Built for Business: La blockchain<br class=\until-sm\/> construida para negocios
+XRPL | XRP Ledger:
+Start Building: Empieza a construir
+Why developers choose the XRP Ledger: ¿Por qué los desarrolladores eligen el XRP Ledger?
+Public and Decentralized: Público y descentralizado
+Open source, open to anyone to build on, maintained by the community: Código abierto, abierto a cualquiera que quiera construir, mantenido por la comunidad
+Streamlined Development: Desarrollo simplificado
+Intentional innovations, tools and documentation reduce time to market: Las innovaciones, herramientas y documentación intencionales reducen el tiempo de comercialización
+High Performance: Alto rendimiento
+Thousands of transactions settled in seconds: Miles de transacciones realizadas en segundos
+Low Cost: Bajo coste
+Motivated Community: Comunidad motivada
+Proven Reliability: Fiabilidad probada
+Powerful Features: Funcionalidades potentes
+Cross-Currency Payments: Pagos entre divisas
+Payment <br class='until-sm'/>Channels: Canales de<br class='until-sm'/>Pago
+Batched micropayments with unlimited speed, secured with XRP: Micropagos en lotes con velocidad ilimitada, segurados con XRP
+Multi-Signing: Multi-firma
+Flexible options for custody and security of on-ledger accounts: Opciones flexibles para la custodia y seguridad de cuentas en el ledger
+Choose a path, and bring your project to life on the XRP Ledger: Elige un camino, y haz tu proyecto realidad en el XRP Ledger
+Where to Start: Dónde empezar
+Quickstart: Inicio rápido
+Access everything you need to get started working with the XRPL: Accede a todo lo que necesitas para empezar a trabajar con XRPL
+Guided Tutorials: Tutoriales guiados
+Follow step-by-step guides for frequent tasks: Sigue las guías paso a paso para tareas frecuentes
+XRPL Fundamentals: Fundamentos del XRPL
+Read about the XRPL’s foundational concepts: Lee sobre los conceptos fundamentales del XRPL
+Choose a Language: Elige un idioma
+Get Inspired: Inspírate
+See what your peers have built on the XRPL: Observa lo que otros compañeros han construido en el XRPL
+Our Shared Vision for XRPL’s Future: Nuestra visión compartida del futuro del XRPL
+Preview New Features: Previsualiza nuevas funcionalidades
+In Development: En desarrollo
+Smart Contracts: Smart Contracts
+Enabled: Activado
+Non-Fungible Tokens: Tokens no fungibles
+Join the Community <br class=\until-sm\/> at XRPL.org: Únete a la comunidad<br class=\until-sm\/> en XRPL.org
+Get Involved: Únete
+Today’s Value, Tomorrow’s Vision: El valor de hoy, la visión del mañana
+XRPL Today, XRPL Tomorrow: XRPL hoy, XRPL mañana
+Building for the Future: Construyendo por el futuro
+Consensus protocol is efficient and sustainable: El protocolo de consenso es eficiente y sostenible
+A Sustainable Future: Un futuro sostenible
+What makes the XRPL sustainable?: ¿Qué hace al XRPL sostenible?
+Featured companies & projects running on the XRP Ledger.: Compañías y proyectos destacados en el XRP Ledger
+Sustainable Projects: Proyectos sostenibles
+See More: Ver más
+How can businesses and developers connect and contribute?: ¿Cómo pueden los negocios y desarrolladores conectar y contribuir?
+Join the Community: Únete a la comunidad
+Blog: Blog
+Code: Código
+References and APIs: Referencia y APIs
+Everything You Need to Know: Todo lo que necesitas saber
+XRP Ledger address, transaction ID, or ledger index: Dirección XRP Ledger, ID de transacción, o índice del ledger
+Try an account like <em>rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn</em>.: Prueba una cuenta como <em>rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn</em>
+Get info: Consigue información
+Result: Resultado
+Permalink: Permalink
+Explorer: Explorador
+expand all: Ampliar todo
+collapse all: Reducir todo
+(last 20): (últimos 20)
+expand tx: Ampliar tx
+next 20: Siguientes 20
+prev 20: Previos 20
+Status: Estado
+Not Connected: No conectado
+Transaction History: Historial de transacciones
+Initialize: Inicializar
+Set up the necessary Testnet XRP addresses to send test payments.: Prepara lo necesario para direcciones XRP de Testnet y enviar pagos de prueba
+Destination Address: Dirección de destino
+Send transactions to this XRP Testnet address: Envía transacciones a esta dirección XRP Testnet
+Send Transaction: Envía una transacción
+(loading): (Cargando)
+Send XRP Payment: Envía un pago XRP
+drops of XRP: XRP drops
+Send a <a href=\send-xrp.html\>simple XRP-to-XRP payment</a>.: Envía un <a href=\send-xrp.html\>pago XRP-XRP sencillo</a>.
+(Getting ready to send partial payments): (Preparando para enviar pagos parciales)
+Send Partial Payment: Envía pago parcial
+Create Escrow: Crear un Escrow
+seconds: segundos
+Finish automatically: Finalizar automáticamente
+(Waiting to release Escrow when it's ready): （Esperando a la liberación del Escrow cuando esté listo)
+Create Payment Channel: Crear canal de pago
+Send Issued Currency: Envia divisas emitidas
+Trust for: Confianza para
+Security: Seguridad
+Release Notes: Notas de la versión
+Custody: Custodia
+Infrastructure: Infraestructura 
+Carbon Markets/Sustainability: Mercados de Carbono/Sostenibilidad
+Developer Tooling: Herramientas de desarrollo
+Gaming: Gaming
+Wallet: Cartera
+Ledger City is a crypto real estate game powered by the XRP Ledger.: Ledger City es un juego inmobiliario el XRP Ledger
+Interoperability: Interoperabilidad
+Ripple's CBDC Platform: CBDC Platform de Ripple
+Ripple's On-Demand Liquidity: On-Demand Liquidity de Ripple
+Exchanges: Exchanges
+XRPL Rosetta explores fiat data on XRPL through visualization.: XRPL Rosetta explora datos de dinero fiat en el XRPL a través de la visualización
+XRPL.org's Ledger Explorer is a block explorer of the XRP Ledger.: El explorador de ledgers de XRPL.org es el explorador de bloques para el XRP Ledger
+Xaman is a non custodial wallet with superpower for the XRP Ledger.: Xaman es una cartera sin custodia con superpoderes para el XRP Ledger
+Web Monetization: Monetización web
+Sustainability: Sostenibilidad
+CBDCs: CBDC
+Cancel: Cancelar
+Featured Categories: Categorías destacadas
+Other Categories: Otras categorías
+Proven Powerful for Innovation: Comprobadamente potente para la innovación
+XRPL Use Cases: Casos de uso XRPL
+Building businesses and creating new value: Construyendo negocios y nuevo valor
+XRPL Ecosystem: Ecosistema XRPL

@l10n/ja/CONTRIBUTING.md

@@ -0,0 +1,3 @@
+# コントリビューション
+
+コントリビューションの情報には[「ドキュメントへの貢献」](https://xrpl.org/ja/resources/contribute-documentation/)をご覧ください。

@l10n/ja/about/faq.md

@@ -0,0 +1,155 @@
+---
+seo:
+    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やリップルなどと表記していることがありますが、それは間違いです。
+またXRP Ledgerは**エックスアールピーレジャー**と呼びます。
+
+#### XRP Ledger(XRPL)はRippleが所有するプライベートブロックチェーンですか？
+
+いいえ。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、相互運用サイドチェーンの開発などが現在進行中です。
+
+
+## バリデータ（検証者）とユニークノードリスト
+
+#### トランザクション（取引）のバリデータはどのようなサービスを提供するのですか?
+
+バリデータは、トランザクションがプロトコル要件を満たしていて、結果として「有効」であるかどうかを判断します。バリデータが独自に提供する機能は、順序付けされた単位にトランザクションをグループ化し、二重支払いを防ぐことを目的としてその順序に同意することです。
+
+コンセンサスプロセスの詳細は、[コンセンサス](../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に依存するビジネスには、ネットワークの信頼性と安定性を確保するインセンティブが内在しています。バリデータはまた、このように貢献することでコミュニティからの評価と信頼を得ることができます。
+
+ネットワークに参加するためにXRP Ledgerのサーバを運営する場合やバリデータを運営するための追加コストや手間は最小限です。つまり、ビットコインにおけるマイニング報酬のような追加のインセンティブは必要ありません。Rippleはバリデータを運用するための報酬としてXRP支払うことはしないため、そのようなインセンティブがバリデータの行動を歪めることはありません。
+
+インセンティブがどのようにバリデータの行動を歪めるかの例については、[miner extractable value (MEV)](https://arxiv.org/abs/1904.05234)をご覧ください。
+
+
+#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?
+
+いいえ。トランザクション選択のためにカスタマイズされたバリデータポリシーを金融機関が設定することはできません。バリデータは既存のプロトコルに従う、従わないのいずれかを選択します。ソフトウェアは、プロトコルルールに従わない場合は機能しません。そのため、金融機関が社内の専門知識なしにカスタム実装を求めることは推奨されません。
+
+
+#### ネットワーク内の20%を超えるノードが他の多数ノードと一致しない場合はどうなりますか? レジャー（台帳）の最終バージョンはどのように選択されますか?
+
+通常、あるトランザクションの有効性について係争があった場合、多数派が合意に達するまでそのトランザクションは保留されます。しかしネットワークの20％超が多数派と同じプロトコルルールに従わなかった場合、ネットワークは一時的に停止します。参加者が互いに合意を得たいUNLに基づいてUNLを再設定すれば再開できます。この一時的な処理の遅延は二重支出よりも望ましいでしょう。
+
+レジャーの正式バージョンを決定する過程で、一時的な内部バージョンが複数存在する可能性があります。分散システムでは、すべてのノードが同じ順序でトランザクションを受け取るわけではないため、このような内部バージョンは自然に発生します。ビットコインにおける類似の動作は、2つのブロックがほぼ同時に採掘されたために、2つのサーバがそれぞれ異なる最長チェーンを見ることです。
+
+しかし、レジャーの最新バージョンは常に1つだけであり、他のバージョンは無関係で無害です。
+
+XRP Ledgerのコンセンサスメカニズムが不利な状況でどのように動作するかについては、[攻撃と失敗モードに対するコンセンサスの保護](../docs/concepts/consensus-protocol/consensus-protections.md)をご覧ください。
+
+
+#### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?
+
+いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。
+
+個々のデフォルトUNLの発行者は、推奨リストにいつバリデータを追加したり削除したりするかについて、独自のポリシーを設けています。
+
+推奨事項やベストプラクティスについては、[バリデータとしての`rippled`の実行](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
+
+
+#### デフォルトUNL(dUNL)がネットワークに最も影響力を持つなら、XRPLは中央集権的ではないでしょうか？
+
+バリデータはdUNLや広く使われているUNLを使わないこともできます。誰でもいつでも自由にUNLを作ることができます。
+
+同じネットワーク上で複数のUNLが使われても構いません。各運営者は自分のサーバのUNLをカスタマイズすることもできるし、別の推奨リストに従うこともできます。これらすべてのサーバは同じチェーンを実行し、互いにコンセンサスを得ることができます。
+
+しかし、もしあなたの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ネットワークはオープンネットワークであり、すべての取引はオープンに公開されています。
+
+Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、該当する疑わしい活動をFinCENに報告することにコミットしています。
+
+[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)を行うことから始まります。
+
+このプルリクエストは、自動化された単体テストと統合テスト、そしてプルリクエストが影響するコード領域で重要な専門知識を持つ複数の開発者によりコードレビューが行われます。
+
+プルリクエストが自動テストに合格し、レビュアーの承認を受けると、信頼できる[リポジトリのメンテナ](https://opensource.guide/best-practices/)が次のベータ版に含めるための手続きを行います。
+
+
+#### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?
+
+いいえ、RippleはXRP LedgerまたはXRP Ledgerネットワークを所有も管理もしていません。
+
+Rippleは、コアとなるXRP Ledgerサーバ（[`rippled`](https://github.com/xrplf/rippled)）のリファレンス実装へ貢献し、オープンソースコードベースに貢献しているエンジニアチームを雇用しています。Rippleはまた、利用可能なソフトウェアのプリコンパイル済みバイナリーパッケージを定期的に公開しています。必要に応じて、誰でも自由に[ソースからソフトウェアをダウンロードしてコンパイル](../docs/infrastructure/installation/index.md)できます。
+
+いくつかの団体が推奨バリデータリスト（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)とは異なるコードベースとリポジトリを持っています。

@l10n/ja/community/report-a-scam.md

@@ -0,0 +1,31 @@
+---
+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)
+
+4. 詐欺業者がXRP Ledger上でXRPを他のトークンと交換した場合、そのトークンの発行者に連絡してください。発行者は[詐欺業者のトラストラインをフリーズする](../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md)ことができるかもしれません。
+
+詐欺業者の報告に関する詳細は、[Xrplorer Forensicsのヘルプ](https://xrplorer.com/forensics/help)をご覧ください。
+
+XRP Ledgerコミュニティからのヘルプについては、[XRPChatフォーラム](https://xrpchat.com)を利用することもできます。

@l10n/ja/docs/_snippets/checkcash-prereqs.md

@@ -0,0 +1,9 @@
+Checkを換金するための前提条件は、正確な金額を換金する場合も変動金額を換金する場合も同じです。
+
+- 現在レジャーに記録されているCheckオブジェクトのIDが必要です。
+  - 例えば、以下の例では、あるCheckのIDとして`838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334`を使用していますが、各ステップをご自分で行う際には、異なるIDを使用する必要があります。
+- Checkに記載されている受取人の**アドレス**と**秘密鍵**。このアドレスは、Checkオブジェクトの`Destination`アドレスと一致している必要があります。
+- 発行済み通貨用のCheckの場合は、ご自身（受取人）にイシュアーに対するトラストラインがある必要があります。このトラストライン上のご自身の限度額は、受け取る金額を追加するための残高より十分高くなければなりません。
+  - トラストラインと限度額について詳しくは、[トークン](../concepts/tokens/index.md)および[トラストラインと発行](../concepts/tokens/fungible-tokens/index.md)をご覧ください。
+- [トランザクションに安全に署名できる手段](../concepts/transactions/secure-signing.md)。
+- XRP Ledgerに接続できる[クライアントライブラリ](../references/client-libraries.md)か、それとも[HTTPライブラリ、WebSocketライブラリなど](../tutorials/http-websocket-apis/build-apps/get-started.md)。

@l10n/ja/docs/_snippets/clawback-disclaimer.md

@@ -0,0 +1 @@
+_[Clawback amendment](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0039d-clawback)が必要です。_

@l10n/ja/docs/_snippets/common-links.md

@@ -0,0 +1,320 @@
+[AMM amendment]: /@l10n/ja/resources/known-amendments.md#amm
+[AMMClawback amendment]: /@l10n/ja/resources/known-amendments.md#ammclawback
+[AMMエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/amm.md
+[AMMオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/amm.md
+[AMMBid]: /@l10n/ja/docs/references/protocol/transactions/types/ammbid.md
+[AMMBidトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammbid.md
+[AMMClawbackトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammclawback.md
+[AMMCreate]: /@l10n/ja/docs/references/protocol/transactions/types/ammcreate.md
+[AMMCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammcreate.md
+[AMMDelete]: /@l10n/ja/docs/references/protocol/transactions/types/ammdelete.md
+[AMMDeleteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammdelete.md
+[AMMDeposit]: /@l10n/ja/docs/references/protocol/transactions/types/ammdeposit.md
+[AMMDepositトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammdeposit.md
+[AMMVote]: /@l10n/ja/docs/references/protocol/transactions/types/ammvote.md
+[AMMVoteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammvote.md
+[AMMWithdraw]: /@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
+[AMMWithdrawトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
+[API v1]: /@l10n/ja/docs/references/http-websocket-apis/index.md
+[API v2]: /@l10n/ja/docs/references/http-websocket-apis/index.md
+[AccountDelete]: /@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
+[AccountDeleteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
+[AccountRootエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md
+[AccountRootオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md
+[AccountSet]: /@l10n/ja/docs/references/protocol/transactions/types/accountset.md
+[AccountSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/accountset.md
+[アドレス]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#アドレス
+[Amendmentsエントリ]: /@l10n/ja/docs/concepts/networks-and-servers/amendments.md
+[Amendmentsオブジェクト]: /@l10n/ja/docs/concepts/networks-and-servers/amendments.md
+[Batch amendment]: /@l10n/ja/resources/known-amendments.md#batch
+[Batch]: /@l10n/ja/docs/references/protocol/transactions/types/batch.md
+[Checkエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/check.md
+[Checkオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/check.md
+[CheckCancel]: /@l10n/ja/docs/references/protocol/transactions/types/checkcancel.md
+[CheckCancelトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/checkcancel.md
+[CheckCashMakesTrustLine amendment]: /@l10n/ja/resources/known-amendments.md#checkcashmakestrustline
+[CheckCash]: /@l10n/ja/docs/references/protocol/transactions/types/checkcash.md
+[CheckCashトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/checkcash.md
+[CheckCreate]: /@l10n/ja/docs/references/protocol/transactions/types/checkcreate.md
+[CheckCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/checkcreate.md
+[Checks amendment]: /@l10n/ja/resources/known-amendments.md#checks
+[Clawback amendment]: /@l10n/ja/resources/known-amendments.md#clawback
+[Clawbackトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/clawback.md
+[credentials]: /@l10n/ja/docs/concepts/decentralized-storage/credentials.md
+[Credentials amendment]: /@l10n/ja/resources/known-amendments.md#credentials
+[CredentialCreate]: /@l10n/ja/docs/references/protocol/transactions/types/credentialcreate.md
+[CredentialCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/credentialcreate.md
+[CredentialAccept]: /@l10n/ja/docs/references/protocol/transactions/types/credentialaccept.md
+[CredentialAcceptトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/credentialaccept.md
+[CredentialDelete]: /@l10n/ja/docs/references/protocol/transactions/types/credentialdelete.md
+[CredentialDeleteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/credentialdelete.md
+[Credentialエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/credential.md
+[Crypto-Conditions仕様]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
+[CryptoConditions amendment]: /@l10n/ja/resources/known-amendments.md#cryptoconditions
+[CryptoConditionsSuite amendment]: /@l10n/ja/resources/known-amendments.md#cryptoconditionssuite
+[通貨額]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#通貨額の指定
+[通貨コード]: /@l10n/ja/docs/references/protocol/data-types/currency-formats.md#通貨コード
+[DID amendment]: /@l10n/ja/resources/known-amendments.md#did
+[DIDエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/did.md
+[DeletableAccounts amendment]: /@l10n/ja/resources/known-amendments.md#deletableaccounts
+[DeepFreeze amendment]: /@l10n/ja/resources/known-amendments.md#deepfreeze
+[DepositAuth amendment]: /@l10n/ja/resources/known-amendments.md#depositauth
+[DepositPreauth amendment]: /@l10n/ja/resources/known-amendments.md#depositpreauth
+[DepositPreauthエントリ]: /@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
+[DepositPreauthオブジェクト]: /@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
+[DepositPreauth]: /@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
+[DepositPreauthトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
+[DIDSet]: /@l10n/ja/docs/references/protocol/transactions/types/didset.md
+[DIDSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/didset.md
+[DirectoryNodeエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
+[DirectoryNodeオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
+[DisallowIncoming amendment]: /@l10n/ja/resources/known-amendments.md#disallowincoming
+[DynamicNFT amendment]: /@l10n/ja/resources/known-amendments.md#dynamicnft
+[EnableAmendment]: /@l10n/ja/docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
+[EnableAmendment疑似トランザクション]: /@l10n/ja/docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
+[EnforceInvariants amendment]: /@l10n/ja/resources/known-amendments.md#enforceinvariants
+[Escrow amendment]: /@l10n/ja/resources/known-amendments.md#escrow
+[Escrowエントリ]: /@l10n/ja/docs/concepts/payment-types/escrow.md
+[Escrowオブジェクト]: /@l10n/ja/docs/concepts/payment-types/escrow.md
+[EscrowCancel]: /@l10n/ja/docs/references/protocol/transactions/types/escrowcancel.md
+[EscrowCancelトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/escrowcancel.md
+[EscrowCreate]: /@l10n/ja/docs/references/protocol/transactions/types/escrowcreate.md
+[EscrowCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/escrowcreate.md
+[EscrowFinish]: /@l10n/ja/docs/references/protocol/transactions/types/escrowfinish.md
+[EscrowFinishトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/escrowfinish.md
+[ExpandedSignerList amendment]: /@l10n/ja/resources/known-amendments.md#expandedsignerlist
+[FeeEscalation amendment]: /@l10n/ja/resources/known-amendments.md#feeescalation
+[FeeSettingsエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/feesettings.md
+[FeeSettingsオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/feesettings.md
+[Flow amendment]: /@l10n/ja/resources/known-amendments.md#flow
+[FlowCross amendment]: /@l10n/ja/resources/known-amendments.md#flowcross
+[FlowV2 amendment]: /@l10n/ja/resources/known-amendments.md#flowv2
+[ハッシュ]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#ハッシュ
+[ImmediateOfferKilled amendment]: /@l10n/ja/resources/known-amendments.md#immediateofferkilled
+[Interledger Protocol]: https://interledger.org/
+[内部の型]: /@l10n/ja/docs/references/protocol/binary-format.md
+[レジャーインデックス]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#レジャーインデックス
+[LedgerHashesエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md
+[LedgerHashesオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md
+[LedgerStateFix]: /@l10n/ja/docs/references/protocol/transactions/types/ledgerstatefix.md
+[LedgerStateFixトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ledgerstatefix.md
+[Marker]: /@l10n/ja/docs/references/http-websocket-apis/api-conventions/markers-and-pagination.md
+[MPTokensV1 amendment]: /@l10n/ja/resources/known-amendments.md#mptokensv1
+[MultiSign amendment]: /@l10n/ja/resources/known-amendments.md#multisign
+[MultiSignReserve amendment]: /@l10n/ja/resources/known-amendments.md#multisignreserve
+[NFTokenAcceptOffer]: /@l10n/ja/docs/references/protocol/transactions/types/nftokenacceptoffer.md
+[NFTokenAcceptOfferトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/nftokenacceptoffer.md
+[NFTokenBurn]: /@l10n/ja/docs/references/protocol/transactions/types/nftokenburn.md
+[NFTokenBurnトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/nftokenburn.md
+[NFTokenCancelOffer]: /@l10n/ja/docs/references/protocol/transactions/types/nftokencanceloffer.md
+[NFTokenCancelOfferトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/nftokencanceloffer.md
+[NFTokenCreateOffer]: /@l10n/ja/docs/references/protocol/transactions/types/nftokencreateoffer.md
+[NFTokenCreateOfferトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/nftokencreateoffer.md
+[NFTokenMint]: /@l10n/ja/docs/references/protocol/transactions/types/nftokenmint.md
+[NFTokenMintトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/nftokenmint.md
+[NFTokenOfferエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenoffer.md
+[NFTokenOfferオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenoffer.md
+[NFTokenPageエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
+[NFTokenPageオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
+[NFToken]: /@l10n/ja/docs/references/protocol/data-types/nftoken.md
+[NegativeUNL amendment]: /@l10n/ja/resources/known-amendments.md#negativeunl
+[NegativeUNLエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/negativeunl.md
+[NegativeUNLオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/negativeunl.md
+[NonFungibleTokensV1 amendment]: /@l10n/ja/resources/known-amendments.md#nonfungibletokensv1
+[NonFungibleTokensV1_1 amendment]: /@l10n/ja/resources/known-amendments.md#nonfungibletokensv1_1
+[Offerエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/offer.md
+[Offerオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/offer.md
+[OfferCancel]: /@l10n/ja/docs/references/protocol/transactions/types/offercancel.md
+[OfferCancelトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/offercancel.md
+[OfferCreate]: /@l10n/ja/docs/references/protocol/transactions/types/offercreate.md
+[OfferCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/offercreate.md
+[OracleDeleteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/oracledelete.md
+[OracleDeleteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/oracledelete.md
+[Oracleエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/oracle.md
+[Oracleオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/oracle.md
+[OracleSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/oracleset.md
+[OracleSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/oracleset.md
+[OwnerPaysFee amendment]: /@l10n/ja/resources/known-amendments.md#ownerpaysfee
+[PayChan amendment]: /@l10n/ja/resources/known-amendments.md#paychan
+[PayChannelエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/paychannel.md
+[PayChannelオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/paychannel.md
+[PaymentChannelClaim]: /@l10n/ja/docs/references/protocol/transactions/types/paymentchannelclaim.md
+[PaymentChannelClaimトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/paymentchannelclaim.md
+[PaymentChannelCreate]: /@l10n/ja/docs/references/protocol/transactions/types/paymentchannelcreate.md
+[PaymentChannelCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/paymentchannelcreate.md
+[PaymentChannelFund]: /@l10n/ja/docs/references/protocol/transactions/types/paymentchannelfund.md
+[PaymentChannelFundトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/paymentchannelfund.md
+[Payment]: /@l10n/ja/docs/references/protocol/transactions/types/payment.md
+[Paymentトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/payment.md
+[PermissionDelegation amendment]: /@l10n/ja/resources/known-amendments.md#permissiondelegation
+[PermissionedDEX amendment]: /@l10n/ja/resources/known-amendments.md#permissioneddex
+[PermissionedDomains amendment]: /@l10n/ja/resources/known-amendments.md#permissioneddomains
+[PermissionedDomainSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/permissioneddomainset.md
+[許可型ドメイン]: /@l10n/ja/docs/concepts/tokens/decentralized-exchange/permissioned-domains.md
+[PriceOracle amendment]: /@l10n/ja/resources/known-amendments.md#priceoracle
+[MPTokensV1_1 amendment]: /@l10n/ja/resources/known-amendments.md#priceoracle
+[RFC-1751]: https://tools.ietf.org/html/rfc1751
+[レポートモード]: /@l10n/ja/docs/concepts/networks-and-servers/rippled-server-modes.md#レポートモード
+[RequireFullyCanonicalSig amendment]: /@l10n/ja/resources/known-amendments.md#requirefullycanonicalsig
+[RippleStateエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
+[RippleStateオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
+[Rippleエポック以降の経過秒数]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#時間の指定
+[SHA-512Half]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#ハッシュ
+[SHAMapV2 amendment]: /@l10n/ja/resources/known-amendments.md#shamapv2
+[シーケンス番号]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#アカウントシーケンス
+[SetFee]: /@l10n/ja/docs/references/protocol/transactions/pseudo-transaction-types/setfee.md
+[SetFee疑似トランザクション]: /@l10n/ja/docs/references/protocol/transactions/pseudo-transaction-types/setfee.md
+[SetRegularKey]: /@l10n/ja/docs/references/protocol/transactions/types/setregularkey.md
+[SetRegularKeyトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/setregularkey.md
+[SignerListエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/signerlist.md
+[SignerListオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/signerlist.md
+[SignerListSet]: /@l10n/ja/docs/references/protocol/transactions/types/signerlistset.md
+[SignerListSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/signerlistset.md
+[SingleAssetVault amendment]: /@l10n/ja/resources/known-amendments.md#singleassetvault
+[SortedDirectories amendment]: /@l10n/ja/resources/known-amendments.md#sorteddirectories
+[通貨額の指定]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#通貨額の指定
+[レジャーの指定]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#レジャーの指定
+[時間の指定]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#時間の指定
+[金額なしの指定]: /@l10n/ja/docs/references/protocol/data-types/currency-formats.md#金額なしでの通貨の指定
+[SusPay amendment]: /@l10n/ja/resources/known-amendments.md#suspay
+[TickSize amendment]: /@l10n/ja/resources/known-amendments.md#ticksize
+[Ticketエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/ticket.md
+[Ticketオブジェクト]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/ticket.md
+[TicketBatch amendment]: /@l10n/ja/resources/known-amendments.md#ticketbatch
+[TicketCreate]: /@l10n/ja/docs/references/protocol/transactions/types/ticketcreate.md
+[TicketCreateトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ticketcreate.md
+[Tickets amendment]: /@l10n/ja/resources/known-amendments.md#tickets
+[TokenEscrow amendment]: /@l10n/ja/resources/known-amendments.md#tokenescrow
+[トランザクションコスト]: /@l10n/ja/docs/concepts/transactions/transaction-cost.md
+[TrustSetAuth amendment]: /@l10n/ja/resources/known-amendments.md#trustsetauth
+[TrustSet]: /@l10n/ja/docs/references/protocol/transactions/types/trustset.md
+[TrustSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/trustset.md
+[UNLModify]: /@l10n/ja/docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
+[UNLModify疑似トランザクション]: /@l10n/ja/docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
+[XChainAddAccountCreateAttestation]: /@l10n/ja/docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
+[XChainAddAccountCreateAttestationトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
+[XChainAddClaimAttestationトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/xchainaddclaimattestation.md
+[XChainBridge amendment]: /@l10n/ja/resources/known-amendments.md#xchainbridge
+[XChainCreateBridge]: /@l10n/ja/docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateBridgeトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateClaimID]: /@l10n/ja/docs/references/protocol/transactions/types/xchaincreateclaimid.md
+[XChainCreateClaimIDトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/xchaincreateclaimid.md
+[XRPのdrop数]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#通貨額の指定
+[XRPFees amendment]: /@l10n/ja/resources/known-amendments.md#xrpfees
+[account_channelsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_channels.md
+[account_currenciesメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_currencies.md
+[account_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info.md
+[account_linesメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_lines.md
+[account_nftsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_nfts.md
+[account_objectsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_objects.md
+[account_offersメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_offers.md
+[account_txメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/account_tx.md
+[amm_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/amm_info.md
+[base58]: /@l10n/ja/docs/references/protocol/data-types/base58-encodings.md
+[book_offersメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/book_offers.md
+[can_deleteメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete.md
+[channel_authorizeメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/payment-channel-methods/channel_authorize.md
+[channel_verifyメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/payment-channel-methods/channel_verify.md
+[共通フィールド]: /@l10n/ja/docs/references/protocol/transactions/common-fields.md
+[connectメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect.md
+[consensus_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/consensus_info.md
+[crawl_shardsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
+[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
+[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
+[deposit_authorizedメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized.md
+[download_shardメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
+[featureメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md
+[手数料レベル]: /@l10n/ja/docs/concepts/transactions/transaction-cost.md#手数料レベル
+[feeメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/fee.md
+[fetch_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/fetch_info.md
+[fix1201 amendment]: /@l10n/ja/resources/known-amendments.md#fix1201
+[fix1368 amendment]: /@l10n/ja/resources/known-amendments.md#fix1368
+[fix1373 amendment]: /@l10n/ja/resources/known-amendments.md#fix1373
+[fix1512 amendment]: /@l10n/ja/resources/known-amendments.md#fix1512
+[fix1513 amendment]: /@l10n/ja/resources/known-amendments.md#fix1513
+[fix1515 amendment]: /@l10n/ja/resources/known-amendments.md#fix1515
+[fix1523 amendment]: /@l10n/ja/resources/known-amendments.md#fix1523
+[fix1528 amendment]: /@l10n/ja/resources/known-amendments.md#fix1528
+[fix1543 amendment]: /@l10n/ja/resources/known-amendments.md#fix1543
+[fix1571 amendment]: /@l10n/ja/resources/known-amendments.md#fix1571
+[fix1578 amendment]: /@l10n/ja/resources/known-amendments.md#fix1578
+[fix1623 amendment]: /@l10n/ja/resources/known-amendments.md#fix1623
+[fixAMMv1_3 amendment]: /@l10n/ja/resources/known-amendments.md#fixammv1_3
+[fixCheckThreading amendment]: /@l10n/ja/resources/known-amendments.md#fixcheckthreading
+[fixDisallowIncomingV1 amendment]: /@l10n/ja/resources/known-amendments.md#fixdisallowincomingv1
+[fixEnforceNFTokenTrustlineV2 amendment]: /@l10n/ja/resources/known-amendments.md#fixenforcenftokentrustlinev2
+[fixFillOrKill amendment]: /@l10n/ja/resources/known-amendments.md#fixfillorkill
+[fixFrozenLPTokenTransfer]: /@l10n/ja/resources/known-amendments.md#fixfrozenlptokentransfer
+[fixInvalidTxFlags amendment]: /@l10n/ja/resources/known-amendments.md#fixinvalidtxflags
+[fixMasterKeyAsRegularKey amendment]: /@l10n/ja/resources/known-amendments.md#fixmasterkeyasregularkey
+[fixNFTokenDirV1 amendment]: /@l10n/ja/resources/known-amendments.md#fixnftokendirv1
+[fixNFTokenPageLinks amendment]: /@l10n/ja/resources/known-amendments.md#fixnftokenpagelinks
+[fixNFTokenRemint amendment]: /@l10n/ja/resources/known-amendments.md#fixnftokenremint
+[fixPayChanCancelAfter amendment]: /@l10n/ja/resources/known-amendments.md#fixpaychancancelafter
+[fixPayChanRecipientOwnerDir amendment]: /@l10n/ja/resources/known-amendments.md#fixpaychanrecipientownerdir
+[fixPreviousTxnID amendment]: /@l10n/ja/resources/known-amendments.md#fixprevioustxnid
+[fixQualityUpperBound amendment]: /@l10n/ja/resources/known-amendments.md#fixqualityupperbound
+[fixRemoveNFTokenAutoTrustLine amendment]: /@l10n/ja/resources/known-amendments.md#fixremovenftokenautotrustline
+[fixTakerDryOfferRemoval amendment]: /@l10n/ja/resources/known-amendments.md#fixtakerdryofferremoval
+[fixTrustLinesToSelf amendment]: /@l10n/ja/resources/known-amendments.md#fixtrustlinestoself
+[get_aggregate_priceコマンド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/get_aggregate_price.md
+[get_aggregate_priceメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/get_aggregate_price.md
+[gateway_balancesメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/gateway_balances.md
+[get_countsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/get_counts.md
+[16進数]: https://ja.wikipedia.org/wiki/Hexadecimal
+[識別用ハッシュ]: /@l10n/ja/docs/concepts/transactions/index.md#トランザクションの識別
+[jsonメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/utility-methods/json.md
+[レジャーフォーマット]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/index.md
+[レジャーインデックス]: /@l10n/ja/docs/references/protocol/data-types/basic-data-types.md#レジャーインデックス
+[ledger_acceptメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/server-control-methods/ledger_accept.md
+[ledger_cleanerメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/ledger_cleaner.md
+[ledger_closedメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_closed.md
+[ledger_currentメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_current.md
+[ledger_dataメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_data.md
+[ledger_entryメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_entry.md
+[ledger_requestメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/ledger_request.md
+[ledgerメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger.md
+[log_levelメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/log_level.md
+[logrotateメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/logrotate.md
+[manifestメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/manifest.md
+[nft_buy_offersメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/nft_buy_offers.md
+[nft_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/clio-methods/nft_info.md
+[nft_sell_offersメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/nft_sell_offers.md
+[ノードキーペア]: /@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md#ノードキーペア
+[ノード公開鍵]: /@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md#ノードキーペア
+[noripple_checkメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/account-methods/noripple_check.md
+[path_findメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/path_find.md
+[ピアリザベーション]: /@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md#固定ピアとピアリザベーション
+[peer_reservations_addメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_add.md
+[peer_reservations_delメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_del.md
+[peer_reservations_listメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_list.md
+[peersメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers.md
+[pingメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/utility-methods/ping.md
+[printメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/print.md
+[公開サーバ]: /@l10n/ja/docs/tutorials/public-servers.md
+[randomメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/utility-methods/random.md
+[結果コード]: /@l10n/ja/docs/references/protocol/transactions/transaction-results/index.md
+[ripple-lib]: https://github.com/XRPLF/xrpl.js
+[ripple_path_findメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/ripple_path_find.md
+[server_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md
+[server_stateメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_state.md
+[sign_forメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/signing-methods/sign_for.md
+[signメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/signing-methods/sign.md
+[スタンドアロンモード]: /@l10n/ja/docs/concepts/networks-and-servers/rippled-server-modes.md#スタンドアロンモード
+[標準フォーマット]: /@l10n/ja/docs/references/http-websocket-apis/api-conventions/response-formatting.md
+[String Number]: /@l10n/ja/docs/references/protocol/data-types/currency-formats#string-numbers
+[stopメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/server-control-methods/stop.md
+[submit_multisignedメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/transaction-methods/submit_multisigned.md
+[submitメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/transaction-methods/submit.md
+[subscribeメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md
+[transaction cost]: /@l10n/ja/docs/concepts/transactions/transaction-cost.md
+[transaction_entryメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/transaction-methods/transaction_entry.md
+[tx_historyメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/transaction-methods/tx_history.md
+[txメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/transaction-methods/tx.md
+[汎用エラータイプ]: /@l10n/ja/docs/references/http-websocket-apis/api-conventions/error-formatting.md#汎用エラー
+[unsubscribeメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/subscription-methods/unsubscribe.md
+[validation_createメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/key-generation-methods/validation_create.md
+[validator_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validator_info.md
+[validator_list_sitesメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validator_list_sites.md
+[validatorsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md
+[wallet_proposeメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/key-generation-methods/wallet_propose.md

@l10n/ja/docs/_snippets/conf-file-location.md

@@ -0,0 +1 @@
+[推奨インストール](../infrastructure/installation/index.md)では、デフォルトで`/etc/opt/ripple/rippled.cfg`という設定ファイルを使用します。その他の場所としては、`$HOME/.config/ripple/rippled.cfg`(`$HOME`は`rippled`を実行しているユーザのホームディレクトリです)、`$HOME/.local/ripple/rippled.cfg`または`rippled`を起動した現在の作業ディレクトリがあります。

@l10n/ja/docs/_snippets/data_types/account_sequence.md

@@ -0,0 +1,13 @@
+シーケンス番号とは、32ビットの符号なし整数であり、指定された送金元からのトランザクションが正しい順序で1回だけ実行されるようにするために使用されます。
+
+すべての[XRP Ledgerアカウント](../../concepts/accounts/index.md)には、`Sequence`フィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが[検証済みレジャー](../../concepts/ledgers/index.md)に記録されるたびに、1ずつ増加します。シーケンス番号は各[トランザクション](../../concepts/transactions/index.md)の`Sequence`フィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。
+
+[チケット](../../concepts/accounts/tickets.md) は、通常の順序とは異なるトランザクションを送信できるように、これらのルールにいくつかの例外を設けています。チケットは、後で使用するために予約されたシーケンス番号を表します。トランザクションは、通常のシーケンス番号の代わりにチケットを使用することができます。
+
+[DeletableAccounts Amendment](/resources/known-amendments.md#deletableaccounts) を適用する場合、アカウントの`Sequence`番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントの`Sequence`番号も1で始まります。
+
+トランザクションがレジャーに記録されると、トランザクションの実行が成功したか[`tec`クラスのエラーコード](../../references/protocol/transactions/transaction-results/tec-codes.md)で失敗したかを問わず、シーケンス番号が1つ消費されます。トランザクションのその他の失敗についてはレジャーに記録されないため、送金元のシーケンス番号は変更されません（その他の影響もありません）。
+
+レジャー内では、[アドレス][]とシーケンス番号を一緒に使用して、その送金元とシーケンス番号を持つ検証済みトランザクションによって作成されたオブジェクトが識別されることがあります。この方法で識別されたオブジェクトの例として、[Escrow](../../concepts/payment-types/escrow.md)と[オファー](../../concepts/tokens/decentralized-exchange/offers.md)が挙げられます。
+
+複数の未確定のトランザクションが、同じ送金元と同じシーケンス番号を持つことが可能です。そのようなトランザクションは互いに排他的であり、検証済みレジャーに記録されるのはいずれか一方のみです。（それ以外は最終的に影響ありません。）

@l10n/ja/docs/_snippets/data_types/address.md

@@ -0,0 +1,13 @@
+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
+
+{% 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)をご覧ください
+
+XRP Ledgerプロトコルは「クラシック」アドレスのみをネイティブにサポートしていますが、多くの[クライアントライブラリ](../../references/client-libraries.md)はXアドレスもサポートしています。
+{% /admonition %}

@l10n/ja/docs/_snippets/data_types/currency_code.md

@@ -0,0 +1,6 @@
+[HTTP / WebSocket API](../../references/http-websocket-apis/index.md)は、2種類の通貨コードをサポートしています。
+
+- **[標準通貨コード](../../references/protocol/data-types/currency-formats.md#標準通貨コード):** `"EUR"`や`"USD"`のような3文字の文字列
+- **[非標準通貨コード](../../references/protocol/data-types/currency-formats.md#非標準通貨コード):** `"0158415500000000C1F76FFF6ECB0BAC600000000"`のような160ビットの16進数の文字列。これは一般的ではありません。
+
+同じコードを持つトークンは、接続されたトラストラインを越えて[rippling(波及)](../../concepts/tokens/fungible-tokens/rippling.md)することができます。通貨コードには、XRP Ledgerに組み込まれた他の動作はありません。

@l10n/ja/docs/_snippets/data_types/hash.md

@@ -0,0 +1,9 @@
+XRP Ledger内の多くのオブジェクト、特にトランザクションとレジャーは、256ビットのハッシュ値で一意に識別されます。通常、この値は「SHA-512ハーフ」として算出されます。SHA-512ハーフは、あるコンテンツから[SHA-512](http://dx.doi.org/10.6028/NIST.FIPS.180-4)ハッシュを計算し、出力の前半を取得したものです。（これは256ビット、つまり32バイトで、16進数表記では64文字です。）オブジェクトのハッシュは、極めて競合の発生しにくい方法でコンテンツから生成されるため、2つのオブジェクトが同じハッシュを持つ場合、それらのオブジェクトは同じものと見なされます。
+
+XRP Ledgerのハッシュ値には、以下の特徴があります。
+
+* 長さは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 %}

@l10n/ja/docs/_snippets/data_types/ledger_index.md

@@ -0,0 +1,7 @@
+レジャーインデックスは、32ビットの符号なし整数であり、レジャーを識別するために使用します。レジャーインデックスは、レジャーの _シーケンス番号_ と呼ばれることもあります。（[アカウントシーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)とは異なります。）一番最初のレジャーでは、レジャーインデックスは1でした。新しいレジャーのレジャーインデックスは、その直前のレジャーのレジャーインデックスに1を加算した値になります。
+
+レジャーインデックスがレジャーの順番を示すのに対し、[ハッシュ][]値はレジャーの正確なコンテンツを示します。2つのレジャーが同じハッシュ値を持つ場合、それらは必ず同じものです。検証済みレジャーでは、ハッシュ値とレジャーインデックスは等しく有効で、1:1の関係です。しかし、進行中のレジャーに対しては、以下の理由によりその限りでありません。
+
+* ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なる`rippled`サーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
+* 決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります（ハッシュも異なります）。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
+* 現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。

@l10n/ja/docs/_snippets/data_types/public_key.md

@@ -0,0 +1,13 @@
+XRP Ledgerは、以下のようなさまざまな状況で暗号署名を検証するために、公開鍵を使用します。
+
+* トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
+* `rippled`サーバ間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバが起動する場合に、サーバがランダムに生成する「ノード公開鍵」が使用されます。
+* コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。
+
+バリデータ公開鍵とノード公開鍵は、まったく同じフォーマットを使用します。
+
+公開鍵は、16進数かbase-58で表すことができます。16進数では、公開鍵は3種類すべて、長さが33バイト（66文字）です。
+
+base-58フォーマットでは、バリデータ公開鍵とノード公開鍵は必ず文字`n`から始まり、その後に文字`9`が続くのが一般的です。base-58フォーマットのバリデータ公開鍵は、最長で53文字にできます。ノード公開鍵の例を以下に示します。`n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG`。
+
+XRP Ledgerのアドレスは、公開鍵に数学的に関連付けられます。この公開鍵がbase-58でエンコードされることはめったにありませんが、その場合は文字`a`から始まります。

@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md

@@ -0,0 +1,17 @@
+<!-- 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. -->
+
+{% 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 /%}
+
+</div>
+
+{% /interactive-block %}

@l10n/ja/docs/_snippets/interactive-tutorials/generate-step.md

@@ -0,0 +1,9 @@
+{% interactive-block label=default($label, "Generate") steps=$frontmatter.steps %}
+
+<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 %}
+
+{% admonition type="warning" name="注意" %}Rippleは[TestnetとDevnet](../../concepts/networks-and-servers/parallel-networks.md)をテストの目的でのみ運用しており、その状態とすべての残高を定期的にリセットしています。予防措置として、Testnet、DevnetとMainnetで同じアドレスを使用**しない**ことをお勧めします。{% /admonition %}

@l10n/ja/docs/_snippets/interactive-tutorials/wait-step.md

@@ -0,0 +1,23 @@
+{% interactive-block label=default($label, "Wait") steps=$frontmatter.steps %}
+
+<table class="wait-step" data-explorerurl="https://testnet.xrpl.org">
+  <tr>
+    <th>トランザクションのID:</th>
+    <td class="waiting-for-tx">(無）</td>
+  <tr>
+    <th>最新の検証レジャーインデックス：</th>
+    <td class="validated-ledger-version">接続されていません</td>
+  </tr>
+  <tr>
+    <th>送信時のレジャーインデックス：</th>
+    <td class="earliest-ledger-version">（まだ送信されません）</td>
+  </tr>
+  <tr>
+    <th>トランザクションの<code>LastLedgerSequence</code>:</th>
+    <td class="lastledgersequence">(準備されません）</td>
+  </tr>
+  <tr class="tx-validation-status">
+  </tr>
+</table>
+
+{% /interactive-block %}

@l10n/ja/docs/_snippets/ledger-objects-intro.md

@@ -0,0 +1,3 @@
+各[レジャー](../concepts/ledgers/index.md)の状態ツリーは**レジャーオブジェクト**のセットで構成されており、それらが総合して共有レジャーのすべての設定、残高、関係を表します。
+
+rippledサーバが互いに通信するために使用する[ピアプロトコル](../concepts/networks-and-servers/peer-protocol.md)では、レジャーオブジェクトは生[バイナリーフォーマット](../references/protocol/binary-format.md)で表されます。rippled APIでは、レジャーオブジェクトはJSONオブジェクトとして表されます。

@l10n/ja/docs/_snippets/mpts-disclaimer.md

@@ -0,0 +1,3 @@
+{% admonition type="info" name="注意" %}
+Multi-Purpose Token機能は、XRP LedgerプロトコルへのXLS-33d拡張機能の一部として提案されています。 現時点では、テストネットワーク上でこれらの機能を使用することができます。 安定版リリースでAmendment有効化されるまででは、これらのページに記載されている詳細内容は変更される可能性があります。
+{% /admonition %}

@l10n/ja/docs/_snippets/no-cli-syntax.md

@@ -0,0 +1,3 @@
+{% admonition type="info" name="注記" %}
+このメソッドにはコマンドライン構文がありません。代わりに[jsonメソッド][]を使って、コマンドラインからこのメソッドにアクセスすることができます。
+{% /admonition %}

@l10n/ja/docs/_snippets/peer_reservation_object.md

@@ -0,0 +1,4 @@
+| `Field`       | 型     | 説明                                                |
+|:--------------|:-------|:----------------------------------------------------|
+| `node`        | 文字列  | この予約の対象となるピアサーバの[ノード公開鍵][]（[base58][]）。 |
+| `description` | 文字列  | _（省略される場合があります）_ このピアリザベーションの説明（ある場合）。 |

@l10n/ja/docs/_snippets/port-descriptor-object.md

@@ -0,0 +1,11 @@
+### ポート記述子オブジェクト
+<!-- このネストされたオブジェクトの定義は、server_stateとserver_infoで共通です。 -->
+
+`ports`配列の各メンバーは以下のフィールドを持つオブジェクトです。
+
+| フィールド   | 値          | 説明         |
+|------------|-------------|-------------|
+| `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 %}

@l10n/ja/docs/_snippets/post-rippled-install.md

@@ -0,0 +1,33 @@
+`rippled`が残りのネットワークと同期されるまでには数分かかることがあります。その間、レジャーがない旨を知らせる警告が出力されます。
+
+`rippled`ログメッセージの詳細は、[ログメッセージについて](../infrastructure/troubleshooting/understanding-log-messages.md)をご覧ください。
+
+`rippled`が残りのネットワークと同期されたら、ストック`rippled`サーバが完全に機能するようになります。このサーバを、ローカル署名やXRP LedgerへのAPIアクセスに使用できます。`rippled`サーバがネットワークと同期されているかどうかを判別するには、[`rippled`サーバの状況](../references/http-websocket-apis/api-conventions/rippled-server-states.md)を使用します。[`rippled`のコマンドラインインターフェイス](../tutorials/http-websocket-apis/build-apps/get-started.md#コマンドライン)を使用すれば、これを迅速にテストできます。
+
+```sh
+rippled server_info
+```
+
+rippled APIを使用した`rippled`サーバとの通信について詳しくは、[rippled API reference](../references/http-websocket-apis/index.md)をご覧ください。
+
+ストック`rippled`サーバを実行できたら、次に検証サーバとして実行してみましょう。検証サーバについて、そして検証サーバを実行する理由については、[バリデータとしてのrippledの実行](../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
+
+`rippled`サーバの起動でお困りですか? [rippledサーバが起動しない](../infrastructure/troubleshooting/server-wont-start.md)をご覧ください。
+
+### その他の構成
+
+`rippled`は、デフォルト構成でXRP Ledgerに接続する必要があります。ただし、`rippled.cfg`ファイルを編集すれば、設定を変更できます。推奨される構成設定については、[容量の計画](../infrastructure/installation/capacity-planning.md)をご覧ください。
+
+{% partial file="/@l10n/ja/docs/_snippets/conf-file-location.md" /%}
+
+すべての構成オプションの説明については、[`rippled` GitHubリポジトリー](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)をご覧ください。
+
+構成の変更を有効にするには、`rippled`を再起動する必要があります。
+
+`[debug_logfile]`セクションまたは`[database_path]`セクションを変更すると、`rippled`を実行するユーザに、新しく構成したパスの所有権を付与する必要が生じる場合があります。
+
+### 更新
+
+`rippled`を定期的に更新して、残りのXRP Ledgerネットワークと同期させておく必要があります。[rippledのGoogleグループ](https://groups.google.com/forum/#!forum/ripple-server)をサブスクライブすれば、`rippled`の新しいリリースに関する通知を受け取ることができます。
+
+`rippled`のパッケージには、[Linuxでの自動更新を有効にする](../infrastructure/installation/update-rippled-automatically-on-linux.md)ために使用できるスクリプトが含まれています。その他のプラットフォームでは、手動での更新が必要です。

@l10n/ja/docs/_snippets/pseudo-tx-fields-intro.md

@@ -0,0 +1,3 @@
+## {% $frontmatter.seo.title %} フィールド
+
+[共通フィールド][../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md]に加えて、{% $frontmatter.seo.title %}擬似トランザクションは以下のフィールドを使用します。

@l10n/ja/docs/_snippets/public-signing-note.md

@@ -0,0 +1 @@
+_デフォルトでは、このメソッドは[管理者専用](../references/http-websocket-apis/admin-api-methods/index.md)です。サーバ管理者が[パブリック署名を有効にしている](../infrastructure/configuration/enable-public-signing.md)場合、パブリックメソッドとして使用できます_。

@l10n/ja/docs/_snippets/secret-key-warning.md

@@ -0,0 +1,3 @@
+{% admonition type="warning" name="注意" %}
+自分が管理していないサーバに秘密鍵を送信しないでください。暗号化されていない秘密鍵をネットワーク経由で送信しないでください。
+{% /admonition %}

@l10n/ja/docs/_snippets/setfee_uniqueness_note.md

@@ -0,0 +1,3 @@
+{% admonition type="info" name="注記" %}
+XRP Ledgerの全履歴では、トランザクションハッシュは一意であるというルールに例外があります。初期の2つの[SetFee疑似トランザクション][]にはまったく同じフィールドがあったため、ハッシュが同じ`1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B`になっています。これらのトランザクションのうち1つ目は[レジャー3715073に](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3715073%7D)表示され、2つ目は[レジャー3721729に](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3721729%7D)表示されます。新しい[SetFee疑似トランザクション][]には`LedgerSequence`フィールドが含まれるため、ハッシュは一意であることが保証されています。
+{% /admonition %}

@l10n/ja/docs/_snippets/string-number-formatting.md

@@ -0,0 +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`と同じです。負の指数も可能です。
+* カンマ(`,`)は使用しません。

@l10n/ja/docs/_snippets/tutorial-sign-step.md

@@ -0,0 +1,3 @@
+トランザクションに署名する最も安全な方法は、[クライアントライブラリ](../references/client-libraries.md)を使用してローカルで署名することです。[signメソッド](../references/http-websocket-apis/admin-api-methods/signing-methods/sign.md)を使用してトランザクションに署名することもできますが、その場合は信頼できる暗号化された接続を使用するか、ローカル接続を使用して、自分が管理しているサーバに対してのみに行うようにしてください。
+
+いずれの場合も、後のために、署名したトランザクションの識別用ハッシュを書き留めておいてください。

@l10n/ja/docs/_snippets/tutorial-submit-step.md

@@ -0,0 +1,3 @@
+前のステップで署名したトランザクションblobを`rippled`サーバに送信します。これは`rippled`サーバを実行していなくても安全にできます。レスポンスには仮の結果が含まれ、それは`tesSUCCESS`であるべきですが、この結果は[通常は最終的なものではありません](../concepts/transactions/finality-of-results/index.md)。[キューに入れられたトランザクション](../concepts/transactions/transaction-cost.md#queued-transactions)は通常、次のオープンレジャーのバージョンに含まれるからです(通常、送信から約10秒後となります)。
+
+{% admonition type="success" name="ヒント" %}仮の結果が `tefMAX_LEDGER` であった場合、そのトランザクションの`LastLedgerSequence`パラメータが現在のレジャー番号よりも低いため、そのトランザクションが失敗しています。これは、トランザクション情報を準備してから送信するまでに、予想されるレジャーのバージョン数よりも長くかかった場合に起こります。このような場合は、`LastLedgerSequence`の値を大きくしてステップ1からやり直してください。{% /admonition %}

@l10n/ja/docs/_snippets/tx-fields-intro.md

@@ -0,0 +1,3 @@
+## {% $frontmatter.seo.title %} フィールド
+
+[共通フィールド][]に加えて、{% $frontmatter.seo.title %}トランザクションは以下のフィールドを使用します。

@l10n/ja/docs/_snippets/tx-metadata-field-table.md

@@ -0,0 +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)。 |
+| [`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)であるかどうかにかかわらず、送金された金額を特定するために使用します。 |

@l10n/ja/docs/_snippets/unsynced_warning_logs.md

@@ -0,0 +1 @@
+サーバ起動後の最初の5～15分間に、サーバがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバ起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、ネットワーク接続の信頼性が低いことや、[ハードウェアのスペック](../infrastructure/installation/system-requirements.md)が不十分であることが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）

@l10n/ja/docs/concepts/accounts/account-types.md

@@ -0,0 +1,83 @@
+---
+html: account-types.html
+parent: accounts.html
+seo:
+    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 "図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー")
+
+発行アドレスは、待機アドレスに支払いを送信することでトークンを作成します。これらのトークンは(多くの場合)債務を表すため、発行アドレスの観点からはマイナスの価値を持ちます。同じトークンは、待機アドレスの観点も含めると、他の観点からはプラスの価値を持ちます。
+
+待機アドレスは、実際の人間によって操作され、トークンを運用アドレスに送信します。このステップにより、発行アドレスはこの時点以降、可能な限り使用されることなく、同時に少なくとも一定のトークンを待機状態にすることができます。
+
+自動化されたシステムにより運用される運用アドレスは、流動性プロバイダー、パートナー、その他の顧客など、他のカウンターパーティに資金を送ります。これらのカウンターパーティは、資金を自由に複数回送金することができます。
+
+いつものように、トークンの支払いはトラストラインを通じて発行者を「波及」しなければなりません。
+
+最終的に、誰かがトークンを発行者に送り返します。これによってトークンはバーンされ、XRP Ledgerにおける発行者の債務は減少します。トークンがステーブルコインであれば、これはトークンを対応するオフレジャー資産と交換する最初のステップです。
+
+## 発行アドレス
+
+発行アドレスは金庫に似ています。パートナーアドレス、顧客アドレス、運用アドレスは、発行アドレスにトラストラインを作成しますが、このアドレスは可能な限りトランザクションを送信しません。人間のオペレーターが定期的に、発行アドレスからトランザクションを作成、署名し、待機アドレスまたは運用アドレスの残高を補充します。理想的には、これらのトランザクションに署名するために使用される秘密鍵は、インターネットに接続されたコンピュータから決してアクセスできないようにする必要があります。
+
+金庫とは異なり、発行アドレスは顧客またはパートナーからの支払いを直接受領できます。XRP Ledgerのトランザクションは全て公開されているため、自動化されたシステムは秘密鍵を必要とせずに発行アドレスへの支払いを監視することができます。
+
+### 発行アドレスの漏えい
+
+悪意のある第三者が金融機関の発行アドレスの秘密鍵を知った場合、その第三者は新しいトークンを発行し、ユーザに送ったり、分散型取引所で取引したりすることができます。これにより、ステーブルコインの発行者は支払不能に陥る可能性があります。金融機関が合法的に入手したトークンを区別し、公正に換金することが困難になる可能性があります。金融機関が発行アドレスのコントロールを失った場合、金融機関は新しい発行アドレスを作成しなければならず、古い発行アドレスにトラストラインを持つすべてのユーザは、新しいアドレスで新しいトラストラインを作成しなければなりません。
+
+### 複数の発行アドレス
+
+金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行することができます。ただし、[送金手数料](../tokens/transfer-fees.md)のパーセンテージや[Global Freeze](../tokens/fungible-tokens/freezes.md)の状態など、1つのアドレスから発行される全ての(代替可能)トークンに等しく適用される設定もあります。トークンの種類ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
+
+
+## 運用アドレス
+
+運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わって支払いを行います。トランザクションに自動的に署名するには、運用アドレスの秘密鍵をインターネットに接続されたサーバに保管する必要があります。(秘密鍵は暗号化して保管できますが、サーバがトランザクションに署名する際に秘密鍵を復号化する必要があります。)顧客やパートナーは、運用アドレスへのトラストラインを作成しませんし、作成すべきではありません。
+
+各運用アドレスのトークンとXRPの残高は限られています。運用アドレスの残高が少なくなると、金融機関は発行アドレスまたは待機アドレスから支払いを送ることで残高を補充します。
+
+### 運用アドレスの漏えい
+
+不正使用者が運用アドレスのシークレットキーを入手した場合に金融機関が失う可能性のある通貨額は、最大でも運用アドレスが保有している額までです。金融機関は、顧客やパートナーからのアクションなしに、新しい運用アドレスに切り替えることができます。
+悪意のある第三者が運用アドレスの秘密鍵を知ってしまった場合、金融機関が失うのはその運用アドレスが持つ分の金額のみです。金融機関は、顧客やパートナーが何もしなくても、新しい運用アドレスに切り替えることができます。
+
+## 待機アドレス
+
+金融機関がリスクと利便性のバランスのために取ることができるもう一つの手段として、発行アドレスと運用アドレスの中間地点として「待機アドレス」を使用することです。金融機関は、待機アドレスとして追加のXRP Ledgerアドレスに資金を供給することができ、その鍵は常時オンラインのサーバでは利用できませんが、別の信頼できるユーザに委託されます。
+
+運用アドレスの資金(トークンまたはXRP)が不足した場合、信頼できるユーザは待機アドレスを使って運用アドレスの残高を補充することができます。待機アドレスの資金が不足した場合、金融機関は発行アドレスを使用して、単一のトランザクションでより多くの資金を待機アドレスに送ることができ、待機アドレスは必要に応じてそれらの資金を自分たちの間で分配することができます。これにより、発行アドレスのセキュリティが向上し、単一の自動化システムの管理下に多くの資金を残すことなく、トランザクションの総数を少なくすることができます。
+
+運用アドレスと同様に、待機アドレスは、顧客やパートナーではなく、発行アドレスとトラストラインを設定しなければなりません。運用アドレスに適用されるすべての注意事項は、待機アドレスにも適用されます。
+
+### 待機アドレスの漏えい
+
+待機アドレスの秘密鍵が漏えいした場合、その影響は運用アドレスの場合と同じです。悪意のある第三者は、待機アドレスが保有するすべての残高を盗むことができ、金融機関は顧客やパートナーが何もしなくても、新しい待機アドレスに切り替えることができます。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [アカウント](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)
+- **リファレンス:**
+    - [account_infoメソッド][]
+    - [SetRegularKeyトランザクション][]
+    - [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+
+{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

@l10n/ja/docs/concepts/accounts/addresses.md

@@ -0,0 +1,95 @@
+---
+html: addresses.html
+parent: accounts.html
+seo:
+    description: アドレスは、base58フォーマットを使用して、XRP Ledgerのアカウントを一意に識別します。
+labels:
+  - アカウント
+---
+# アドレス
+
+{% partial file="/@l10n/ja/docs/_snippets/data_types/address.md" /%}
+
+有効なアドレスであれば、資金を入金することで[XRP Ledgerのアカウントになる](index.md#creating-accounts)ことができます。また、[レギュラーキー](cryptographic-keys.md)や[署名者リスト](multi-signing.md)のメンバーとして、資金提供されていないアドレスを使用することもできます。資金を供給されたアカウントだけがトランザクションの送信者になることができます。
+
+キーペアの生成を始めとする有効なアドレスの作成は、厳密には数学的な作業です。キーペアの生成とアドレスの計算は、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)をエンコードするときにこのアドレスを生成しました。 | はい |
+
+
+## アドレスのエンコード
+
+{% admonition type="success" name="ヒント" %}これらの技術的な詳細は、XRP Ledgerとの互換性を保つために低レベルのライブラリソフトウェアを構築しているユーザのみを対象としています!{% /admonition %}
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "ソース")
+
+XRP Ledgerのアドレスは、[base58][]形式の _ディクショナリ_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`を使用してエンコードされています。XRP Ledgerはbase58でいくつかのタイプのキーをエンコードするため、それらを区別するためにエンコードされたデータの前に1バイトの「タイプ接頭辞」（「バージョン接頭辞」とも呼ばれます）を付けます。タイプ接頭辞によりアドレスは通常、base58形式の異なる文字で始まります。
+
+次の図は、キーとアドレスの関係を示しています
+
+[{% 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);
+
+    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);
+    ```
+
+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();
+    ```
+
+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);
+    ```
+
+5. ペイロードとチェックサムを連結します。連結バッファーのbase58値を計算します。この結果が、アドレスになります。
+
+    ```
+    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" /%}

@l10n/ja/docs/concepts/accounts/cryptographic-keys.md

@@ -0,0 +1,261 @@
+---
+html: cryptographic-keys.html
+parent: accounts.html
+seo:
+    description: 暗号鍵を使用してトランザクションを承認し、XRP Ledgerがトランザクションを実行できるようにします。
+labels:
+  - セキュリティ
+  - スマートコントラクト
+---
+# 暗号鍵
+
+XRP Ledgerでは、[トランザクション](../transactions/index.md)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
+
+すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.md)のメンバーとして使用できます。
+
+{% admonition type="danger" name="警告" %}秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。お使いのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。{% /admonition %}
+
+## キーの生成
+
+多くの[クライアントライブラリ](../../references/client-libraries.md)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザに公開する可能性があり、そのユーザはあなたのアカウントから後でトランザクションを送信することができます。
+
+注：ツールによってデフォルト値が異なります。多くのクライアントライブラリ（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 ←→ アドレス")
+_図: 暗号鍵の値の関係を簡略化した図_
+
+パスフレーズ、シード、秘密鍵は**秘密情報**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
+
+公開鍵、アカウントID、アドレスは公開情報です。一時的に公開鍵を秘密にするような状況もありますが、最終的にはトランザクションの一部として公開し、XRP Ledgerが署名を検証してトランザクションを処理できるようにすることが必要です。
+
+鍵の導出の仕組みの技術的な詳細については、[鍵の導出](#鍵導出)をご覧ください。
+
+### パスフレーズ
+
+オプションとして、パスフレーズやその他の情報を、シードや秘密鍵の決定方法として使用することができます。これは、完全にランダムにシードや秘密鍵を選択するよりも安全性が低いですが、これを行いたいレアケースもあります。(例えば、2018年に「XRPuzzler」が最初に[パズルを解いた人](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/)にXRPをプレゼントしました。彼はパズルの解答を、賞品のXRPを保有するアカウントへのパスフレーズとして使用しました)
+
+パスフレーズは秘密情報であるため、厳重に保管する必要があります。アドレスのパスフレーズを知った人は、そのアドレスを実質的に完全にコントロールすることができます。
+
+### シード
+
+_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`,`master_seed`,`master_seed_hex`はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](../../references/http-websocket-apis/index.md)やいくつかの[他のXRP Ledgerソフトウェア](../../introduction/software-ecosystem.md)で[トランザクションの署名](../transactions/index.md#トランザクションへの署名とトランザクションの送信)に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
+
+シード値は秘密情報であるため、非常に厳重に保管する必要があります。あるアドレスのシード値を知っている人は、そのアドレスを実質的に完全にコントロールすることができます。
+
+### 秘密鍵
+
+_秘密鍵_ は、デジタル署名を作成するために使用される値です。ほとんどのXRP Ledgerソフトウェアは、秘密鍵を明示的に表示せず、必要に応じてシード値から[秘密鍵の導出](#鍵導出)を行っています。シードの代わりに秘密鍵を保存し、それを使ってトランザクションに直接署名することは技術的には可能ですが、この使い方はレアケースです。
+
+シードと同様、秘密鍵は秘密情報であるため、厳重に保管する必要があります。あるアドレスの秘密鍵を知っている人は、そのアドレスを事実上完全にコントロールすることができます。
+
+### 公開鍵
+
+公開鍵は、電子署名の正当性を検証するために使用される値です。公開鍵は、鍵の導出の一部として秘密鍵から導出されます。[wallet_proposeメソッド][]のレスポンスでは、`public_key`と`public_key_hex`は両方とも同じ公開鍵の値を表します。
+
+XRP Ledgerのトランザクションには、ネットワークがトランザクションの署名を検証できるように、公開鍵が含まれている必要があります。公開鍵は有効な署名を作成するために使用することはできないので、公開しても問題はありません。
+
+
+### アカウントIDとアドレス
+
+**アカウントID**は、[アカウント](index.md)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
+
+- 「クラシックアドレス」は、[base58][]にチェックサム付きでアカウントIDを書きます。[wallet_proposeメソッド][]のレスポンスでは、これが`account_id`の値となります。
+- 「X-Address」は、アカウントIDと[宛先タグ](../transactions/source-and-destination-tags.md)を組み合わせ、チェックサムとともに[base58][]にその値を書き込みます。
+
+どちらの形式でもチェックサムがあるため、わずかな変更でアドレスが無効になり、他の有効なアカウントと入れ替わる可能性はありません。これにより、タイプミスや送信エラーが発生しても、間違った場所に送金されることはありません。
+
+すべてのアカウントID（またはアドレス）が台帳のアカウントを参照しているわけではないことを知っておくことが重要です。キーとアドレスの導出は、純粋に数学的な操作です。アカウントがXRP Ledgerに情報を持つには、[XRPの支払いを受け](index.md#creating-accounts)、[準備金](reserves.md)を満たす必要があります。アカウントは、資金が供給されるまでトランザクションを送信することはできません。
+
+アカウントIDやアドレスが資金提供されたアカウントを指していない場合でも、そのアカウントIDやアドレスを使用して、[レギュラーキーペア](#レギュラーキーペア)や[署名者リストのメンバー](multi-signing.md)を表すことはできます。
+
+### キーの種類
+
+XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズム)をサポートしています。任意のキーペアは、特定の暗号化署名アルゴリズムに対してのみ有効です。いくつかの秘密鍵は、技術的には複数のアルゴリズムに対して有効な鍵として適格かもしれませんが、それらの秘密鍵は各アルゴリズムに対して異なる公開鍵を持つことになり、いずれにしても秘密鍵を再利用すべきではありません。
+
+[wallet_proposeメソッド][]の`key_type`フィールドは、使用する暗号化署名アルゴリズムを指します。
+
+
+## マスターキーペア
+
+マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](addresses.md#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
+
+[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからのレスポンスには、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](../transactions/secure-signing.md)をご覧ください。
+
+{% admonition type="warning" name="注意" %}悪意のある行為者があなたのマスター秘密鍵（またはシード）を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください！{% /admonition %}
+
+マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](../../tutorials/how-tos/manage-account-settings/offline-account-setup.md)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
+
+マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
+
+
+
+### 特殊な権限
+
+**マスターキーペアのみ**が、ある特定の処理を行うトランザクションを承認することができます。
+
+- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](../transactions/index.md#トランザクションの承認)して初期化することができないからです。
+
+- マスターキーペアを無効化する。
+
+- [フリーズ](../tokens/fungible-tokens/freezes.md#no-freeze)の機能を永久に放棄する。
+
+- トランザクションコスト0XRPの特別な[キーリセットトランザクション](../transactions/transaction-cost.md#key-resetトランザクション)を送信する。
+
+レギュラーキーや[マルチシグ](multi-signing.md)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](deleting-accounts.md)を行うことも可能です。
+
+
+## レギュラーキーペア
+
+XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセカンダリキーペアを許可することができます。そうすると、[マスターキーペア](#マスターキーペア)とレギュラーキーのどちらかを使ってトランザクションを承認することができるようになります。レギュラーキーペアは、アカウントの他の部分を変更することなく、いつでも削除または変更することができます。
+
+レギュラーキーペアは、マスターキーペアと同じ種類のトランザクションのほとんどを承認することができますが、[特定の例外](#特殊な権限)があります。例えば、レギュラーキーペアは、レギュラーキーペアを変更するトランザクションを _承認_ することができます。
+
+マスター秘密鍵はオフラインの場所に保存し、ほとんどの時間、レギュラーキーペアを使用することがセキュリティ上推奨されます。万一の備えとして、レギュラーキーペアを定期的に変更するのもよいでしょう。悪意のあるユーザにレギュラーの秘密鍵を知られてしまった場合、マスターキーペアをオフラインで保存し、それを使ってレギュラーキーペアを変更または削除することができます。こうすることで、アカウントの制御を取り戻すことができます。悪意のあるユーザにお金を盗まれるのを阻止するほどのスピードがなかったとしても、少なくとも、新しいアカウントに移行して、すべての設定や人間関係を一から作り直す必要はありません。
+
+レギュラーキーペアは、マスターキーペアと同じ形式です。生成方法も同じです（例えば、[wallet_proposeメソッド][]を使用します）。唯一の違いは、レギュラーキーペアは、トランザクションに署名するアカウントと本質的に結びついていないことです。あるアカウントのマスターキーペアを別のアカウントの通常キーペアとして使用することは可能です（ただし、推奨されるものではありません）。
+
+[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バイトになります。 |
+
+[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ビットのみを保持します）。
+
+### サンプルコード
+
+ここで説明する鍵導出プロセスは、さまざまなプログラミング言語で複数の場所に実装されています。
+
+- 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)
+- 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 "パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵")
+
+1. シード値の[SHA-512Half][]を計算します。32バイトの秘密鍵が導出されます。
+
+    {% 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 %}
+
+3. Ed25519公開鍵を示すには、32バイトの公開鍵の前にシングルバイトのプレフィクス`0xED`を付加し、33バイトにします。
+
+    トランザクションに署名するコードを実装している場合は、プレフィクス`0xED`を削除し、実際の署名プロセスに32バイトキーを使用します。
+
+4. アカウントの公開鍵を[base58][]にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
+
+    バリデータの一時キーに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 "パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア")
+
+XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よりも多くの手順が含まれる理由は次のとおりです。
+
+- 32バイトの数値がすべて、有効なsecp256k1秘密鍵であるとは限りません。
+- XRP Ledgerのリファレンス実装には、単一のシード値からキーペアのファミリーを導出するための、未使用の不完全なフレームワークがあります。
+
+シード値からXRP Ledgerのsecp256k1アカウントキーペアを導出する手順は次のとおりです。
+
+1. 次のように、シード値から「ルートキーペア」を計算します。
+
+    1. 以下を順番に連結して、合計20バイトにします。
+        - シード値（16バイト）
+        - 「ルートシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。ルートシーケンスの開始値として0を使用します。
+
+    2. 連結された（シード+ルートシーケンス）値の[SHA-512Half][]を計算します。
+
+    3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
+
+        有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。
+
+    4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、ルート公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
+
+    {% admonition type="success" name="ヒント" %}バリデータではこのルートキーペアを使用します。バリデータのキーペアを計算する場合は、ここで停止できます。この2つのタイプの公開鍵を区別するには、バリデータの公開鍵の[base58][]シリアル化でプレフィクス`0x1c`を使用します。{% /admonition %}
+
+2. ルート公開鍵を33バイトの圧縮形式に変換します。
+
+    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
+    ```
+
+3. 次のように、圧縮されたルート公開鍵から「仲介銀行（機関）キーペア」を導出します。
+
+    1. 以下を順番に連結して、合計40バイトにします。
+        - 圧縮されたルート公開鍵（33バイト）
+        - `0x00000000000000000000000000000000`(4バイトのゼロ)（この値は、同じファミリーの異なるメンバーの導出に使用することを目的としていましたが、実際には値0のみが使用されます。）
+        - 「キーシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。キーシーケンスの開始値として0を使用します。
+
+    2. 連結された値の[SHA-512Half][]を計算します。
+
+    3. 結果が有効なsecp256k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。
+
+    4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、仲介銀行（機関）公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
+
+4. 仲介銀行（機関）公開鍵をルート公開鍵に追加して、マスター公開鍵ペアを導出します。同様に、仲介銀行（機関）秘密鍵をルート秘密鍵に追加して秘密鍵を導出します。
+
+    - ECDSA秘密鍵は非常に大きな整数値であるため、secp256k1グループ順序を法として2つの秘密鍵を合計することで、2つの秘密鍵の合計を計算できます。
+
+    - ECDSA公開鍵は楕円曲線上の点であるため、楕円曲線の数値を使用して点の合計値を計算する必要があります。
+
+5. 以前と同様に、マスター公開鍵を33バイトの圧縮形式に変換します。
+
+6. アカウントの公開鍵を[base58][]形式にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
+
+    アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.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)
+- **リファレンス:**
+    - [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" /%}