Resumen Ejecutivo
Una propuesta de tesorería es una propuesta de gobernanza cuyo payload ejecutable autoriza una acción de tesorería en cadena (normalmente una transferencia, subvención o llamada de contrato). En Livepeer, las propuestas de tesorería se aplican a nivel de protocolo (en cadena)nivel de protocolo (en cadena): una vez que se alcanza el quórum y los umbrales y expira el tiempo de espera, las acciones codificadas se ejecutan de forma determinista.
Esta página define la estructura de los payloads de las propuestas de tesorería, sus semánticas de ejecución y los principales modos de fallo.
Una propuesta de tesorería es un conjunto de acciones ejecutables:
Cada acción se define como:
Donde:
- Objetivoes el contrato o dirección llamada
- Valores la cantidad de token nativo adjunta (si aplica)
- Datoses calldata codificado en ABI que especifica el selector de función y los argumentos
La propuesta pasa por la gobernanza y se ejecuta después del tiempo de espera.
2. Autorización de gobernanza
Dejar las variables de stake vinculado:
- = stake vinculado del votante
- = stake vinculado total
Poder de votación:
Condición de cuórum:
Condición umbral (ejemplo):
Solo las propuestas que cumplan las condiciones de gobernanza ingresan en la cola de timelock.
3. Semántica de la cola de timelock
Una vez aprobada, la propuesta se coloca en una cola de timelock con un retraso.
Timelock proporciona:
- Ventana de ejecución predecible
- Tiempo de reacción para los interesados
- Mitigación contra cambios repentinos o maliciosos
La ejecución solo es posible después de que transcurra el retraso.
4. Semántica de ejecución
Después de que expire el timelock, los intentos de ejecución tratan de aplicar cada acción de forma atómica dentro de la transacción de ejecución.
Dos propiedades importantes:
- Determinismo: la ejecución está definida de forma estricta por los datos de entrada
- Atomicidad: si alguna acción revierte, la transacción revierte a menos que el modelo de ejecución tolerara explícitamente un fallo parcial
Las propuestas del tesoro deben escribirse teniendo en cuenta la corrección de calldata y el modelo de fallos.
5. Transferencia de tesoro como caso canónico
Una acción común es una transferencia de tesoro.
Si el saldo del tesoro es y la cantidad de asignación es :
El saldo del destinatario aumenta en bajo las reglas de transferencia del activo.
6. Modos de falla
La ejecución de una propuesta del tesoro puede fallar por varias razones.
6.1 Error de calldata
Un selector de función incorrecto o una codificación ABI malformada causa un rechazo.
6.2 Saldo insuficiente en el tesoro
La cantidad transferida excede los fondos del tesoro.
6.3 Revertir contrato objetivo
El contrato llamado rechaza la llamada debido a controles de acceso, estado pausado o validación de parámetros.
6.4 Semántica de transferencia de activos
Algunos contratos de tokens pueden:
- Devolver false en lugar de revertir
- Aplicar tarifas de transferencia
- Imponer listas de permisos
Los autores de propuestas deben verificar el comportamiento del activo objetivo.
6.5 Configuración del timelock
Si las condiciones de retraso del timelock o ventana de ejecución están mal configuradas, las propuestas pueden volverse inexecutables.
7. Lista de mitigación de riesgos
Antes de presentar una propuesta de tesorería:
- Verificar las direcciones y contratos objetivo a través del registro
- Confirmar que el codificado ABI es correcto
- Confirmar que el saldo de la tesorería es suficiente
- Simular la ejecución donde sea posible
- Asegúrate de que el calldata sea auditable y tenga un alcance mínimo
8. Flujo de ejecución de la propuesta
9. Separación entre protocolo y red
Protocolo (En cadena):
- Definición del payload de la propuesta
- Conteo de votos y autorización
- Cola de timelock
- Ejecución determinista
- Transferencias del tesoro
Red (fuera de cadena):
- Redacción y revisión
- Entrega de subvenciones y ejecución operativa por parte de los beneficiarios
Las propuestas del tesoro están respaldadas por lógica del protocolo; los resultados requieren entrega fuera de cadena.
Referencias
Last modified on March 1, 2026