Algorand's Smart ASA v2 moves a token's freeze to a place its holder cannot clear

A token can now be frozen before its holder owns a single unit, and the freeze stays after the holder walks away. That is the change in Smart ASA v2, the rebuilt reference implementation of Algorand's ARC-20 standard, published on October 23.

The token with a contract in the middle

An ASA is Algorand's native token. It is created in one transaction and held by opting in. Its name, unit, decimals and maximum supply are fixed at creation. Its four roles sit on addresses, and there is no hook for an issuer's own rule to run on a transfer between two holders.

The older route to enforcing a rule was to freeze the asset and push units through clawback, which looks to a holder like a seizure where a transfer was expected. ARC-20 keeps the native token and hands the four roles to a contract. The asset is created frozen by default, so units reach a holder only through the contract, and every movement is checked first.

That makes ARC-20 the mirror image of ARC-200¹, Algorand's other contract-token standard, where the token is the contract and behaves like an Ethereum token with balances and approvals. ARC-20 keeps the asset native, so wallets and exchanges hold it as they hold any other token, and puts the rulebook on top.

What version 2 changes

Account freezes move out of the holder's own storage and into empty boxes the contract owns. Under the old design the flag lived in the account's local state, and the holder could clear it. The specification² now notes that boxed state cannot be deleted by the holder, and that holders need not opt in to the contract at all. Their locked balance falls from 0.2285 to 0.1³ ALGO.

Some limits remain. A freeze can be placed on an address before it holds anything, which is what a sanctions list needs, and it survives the holder leaving and returning. The first freeze on an account creates a box. It is funded by a deposit of 0.0157⁴ ALGO paid to the contract just before the freeze call and refunded when the account returns to its default state.

What that buys is narrow and real: an issuer can hold a rule against a holder who does not cooperate, while the supply cap and the payout logic sit in public state that anyone can read. Whether it is a feature depends on which side of the freeze you stand.

The rest is housekeeping with teeth. The previous version, published three days earlier, encoded asset and account arguments as plain integers and addresses, so 'its method selectors didn't match the ARC-20 interface⁵'. Version 2 uses the standard's own types and asks clients to regenerate. Failed calls now log ARC-65 error codes, so a wallet can name the reason instead of showing an assertion message. Two extension points let an issuer add checks to ordinary transfers and define circulating supply, with a capped example in the repository.

Freezes are layered. A global freeze halts transfers and an account freeze stops one holder; the release notes say a clawback is never blocked by either, and roles held by one address each act by their own rules.

What it takes to use it

Deploying one means deploying a contract and creating an asset, then paying a fee per action. The release's migration checklist prices issue, redeem, clawback, ordinary transfer and a freeze reset at twice the minimum fee. Destroying a token costs three times that. Each frozen account also locks a 0.0157⁶ ALGO deposit in the contract, returned on reset.

The development route is AlgoKit, Poetry and a local network in Docker, all from the repository⁷. There is no hosted service and nothing to sign up for.

Nor is there anything for a general user to open. The release's TestNet section describes a demonstration of five standards but names no application or asset, unlike the notes for the previous version three days before. A developer can read the code and deploy it locally; a reader looking for a live version 2 token has nowhere to go.

The fuller variant leans on ARC-89, the metadata registry, which its own adoption record lists as deployed on TestNet and pending a MainNet deployment. That registry's latest release calls itself the first release candidate for the MainNet deployment. Until it lands, the fuller flavor is TestNet work.

Who builds it

Cosimo Bassi, who posts as cusma⁸, wrote the ARC-20 specification. He maintains this implementation and wrote the metadata registry it leans on. The repository sits under the Algorand Foundation, and its release list puts the previous version on October 20 and this one on October 23. On release day he asked issuers, wallets and explorers for feedback.

An earlier implementation at algorandlabs/smart-asa⁹ did the same job from 2022. It bound the token to its contract by writing the contract's number into the token's URL field and kept each holder's frozen flag in local state. Version 2 replaces that arrangement, and it is the one the live tokens still follow.

The only live user

ARC-20's adoption file lists exactly one project, enel-ebitts, with readiness marked low and wallets, explorers and tooling empty. ebitts is the Enel and Conio service that sells Italian households tokens tied to the output of two renewable plants and credits that output against the electricity bill; PXke covered its launch in October.

Each plant has its own token named after it: ebitts Barile Venosa, ticker EBT-BVEN, and ebitts Piani della Marina, EBT-PDM.¹⁰ Both have been on Algorand mainnet since May 2026.¹¹ The wind token's four roles sit on the account its own contract owns, not on a person's key, so every movement runs through that contract. Inside the contract, those four roles are assigned to a single wallet. The tokens carry the older binding in their URL fields. Their contracts also point to a payout application, a reward token and an identity application that this release's contract does not. They answer to the same interface as a custom build, not as a copy of version 2.

They are alive. The wind token's contract has sent about 1,830¹² transfers to roughly 370¹³ wallets since May 4, 475¹⁴ of them in the thirty days to October 26, all from a single address, so these are distributions out of the contract rather than trades between holders. Neither token trades at all.

Nearly all of both supplies still sits with one wallet. It created both contracts. Each contract's stored state names it as manager, reserve, freeze and clawback. It holds about 97.7%¹⁵ of the wind token and about 99.8%¹⁶ of the solar one.

The adoption file's evidence link opens a different token in the same family, one whose contract is named REWARD and stores two decimals, not either plant token. The record shows the family exists; it does not by itself show that the units households hold conform.

What can go wrong

The release says two things about itself. It tells deployers to start a new contract, because the previous version's applications cannot be upgraded in place. And the code has not been audited.

The rest rests on the issuer, and the specification says so. The rules hold only while the token stays frozen by default, its clawback address stays with the contract, and that contract cannot be updated, deleted or rekeyed. Its revised text names two ways out. The asset's freeze address can unfreeze holdings, and its manager address can change the clawback, unless either is set to the contract or left empty.

A holder can be misled by their own wallet. The underlying asset always reports zero decimals and a placeholder maximum, whatever the issuer configured, and wallets that do not understand ARC-20 display that instead of the real configuration.

The paperwork drifts too. The repository changed its metadata rule from must-be-immutable to should-be-immutable on the day of the release, and the developer portal's copy still says must, and still describes freeze state sitting in a holder's local storage. Anyone checking the portal reads the version this release replaced.

One reply to the announcement asked plainly what a use case for a smart ASA would be. The only working example on the record is an electricity bill in Italy, and it runs on an earlier build.