> 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, la cronología del bono, tramos, ratio de cobertura, salida anticipada y el vocabulario de PoX-5. Términos utilizados en el conjunto de documentación de Bitcoin Staking (PoX-5). ## Bono del protocolo Un compromiso de doble activo de 12 ciclos, aproximadamente seis meses: un bloqueo temporal de BTC en Bitcoin L1 emparejado con un bloqueo de STX en Stacks L2, vinculados criptográficamente, orientado al rendimiento del Tramo 1 en la parte de BTC. El término es la constante del contrato `BOND_LENGTH_CYCLES u12`. ## Día 0 / Día 175 / Día 182 (cronograma del bono) El Día 0 es la fecha límite para que ambas partes estén bloqueadas y sean elegibles; el registro debe realizarse antes de la altura de inicio del bono. El Día 175 es la altura mínima de desbloqueo del timelock de L1. Se sitúa 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 termina el período de vinculación en L2; los STX se desbloquean en el siguiente límite de ciclo. El bloqueo de L1 se rechaza al registrarse si su altura de desbloqueo está por debajo del Día 175. ## Período de vinculación El plazo completo de 12 ciclos de un solo bono, del Día 0 al Día 182. Seis períodos de vinculación se ejecutan simultáneamente y de forma escalonada, 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 de firmantes (ciclo de recompensa) Otro nombre para un ciclo de recompensa: 2.100 bloques de Bitcoin, unos 14 días en mainnet. Es una fase de recompensa más su fase de preparación final de 100 bloques. Las demás cifras de ciclos en esta página se derivan de él. ## Ciclo de distribución Medio ciclo de recompensa, 1.050 bloques de Bitcoin en mainnet, y el reloj sobre el que se calculan las recompensas. 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 parte de 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, cumplir el subscript de desbloqueo anticipado del bono y la firma del staker. El staker queda vinculado al script mediante un compromiso hash, `sha256(sha256(to-consensus-buff? staker))`, en lugar de un push en texto claro. Por eso un bono de L1 es intrínsecamente de un solo staker y no puede agruparse. Se requiere la firma del propio staker 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. Por tanto, un gasto de salida anticipada necesita la firma del staker y el preimagen del 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 al registrarse para demostrar que la salida del timelock de L1 existe y está confirmada. Dos límites duros importan antes de construir un registro: * **Como máximo 10 outpoints de bloqueo por registro.** `register-for-bond`de `btc-lockup` la rama ok está tipada `salidas: (lista 10 {…})`, y el fold de validación limita su `seen-outpoints` acumulador en `u10`. Un repetido `(txid, índice-de-salida)` falla con `ERR_DUPLICATE_LOCKUP_OUTPOINT u46`. Puedes distribuir los BTC entre varios UTXOs con timelock, pero no más de diez. * **Las pruebas de Merkle no pueden superar la profundidad 14.** El campo `leaf-hashes` de la prueba está tipado `(list 14 (buff 32))`. ## Tramo 1: Bonos de protocolo activos El primer escalón de la cascada. A cada bono activo se le paga su rendimiento objetivo antes de asignar cualquier otra cosa. 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 de STX El segundo escalón. Los stakers solo de STX reciben el 85% del excedente del ciclo, prorrateado según las participaciones apostadas. ## Tramo 3: Fondo de reserva El tercer escalón. Toma el 15% restante del excedente del ciclo. > **Convención interna.** Este glosario es la única página del conjunto que lleva los números de tramo: el Tramo 1 son los bonos del protocolo, el Tramo 2 son los stakers solo de STX, el Tramo 3 es el fondo de reserva. En el resto de la documentación, los tramos se nombran, nunca se numeran: el tramo de bonos del protocolo, el tramo de staking solo de STX, el tramo del fondo de reserva. Cuando se nombran dos o más juntos, el orden siempre es bonos del protocolo, luego solo STX, luego fondo de reserva. ## Excedente del ciclo Ingresos del minero 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 de 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 de STX y la reserva. Los bonos se pagan en orden descendente `stx-value-ratio` de la relación de valor STX, y cualquier déficit recae por completo en los últimos bonos de ese orden en lugar de repartirse proporcionalmente. El efecto es un rendimiento del lado BTC más estable y un retorno solo de STX más variable. Fuera de este glosario, los tres escalones se mencionan por nombre, en el orden bonos del protocolo, solo STX, fondo de reserva. Tratamiento completo en [Recompensas y tramos](/learn/es/bitcoin-staking/rewards-and-tranches.md). ## Relación 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 superior, gestionada manualmente por el Stacks Endowment durante el bootstrap de PoX-5. El contrato ni lo calcula ni reacciona a ello; es un constructo a nivel de diseño. ## Fondo de reserva El tercer escalón de la cascada. Acumula el 15% del excedente del ciclo, más la parte de los stakers de STX en cualquier ciclo sin stakers solo de STX. El libro blanco lo describe como mantenido en dos compartimentos, un compartimento BTC y un compartimento USD de stablecoins o bonos del Tesoro de corta duración, dividido al 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 lleva 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 todo el contrato. Solo puede ser invocado por el nodo como parte del consenso, así que llegar a la reserva requiere una bifurcación dura. 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 bootstrap mediado por Endowment en el que la capacidad, la relación y el APY objetivo se establecen administrativamente; PoX-6 es el sucesor algorítmico planificado. ## Época 4.0 La época de consenso de Stacks que activó PoX-5 junto con los cambios de Clarity y de consenso de SIP-044: el nuevo esquema de versión de encabezado 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 960.230 de Bitcoin 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 el conjunto de firmantes y stakers del siguiente ciclo queda congelado. Seis puntos de entrada se rechazan 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 mediante una comprobación separada con `ERR_UNSTAKE_IN_PREPARE_PHASE (u28)`. ## Gestor de firmantes Un contrato al que delega cada staker, ya sea de bono o solo STX. Posee la lógica de aprobación a través de `validate-stake!` callback definido por `signer-manager-trait`, y es donde aterrizan las recompensas antes de su distribución posterior. La mayoría de los integradores utilizan un gestor de firmantes proporcionado en lugar de escribir uno. Véase [Hacer stake 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 los STX de bono como los STX solo de STX, sin mínimo por staker. Un firmante que lo supera se añade al conjunto de firmantes de ese ciclo; si cae por debajo, se elimina. ## Salida anticipada La rama de salida anticipada del script de bloqueo de 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 establece 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 ` OP_CHECKSIG` o un M-de-N `CHECKMULTISIG` plantilla, y DEBE dejar un resultado válido en la pila (es consumido por el OP\_VERIFY compartido)". Se almacena como un opaco `(buff 683)` por bono y el contrato nunca inspecciona su forma. Por lo tanto, la forma del conjunto de firmantes es 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 redundante de firma de salida anticipada respaldado por KMS, no por una multifirma en cadena. Eso 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 multifirma 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 él mismo: `contract-caller` debe ser igual a ambos `tx-sender` y el argumento del staker, así que ningún contrato puede hacerlo en su nombre. Pone a cero el `amount-sats` mientras deja la fila de membresía en su sitio, por eso **los STX emparejados permanecen bloqueados hasta el vencimiento**. Es una vez por bono. Un segundo anuncio para el mismo bono revierte con `ERR_L1_EARLY_EXIT_ALREADY_ANNOUNCED u50`, así que los llamadores deberían comprobar `fetchHasAnnouncedL1EarlyExit` primero. ### Orden El contrato no impone ningún orden entre `announce-l1-early-exit` y el gasto del lado de Bitcoin. Operativamente, el orden está fijado de todos modos: el cosignatario solo firma después de encontrar la transacción de anuncio en Stacks, y la posición deja de generar ganancias en el momento en que ese anuncio se registra. Construir solo a partir de la semántica del contrato produce el flujo incorrecto. La cofirma solo es necesaria antes de la altura CLTV. Después de eso, el staker recupera por sí solo 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 compuerta de salida anticipada ni paso de anuncio. ## puente automático de sBTC La ruta de recompensa predeterminada: el BTC de los mineros se dirige al fondo de recompensas y se puentea automáticamente a sBTC para su distribución. Un staker puede optar por un pago en BTC en L1 proporcionando `signer-calldata` en la capa del gestor de firmantes. No es un `register-for-bond` parámetro. `signer-calldata` es un opaco `(optional (buff 500))` que pox-5 pasa al gestor de firmantes sin interpretarlo. ## Ventana de renovación El período en el que un bono que termina puede renovarse directamente a un nuevo bono o a un stake solo de STX sin un retiro intermedio. Se abre en la altura de desbloqueo de L1 del bono, medio ciclo de recompensa antes del final en L2 del bono, y no se cierra. Ambos `register-for-bond` y `stake` la comprueban cuando el llamador ya posee una membresía de bono; actuar antes devuelve `ERR_ROLLOVER_TOO_EARLY (u48)`. Una prueba separada de no superposición rechaza una nueva posición cuyo primer ciclo cae antes del final del bono anterior. Ambos filtros se superan juntos por primera vez en la última media 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 Andon 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 existe función de reanudación; la recuperación requiere una bifurcación dura. ## `BOND_GAP_CYCLES` La constante del contrato `u2`. Establece tanto la ventana en la que puede configurarse un nuevo bono antes de su altura de inicio como la cadencia con la que se abren nuevos bonos, lo que produce seis bonos superpuestos de 12 ciclos en estado estacionario. ## Fuentes Cada afirmación a nivel de contrato en esta página se comprueba 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 objetivo y la banda de la relación de cobertura, y el auto-puente como ruta de recompensa predeterminada, no aparecen en el contrato de ninguna forma. Ambos provienen de `glossary.mdx` y el libro blanco. --- # 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/glossary.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.