Mecánica de bonos de protocolo y recompensas
A dónde va el fondo de recompensas de cada ciclo: la cascada de tres tramos, el fondo de reserva, la banda de 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.
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.
El tramo de bonos del protocolo
Cada bono activo recibe su rendimiento objetivo antes de que se asigne cualquier otra cosa. Por distribución:
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.
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:
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:
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.
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:
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.
¿Te fue útil?