Smart ASA v2 de Algorand traslada el congelamiento de un token a un lugar que su titular no puede desactivar

Un token puede congelarse ahora antes de que su titular posea una sola unidad, y el congelamiento se mantiene aunque el titular se marche. Ese es el cambio que introduce Smart ASA v2, la implementación de referencia reconstruida del estándar ARC-20 de Algorand, publicada el 23 de octubre.

El token con un contrato en medio

Un ASA es el token nativo de Algorand. Se crea en una sola transacción y se posee mediante la adhesión voluntaria. Su nombre, unidad, decimales y suministro máximo quedan fijados en el momento de la creación. Sus cuatro roles recaen sobre direcciones, y no existe ningún gancho para que la regla propia de un emisor se ejecute en una transferencia entre dos titulares.

La vía anterior para imponer una regla consistía en congelar el activo y mover unidades mediante clawback, lo que a ojos del titular parece una incautación donde esperaba una transferencia. ARC-20 conserva el token nativo y entrega los cuatro roles a un contrato. El activo se crea congelado por defecto, de modo que las unidades solo llegan a un titular a través del contrato y cada movimiento se verifica antes.

Eso convierte a ARC-20 en el reflejo inverso de ARC-200¹, el otro estándar de token por contrato de Algorand, donde el token es el contrato y se comporta como un token de Ethereum con saldos y aprobaciones. ARC-20 mantiene el activo como nativo, de forma que las billeteras y los exchanges lo custodian igual que cualquier otro token, y coloca el reglamento por encima.

Qué cambia la versión 2

Los congelamientos de cuenta salen del almacenamiento del propio titular y pasan a cajas vacías que posee el contrato. Con el diseño anterior, la marca residía en el estado local de la cuenta y el titular podía desactivarla. La especificación² señala ahora que el titular no puede eliminar el estado guardado en cajas y que ni siquiera necesita adherirse al contrato. Su saldo bloqueado baja de 0,2285 a 0,1³ ALGO.

Quedan algunas limitaciones. Un congelamiento puede aplicarse a una dirección antes de que esta posea nada, que es lo que requiere una lista de sanciones, y sobrevive a que el titular se vaya y regrese. El primer congelamiento de una cuenta crea una caja. Se financia con un depósito de 0,0157⁴ ALGO abonado al contrato justo antes de la llamada de congelamiento y reembolsado cuando la cuenta vuelve a su estado por defecto.

Lo que eso aporta es limitado y real: un emisor puede mantener una regla contra un titular que no colabora, mientras el límite de suministro y la lógica de pago residen en un estado público que cualquiera puede consultar. Que sea una ventaja depende del lado del congelamiento en el que uno se encuentre.

El resto son tareas de mantenimiento con consecuencias. La versión anterior, publicada tres días antes, codificaba los argumentos de activo y cuenta como enteros y direcciones simples, de modo que 'sus selectores de método no coincidían con la interfaz de ARC-20⁵'. La versión 2 usa los tipos propios del estándar y pide a los clientes que los regeneren. Las llamadas fallidas registran ahora códigos de error ARC-65, para que una billetera pueda indicar el motivo en lugar de mostrar un mensaje de aserción. Dos puntos de extensión permiten al emisor añadir comprobaciones a las transferencias ordinarias y definir el suministro en circulación, con un ejemplo con límite en el repositorio.

Los congelamientos se aplican por capas. Un congelamiento global detiene las transferencias y un congelamiento de cuenta frena a un solo titular; las notas de la publicación indican que ninguno de los dos bloquea nunca un clawback, y los roles que recaen cada uno en una dirección actúan según sus propias reglas.

Qué hace falta para usarlo

Desplegarlo implica desplegar un contrato y crear un activo, y luego pagar una comisión por cada acción. La lista de comprobación de migración de la publicación fija en el doble de la comisión mínima el coste de emisión, reembolso, clawback, transferencia ordinaria y reinicio de un congelamiento. Destruir un token cuesta el triple. Además, cada cuenta congelada bloquea un depósito de 0,0157⁶ ALGO en el contrato, que se devuelve al reiniciarla.

La vía de desarrollo es AlgoKit, Poetry y una red local en Docker, todo desde el repositorio⁷. No hay servicio alojado ni nada a lo que registrarse.

Tampoco hay nada que un usuario general pueda abrir. La sección de TestNet de la publicación describe una demostración de cinco estándares, pero no nombra ninguna aplicación ni ningún activo, a diferencia de las notas de la versión anterior de tres días antes. Un desarrollador puede leer el código y desplegarlo en local; un lector que busque un token vivo de la versión 2 no tiene adónde ir.

La variante más completa se apoya en ARC-89, el registro de metadatos, que su propio historial de adopción da por desplegado en TestNet y pendiente de un despliegue en MainNet. La última publicación de ese registro se presenta como la primera candidata para el despliegue en MainNet. Hasta que llegue, la variante más completa es trabajo de TestNet.

Quién lo construye

Cosimo Bassi, que publica como cusma⁸, redactó la especificación de ARC-20. Mantiene esta implementación y escribió el registro de metadatos en el que se apoya. El repositorio depende de la Algorand Foundation, y su lista de publicaciones sitúa la versión anterior el 20 de octubre y esta el 23 de octubre. El día de la publicación pidió comentarios a emisores, billeteras y exploradores.

Una implementación anterior en algorandlabs/smart-asa⁹ hacía la misma función desde 2022. Vinculaba el token a su contrato escribiendo el número del contrato en el campo URL del token y guardaba la marca de congelamiento de cada titular en el estado local. La versión 2 sustituye ese esquema, y es el que siguen todavía los tokens vivos.

El único usuario activo

El archivo de adopción de ARC-20 enumera exactamente un proyecto, enel-ebitts, con la preparación marcada como baja y las casillas de billeteras, exploradores y herramientas vacías. ebitts es el servicio de Enel y Conio que vende a hogares italianos tokens vinculados a la producción de dos plantas renovables y abona esa producción contra la factura eléctrica; PXke cubrió su lanzamiento en octubre.

Cada planta tiene su propio token con su nombre: ebitts Barile Venosa, con el ticker EBT-BVEN, y ebitts Piani della Marina, EBT-PDM.¹⁰ Ambos están en la mainnet de Algorand desde mayo de 2026.¹¹ Los cuatro roles del token eólico recaen sobre la cuenta que posee su propio contrato, no sobre la clave de una persona, de modo que cada movimiento pasa por ese contrato. Dentro del contrato, esos cuatro roles están asignados a una única billetera. Los tokens conservan en sus campos URL el vínculo del esquema anterior. Sus contratos apuntan además a una aplicación de pago, a un token de recompensa y a una aplicación de identidad, algo que el contrato de esta publicación no hace. Responden a la misma interfaz que una compilación personalizada, no a una copia de la versión 2.

Están vivos. El contrato del token eólico ha enviado unas 1.830¹² transferencias a aproximadamente 370¹³ billeteras desde el 4 de mayo, 475¹⁴ de ellas en los treinta días hasta el 26 de octubre, todas desde una única dirección, así que se trata de distribuciones que salen del contrato y no de intercambios entre titulares. Ninguno de los dos tokens cotiza en absoluto.

Casi todo el suministro de ambos sigue en una sola billetera. Fue la que creó los dos contratos. El estado almacenado de cada contrato la designa como gestora, reserva, congelamiento y clawback. Posee alrededor del 97,7¹⁵% del token eólico y del 99,8¹⁶% del solar.

El enlace de evidencia del archivo de adopción abre un token distinto de la misma familia, uno cuyo contrato se llama REWARD y almacena dos decimales, no ninguno de los tokens de las plantas. El registro demuestra que la familia existe; por sí solo no demuestra que las unidades que poseen los hogares se ajusten a la norma.

Qué puede salir mal

La publicación dice dos cosas de sí misma. Indica a quienes despliegan que inicien un contrato nuevo, porque las aplicaciones de la versión anterior no se pueden actualizar sobre la marcha. Y el código no ha sido auditado.

El resto recae sobre el emisor, y la especificación lo dice. Las reglas solo se sostienen mientras el token siga congelado por defecto, su dirección de clawback siga en poder del contrato y ese contrato no pueda actualizarse, eliminarse ni cambiar sus claves. Su texto revisado señala dos vías de escape. La dirección de congelamiento del activo puede descongelar las tenencias, y su dirección gestora puede cambiar el clawback, salvo que una u otra estén fijadas al contrato o se dejen vacías.

Un titular puede llevarse una impresión equivocada por culpa de su propia billetera. El activo subyacente informa siempre de cero decimales y de un suministro máximo de relleno, sea cual sea la configuración del emisor, y las billeteras que no entienden ARC-20 muestran eso en lugar de la configuración real.

La documentación también se desfasa. El repositorio cambió su regla de metadatos de debe-ser-inmutable a debería-ser-inmutable el mismo día de la publicación, y la copia del portal para desarrolladores sigue diciendo debe y sigue describiendo el estado de congelamiento en el almacenamiento local del titular. Quien consulte el portal lee la versión que esta publicación ha sustituido.

Una respuesta al anuncio preguntaba sin rodeos cuál sería un caso de uso de un ASA inteligente. El único ejemplo que funciona según los registros es una factura eléctrica en Italia, y corre sobre una compilación anterior.

Fuentes

• Release v2.0.0 · algorandfoundation/arc20 · GitHub¹⁷
• ARCs/ARCs/arc-0020.md at main · algorandfoundation/ARCs · GitHub²
• github.com⁷
• Releases · algorandfoundation/arc20¹⁸
• Algorand Smart Contract Token Specification | Algorand Developer Portal¹
• GitHub - algorandlabs/smart-asa: Smart ASA reference implementation · GitHub⁹
• raw.githubusercontent.com¹⁹