mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 15:45:50 +00:00
[es-ES] tokens/decentralized-exchange spanish translation
[es-ES] tokens/decentralized-exchange spanish translation
This commit is contained in:
Ekiserrepé
@@ -0,0 +1,26 @@
|
||||
---
|
||||
html: autobridging.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
description: El puente automático conecta automáticamente los libros de órdenes utilizando XRP como intermediario cuando reduce los costes.
|
||||
labels:
|
||||
- XRP
|
||||
- Exchange Descentralizado
|
||||
---
|
||||
# Puente automático
|
||||
|
||||
Cualquier [Oferta](offers.md) en el [exchange descentralizado](index.md) del XRP Ledger que intercambie dos tokens podría potencialmente utilizar XRP como moneda intermediaria en un libro de órdenes sintético. Esto se debe al _puente automático_, que sirve para mejorar la liquidez en todos los pares de activos utilizando XRP cuando es más barato que intercambiar directamente. Esto funciona debido a la naturaleza de XRP como criptomoneda nativa del XRP Ledger. La ejecución de la oferta puede utilizar una combinación de ofertas directas y ofertas auto-puenteadas para lograr la mejor tasa de cambio total.
|
||||
|
||||
Ejemplo: _Anita crea una oferta para vender GBP y comprar BRL. Ella podría encontrar que este mercado poco común tiene pocas ofertas. Hay una oferta con una buena tasa, pero tiene una cantidad insuficiente para satisfacer el intercambio de Anita. Sin embargo, tanto GBP como BRL tienen mercados activos y competitivos para XRP. El sistema de puente automático del XRP Ledger encuentra una forma de completar la oferta de Anita comprando XRP con GBP de un trader, luego vendiendo el XRP a otro trader para comprar BRL. Anita obtiene automáticamente la mejor tasa posible combinando la pequeña oferta en el mercado directo de GBP:BRL con las mejores tasas compuestas creadas emparejando las ofertas GBP:XRP y XRP:BRL._ <!-- SPELLING_IGNORE: gbp -->
|
||||
|
||||
El puente automático ocurre automáticamente en cualquier [transacción OfferCreate][]. Las [transacciones de Payment](../../../references/protocol/transactions/types/payment.md) _no_ usan auto-puente por defecto, pero path-finding pueden encontrar [rutas o paths](../fungible-tokens/paths.md) que tengan el mismo efecto.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [Dev Blog: Introducción al Autopuente](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) <!-- SPELLING_IGNORE: autobridging -->
|
||||
|
||||
- [Preferencia de oferta](offers.md#offer-preference)
|
||||
|
||||
- [Rutas de pago](../fungible-tokens/paths.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
html: automated-market-makers.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
title: ¿Qué es un Automated Market Maker (AMM)?
|
||||
description: Los Automated Market Makers (AMMs) son una parte esencial de las criptomonedas, proveen liquidez entre dos pares de activos. Aprende más sobre AMMs y el XRP Ledger.
|
||||
labels:
|
||||
- XRP
|
||||
- Exchange Descentralizado
|
||||
- AMM
|
||||
---
|
||||
# ¿Qué es un Automated Market Maker (AMM)?
|
||||
|
||||
_(Requiere la [enmienda AMM][] XLS-30)_
|
||||
|
||||
Los Creadores de Mercado Automatizados o Automated Market Maker (AMMs) son contratos inteligentes que proporcionan liquidez en el exchange descentralizado del XRP Ledger. Cada AMM posee un pool de dos activos y permite a los usuarios intercambiar entre ellos a una tasa de cambio establecida por una fórmula.
|
||||
|
||||
Para cualquier par de activos dado, puede haber hasta un AMM en el ledger. Cualquiera puede crear el AMM para un par de activos si aún no existe, o depositar en un AMM existente. Aquellos que depositan activos en un AMM se llaman proveedores de liquidez o _liquidity providers_ (LPs) y reciben "Tokens LP" del AMM. Los Tokens LP permiten a los proveedores de liquidez:
|
||||
|
||||
- Canjear sus Tokens LP por una parte de los activos en el pool del AMM, incluidas las tarifas recolectadas.
|
||||
- Votar para cambiar la configuración de tarifas del AMM. Los votos están ponderados en función de cuántos Tokens LP poseen los votantes.
|
||||
- Pujar con algunos de sus Tokens LP para recibir un descuento temporal en las tarifas de intercambio del AMM.
|
||||
|
||||
Cuando el flujo de fondos entre los dos activos en un pool es relativamente activo y equilibrado, las tarifas proporcionan una fuente de ingresos pasivos para los proveedores de liquidez. Sin embargo, cuando el precio relativo entre los activos cambia, los proveedores de liquidez pueden sufrir una pérdida en el [riesgo de divisa](https://www.investopedia.com/terms/c/currencyrisk.asp).
|
||||
|
||||
## ¿Cómo funciona el AMM?
|
||||
|
||||
Un AMM posee dos activos diferentes: como máximo, uno de estos puede ser XRP, y uno o ambos pueden ser [tokens](../index.md). Los tokens con diferentes emisores se consideran activos diferentes para este propósito. Esto significa que puede haber un AMM para dos tokens con el mismo código de moneda pero diferentes emisores ("FOO emitido por WayGate" es diferente de "FOO emitido por StableFoo"), o el mismo emisor pero diferentes códigos de moneda. El orden no importa; el AMM para FOO.WayGate a XRP es el mismo que para XRP a FOO.WayGate.
|
||||
|
||||
Cuando los usuarios desean comerciar en el exchange descentralizado, sus [Ofertas](offers.md) y [Pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden utilizar automáticamente los AMMs para completar el intercambio. Una sola transacción podría ejecutarse mediante la coincidencia de Ofertas, AMMs o una combinación de ambos, dependiendo de lo que sea más económico.
|
||||
|
||||
Un AMM establece su tasa de cambio en función del saldo de activos en el pool. Cuando intercambias contra un AMM, la tasa de cambio se ajusta según cuánto tu intercambio desequilibre el saldo de activos que el AMM posee. A medida que su suministro de un activo disminuye, el precio de ese activo sube; a medida que su suministro de un activo aumenta, el precio de ese activo baja. Un AMM ofrece tasas de cambio generalmente mejores cuando tiene cantidades más grandes en general en su pool. Esto se debe a que cualquier intercambio dado causa un cambio más pequeño en el equilibrio de los activos del AMM. Cuanto más desequilibre un intercambio el suministro de los dos activos del AMM, más extrema se vuelve la tasa de cambio.
|
||||
|
||||
El AMM también cobra una tarifa de intercambio porcentual además de la tasa de cambio.
|
||||
|
||||
El XRP Ledger implementa un AMM de _media geométrica_ con un parámetro de peso de 0.5, por lo que funciona como un creador de mercado de _producto constante_. Para obtener una explicación detallada de la fórmula AMM de _producto constante_ y la economía de los AMMs en general, consulta [Introducción a los Automated Market Makers de Kris Machowski](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/).
|
||||
|
||||
### Restricciones sobre los activos
|
||||
|
||||
Para evitar el mal uso, se aplican algunas restricciones a los activos utilizados en un AMM. Si intentas crear un AMM con un activo que no cumple con estas restricciones, la transacción falla. Las reglas son las siguientes:
|
||||
|
||||
- El activo no debe ser un Token LP de otro AMM.
|
||||
- Si el activo es un token cuyo emisor utiliza [Authorized Trust Lines](../fungible-tokens/authorized-trust-lines.md), el creador del AMM debe estar autorizado para poseer esos tokens. Solo los usuarios cuyas líneas de confianza (trustlines) estén autorizadas pueden depositar ese token en el AMM o retirarlo; sin embargo, los usuarios aún pueden depositar o retirar el otro activo.
|
||||
- Si la [enmienda Clawback][] está habilitada, el emisor del token no debe haber habilitado la capacidad de recuperar sus tokens.
|
||||
|
||||
|
||||
## Tokens LP
|
||||
<!-- TODO: add diagrams showcasing flow of funds -->
|
||||
Quien crea el AMM se convierte en el primer proveedor de liquidez y recibe Tokens LP que representan el 100% de la propiedad de los activos en el pool del AMM. Pueden canjear algunos o todos esos Tokens LP para retirar activos del AMM en proporción a las cantidades actualmente allí. (Las proporciones cambian con el tiempo a medida que las personas comercian contra el AMM). El AMM no cobra una tarifa al retirar ambos activos.
|
||||
|
||||
Por ejemplo, si creaste un AMM con 5 ETH y 5 USD, y luego alguien cambió 1.26 USD por 1 ETH, el pool ahora tiene 4 ETH y 6.26 USD en él. Puedes gastar la mitad de tus Tokens LP para retirar 2 ETH y 3.13 USD.
|
||||
|
||||
Cualquiera puede depositar activos en un AMM existente. Cuando se hace, se reciben nuevos Tokens LP según lo que depositaron. La cantidad que un proveedor de liquidez puede retirar de un AMM se basa en la proporción de los Tokens LP del AMM que poseen en comparación con el número total de Tokens LP pendientes.
|
||||
|
||||
Los Tokens LP son como otros tokens en el XRP Ledger, por lo que puedes usarlos en muchos [tipos de pagos](../../payment-types/index.md) o intercambiarlos en el exchange descentralizado. (Para recibir Tokens LP como pago, debes configurar una [trust line](../fungible-tokens/index.md) con un límite distinto de cero con la cuenta del AMM como emisor). Sin embargo, _solo_ puedes enviar Tokens LP directamente al AMM (canjeándolos) usando el tipo de transacción [AMMWithdraw][], no a través de otros tipos de pagos. Del mismo modo, solo puedes enviar activos al pool del AMM a través del tipo de transacción [AMMDeposit][].
|
||||
|
||||
El AMM está diseñado de manera que el pool de activos de un AMM esté vacío si y solo si el AMM no tiene Tokens LP pendientes. Esta situación solo puede ocurrir como resultado de una transacción [AMMWithdraw][]; cuando ocurre, el AMM se elimina automáticamente.
|
||||
|
||||
### Códigos de moneda de Tokens LP
|
||||
|
||||
Los Tokens LP utilizan un tipo especial de código de moneda en el formato hexadecimal de 160 bits ["no estándar"](../../../references/protocol/data-types/currency-formats.md#nonstandard-currency-codes). Estos códigos tienen los primeros 8 bits `0x03`. El resto del código es un hash SHA-512, truncado a los primeros 152 bits, de los códigos de moneda de los dos activos y sus emisores. (Los activos se colocan en un "orden canónico" con el par de moneda+emisor numéricamente inferior primero). Como resultado, los Tokens LP para un par de activos dado de un AMM tienen un código de moneda predecible y consistente.
|
||||
|
||||
|
||||
## Tarifas de intercambio
|
||||
|
||||
Las tarifas de intercambio son una fuente de ingresos pasivos para los proveedores de liquidez, y compensan el riesgo cambiario de permitir que otros intercambien activos del pool. Las tarifas de intercambio se pagan al AMM, no directamente a los proveedores de liquidez, pero estos se benefician porque sus Tokens LP se pueden canjear por un porcentaje del pool del AMM.
|
||||
|
||||
Los proveedores de liquidez pueden votar para establecer la tarifa del 0% al 1%, en incrementos de 0.001%. Los proveedores de liquidez tienen un incentivo para establecer las tarifas de intercambio a una tasa adecuada: si las tarifas son demasiado altas, los intercambios usarán libros de pedidos para obtener una mejor tasa; si las tarifas son demasiado bajas, los proveedores de liquidez no obtienen ningún beneficio por contribuir al pool. <!-- STYLE_OVERRIDE: will --> Cada AMM da a sus proveedores de liquidez el poder de votar sobre sus tarifas, en proporción a la cantidad de Tokens LP que poseen esos proveedores de liquidez.
|
||||
|
||||
Para votar, un proveedor de liquidez envía una [transacción AMMVote][]. Cada vez que alguien realiza una nueva votación, el AMM recalcula su tarifa para ser un promedio de las últimas votaciones ponderadas por la cantidad de Tokens LP que poseen esos votantes. Se pueden contar hasta 8 votos de proveedores de liquidez de esta manera; si más proveedores de liquidez intentan votar, solo se contarán los 8 mejores votos (por la mayor cantidad de Tokens LP que poseen). Aunque la participación de los proveedores de liquidez en Tokens LP puede cambiar rápidamente por muchas razones (como el comercio de esos tokens usando [Ofertas](offers.md)), las tarifas de intercambio solo se recalculan cuando alguien realiza una nueva votación (incluso si esa votación no está entre los 8 mejores).
|
||||
|
||||
### Slot de subasta
|
||||
|
||||
A diferencia de cualquier Automated Market Maker anterior, el diseño de AMM del XRP Ledger tiene un _slot de subasta_ en la que un proveedor de liquidez puede pujar para obtener un descuento en la tarifa de intercambio durante un período de 24 horas. La oferta debe pagarse en Tokens LP, que se devuelven al AMM. No más de una cuenta puede tener el slot de subasta al mismo tiempo, pero el ofertante puede nombrar hasta 4 cuentas adicionales para también recibir el descuento. No hay una oferta mínima, pero si el slot está ocupado actualmente, debes superar al titular actual del slot para desplazarlos. Si alguien te desplaza, recuperas parte de tu oferta según el tiempo restante. Mientras mantengas un slot de subasta activo, pagas una tarifa de intercambio con descuento igual a 1/10 (una décima parte) de la tarifa de intercambio normal al realizar operaciones contra ese AMM.
|
||||
|
||||
Con cualquier AMM, cuando el precio de sus activos cambia significativamente en los mercados externos, los traders pueden usar arbitraje para obtener beneficios del AMM, lo que resulta en una pérdida para los proveedores de liquidez. El mecanismo de subasta tiene como objetivo devolver más de ese valor a los proveedores de liquidez y llevar los precios del AMM más rápidamente de vuelta al equilibrio con los mercados externos.
|
||||
|
||||
|
||||
## Representación en el Ledger
|
||||
|
||||
En los datos de estado del ledger, un AMM consiste en múltiples [entradas de ledger](../../../references/protocol/ledger-data/ledger-entry-types/index.md):
|
||||
|
||||
- Una [entrada AMM][] que describe el creador de mercado automatizado en sí mismo.
|
||||
|
||||
- Una [entrada AccountRoot][] especial que emite Tokens LP del AMM, y tiene XRP del AMM (si lo tiene).
|
||||
|
||||
La dirección de esta AccountRoot se elige de forma algo aleatoria cuando se crea el AMM, y es diferente si el AMM se elimina y se vuelve a crear. Esto puede prevenir que las personas financien la cuenta AMM con XRP excesivo por adelantado.
|
||||
|
||||
- Las [Trust lines](../fungible-tokens/index.md) a la cuenta especial AMM para los tokens en el pool del AMM.
|
||||
|
||||
Estas entradas de ledger no son propiedad de ninguna cuenta, por lo que el [requisito de reserva](../../accounts/reserves.md) no se aplica a ellas. Sin embargo, para prevenir el spam, la transacción para crear un AMM tiene un [coste de transacción](../../transactions/transaction-cost.md) especial que requiere que el remitente queme una cantidad de XRP mayor de lo habitual.
|
||||
|
||||
|
||||
## Eliminación
|
||||
|
||||
Un AMM se elimina cuando una [transacción AMMWithdraw][] retira todos los activos de su pool. Esto solo ocurre canjeando todos los Tokens LP pendientes del AMM. La eliminación del AMM incluye la eliminación de todas las entradas del ledger asociadas con él, como:
|
||||
|
||||
- AMM
|
||||
- AccountRoot
|
||||
- Trust lines para los Tokens LP del AMM. Estas trust lines tendrían un saldo de 0 pero pueden tener otros detalles como el límite, establecido en un valor no predeterminado.
|
||||
- Las Trust lines para los tokens que estaban en el pool del AMM.
|
||||
|
||||
Si hay más de 512 trust lines enlazadas a la cuenta del AMM cuando se eliminase, el proceso de retiro tiene éxito y elimina tantas trust lines como puede, pero deja el AMM en el ledger sin activos en su pool.
|
||||
|
||||
Mientras un AMM no tenga activos en su pool, cualquiera puede eliminarlo enviando una [transacción AMMDelete][]; si el número restante de líneas de confianza sigue siendo mayor que el límite, pueden ser necesarias múltiples transacciones AMMDelete para eliminar completamente el AMM. Alternativamente, cualquier persona puede realizar un [depósito especial](../../../references/protocol/transactions/types/ammdeposit.md#empty-amm-special-case) para financiar el AMM como si fuera nuevo.
|
||||
|
||||
No hay reembolso o incentivo para eliminar un AMM vacío.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
html: decentralized-exchange.html
|
||||
parent: tokens.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: El XRP Ledger contiene un exchange completamente funcional donde los usuarios pueden intercambiar tokens por XRP o entre sí.
|
||||
targets:
|
||||
- en
|
||||
---
|
||||
# Exchange descentralizado
|
||||
|
||||
El XRP Ledger posiblemente tenga el _exchange descentralizado_ más antiguo del mundo (a veces abreviado como "DEX"), operando de manera continua desde el lanzamiento del XRP Ledger en 2012. Este exchange permite a los usuarios comprar y vender [tokens](../index.md) por XRP u otros tokens, con [costes](../../transactions/fees.md) mínimos cargados a la red misma (no pagados a ninguna parte).
|
||||
|
||||
**Atención**: Cualquiera puede [emitir un token](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) con el código de moneda o símbolo de ticker que desee y venderlo en el exchange descentralizado. Siempre realiza una debida diligencia antes de comprar un token y presta atención al emisor. De lo contrario, podrías entregar algo de valor y recibir tokens sin valor a cambio.
|
||||
|
||||
## Estructura
|
||||
|
||||
El exchange descentralizado del XRP Ledger consta de un número ilimitado de pares de divisas, rastreados según la demanda cuando los usuarios realizan intercambios. Un par de divisas puede consistir en XRP y un token o dos tokens diferentes; los tokens siempre se identifican por la combinación de un emisor y un código de moneda. Es posible comerciar entre dos tokens con el mismo código de moneda y diferentes emisores, o el mismo emisor y diferentes códigos de moneda. <!-- STYLE_OVERRIDE: limited number -->
|
||||
|
||||
Como con todos los cambios en el XRP Ledger, necesitas enviar una [transacción](../../transactions/index.md) para realizar un intercambio. Un intercambio en el XRP Ledger se conoce como Oferta u [Offer](offers.md). Una Oferta es efectivamente una [_Orden límite_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) para comprar o vender una cantidad específica de una moneda (XRP o un token) por una cantidad específica de otra. Cuando la red ejecuta una Oferta, si hay otras Ofertas coincidentes para el mismo par de divisas, estas se consumen comenzando con la mejor tasa de cambio primero.
|
||||
|
||||
Una Oferta puede llenarse completamente o parcialmente; si no se llena completamente de inmediato, se convierte en un objeto de Oferta pasiva en el ledger para la cantidad restante. Más adelante, otras Ofertas o [pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden coincidir y consumir la Oferta. Debido a esto, las Ofertas pueden ejecutarse a un mejor precio que el solicitado inicialmente, o exactamente al tipo de cambio indicado más tarde (excepto por diferencias menores para tener en cuenta el redondeo).
|
||||
|
||||
Las Ofertas pueden cancelarse manual o automáticamente después de ser colocadas. Para obtener detalles sobre esto y otras propiedades de las Ofertas, consulta [Ofertas](offers.md).
|
||||
|
||||
Al comerciar con dos tokens, el [puente automático](autobridging.md) mejora las tasas de cambio y la liquidez al intercambiar automáticamente token por XRP y XRP por token cuando hacerlo es más barato que intercambiar directamente token por token.
|
||||
|
||||
### Ejemplo de intercambio
|
||||
|
||||
[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.svg" /%}](/docs/img/decentralized-exchange-example-trade.svg "Diagrama: Oferta parcialmente completada para comprar un token con XRP.")
|
||||
|
||||
El diagrama anterior muestra un ejemplo de intercambio en el exchange descentralizado. En este ejemplo, un trader llamado Tran coloca una Oferta para comprar 100 tokens con el código de moneda FOO emitido por un negocio ficticio llamado WayGate. (Por brevedad, "FOO.WayGate" se refiere a estos tokens.) Tran especifica que está dispuesto a gastar hasta 1000 XRP en total. Cuando la transacción de Tran es procesada, ocurren las siguientes cosas:
|
||||
|
||||
1. La red calcula la tasa de cambio de la Oferta de Tran, dividiendo la cantidad a comprar por la cantidad a pagar.
|
||||
0. La red encuentra el libro de órdenes para el reverso de la Oferta de Tran: en este caso, eso significa el libro de órdenes para vender FOO.WayGate y comprar XRP. Este libro de órdenes ya tiene varias Ofertas existentes de otros traders para diferentes cantidades y tasas de cambio.
|
||||
0. La Oferta de Tran "consume" Ofertas coincidentes, comenzando con la mejor tasa de cambio y trabajando hacia abajo, hasta que la Oferta de Tran se haya llenado por completo o no haya más Ofertas cuya tasa de cambio sea igual o mejor que la tasa especificada en la Oferta de Tran. En este ejemplo, solo hay disponibles 22 FOO.WayGate a la tasa solicitada o mejor. Las Ofertas consumidas se eliminan del libro de órdenes.
|
||||
0. Tran recibe la cantidad de FOO.WayGate que el intercambio pudo adquirir, de los varios traders que previamente habían colocado órdenes para venderlo. Estos tokens van a la [trust line](../fungible-tokens/index.md) de Tran a WayGate para FOO. (Si Tran no tenía esa trust line previamente, se crea automáticamente una).
|
||||
0. A cambio, esos traders reciben XRP de Tran de acuerdo con sus tasas de cambio declaradas.
|
||||
0. La red calcula el resto de la Oferta de Tran: dado que la Oferta original era para comprar 100 FOO.WayGate y hasta ahora Tran ha recibido 22, el resto es de 78 FOO.WayGate. Usando la tasa de cambio original, eso significa que el resto de la Oferta de Tran ahora es comprar 78 FOO.WayGate por 780 XRP.
|
||||
0. El "resto" resultante se coloca en el libro de órdenes para intercambios en la misma dirección que la de Tran: vendiendo XRP y comprando FOO.WayGate.
|
||||
|
||||
Las transacciones posteriores, incluidas aquellas ejecutadas inmediatamente después de las de Tran en el _mismo_ ledger, utilizan los libros de órdenes actualizados para sus intercambios, por lo que pueden consumir parte o toda la Oferta de Tran hasta que se llene por completo o Tran la cancele.
|
||||
|
||||
**Nota**: El orden canónico en el que las transacciones se ejecutan cuando se cierra y valida un ledger no es el mismo que el orden en el que se enviaron esas transacciones. Cuando varias transacciones afectan al mismo libro de órdenes en el mismo ledger, los resultados finales de esas transacciones pueden ser muy diferentes a los resultados tentativos calculados en el momento del envío de la transacción. Para obtener más detalles sobre cuándo los resultados de las transacciones son o no finales, consulta [Finalidad de resultados](../../transactions/finality-of-results/index.md).
|
||||
|
||||
|
||||
## Limitaciones
|
||||
|
||||
El exchange descentralizado está diseñado con las siguientes limitaciones:
|
||||
|
||||
Debido a que los intercambios se ejecutan solo cada vez que se cierra un nuevo ledger (aproximadamente cada 3-5 segundos), el XRP Ledger no es adecuado para el [trading de alta frecuencia](https://en.wikipedia.org/wiki/High-frequency_trading). El orden en el que las transacciones se ejecutan dentro de un ledger está diseñado para ser impredecible, para desalentar el [front-running](https://en.wikipedia.org/wiki/Front_running).
|
||||
|
||||
El XRP Ledger no representa nativamente conceptos como órdenes de mercado, órdenes de stop o trading con apalancamiento. Algunos de estos pueden ser posibles con el uso creativo de tokens personalizados y propiedades de Oferta.
|
||||
|
||||
Como sistema descentralizado, el XRP Ledger no tiene información sobre las personas y organizaciones reales detrás de las [cuentas](../../accounts/index.md) involucradas en el trading. El Ledger en sí no puede implementar restricciones sobre quién puede o no puede participar en el trading, y los usuarios y emisores deben tener cuidado de seguir todas las leyes relevantes para regular el trading de tokens que representan varios tipos de activos subyacentes. Funciones como [congelamientos](../fungible-tokens/freezes.md) y [trust lines autorizadas](../fungible-tokens/authorized-trust-lines.md) están destinadas a ayudar a los emisores a cumplir con las leyes y regulaciones relevantes.
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- Ver [Ofetas](offers.md) para obtener detalles sobre cómo funcionan los intercambios en el XRP Ledger.
|
||||
- Ver [Tokens](../index.md) para obtener una descripción general de cómo se pueden representar diversos tipos de valor en el XRP Ledger.
|
||||
- **Referencias:**
|
||||
- [método account_offers][] para buscar Ofertas creadas por una cuenta
|
||||
- [método book_offers][] para buscar Ofertas de compra o venta según un par de divisas dado
|
||||
- [transacción OfferCreate][] para crear una Oferta nueva o reemplazar una Oferta existente
|
||||
- [transacción OfferCancel][] para cancelar una Oferta existente
|
||||
- [objeto Offer][] para la estructura de datos de las Ofertas pasivas en el ledger
|
||||
- [objeto DirectoryNode][] para la estructura de datos que sigue todas las Ofertas para un par de divisas y tarifa de intercambio dados.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
html: offers.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
description: Las ofertas son la forma de órdenes de comercio de divisas del XRP Ledger. Comprende su ciclo de vida y propiedades.
|
||||
labels:
|
||||
- Exchange Descentralizado
|
||||
---
|
||||
# Ofertas
|
||||
|
||||
En el [exchange descentralizado](index.md) del XRP Ledger, las órdenes de intercambio se llaman "Ofertas". Las Ofertas pueden intercambiar XRP con [tokens](../index.md), o tokens por otros tokens, incluyendo tokens con el mismo código de moneda pero diferentes emisores. (Los tokens con el mismo código pero diferentes emisores también a veces pueden intercambiarse a través de [rippling](../fungible-tokens/rippling.md).)
|
||||
|
||||
- Para crear una Oferta, envía una [transacción OfferCreate][].
|
||||
- Las Ofertas que no se completan totalmente inmediatamente se convierten en [objetos Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md) en los datos del ledger. Ofertas posteriores o Pagos pueden consumir el objeto Oferta desde el ledger.
|
||||
- [Pagos entre divisas](../../payment-types/cross-currency-payments.md) consumen Ofertas para proveer liquidez, nunca crean objetos de Oferta en el ledger.
|
||||
|
||||
## Ciclo de vida para una Oferta
|
||||
|
||||
Una [transacción OfferCreate][] es una instrucción para realizar un intercambio, ya sea entre dos tokens, o un token y XRP. Cada transacción de este tipo contiene una cantidad de compra (`TakerPays`) y una cantidad de venta (`TakerGets`). Cuando se procesa la transacción, consume automáticamente Ofertas coincidentes o cruzadas en la medida de lo posible. Si eso no llena completamente la nueva Oferta, entonces el resto se convierte en un objeto de Oferta en el ledger.
|
||||
|
||||
El objeto de Oferta espera en el ledger hasta que otras Ofertas o pagos entre divisas lo consumen completamente. La cuenta que colocó la Oferta se llama el _propietario_ de la Oferta. Puedes cancelar tus propias Ofertas en cualquier momento, usando la [transacción OfferCancel][] dedicada, o como opción de la [transacción OfferCreate][].
|
||||
|
||||
Mientras tengas una Oferta en el ledger, se aparta parte de tu XRP hacia la [reserva de propietario](../../accounts/reserves.md). Cuando se elimina la Oferta, por cualquier motivo, ese XRP se libera nuevamente.
|
||||
|
||||
### Variaciones
|
||||
|
||||
- **Compra vs. Venta**: Por defecto, las Ofertas son Ofertas de "compra" y se consideran completamente llenas cuando has adquirido la cantidad total de "compra" (`TakerPays`). (Puedes gastar menos de lo esperado mientras recibes la cantidad especificada.) En contraste, una Oferta de "venta" solo se considera completamente llena cuando has gastado la cantidad total de "venta" (`TakerGets`). (Puedes recibir más de lo esperado mientras gastas la cantidad especificada.) Esto solo es relevante si la Oferta se ejecuta _inicialmente_ a un tipo de cambio mejor que el solicitado: después de que la Oferta se coloca en el ledger, solo se ejecuta _exactamente_ al tipo de cambio solicitado.
|
||||
- Una Oferta **Inmediata o Cancelar** no se coloca en el ledger, por lo que solo intercambia hasta la cantidad que coincide con Ofertas existentes en el momento en que se procesa la transacción.
|
||||
- Una Oferta **Completar o Cancelar** no se coloca en el ledger, _y_ se cancela si la cantidad total no se completa cuando se ejecuta inicialmente. Esto es similar a "Inmediata o Cancelar", excepto que _no puede_ completarse parcialmente.
|
||||
- Una Oferta **Pasiva** no consume Ofertas coincidentes que tengan el mismo tipo de cambio (en la otra dirección), y en su lugar se coloca directamente en el ledger. Puedes usar esto para crear un peg exacto entre dos activos. Las Ofertas Pasivas aún consumen otras Ofertas que tienen un tipo de cambio _mejor_ en la otra dirección.
|
||||
|
||||
|
||||
### Requisitos de financiación
|
||||
|
||||
Cuando intentas realizar una Oferta, la transacción se rechaza como "no financiada" si no tienes al menos parte del activo que la operación vendería. Más específicamente:
|
||||
|
||||
**Para vender un token,** debes:
|
||||
|
||||
- Tener una cantidad positiva de ese token, _o_
|
||||
- Ser el emisor del token.
|
||||
|
||||
Sin embargo, no necesitas tener la cantidad completa especificada en la Oferta. Colocar una Oferta no bloquea tus fondos, por lo que puedes colocar múltiples Ofertas para vender los mismos tokens (o XRP), o colocar una Oferta y esperar obtener suficientes tokens o XRP para financiarla completamente más adelante.
|
||||
|
||||
**Para vender XRP**, debes tener suficiente XRP para cumplir con todos los [requisitos de reserva](../../accounts/reserves.md), incluida la reserva para que el objeto de Oferta se coloque en el ledger y para la trust line para mantener el token que estás comprando. Mientras tengas XRP restante después de apartar la cantidad de reserva, puedes colocar la Oferta.
|
||||
|
||||
Cuando otra Oferta coincide con la tuya, ambas Ofertas se ejecutan en la medida en que los fondos de sus propietarios lo permitan en ese momento. Si hay Ofertas coincidentes y te quedas sin fondos antes de que la tuya se finalice por completo, el resto de tu Oferta se cancela. Una Oferta no puede hacer que tu saldo de un token sea negativo, a menos que seas el emisor de ese token. (Si eres el emisor, puedes usar Ofertas para emitir nuevos tokens hasta el monto total especificado en tus Ofertas; los tokens que emites se representan como saldos negativos desde tu perspectiva.)
|
||||
|
||||
Si colocas una Oferta que cruza alguna de tus propias Ofertas que existen en el ledger, las Ofertas antiguas cruzadas se cancelan automáticamente independientemente de las cantidades involucradas.
|
||||
|
||||
Es posible que una Oferta se vuelva temporal o permanentemente _no financiada_ en los siguientes casos:
|
||||
|
||||
- Si el propietario ya no tiene ningún activo de venta.
|
||||
- La Oferta se vuelve financiada nuevamente cuando el propietario obtiene más de ese activo.
|
||||
- Si el activo en venta es un token en una [trust line congelada](../fungible-tokens/freezes.md).
|
||||
- La Oferta se vuelve financiada nuevamente cuando la trust line ya no está congelada.
|
||||
- Si la Oferta necesita crear una nueva trust line, pero el dueño no tiene suficiente XRP para el aumento de la [reserva](../../accounts/reserves.md). (Ver [Ofertas y confianza](#offers-and-trust).)
|
||||
- La oferta vuelve a estar financiada cuando el propietario obtiene más XRP, o los requisitos de reserva disminuyen.
|
||||
- Si la Oferta ha expirado. (Ver [Expiración de ofertas](#offer-expiration).)
|
||||
|
||||
Una Oferta no financiada permanece en el ledger hasta que una transacción la elimine. Las formas en que una Oferta puede ser eliminada del ledger incluyen:
|
||||
|
||||
- Una Oferta coincidente o [Pago entre divisas](../../payment-types/cross-currency-payments.md) que consuman completamente la Oferta.
|
||||
- El propietario cancela explicitamente la Oferta.
|
||||
- El propietario cancela implícitamente la Oferta enviando una nueva Oferta que la cruza.
|
||||
- La Oferta es encontrada sin financiar o expirada durante el procesamiento de la transacción. Normalmente esto significa que otra Oferta intentó consumirla y no pudo hacerlo.
|
||||
- Esto incluye casos donde la cantidad restante puede ser pagada mediante la Oferta redondeada a cero.
|
||||
|
||||
### Seguimiento de ofertas no financiadas
|
||||
|
||||
Seguir el estado de financiación de todas las Ofertas puede ser computacionalmente exigente. En particular, las direcciones que están operando activamente pueden tener un gran número de Ofertas abiertas. Un solo balance puede afectar el estado de financiación de muchas Ofertas. Debido a esto, el XRP Ledger no encuentra y elimina _proactivamente_ Ofertas no financiadas o expiradas.
|
||||
|
||||
Una aplicación de cliente puede seguir localmente el estado de financiación de las Ofertas. Para hacerlo, primero recupera un libro de órdenes utilizando el [método book_offers][] y verifica el campo `taker_gets_funded` de las Ofertas. Luego, [suscríbete](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md) al flujo de `transactions` y observa los metadatos de transacción para ver qué Ofertas se modifican.
|
||||
|
||||
|
||||
## Ofertas y confianza
|
||||
|
||||
Los valores límite de las [trust lines](../fungible-tokens/index.md) no afectan a las Ofertas. En otras palabras, puedes usar una Oferta para adquirir más de la cantidad máxima en la que confías en un emisor.
|
||||
|
||||
Sin embargo, mantener tokens aún requiere una trust line con el emisor. Cuando una Oferta se consume, automáticamente crea cualquier trust line necesaria, estableciendo sus límites en 0. Debido a que [las trust lines aumentan la reserva que una cuenta debe mantener](../../accounts/reserves.md), cualquier Oferta que requiera una nueva trust line también requiere que la dirección tenga suficiente XRP para cumplir con la reserva de esa trust line.
|
||||
|
||||
Los límites de la trust line te protegen de recibir más de un token como pago de lo que deseas. Las Ofertas pueden superar esos límites porque son una declaración explícita de cuánto del token deseas.
|
||||
|
||||
|
||||
## Preferencia de Oferta
|
||||
|
||||
Las Ofertas existentes se agrupan por tipo de cambio, que se mide como la relación entre `TakerGets` y `TakerPays`. Las Ofertas con un tipo de cambio más alto se toman preferentemente. (Es decir, la persona que acepta la oferta recibe tanto como sea posible por la cantidad de moneda que paga). Las Ofertas con el mismo tipo de cambio se toman en función de cuál se colocó primero.
|
||||
|
||||
Cuando las Ofertas se ejecutan en el mismo bloque del ledger, el orden en que se ejecutan se determina por el [orden canónico](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Código fuente: Ordenación de transacciones") en el que las transacciones fueron [aplicadas en el ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Código fuente: Aplicando transacciones"). Este comportamiento está diseñado para ser determinista, eficiente y difícil de manipular.
|
||||
|
||||
|
||||
## Caducidad de la oferta
|
||||
|
||||
Cuando colocas una Oferta, puedes opcionalmente añadirle un tiempo de caducidad. Por defecto, las Ofertas no caducan. No puedes crear una nueva Oferta que ya esté caducada.
|
||||
|
||||
Los tiempos de caducidad se especifican hasta el segundo, pero el momento exacto en el que una Oferta caduca en el mundo real es menos preciso. Una Oferta caduca si tiene una hora de caducidad que es _anterior o igual al_ momento de cierre del ledger anterior. De lo contrario, la Oferta aún puede ejecutarse, incluso si el momento real es posterior a la caducidad de la Oferta. En otras palabras, una Oferta sigue "activa" si su hora de caducidad es posterior al momento de cierre del último ledger validado, independientemente de lo que diga tu reloj.
|
||||
|
||||
Esto es una consecuencia de cómo la red alcanza un acuerdo. Para que toda la red peer-to-peer alcance un consenso, todos los servidores deben estar de acuerdo en qué Ofertas han caducado al ejecutar transacciones. Los servidores individuales pueden tener pequeñas diferencias en su configuración interna de reloj, por lo que podrían no llegar a las mismas conclusiones sobre qué Ofertas han caducado si cada uno usara el tiempo "actual". El momento de cierre de un ledger no se conoce hasta después de que las transacciones en ese ledger se hayan ejecutado, por lo que los servidores utilizan el momento oficial de cierre del ledger _anterior_ en su lugar. Los [tiempos de cierre de los ledgers se redondean](../../ledgers/ledger-close-times.md), lo que aumenta aún más la diferencia potencial entre el tiempo real y el tiempo utilizado para determinar si una Oferta ha caducado.
|
||||
|
||||
**Nota:** Las Ofertas caducadas permanecen en los datos del ledger hasta que una transacción las elimine. Hasta entonces, pueden continuar apareciendo en los datos recuperados a través de la API (por ejemplo, utilizando el [método ledger_entry][]). Las transacciones eliminan automáticamente cualquier Oferta caducada y no financiada que encuentren, generalmente mientras ejecutan Ofertas o pagos de monedas cruzadas que las hubieran igualado o cancelado. La reserva del propietario asociada con una Oferta solo vuelve a estar disponible cuando la Oferta se elimina realmente.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Tokens](../index.md)
|
||||
- [Paths](../fungible-tokens/paths.md)
|
||||
- **Referencias:**
|
||||
- [método account_offers][]
|
||||
- [método book_offers][]
|
||||
- [transacción OfferCreate][]
|
||||
- [transacción OfferCancel][]
|
||||
- [Objeto Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
html: ticksize.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
description: Los emisores pueden establecer tamaños de ticks personalizados para las monedas para reducir la rotación de libros de pedidos por diferencias minúsculas en los tipos de cambio.
|
||||
labels:
|
||||
- Exchange Descentralizado
|
||||
- Tokens
|
||||
---
|
||||
# Tamaño de Tick
|
||||
|
||||
Cuando se coloca una Oferta en un libro de órdenes, su tasa de cambio se trunca en base a los valores de `TickSize` establecidos por los emisores de las monedas involucradas en la Oferta. Cuando se negocia XRP y un token, se aplica el `TickSize` del emisor del token. Cuando se negocian dos tokens, la Oferta utiliza el valor de `TickSize` más pequeño (es decir, el que tiene menos dígitos significativos). Si ninguno de los tokens tiene un `TickSize` establecido, se aplica el comportamiento predeterminado.
|
||||
|
||||
El valor de `TickSize` trunca la cantidad de _dígitos significativos_ en la tasa de cambio de una oferta cuando se coloca en un libro de órdenes. Los emisores pueden establecer `TickSize` como un número entero de `3` a `15` usando una [transacción AccountSet][]. La tasa de cambio se representa como dígitos significativos y un exponente; el `TickSize` no afecta al exponente. Esto permite que el XRP Ledger represente tasas de cambio entre activos que varían considerablemente en valor (por ejemplo, una moneda altamente inflada en comparación con un activo raro). Cuanto menor sea el `TickSize` que establezca un emisor, mayor será el incremento que los traders deben ofrecer para considerarse una tasa de cambio más alta que las Ofertas existentes.
|
||||
|
||||
El `TickSize` no afecta a la parte de una Oferta que se puede ejecutar inmediatamente. (Por esa razón, las transacciones OfferCreate con `tfImmediateOrCancel` no se ven afectadas por los valores de `TickSize`.) Si la Oferta no puede ejecutarse completamente, el motor de procesamiento de transacciones calcula la tasa de cambio y la trunca en base a `TickSize`. Luego, el motor redondea la cantidad restante de la Oferta desde el lado "menos importante" para que coincida con la tasa de cambio truncada. Para una transacción OfferCreate predeterminada (una Oferta de "compra"), la cantidad de `TakerPays` (la cantidad que se compra) se redondea. Si se activa la bandera `tfSell` (una Oferta de "venta"), la cantidad de `TakerGets` (la cantidad que se vende) se redondea.
|
||||
|
||||
Cuando un emisor habilita, deshabilita o cambia el `TickSize`, las Ofertas que se colocaron bajo la configuración anterior no se ven afectadas.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [Dev Blog: Introducción a la enmienda TickSize](https://xrpl.org/blog/2017/ticksize-voting.html#ticksize-amendment-overview)
|
||||
- **Referencias:**
|
||||
- [transacción AccountSet][]
|
||||
- [método book_offers][]
|
||||
- [transacción OfferCreate][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
Reference in New Issue
Block a user