Delegaste tu poder de voto una vez y ahora lo quieres de vuelta. En el contrato no hay una instrucción de revocación aparte, y no hace falta que la haya, porque una delegación es un único campo que se sobrescribe. Lo que no puedes hacer es recuperarlo con efecto retroactivo.
Qué movió realmente una delegación
Tener un token de gobernanza no es lo mismo que tener poder de voto. La documentación de gobernanza de OpenZeppelin es explícita en que son los delegados quienes portan el poder de voto: un titular que quiera participar puede designar como delegado a un representante de confianza, o convertirse él mismo en delegado autodelegándose. La documentación de Compound describe el mismo paso, con titulares de tokens que delegan su derecho de voto en sí mismos o en una dirección de su elección.
Nada salió de tu monedero al hacerlo. Compound indica el tamaño de lo que sí se mueve: el número de votos añadidos al recuento del delegado equivale al saldo que hay en la cuenta del usuario. Tus tokens siguieron donde estaban, junto a ellos quedó registrado un destino, y un recuento de votos en otra dirección subió por tu saldo.
La razón de ese diseño es el coste. OpenZeppelin señala que, por defecto, un saldo de tokens no contabiliza poder de voto, lo que abarata las transferencias, y la contrapartida declarada es que exige que los usuarios se deleguen a sí mismos para activar siquiera el seguimiento. El poder de voto es maquinaria opcional adosada al costado de un saldo, no una propiedad del saldo.
Así que lo que estás deshaciendo es un puntero, no una transferencia. La pregunta no es cómo recuperar los tokens, porque nunca fueron a ninguna parte. Es qué debe decir ese puntero a continuación.
Revocar es delegar otra vez, no borrar
La documentación de Compound indica que los votos quedan delegados desde el bloque actual en adelante, hasta que el emisor vuelva a delegar o transfiera sus tokens. Lee esa cláusula al revés y tienes el procedimiento de revocación: vuelves a delegar.
El campo guarda un destino, así que no hay hueco vacío al que volver ni segunda instrucción que enviar. Escribir un destino nuevo sobrescribe el viejo en el mismo acto. Una interfaz que te ofrece un control de revocación y otra que solo ofrece un control de delegación hacen por debajo lo mismo, y el mensaje que tu monedero te pide firmar dirá delegar en ambos casos.
De ahí se siguen dos consecuencias. Revocar cuesta una transacción y una comisión, exactamente igual que la delegación original. Y revocar es público: el nuevo destino queda escrito en la cadena, donde puede verlo cualquiera que lea el registro de delegados.
Adónde va el peso cuando actúas
Deshacer una delegación es elegir un destino, y los destinos no te dejan en la misma posición.
| Qué haces | Recuento de tu antiguo delegado | Tu propio poder de voto |
|---|---|---|
| Delegar en ti mismo | Baja por tu saldo | Igual a tu saldo |
| Delegar en otra dirección | Baja por tu saldo | Sigue en cero, ahora lo porta otro |
| Transferir los tokens fuera | Baja por el saldo que moviste | Se va con los tokens |
| No hacer nada | Sin cambios | Cero |
Solo la primera fila te convierte en votante. La segunda es un cambio de representante, no una salida del sistema. La tercera funciona, y es una mala vía para el objetivo, porque se deshace del activo para ajustar un campo. La cuarta merece nombrarse: un titular que deja de confiar en un delegado y luego no hace nada no ha registrado disconformidad, porque su peso se sigue emitiendo en su nombre.
Por qué una propuesta ya abierta no se mueve
Aquí es donde una revocación parece rota sin estarlo. La extensión de gobernanza de OpenZeppelin conserva saldos históricos para que el poder de voto se recupere de instantáneas pasadas y no de un saldo actual, algo que su documentación llama una protección importante que impide el voto doble. Compound lee el peso de la misma manera: las direcciones que tenían peso de voto al inicio de la propuesta son las que pueden emitir votos.
Por eso una revocación surte efecto en el bloque en que se mina y se aplica desde ahí en adelante. Si el bloque de instantánea de una propuesta ya pasó, el recuento de esa propuesta lee el registro tal como estaba entonces, y tu antiguo delegado aún puede emitir tu peso en ella después de que hayas recuperado la delegación.
La regla práctica es un plazo, no un botón. Para que un delegado no vote tu peso en una propuesta concreta, la revocación tiene que quedar registrada antes de la instantánea de esa propuesta. Una revocación enviada al día siguiente de abrirse una votación disputada es correcta, llega a tiempo para todo lo que venga después y no vale nada en la votación a la que reaccionabas.
Lo que revocar no hace
Revocar una delegación no es la misma operación que revocar una aprobación de tokens, y el verbo compartido esconde una diferencia real. Una aprobación es un permiso permanente para que un contrato mueva tus tokens. Una delegación no concede ese permiso: un delegado puede emitir tu peso y no puede tocar tu saldo. Borrar todas las aprobaciones de tu monedero deja tu delegación donde estaba, y revocar tu delegación deja cada aprobación donde estaba.
No deshace lo que tu delegado ya hizo. Los votos ya emitidos siguen emitidos, las propuestas ya decididas siguen decididas, y el registro de cómo se usó tu peso no queda editado por la revocación.
No libera tokens que retiene un contrato aparte. Si tu saldo está bloqueado, en staking o envuelto en una posición vote-escrow, la delegación asociada a esa posición sigue las reglas de ese contrato, y una revocación enviada al contrato del token no llega hasta ella.
La delegación fuera de la cadena se revoca en otro sitio
No toda votación se liquida en la cadena, y una DAO que celebra sus votaciones fuera de ella guarda su registro de delegaciones fuera del contrato del token. La documentación de Snapshot describe tres vías para delegar: un registro de delegados, que se usa cuando un espacio ha configurado un contrato de delegación propio; la propia página de delegación de Snapshot, que presenta como la solución más rápida para delegar en una dirección conocida; y la interacción directa con el contrato.
Esa pluralidad es lo que hay que comprobar antes de dar por terminado el trabajo. La documentación de Snapshot señala además que una delegación directa a un espacio elegido tiene prioridad sobre una delegación hecha a todos los espacios, de modo que un mismo titular puede estar delegado en más de un sitio a la vez, con un orden definido entre ellos.
La auditoría es sencilla de enunciar. Enumera cada registro en el que tu dirección aparezca como delegante, dentro y fuera de la cadena, y límpialos uno a uno. Una revocación en el contrato del token no dice nada sobre una entrada de registro que lee otro sistema.
Un ejemplo resuelto
Supón que tienes 10.000 tokens y los delegaste en una dirección que porta 250.000 de peso de voto en total, de modo que tu saldo es el 4 % de lo que ese delegado puede emitir. Se abre la propuesta A y pasa su bloque de instantánea. Después delegas en ti mismo.
Desde ese bloque en adelante, dos afirmaciones son ciertas a la vez. En la propuesta A, tu antiguo delegado sigue portando 250.000, porque ese recuento lee la instantánea y no el registro tal como está ahora. En la propuesta siguiente, el mismo delegado porta 240.000, y tú portas 10.000 que puedes emitir por tu cuenta.
La segunda línea es también donde cambia el reporte. Tu peso pasó de un delegado a un titular, lo que tira hacia abajo de una lectura de concentración de votantes y hacia arriba del número de participantes, mientras que una tasa de participación medida sobre el peso delegado solo mejora si después emites un voto. Recuperar tu peso y no usarlo nunca te deja en el mismo lugar que dejarlo con un delegado que se abstiene.
En resumen
Una delegación es un campo que guarda un destino, así que revocarla significa escribir un destino nuevo en lugar de borrar uno viejo. Delega en ti mismo y te conviertes en el votante; delega en otro sitio y has cambiado de representante; no hagas nada y tu peso se seguirá emitiendo sin ti.
Lo que atrapa a la gente es el calendario. El poder de voto se lee de una instantánea pasada, así que una revocación obliga a toda propuesta cuya instantánea llegue después de ella y a ninguna de las ya abiertas. Comprueba el registro de delegados antes de una votación que te importe, no después, y comprueba cada registro que tu organización usa de verdad. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Por qué una migración de token pide una aprobación en la billetera
- Migración de tokens completada pero los nuevos tokens no aparecen
- Cómo calcular la autonomía de la tesorería de un token
- Ratio NVT: valor de red frente a transacciones
- Estafas de airdrops y una lista de seguridad previa a la reclamación
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[1] Documentación de OpenZeppelin Contracts 5.x, Governance docs.openzeppelin.com
[2] Documentación de OpenZeppelin Contracts 5.x, API, ERC20 (ERC20Votes) docs.openzeppelin.com
[3] Documentación de Compound, Governance (Compound v2) docs.compound.finance
[4] Documentación de Snapshot, guías de usuario, Delegation docs.snapshot.box
