Operaciones del protocolo¶
Emisión y redención¶
Los conceptos detrás de la emisión y redención de RTokens son muy simples. Cualquiera puede traer el valor X del protocolo en canastas colaterales y recibir X RTokens a cambio. Cualquiera también puede traer el protocolo Y RTokens y recibir a cambio el valor de Y en canastas colaterales.

Acelerador de emisión¶
Como una forma de limitar el valor extraíble en el caso de un ataque o explotación de un RToken, el protocolo permite que el implementador de RToken (y sus gobernadores) establezca un límite sobre la cantidad de RToken que se puede emitir.
El mecanismo de regulación funciona como una batería en la que, después de una emisión grande, el límite de emisió se recarga linealmente hasta el máximo definido a una velocidad de recarga definida.
La idea es asegurar que las emisiones netas para un RToken nunca excedan ciertos límites por unidad de tiempo (hora). Los límites pueden configurarse como un monto fijo de RTokens (e.g. 1,000,000 rtokens) y/o como un porcentaje del suministro actual de RTokens (e.g. 5% por defecto)
Acelerador de redención¶
Al igual que el acelerador de emisión, cada RToken puede tener un acelerador de redención para limitar la cantidad de valor extraíble en el caso de un ataque o explotación.
El mecanismo de regulación funciona como una batería en la que, después de una redención grande, el límite de canje se recarga linealmente hasta el máximo definido a una velocidad de recarga definida.
La idea es asegurar que las redenciones netas para un RToken nunca excedan ciertos límites por unidad de tiempo (hora). Los límites pueden configurarse como un monto fijo de RTokens (e.g. 1,000,000 rtokens) y/o como un porcentaje del suministro actual de RTokens (e.g. 2.5% por defecto)
Nota: Se recomienda que el acelerador de redención sea mayor que el acelerador de emisión, para evitar que el límite de redención sea consumido en su totalidad con una operación conjunta de emision-redención.
Staking y un-staking¶
Los holders de Reserve Rights (RSR) pueden decidir apostar sus tokens RSR en RTokens para que los titulares de RToken estén completos en el caso improbable de un incumplimiento de token colateral, y recibir una parte de los ingresos que genera el RToken a cambio.
Esta sección entrará en más detalles sobre los aspectos de bajo nivel del staking de RSR. Para obtener una descripción de más alto nivel, consulte la sección Rendimientos para los holders de RSR.
Inmediatamente después de hacer staking de tokens RSR en un RToken, el participante recibe un token stRSR (staked Reserve Rights) a un tipo de cambio particular para RSR. Este tipo de cambio comienza en 1,00 y cambiará con el tiempo, ya sea porque los ingresos de RToken se comparten con los participantes de RSR o mediante la reducción de su sobrecolateralización.
Para participar en propuestas de gobernanza, los stakers de RSR deben delegar su stake a sí mismos para activar su peso en la votación.

Si un staker de RSR decide dejar de hacer staking de sus tokens RSR, tendrá que esperar el retraso para dejar de hacer stake (establecido de forma predeterminada en 2 semanas) antes de recibir sus tokens de RSR de vuelta. Durante el período de retraso, el tipo de cambio de stRSR a RSR está bloqueado (el staker ya no acumula ingresos del RToken). Sin embargo, el RSR es aún susceptible de ser recortado en caso de una falla en el colateral.
La razón por la que una posición de stRSR necesita ser recortada, pero no generar ingresos, durante el período de demora de no participación es porque la alternativa permitiría jugar con el sistema. Si los ingresos aún se estaban acumulando durante el período de demora, uno podría retirar inmediatamente después de apostar su RSR (y repetir este proceso) para eludir el período de demora, lo que en última instancia daría como resultado un grupo de seguros menos consistente.
Retirar el staking de una posición stRSR requiere dos transacciones, una para iniciar el proceso de reposicionamiento y otra al final del período de demora para recibir los tokens RSR de vuelta. Entre estas dos transacciones, la posición de stRSR no es transferible, ya que stRSR se quema en la primera transacción).
Gestion de activos¶
Aquellos activos ERC20 que necesiten ser usados como parte de un RToken (ya sea como colateral o como ingresos) debe ser registrados en el contrato Asset Registry para ese RToken en particular.
La Gobernanza esta a cargo de registrar, de-registrar e intercambiar activos (swap).
- registrar: (
register
): Agrega el activo al Asset Registry. incluyendo todos los detalles que el protocolo necesita para poder manejar ese activo. - intercambiar (
swapRegistered
): Permite modificar y actualizar detalles o funcionalidad de un activo registrado previamente. - de-registrar: (
unregister
: Elimina el activo del Asset Registry. Ya no podrá ser utilizado por el RToken. La intención de esta funcionalidad es permitir a la gobernanza eliminar colaterales en mal estado. Es importante que aquellas propuestas que performen una de-registración de activos incluyan al final una llamada para refrescar/actualizar la canasta (refreshBasket()
).
Una lista detallada de activos no-compatibles puede verse en la sección RTokens (en inglés)
Gestión de ingresos¶
Fuente de ingresos¶
Los ingresos que acumulan los RTokens provienen de sus canastas colaterales, incluidas las salidas tokenizadas de los protocolos DeFi como cUSDC (Compound USDC), aDAI (Aave DAI) o varios tokens AMM LP. Estos tokens están diseñados para aumentar de forma monótona (siempre creciente) en comparación con sus tokens base, ya que están vinculados al valor del token base + cualquier tarifa de préstamo/intercambio pagada en el grupo correspondiente.
El protocolo puede rastrear la apreciación de los tokens colaterales de un RToken en términos de USD y disminuir la canjeabilidad de ese RToken en consecuencia.

Distribución de ingresos¶
Hay varios componentes que son esenciales para comprender cómo se distribuyen los ingresos de RToken a los holders de RToken o a los stakers de RSR. En esta sección, primero los presentaremos uno por uno y luego los consolidaremos para presentar el cuadro completo.
Rendimientos para los holders de RSR¶
Después de acuñar RTokens, todos los tokens colaterales proporcionados al protocolo se almacenarán en Backing Manager (BM). El BM es responsable de retenerlos, extraer más RTokens de ellos o intercambiarlos por RTokens o RSR (para luego pagar recompensas a los holders de RToken o a los staker de RSR).
Para ello, primero imaginemos un RToken X cuyos ingresos van en su totalidad a los holders de RToken. El BM acuñará periódicamente tantos RTokens X como pueda de la garantía en crecimiento. Toda la garantía acumulada restante que no se pueda acuñar uniformemente en RTokens X se enviará al RToken Trader, donde se intercambiará directamente por más RTokens X a través de subastas.

Después de la comercialización, tanto los RTokens X recién acuñados como los RTokens X recién negociados se consolidarán en el Furnace. El Furnance es responsable de derretir (= quemar lentamente) estos nuevos RTokens, lo que aumenta gradualmente la tasa de cambio entre el RToken y su canasta de garantías.

Para resumir: el protocolo mantendrá todos los tokens colaterales en el Administrador de respaldo. Siempre que pueda, emitirá nuevos RTokens o intercambiará el exceso de garantías con RTokens a través del RToken Trader. Después de acuñar/intercambiar, los RTokens se derriten (= se queman lentamente) a través del Furnace, lo que da como resultado que los RTokens se vuelvan más valiosos (canjeables por más tokens colaterales).
La distribución de ingresos a los holders de RToken se puede visualizar de la siguiente manera:

Distribución de ingresos a stakers de RSR¶
Como se mencionó en la sección anterior, todos los tokens colaterales depositados para un RToken se almacenarán en el Backing Manager (BM). El BM es responsable de retenerlos, extraer más RTokens de ellos o intercambiarlos por RTokens o RSR (para luego pagar recompensas a los holders de RToken o a los stakers de RSR).
Para simplificar, imaginemos ahora un RToken Y cuyos ingresos van en su totalidad a los stakers de RSR para compensarlos por el seguro y la gobernanza. En este caso, el BM acuñará periódicamente tantos RTokens Y como pueda de la garantía en crecimiento. Después de este minteo periódico, los RTokens recién acuñados y todas las garantías acumuladas restantes que no pudieron acuñarse uniformemente en RTokens Y, se enviarán al RSR Trader, donde se intercambiarán directamente por más RSR tokens a través de subastas.
Después de la negociación, el protocolo enviará todos los RSR recién adquiridos al grupo de stRSR, donde se entregarán lentamente como recompensas para los stakers de RSR al aumentar el tipo de cambio stRSR/RSR.

Para resumir: el protocolo mantendrá todos los tokens de garantía en el Backing Manager. Siempre que pueda, intercambiará el exceso de garantía a RSR a través del RSR Trader. Después de negociar, el RSR se entrega lentamente a través del grupo de stRSR, lo que hace que stRSR se vuelva más valioso (canjeable por más tokens RSR).
La distribución de ingresos a los participantes de RSR se puede visualizar de la siguiente manera:

Resumen de distribución de ingresos¶
Las dos secciones anteriores explican cómo se distribuyen los ingresos (garantía creciente) de un RToken a los holders de RToken o a los stakers de RSR a través de la acuñación/comercio de RTokens o tokens RSR. En esta sección combinamos los dos enfoques para presentar el panorama completo de la distribución de ingresos.
Al implementar un RToken, el implementador define qué parte de los ingresos se destina a los holders de RToken frente a los stakers de RSR. Ahora imaginemos un RToken Z en el que el 40 % de los ingresos se destina a los holders de RToken y el 60 % a los stakers de RSR.
En ese caso, el protocolo tomará periódicamente las siguientes acciones:
- Del 40 % de todos los ingresos acumulados en Backing Manager en ese momento, el protocolo emitirá tantos RTokens Z como pueda. El resto de la garantía (del cual no se pueden acuñar nuevos RTokens Z) se enviará al RToken Trader, donde se intercambiará directamente por RTokens Z. Luego, todos los RTokens Z recién acuñados/negociados se consolidarán en el Furnace, donde se derretirán (= quemarán lentamente), lo que tendrá un impacto positivo en la tasa de cambio de RToken Z a su garantía.
- Del 60 % de todos los ingresos acumulados en Backing Manager en ese momento, el protocolo emitirá tantos RTokens Z como pueda. Los tokens recién acuñados, así como el resto de la garantía (del cual no se pueden acuñar RTokens Z nuevos) se enviarán al RSR Trader, donde se intercambiarán directamente por tokens RSR. Posteriormente, todos los tokens RSR recién adquiridos se enviarán al grupo de stRSR, donde se entregarán lentamente a los holders de stRSR, lo que tendrá un impacto positivo en el tipo de cambio de stRSR a RSR.
La imagen completa de la distribución de ingresos se puede visualizar de la siguiente manera:

💡 El protocolo de Reserve se puede configurar para enviar (parte de) los ingresos de un RToken a cualquier dirección arbitraria de Ethereum (por ejemplo, para compensar al implementador de RToken, para crear una tesorería de RToken, etc.). En esta configuración, el implementador de RToken puede decidir si paga la dirección de terceros en RTokens o RSR. En cualquier caso, la parte de los ingresos designados a la dirección de un tercero puede enviarse directamente desde RToken Trader o RSR Trader; no tiene que pasar primero por el grupo Furnace o stRSR.{ .note-2 }
Recapitalización¶
Totalmente garantizado vs Totalmente financiado¶
Cuando hablamos de recapitalización, hacemos una distinción entre dos estados en los que puede estar un RToken:
- Totalmente colateralizado: el protocolo mantiene los saldos correctos de los tokens correctos para ofrecer un 100 % de capacidad de canje de RToken.
- Totalmente financiado: el protocolo tiene la cantidad correcta de valor, pero no necesariamente las cantidades correctas de garantía para ofrecer el 100 % de canjeabilidad de RToken.
El Protocolo de Reserve tiene como objetivo estar totalmente colateralizado en todo momento, pero es probable que no siempre lo esté. Por ejemplo, justo después de que el gobierno decida cambiar la canasta de garantías, el protocolo estará totalmente financiado pero aún no tendrá todas las garantías necesarias para ofrecer una redención completa. De manera similar, en el caso de un incumplimiento de garantía, el protocolo podría estar totalmente financiado a través de un exceso de garantía o una sobrecolateralización de RSR, pero es probable que todavía no esté totalmente garantizado para ofrecer una redención total.
Cuando el protocolo no está totalmente garantizado, venderá cualquier activo que tenga que no forme parte de la cesta de garantía adecuada hasta que (a) el protocolo esté totalmente garantizado de nuevo o (b) sea necesario vender RSR del contrato stRSR. para recapitalizar el protocolo.
Recapitalización a través de Reserve Rights¶
Si alguno de los tokens colaterales de un RToken incumpliera, el protocolo levantaría instantáneamente la bandera predeterminada a través de los mecanismos de verificación predeterminados que se explican en la sección Unidades monetarias. En ese momento, el protocolo venderá la mayor cantidad posible de la garantía defectuosa a través de subastas y utilizará los ingresos, así como cualquier exceso de garantía que aún esté en el sistema, para comprar la garantía de emergencia predefinida (sobre la cual puede obtener más información en el Cómo implementar una sección RToken (próximamente)).
En el caso de que los ingresos de la(s) subasta(s) + cualquier exceso de garantía aún en el sistema no brinden valor suficiente para garantizar completamente el RToken con la garantía de emergencia, el protocolo intentará recapitalizar utilizando tokens RSR apostados en el contrato stRSR. Más concretamente, la cantidad requerida de tokens RSR se incautará del contrato stRSR y se venderá por la cantidad requerida de garantía de emergencia a través de subastas, lo que dará como resultado un "recorte" uniforme para todos los stakers de RSR.
