Saltar al contenido
Financial Context Wiki

¿Es segura una firma de delegación de gobernanza?

Aprende qué autoriza una firma de delegación de gobernanza, cómo la separación de dominios EIP-712, los nonces y el vencimiento reducen el riesgo de repetición, y qué verificar antes de firmar.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Las transacciones y firmas de activos digitales pueden causar pérdidas irreversibles.

Respuesta directa

Una firma de delegación de gobernanza solo es segura cuando el mensaje decodificado coincide exactamente con la delegación prevista y el contrato de gobernanza aplica una protección adecuada contra la repetición. En un diseño típico de token de votación, la delegación cambia quién puede ejercer el poder de voto del firmante; no transfiere el saldo de tokens ni concede autorización para gastarlos. Sin embargo, el contrato desplegado es la autoridad definitiva sobre lo que hace la firma.

Una firma fuera de la cadena puede ser enviada por un retransmisor, por lo que el firmante puede no pagar gas y, aun así, autorizar un cambio de estado en la cadena. Trata la firma como una instrucción ejecutable, no como un inicio de sesión ni como una solicitud inofensiva para conectar una billetera.

Cómo funciona

Un flujo habitual de delegateBySig consta de cuatro pasos:

  1. La aplicación prepara datos tipados EIP-712 que contienen la dirección de un delegado, un nonce y un vencimiento.
  2. La billetera firma un resumen vinculado al mensaje tipado y a un dominio EIP-712.
  3. Cualquier cuenta puede retransmitir la firma al contrato del token o de gobernanza.
  4. El contrato recupera o valida al firmante, comprueba el nonce y el vencimiento, y registra al nuevo delegado.

El dominio EIP-712 puede incluir name, version, chainId y verifyingContract. Estos campos separan mensajes que, de otro modo, serían idénticos entre aplicaciones, versiones, redes y contratos. EIP-712 por sí mismo declara expresamente que no ofrece protección contra repetición; el contrato debe consumir un nonce o hacer que cada autorización sea de un solo uso por otro medio, y un vencimiento solo limita el periodo si el contrato realmente lo comprueba.

Antes de firmar, verifica todo lo siguiente mediante una interfaz oficial de gobernanza, la documentación o datos del contrato comprobados de forma independiente:

  • primaryType y los nombres de los campos describen una delegación, no un permiso, una transferencia de tokens, una orden ni una autorización de gestión de cuenta.
  • verifyingContract es el contrato de token o gobernanza previsto en el chainId activo.
  • delegatee es la dirección del representante que seleccionaste, comprobada por la dirección completa y no por un nombre mostrado.
  • nonce coincide con el nonce actual del contrato para el firmante, y expiry es lo bastante breve para el flujo previsto.
  • La billetera muestra todos los datos tipados. Rechaza solicitudes de firma ciega o hashes sin procesar cuyo significado no puedas reproducir de forma independiente.

Las implementaciones varían. Por ejemplo, el contrato COMP de Compound calcula el hash del delegado, el nonce y el vencimiento, exige que el nonce coincida con el almacenado para el firmante, incrementa ese nonce y rechaza una firma vencida. La interfaz Votes de OpenZeppelin también expone delegateBySig, la gestión de nonces y comprobaciones de vencimiento. No supongas que una función con un nombre similar en otro contrato tiene protecciones idénticas.

Ejemplo

Mira quiere delegar 10.000 votos a la dirección 0xAB...1234. Su billetera muestra primaryType: Delegation, el contrato verificado del token de votación, el ID de la cadena activa, delegatee: 0xAB...1234, el nonce actual y un vencimiento dentro de 20 minutos. Tras comprobar la dirección mediante una segunda fuente de confianza, firma; un retransmisor envía el mensaje y el contrato emite el evento de delegación. El saldo de tokens permanece en su billetera, mientras que el representante recibe el poder de voto asociado conforme a las reglas del protocolo.

Ahora cambia un detalle: la página solicita primaryType: Permit e indica un gastador de tokens, o verifyingContract es un contrato no relacionado. No es la misma instrucción de delegación. Podría autorizar el gasto de tokens, aunque la página etiquete el botón como «Delegar» y el firmante no pague gas. Mira debe rechazarla.

Riesgos y controles

  • Delegado equivocado: el envenenamiento de direcciones, los mensajes privados y los nombres mostrados copiados pueden sustituir delegatee por una dirección controlada por un atacante. Verifica la dirección completa mediante una propuesta oficial o el perfil del delegado.
  • Acción equivocada: una interfaz maliciosa puede solicitar otro tipo EIP-712, como un permiso. Lee primaryType, todos los campos y el contrato de verificación; la etiqueta del botón no ofrece seguridad alguna.
  • Repetición: unas comprobaciones de nonce débiles o inexistentes pueden permitir reutilizar una firma. Un dominio que no esté vinculado a la cadena o al contrato previstos también puede permitir su uso en un contexto no deseado. Confirma el código de verificación real, porque EIP-712 por sí solo no protege contra la repetición.
  • Firma de larga duración: un mensaje firmado sin utilizar puede seguir siendo ejecutable hasta que venza o su nonce deje de ser válido. Prefiere un vencimiento corto, no publiques la firma y, si necesitas cancelarla, usa únicamente el método de invalidación documentado por el protocolo.
  • Visualización engañosa de la billetera: los campos truncados, un dominio desconocido o la firma ciega impiden un consentimiento informado. Cancela e inspecciona la solicitud de datos tipados con una billetera o un decodificador que muestre el mensaje completo.
  • Diferencias de las cuentas de contrato: las billeteras de contrato inteligente pueden validar firmas mediante ERC-1271, donde la validez puede depender del estado y la política de autorización de la billetera. Confirma que tanto la billetera como el contrato de gobernanza sean compatibles, en lugar de asumir una recuperación propia de una EOA.
  • Consecuencias para la gobernanza: la delegación puede concentrar poder de voto o permitir que un delegado no fiable vote en contra de tus intereses. Revisa la identidad, el historial de votación y los conflictos del delegado, además del proceso del protocolo para volver a delegar.

Después del envío, verifica la transacción en la cadena correcta: comprueba el contrato de destino, la función decodificada, el firmante recuperado o indicado por el evento, el nuevo delegado y el nonce. Que una transacción del retransmisor sea exitosa solo demuestra que el contrato aceptó la llamada; no demuestra que la intención firmada fuera segura.

Si firmaste pero no has visto un envío, deja de compartir la firma y consulta el procedimiento documentado por el protocolo para cancelar o invalidar el nonce. Si se ejecutó una delegación no deseada, vuelve a delegar mediante el contrato oficial y verifica el nuevo estado. Una delegación por sí sola normalmente no crea una autorización de tokens, así que no confundas volver a delegar con revocar autorizaciones. Si además firmaste un permiso o expusiste una frase semilla o clave privada, trátalo como un incidente de billetera distinto y de mayor gravedad.

Errores comunes

  • «Sin gas no hay autorización». El retransmisor puede pagar el gas mientras la firma aporta la autorización del firmante.
  • «EIP-712 hace segura cualquier firma». Estandariza el hash de datos tipados y la separación de dominios, pero el estándar no incluye protección contra repetición ni puede verificar que un usuario pretendía realizar la acción mostrada.
  • «La delegación transfiere mis tokens». La delegación de voto convencional mueve o asigna poder de voto, no la propiedad de los tokens, pero solo el contrato desplegado y el mensaje decodificado pueden determinar el efecto real.
  • «Siempre puedo revocar una firma fuera de la cadena». No existe una transacción universal para revocar firmas. El vencimiento, el consumo o la invalidación del nonce y la nueva delegación son mecanismos específicos de cada contrato.
  • «Cambiar de delegado borra los votos anteriores». Volver a delegar modifica el poder de voto futuro o actual según las reglas del protocolo; puede no deshacer votos ya emitidos ni cambiar instantáneas históricas.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...