> For the complete documentation index, see [llms.txt](https://docs.stacks.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stacks.co/learn/es/bitcoin-staking/rewards-and-tranches.md). # Bono de protocolo y mecánica de recompensas A dónde va el fondo de recompensas de cada ciclo: la cascada de tres tramos, el fondo de reserva, la banda del ratio de cobertura y la pausa unidireccional. Las recompensas se acumulan para el contrato pox-5 como sBTC y se distribuyen en un orden de prioridad fijo. Los bonos se pagan primero, y solo lo que sobra llega a los stakers solo STX y a la reserva. Ese orden es todo el diseño: estabiliza el rendimiento del lado BTC a costa de hacer más variables los retornos solo STX. La distribución funciona con su propio reloj. Un ciclo de distribución equivale a la mitad de un ciclo de recompensas, 1,050 bloques de Bitcoin en mainnet o aproximadamente una semana. Así que hay dos distribuciones por ciclo de recompensas y unas 50 al año. El contrato codifica ese valor como divisor en el objetivo por distribución de cada bono. Los términos usados aquí se definen en el [Glosario](/learn/es/bitcoin-staking/glossary.md). ## La cascada, en orden La distribución no es automática en el sentido de ocurrir por sí sola. Cualquiera puede llamar a `calculate-rewards`; es sin permisos, y se ejecuta como máximo una vez por altura de distribución, rechazando una segunda llamada con `ERR_DISTRIBUTION_ALREADY_COMPUTED u30`. También afirma que cada bono actualmente activo aparece en el `(list 6 uint)` que se le da, fallando con `ERR_ACTIVE_BOND_NOT_INCLUDED u33` de lo contrario. Las recompensas no llegan solas; alguien tiene que tocar el contrato.
A three-step waterfall diagram. The cycle's reward pool flows first into the protocol bond tranche, which takes each active bond's target yield in full. What remains, labelled the cycle excess, flows into a second step that splits eighty-five percent to the STX-only staking tranche and fifteen percent to the reserve fund tranche.

El fondo de recompensas de cada ciclo llena primero el tramo de bonos del protocolo. Solo el excedente del ciclo llega al tramo de staking solo STX y al tramo del fondo de reserva, que lo dividen 85/15.

### El tramo de bonos del protocolo Cada bono activo recibe su rendimiento objetivo antes de que se asigne cualquier otra cosa. Por distribución: ```clarity (target-yield (/ (/ (* total-sats (get target-rate bond)) u10000) u50)) ``` Eso es el total de sats apostados del bono multiplicado por su tasa objetivo en puntos básicos, dividido entre 50 distribuciones al año. Los bonos se pagan en un orden canónico impuesto por el contrato, que rechaza una lista mal ordenada con `ERR_INVALID_BOND_PERIOD_ORDERING (u29)`: descendente `stx-value-ratio`, con el índice del bono en orden ascendente como criterio de desempate. `stx-value-ratio` es uSTX por 100 sats, así que primero se pagan los bonos con más STX bloqueados por unidad de BTC. Esto importa cuando el fondo no puede cubrir todos los bonos. Cada bono toma su objetivo completo si el fondo restante lo cubre; de lo contrario, toma lo que quede. Por lo tanto, un déficit no se reparte proporcionalmente. Cae por completo sobre los últimos bonos en el orden, es decir, sobre los bonos con menor `stx-value-ratio` bonos. La tasa objetivo de un bono queda fija durante todo su plazo. Se escribe una sola vez en `setup-bond` y ninguna función la modifica, por lo que la tasa se aplica de forma consistente en cada distribución durante el período de vinculación. Aproximadamente el 10% de la capacidad de bonos del protocolo se reserva para la participación comunitaria mediante pools, junto con asignaciones negociadas para socios institucionales incluidos en la lista blanca. Esta es una política de asignación de la sección 4.2 del white paper. No existe ninguna constante de capacidad ni de reserva específica en el contrato. ### El tramo de staking solo STX Los ingresos de los mineros por encima de las obligaciones de bonos del protocolo son el **excedente del ciclo**. Se divide entre el tramo de staking solo STX y el tramo del fondo de reserva. Los stakers solo STX se llevan el 85% de eso, distribuido prorrata según las participaciones apostadas. La parte visible para los participantes de esto se cubre en [Stake to an Existing Signer-Manager](https://docs.stacks.co/operate/staking-stx/stack-with-a-pool). Si un ciclo no tiene ningún staker solo STX, ese 85% no queda sin asignar ni infla la cifra de recompensas por token del ciclo. `unallocated-staker-cut` reintegra toda la parte de los stakers en `reserve-deposit` en lugar de dejarla sin destino. ### El tramo del fondo de reserva La reserva se queda con el otro 15%, definido por `RESERVE_RATIO u1500` contra un denominador de 10,000 puntos básicos. La parte de la reserva se calcula primero y la parte de los stakers STX es el resto: ```clarity (reserve-cut (/ (* remaining-rewards RESERVE_RATIO) u10000)) (stx-staker-rewards (- remaining-rewards reserve-cut)) ``` Ese orden de cálculo es el inverso del orden de prioridad descrito arriba, y es deliberado. Las posiciones de la cascada son las etiquetas de prioridad del modelo económico; el orden del código es aritmético. Leer el contrato sin esa distinción hace que la documentación parezca contradecir la fuente. El white paper llama 85/15 a un valor inicial propuesto para el porcentaje de asignación de la reserva. En mainnet no es un parámetro: `RESERVE_RATIO` es una constante del contrato, así que cambiar la división requiere un nuevo contrato. La reserva existe para amortiguar los déficits de los bonos del protocolo. El white paper describe la reserva como mantenida en dos compartimentos, un compartimento BTC y un compartimento USD de stablecoins o bonos del Tesoro de corta duración, con nuevas aportaciones divididas en el momento del depósito. En una retirada, primero se usa el compartimento BTC y el compartimento USD es la última línea de defensa. Ninguna de esa estructura de compartimentos existe en pox-5. El contrato lleva un único `reserve-balance` denominado en sBTC, por lo que la división en dos compartimentos y el orden de retirada son disposiciones del tesoro fuera de la cadena. **Nada dentro del contrato puede agotar esa reserva.** `reserve-balance` se incrementa en `calculate-rewards` y se decrementa en exactamente un lugar: `transfer-from-reserve`, que es `define-private`, lleva `#[allow(unused_private_fn)]`, y no tiene ningún punto de llamada en todo el contrato. Su propio comentario lo dice claramente: "solo puede ser llamada por el nodo como parte del consenso (mediante el proceso SIP)". Ni el administrador de bonos ni el administrador de pausa pueden الوصول a ella, así que liberar fondos de la reserva requiere un hard fork. Cuando se invoca de esa manera, verifica que el saldo cubra la cantidad (`ERR_INSUFFICIENT_RESERVE_BALANCE u51`), debita `reserve-balance`, y transfiere el sBTC. Esa constante de error existe solo para esa ruta, por eso parece no estar referenciada. Una segunda función privada, `transfer-stranded-rewards`, está inactiva de la misma manera y tiene un alcance más amplio: un mecanismo general para mover sBTC fuera del contrato, por ejemplo recompensas atrapadas por una pausa. A diferencia de `transfer-from-reserve` no mantiene contabilidad interna ni limita la cantidad contra nada. Por lo tanto, la reserva se acumula automáticamente y solo se libera mediante hard fork. Decirlo claramente importa, porque de lo contrario parece un error. ## Ratio de cobertura El ratio de cobertura es el fondo de recompensas por ciclo dividido entre las obligaciones de BTC emparejado por ciclo. El objetivo es 2.0x, con una banda de respuesta que va desde 0.8x hasta 2.0x y más. Durante el arranque de PoX-5, esta banda es gestionada manualmente por la Stacks Endowment. Nada en el contrato calcula, almacena ni reacciona a un ratio de cobertura. Se anticipan respuestas automáticas en cadena para PoX-6. ## El cordón Andon El cordón Andon es independiente de las bandas del ratio de cobertura y es el único interruptor de corte que existe en la cadena. El administrador de pausa llama a `pause-rewards`. Después de eso, `claim-rewards` falla su `(not (var-get rewards-paused))` afirmación y revierte con `ERR_REWARDS_PAUSED u53`. El freno es real porque el rol está en manos de un principal activo. En el contrato desplegado, ambos roles de administrador se inicializan con el mismo: ```clarity (define-data-var bond-admin principal 'SP72DMR3MJKS7RVBY33JVV7EEJSQ1PYDVKDP10FX) (define-data-var pause-admin principal 'SP72DMR3MJKS7RVBY33JVV7EEJSQ1PYDVKDP10FX) ``` En redes que no son mainnet `make_pox_5_body` reescribe ambos literales al administrador configurado en el momento del despliegue. El `TODO: esto debería establecerse en una multisig predefinida para mainnet` comentario en el código fuente está solo sobre `bond-admin` y no sobre `pause-admin`. Pausar detiene los reclamos. No redirige las recompensas, que siguen acumulándose en el contrato. Es de una sola dirección. El contrato no tiene función de reanudar, algo que su propio comentario indica: "Es de una sola dirección: no hay función de reanudar. Una vez en pausa, las recompensas pueden seguir acumulándose aquí, y la recuperación requiere un hard fork." Esa recuperación es para lo que `transfer-stranded-rewards` existe. ## Los dos roles de administrador `bond-admin` y `pause-admin` son roles distintos, mantenidos en variables de datos separadas y transferibles por separado, aunque ambos se inicializan con el mismo principal. Ambos son operaciones de la Endowment. Si estás leyendo esta página como participante, no llamarás a ninguno de ellos. | Rol | Establece | Rotado por | Protección | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------- | | `bond-admin` | Parámetros de bonos mediante `setup-bond`: `target-rate`, `stx-value-ratio`, `min-ustx-ratio`, `early-unlock-bytes`, la lista de अनुमति | `set-bond-admin`, invocable solo por el titular actual | `ERR_UNAUTHORIZED u1`, protegido contra reentradas | | `pause-admin` | La pausa unilateral de recompensas mediante `pause-rewards` | `set-pause-admin`, invocable solo por el titular actual | `ERR_UNAUTHORIZED u1`, protegido contra reentradas | Ambos se rigen por `contract-caller`, así que ninguno puede ser reenviado a través de un contrato intermediario. ## Fuentes Cada afirmación a nivel de contrato en esta página se verifica contra la versión fijada y el contrato desplegado: * [`pox-5.clar` en la etiqueta 4.0.1](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/chainstate/stacks/boot/pox-5.clar) * [`SP000000000000000000002Q6VF78.pox-5` en mainnet](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-5?chain=mainnet\&tab=sourceCode) El carve-out comunitario del 10% y el objetivo y las bandas del ratio de cobertura no aparecen en el contrato de ninguna forma. Ambos pertenecen al nivel de diseño, del white paper. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.stacks.co/learn/es/bitcoin-staking/rewards-and-tranches.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.