[es-ES] First batch of files translated

[es-ES] First batch of files translated

@i18n/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

@i18n/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).

@i18n/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.

@i18n/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

@i18n/es-ES/docs/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](accounts.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" /%}

@i18n/es-ES/docs/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.html#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" /%}

@i18n/es-ES/docs/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 [esta sección de códigos de ejemplo del repositorio]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/key-derivation/py/key_derivation.py).
+- 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" /%}

@i18n/es-ES/docs/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" /%}

@i18n/es-ES/docs/accounts/deleting-accounts.md

@@ -0,0 +1,38 @@
+---
+html: deleting-accounts.html
+parent: accounts.html
+blurb: 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 2 XRP).
+
+## 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 10 XRP de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos 2 XRP haciéndolo.
+
+Instituciones que reciben y envían valor en nombre de muchos usuarios pueden utilizar [**Source Tags** y **Destination Tags**](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" /%}

@i18n/es-ES/docs/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 10 XRP). 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" /%}

@i18n/es-ES/docs/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 10 XRP), 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" /%}

@i18n/es-ES/docs/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" /%}

@i18n/es-ES/docs/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: **10 XRP**
+- Reserva de propietario: **2 XRP** 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" /%}

@i18n/es-ES/docs/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 2 XRP 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 2 XRP 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" /%}

@i18n/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 [XUMM](https://xumm.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)

@i18n/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 /%}

@i18n/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" /%}

@i18n/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)

@i18n/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)

@i18n/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)

CODE_OF_CONDUCT.es-ES.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

CONTRIBUTING.es-ES.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).

redocly.yaml

@@ -11,6 +11,8 @@ i18n:
       name: English
     - code: ja
       name: 日本語
+    - code: es-ES
+      name: Español
 redirects:
   $ref: redirects.yaml
 seo: