> 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/glossary.md). # Glosario de Staking de Bitcoin Términos usados en la documentación de Staking de Bitcoin: bonos, cronología del bono, tramos, ratio de cobertura, salida anticipada y el vocabulario de PoX-5. Términos utilizados en todo el conjunto de documentación de Bitcoin Staking (PoX-5). ## Bono de protocolo Un compromiso de dos activos de 12 ciclos, aproximadamente seis meses: un timelock de BTC en Bitcoin L1 emparejado con un bloqueo de STX en Stacks L2, vinculados criptográficamente, orientado al rendimiento de Tramo 1 en la pata de BTC. El término es la constante del contrato `BOND_LENGTH_CYCLES u12`. ## Día 0 / Día 175 / Día 182 (cronología del bono) El Día 0 es el corte por el que ambas patas deben estar bloqueadas para ser elegibles; el registro debe llegar antes de la altura de inicio del bono. El Día 175 es la altura mínima de desbloqueo del timelock en L1. Está exactamente a medio ciclo de recompensa antes del final en L2 del bono, que es de 1.050 bloques de Bitcoin en mainnet, unos siete días. El Día 182 pone fin al período de vinculación en L2; los STX se desbloquean en el siguiente límite de ciclo. El bloqueo en L1 se rechaza en el registro si su altura de desbloqueo es inferior al Día 175. ## Período de vinculación El plazo completo de 12 ciclos de un bono único, del Día 0 al Día 182. Se ejecutan en paralelo y escalonados seis períodos de vinculación, abriéndose cada dos ciclos. Índice del bono *n* termina cuando el índice del bono *n+6* comienza, lo que produce el solapamiento de seis niveles. ## Ciclo del firmante (ciclo de recompensa) Otro nombre para un ciclo de recompensa: 2.100 bloques de Bitcoin, aproximadamente 14 días en mainnet. Es una fase de recompensa más su fase preparatoria final de 100 bloques. Las demás cifras de ciclo en esta página se derivan de ella. ## Ciclo de distribución Medio ciclo de recompensa, 1.050 bloques de Bitcoin en mainnet, y el periodo sobre el que se calculan las recompensas del reloj. Dos distribuciones por ciclo de recompensa, unas 50 al año, que es el divisor en el rendimiento objetivo por distribución de cada bono. ## Script de bloqueo La pata en L1 es una salida P2WSH con dos ramas de gasto. La rama de timelock requiere la firma del staker después de la altura CLTV. La rama de salida anticipada requiere revelar un preimagen de 32 bytes, satisfaciendo el subscript de desbloqueo anticipado del bono, y la firma del staker. El staker queda vinculado al script mediante un compromiso hasheado, `sha256(sha256(to-consensus-buff? staker))`, en lugar de un envío en texto claro. Por eso un bono en L1 es inherentemente de un solo staker y no puede agruparse. La propia firma del staker se requiere en ambas ramas, no solo en la de timelock: `staker-unlock-bytes` se ejecuta incondicionalmente después de `OP_ENDIF`, fuera de la selección de rama. Un gasto de salida anticipada, por tanto, necesita la firma del staker y el preimagen de compromiso de 32 bytes, además de lo que exija el subscript de desbloqueo anticipado. ## Prueba SPV de BTC La prueba del lado de Bitcoin que se presenta en el registro para demostrar que la salida de timelock en L1 existe y está confirmada. Antes de construir un registro hay dos límites duros que importan: * **Como máximo 10 outpoints de bloqueo por registro.** `register-for-bond`'s `btc-lockup` la rama ok está tipada `outputs: (list 10 {…})`, y el pliegue de validación limita su `outpoints vistos` acumulador en `u10`. Un `(txid, output-index)` repetido falla con `ERR_DUPLICATE_LOCKUP_OUTPOINT u46`. Puedes repartir el BTC entre varios UTXOs de timelock, pero no más de diez. * **Las pruebas de Merkle no pueden superar una profundidad de 14.** de la prueba `hashes de hojas` campo está tipado `(list 14 (buff 32))`. ## Tramo 1: Bonos de protocolo activos La primera parada en la cascada. Todos los bonos activos reciben primero su rendimiento objetivo antes de que se asigne nada más. Aproximadamente el 10% de la capacidad del Tramo 1 se reserva para la participación comunitaria mediante pools, según la Sección 4.2 del libro blanco. Tratamiento completo en [Recompensas y tramos](/learn/es/bitcoin-staking/rewards-and-tranches.md). ## Tramo 2: stakers solo STX La segunda parada. Los stakers solo STX reciben el 85% del excedente del ciclo, a prorrata de las participaciones apostadas. ## Tramo 3: Fondo de reserva La tercera parada. Toma el 15% restante del excedente del ciclo. ## Excedente del ciclo Ingresos de los mineros por encima de las obligaciones del Tramo 1 para ese ciclo. Es lo que se reparten el Tramo 2 y el Tramo 3, 85% para los stakers solo STX y 15% para la reserva. ## Cascada El orden de prioridad de las recompensas entre los tres tramos: primero los bonos, luego el excedente repartido entre los stakers solo STX y la reserva. Los bonos se pagan en orden descendente `stx-value-ratio` y una carencia recae por completo en los últimos bonos de ese orden, en lugar de repartirse proporcionalmente. El efecto es un rendimiento más estable del lado de BTC y una rentabilidad más variable para los stakers solo STX. Tratamiento completo en [Recompensas y tramos](/learn/es/bitcoin-staking/rewards-and-tranches.md). ## Ratio de cobertura Fondo de recompensas por ciclo dividido por las obligaciones de BTC emparejado por ciclo. El objetivo es 2,0x con una banda de respuesta de 0,8x a 2,0x y superiores, gestionada manualmente por la Stacks Endowment durante el arranque de PoX-5. El contrato no la calcula ni reacciona ante ella; es una construcción a nivel de diseño. ## Fondo de reserva La tercera parada en la cascada. Acumula el 15% del excedente del ciclo, más la parte de los stakers STX en cualquier ciclo sin stakers solo STX. El libro blanco lo describe como mantenido en dos compartimentos, un compartimento BTC y un compartimento USD de stables o bonos del Tesoro de corta duración, divididos en el momento del depósito, con el compartimento BTC utilizado primero y el compartimento USD como última línea de defensa. Esa estructura no está en pox-5, que rastrea un `reserve-balance` denominado en sBTC. Los compartimentos son un arreglo de tesorería fuera de la cadena. Nada dentro del contrato puede reducirlo. `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 ninguna parte del contrato. Solo puede ser invocada por el nodo como parte del consenso, por lo que acceder a la reserva requiere un hard fork. Ni el administrador de bonos ni el administrador de pausa pueden acceder a ella. ## PoX-5 El contrato de arranque de Clarity que implementa Bitcoin Staking. Sustituyó a PoX-4 en la Época 4.0. PoX-5 ejecuta un arranque mediado por la Endowment en el que la capacidad, el ratio y el APY objetivo se fijan administrativamente; PoX-6 es el sucesor algorítmico previsto. ## Época 4.0 La época de consenso de Stacks que activó PoX-5 junto con los cambios de SIP-044 en Clarity y consenso: el nuevo esquema de versión de cabecera de bloque, la eliminación de la votación de costos, la restauración de la emisión de 1.000 STX por bloque y la eliminación de la dirección de quema. Se activó en el bloque de Bitcoin 960.230 y requiere la versión 4.0.1. ## Fase de preparación Los últimos 100 bloques de Bitcoin de cada ciclo de recompensa, que se repiten en cada ciclo, durante los cuales se congela el conjunto de firmantes y stakers del siguiente ciclo. Se rechazan seis puntos de entrada durante ella con `ERR_STAKE_IN_PREPARE_PHASE (u47)`: `register-for-bond`, `update-bond-registration`, `stake`, `stake-update`, `announce-l1-early-exit`, y `unstake-sbtc`. `unstake` se rechaza por una comprobación separada con `ERR_UNSTAKE_IN_PREPARE_PHASE (u28)`. ## Gestor de firmantes Un contrato al que delega todo staker, ya sea de bono o solo STX. Posee la lógica de aprobación a través de la `validate-stake!` retrollamada definida por `signer-manager-trait`, y es donde aterrizan las recompensas antes de su distribución posterior. La mayoría de los integradores usan un signer-manager proporcionado en lugar de escribir uno. Véase [Delegar en un gestor de firmantes existente](https://docs.stacks.co/operate/staking-stx/stack-with-a-pool). ## Mínimo del conjunto de firmantes `SIGNER_SET_MIN_USTX u50000000000` es 50.000 STX. Es un umbral agregado sobre el total de uSTX delegados a un firmante, contando tanto el STX de bonos como el STX solo STX, sin mínimo por staker. Un firmante que esté en o por encima de él recibe una distribución de rendimiento para ese ciclo; caer por debajo la detiene. ## Salida anticipada La rama de salida anticipada del script de bloqueo en L1, que requiere conjuntamente la clave de desbloqueo anticipado y el staker. Ninguno puede mover las monedas por sí solo. ### Lo que permite el contrato El subscript de desbloqueo anticipado se fija por bono por el administrador del bono en `setup-bond`. El propio comentario de documentación del contrato dice `early-unlock-bytes` "debería tener la forma de ` OP_CHECKSIG` o un M-de-N `CHECKMULTISIG` template, y DEBE dejar un resultado válido en la pila (es consumido por el OP\_VERIFY compartido)." Se almacena como un `(buff 683)` opaco por bono y el contrato nunca inspecciona su forma. La forma del conjunto de firmantes es, por tanto, una elección de política por bono, no una constante del protocolo. ### Lo que realmente está desplegado En la práctica siempre es una sola clave pública de cosignatario con `OP_CHECKSIG`, una clave gestionada por un servicio de firma de salida anticipada redundante y respaldado por KMS, no por una multisig en cadena. Esa es una elección operativa, no una restricción del protocolo. Cualquiera de las dos afirmaciones por sí sola induce a error: si solo te dicen "M-de-N", diseñas para una multisig que no existirá; si solo te dicen "siempre una clave", crees que el contrato impone algo que no impone. ### La llamada del lado de Stacks `announce-l1-early-exit` es la llamada del lado de Stacks, y el staker debe hacerla por sí mismo: `contract-caller` debe ser igual a `tx-sender` y al argumento del staker, de modo que ningún contrato puede hacerla en su nombre. Pone a cero el `amount-sats` mientras deja la fila de membresía en su lugar, por lo que **el STX emparejado permanece bloqueado hasta el vencimiento**. Es una vez por bono. Un segundo anuncio para el mismo bono revierte con `ERR_L1_EARLY_EXIT_ALREADY_ANNOUNCED u50`, por lo que los llamadores deben comprobar `fetchHasAnnouncedL1EarlyExit` primero. ### Orden El contrato no impone ningún orden entre `announce-l1-early-exit` y el gasto del lado de Bitcoin. Operativamente, de todos modos el orden está fijado: el cosignatario solo firma después de encontrar la transacción de anuncio en Stacks, y la posición deja de generar en el momento en que ese anuncio llega. Construir solo a partir de la semántica del contrato produce un flujo incorrecto. La cofirma solo es necesaria antes de la altura CLTV. Después de ella, el staker recupera en solitario a través de la `OP_IF` rama y no interviene ningún cosignatario. Los participantes bloqueados en sBTC usan `unstake-sbtc` en su lugar, que no tiene bloqueo de salida anticipada ni paso de anuncio. ## Puente automático de sBTC La ruta de recompensa predeterminada. El BTC de los mineros entra en el fondo de recompensas y se puentea automáticamente a sBTC, y pox-5 paga a cada signer-manager sus recompensas en sBTC. El signer-manager luego paga a sus stakers: en sBTC por defecto, o como BTC en L1 mediante una retirada de sBTC si el staker usa un signer-manager que lo admite y almacenó con él una dirección de Bitcoin. El staker almacena esa dirección en `signer-calldata`, un `(optional (buff 500))` argumento de `stake`, `stake-update`, `register-for-bond` y `update-bond-registration`. pox-5 lo pasa al `validate-stake!` sin interpretarlo, por lo que las opciones de pago son las que implemente ese signer-manager. El [signer-manager Fastpool Max 500](https://explorer.hiro.so/txid/SPMPMA1V6P430M8C91QS1G9XJ95S59JS1TZFZ4Q4.fastpool-max500-signer-manager?chain=mainnet), por ejemplo, también permite que un staker establezca o borre la dirección directamente con `set-payout-config` y `clear-payout-config`, y realiza la retirada en su `pago` función a través de `.sbtc-withdrawal`. ## Ventana de renovación El período en el que un bono que termina puede renovarse directamente en un bono nuevo o en una participación solo STX sin una retirada intermedia. Se abre en la altura de desbloqueo en L1 del bono, medio ciclo de recompensa antes del final en L2 del bono, y no se cierra. Ambos `register-for-bond` y `stake` lo comprueban cuando el llamador ya posee una membresía de bono; actuar antes devuelve `ERR_ROLLOVER_TOO_EARLY (u48)`. Una prueba separada de no solapamiento rechaza una nueva posición cuyo primer ciclo cae antes del final del bono anterior. Ambas barreras se superan primero juntas en la mitad final del ciclo de recompensa del bono, así que ese es el momento más temprano en que puede producirse una renovación. Una renovación de bono a bono transfiere solo la diferencia neta de sBTC; una renovación de bono a solo STX reembolsa todo el sBTC custodiado. ## Cordón andón El disyuntor unidireccional en cadena. El administrador de pausa llama a `pause-rewards`, después de lo cual `claim-rewards` revierte con `ERR_REWARDS_PAUSED (u53)`. Las recompensas siguen acumulándose en el contrato. No hay función de reactivación; la recuperación requiere un hard fork. ## `BOND_GAP_CYCLES` La constante del contrato `u2`. Establece tanto la ventana en la que se puede configurar un nuevo bono antes de su altura de inicio como la cadencia con la que se abren nuevos bonos, que es lo que produce seis bonos de 12 ciclos superpuestos en estado estacionario. ## Fuentes Toda afirmación a nivel de contrato en esta página se comprueba frente a 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 objetivo de ratio de cobertura y sus bandas provienen de [SIP-045 §3.1.5](https://github.com/stacksgov/sips/blob/642af6804dacc80455c3d49ef66b62bc4fb209aa/sips/sip-045/sip-045-pox-5-bitcoin-staking.md#315-coverage-ratio-requirements) y su [libro blanco](https://github.com/stacksgov/sips/blob/642af6804dacc80455c3d49ef66b62bc4fb209aa/sips/sip-045/sip-045-5.pdf); ningún contrato los calcula. La opción de pago en L1 es lógica de signer-manager, no lógica de pox-5: el ejemplo Fastpool Max 500 es el contrato desplegado `SPMPMA1V6P430M8C91QS1G9XJ95S59JS1TZFZ4Q4.fastpool-max500-signer-manager`. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stacks.co/learn/es/bitcoin-staking/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.