Vestige's on-chain ASA metadata registry passes 766 entries

2026-08-18

metadata · asa · smart-contract · infrastructure · defi · discovery · web · updated

Vestige's on-chain ASA metadata registry passes 766 entries

An Algorand token's public identity has mostly been rented. Its icon sits in an exchange's GitHub repository, its description is curated by whichever wallet app happens to display it, and a project that wants to change its logo opens a pull request and waits for a maintainer. Vestige Labs built the Asset Manager to move that entire profile onto the ledger, and the launch write-up opens by naming the friction directly: 'token metadata was scattered everywhere, with no standard way to manage it.'

Algorand Standard Assets (ASAs), the chain's built-in mechanism for issuing tokens, carry only a few native fields — name, unit name, total supply, decimals, and control addresses. Everything that makes a token presentable has lived in curator-run lists off-chain: icons in Tinyman's asa-list repository, wallet labels (team or burn addresses) in Vestige's own KnownAssetWallets repository, descriptions and social links scattered across platforms. The practical cost for a creator is updates that require several services' manual review; for a user it is circulating-supply figures that disagree between explorers because each maintains its own labels. Vestige — the swap aggregator and explorer that began as TinyChart, whose homepage counters now show 1,482,038 routed swaps and $207,426,223 in cumulative volume — answers with a smart contract that stores a token's profile directly on-chain, documented in depth at vestigelabs.org.

What the contract stores

The AsaMetadataManager contract (application ID 3129810607 on mainnet) keeps three kinds of records per asset in box storage, the ledger's key-value area for application data. Because Algorand settles blocks in roughly four seconds at fraction-of-a-cent transaction costs, writing and updating these records is cheap enough for a routine workflow — a pattern that would be impractical on a chain with heavy gas fees.

Registry	Concept	Real-World Implication
Core metadata	Description (max 240 bytes), icon URL (max 96 bytes), and up to 15 fields with enumerated labels — Twitter, Telegram, Discord, Farcaster, Bluesky, website and more — each value up to 96 bytes	A token's logo, pitch and social links become a first-class on-chain record any explorer can read, instead of a row in someone's database
Wallet labels	Up to 20 labeled addresses, each with a type (1 = burn, 2 = team) and a short note (max 60 bytes)	Projects can prove which wallets are theirs — team treasury, marketing fund, burned tokens — without anyone's permission
Metadata managers	Up to 10 addresses authorized to edit the asset's records	Control can be shared across a team; the last manager can never be removed, so an asset cannot be orphaned

A creator walks into the Asset Manager UI, connects a wallet (Pera, Defly, Lute, WalletConnect, Exodus or W3 Wallet), types an ASA ID into a search box, and lands on a page split into a read-only overview — asset info, related addresses, supply distribution — and editable sections for metadata, managers, fields and wallet labels. The first save triggers a one-time initialization that seeds the managers list with the asset's creator, manager and reserve addresses plus the contract's admin. Icons uploaded from a computer are pushed to IPFS, the decentralized file-storage network, and the resulting URL is stored on-chain. As edits accumulate, a floating bar shows the transaction count and estimated fees, including the minimum-balance requirements of new boxes — box storage obliges the application account to hold ALGO proportional to the bytes it stores.

The wallet labels do the heaviest lifting. ARC-62, a draft Algorand standard, defines circulating supply as total supply minus the balance of the reserve address and all labeled wallets; the contract implements that calculation directly in its arc62_get_circulating_supply method. A token's 'circulating supply' stops being one team's estimate and becomes a number anyone can reproduce from the ledger. Vestige's backend also accounts for vault contracts and 'bonfire' burn addresses automatically, even when creators have not labeled them, per the project's launch post.

On-chain: verified, and growing

The registry is checkable rather than claimed. The contract's creator is the account behind the NFD satishccy.algo — Satish Chandra Chowdary Yadlapalli, listed on the team page as a full-stack blockchain developer and sole contributor to the open-source contract repository — and its global manager is vest.algo, Vestige's own wallet. The app account was funded on 20 July 2025 and the launch post ran two days later; a testnet twin (app 743122411) was created by the same account.

Box storage currently holds 766 entries across the three registries — corresponding, at up to three boxes per asset, to a few hundred distinct tokens — up from 763 when this outlet last checked the contract earlier in August. The box names decode to asset IDs, with 'm' and 'w' prefixes marking the manager and wallet-label registries, and sampled names resolve to real ASAs such as Glizzy Financial (ID 1053260256). The app account has received a steady stream of small ALGO payments, the most recent on 16 August 2026, consistent with the minimum-balance funding that box storage imposes and a signal the contract is still in active use.

The dogfooding is visible. VEST, Vestige's own token, carries a full on-chain profile: three managers — satishccy.algo, vest.algo, and grzracz.orange.algo, the NFD of founder Grzegorz Raczek — four social fields, and three wallet labels including a burn address described as 'Bonfire Address' and the founder's wallet, from which the contract derives a circulating supply of 42.28 million of 100 million VEST. A smaller project shows the same loop end to end: Glizzy Financial's management page carries an IPFS icon, a description ('A Tokenized actively managed ASA Portfolio. We aim to add liquidity and acquire ASAs across many of the exciting projects in the Algorand community.'), and vest.algo as app manager — and that description is exactly what the asset's page on Vestige displays, with an 'Asset Manager' link in its explorer list. The registry is already wired into the explorer's data pipeline.

Standards, docs, and a hub that is still settling

For developers, the contract is unusually well documented. The docs site carries a Developer Guide with JavaScript examples against an ARC-56 ABI JSON, an API reference covering every method, and a Standards Compliance page. Because the AVM caps return values at 4KB, the contract's bulk getters emit data through transaction logs rather than return values; clients capture and decode the ABI-encoded output, a detail the guide spells out with working code.

Standard	Concept	Real-World Implication
ARC-22	Read-only methods callable without a signer	Any client can query metadata via a simulated call — no wallet, no fees
ARC-28	Standardized application events	Every metadata change is emitted as a machine-readable event, a permanent audit trail
ARC-56	ABI specification in JSON	Developer tools can generate typed clients from a single published file
ARC-62	Circulating-supply calculation	Supply figures become verifiable and consistent across apps
ARC-65	Standardized contract-to-client errors	Failed calls log codes like ERR:004:MAX that map to readable messages, easing debugging

The docs also cover the rest of the suite — Swap, Vault, Launchpad, Free API — plus team, contact, glossary and disclaimers, with a rug.ninja section that is still a single 'TBD'. Some rough edges remain. The free API's documentation endpoint, advertised at free-api.vestige.fi/docs, returns a 530 server error as of this writing; the older GitBook wiki at about.vestige.fi still carries 'last updated' stamps from three years ago; and the FAQ's answer to when the next update ships is, characteristically, 'Two weeks.' The Vestige Labs Discord lists 2,187 members with 128 online at the time of checking.

Risks and tradeoffs worth naming

A few caveats are structural rather than cosmetic. First, centralization: vest.algo is seeded into every asset's manager list at initialization — the UI itself notes, 'This address manages the metadata contract and will be added to the asset managers list during initialization. You may remove it if desired.' An asset's own managers can remove Vestige, but by default the registry operator holds write access to every registered profile: the gatekeeper problem the product claims to remove is partially reproduced, with the difference that it is opt-outable and visible on-chain. Second, neither the documentation nor the repository references a third-party audit of the contract; the security story rests on manager authentication, input validation, last-manager removal protection and event logging, all of which the README documents. Third, incentives: the same company operates the registry, the explorer that displays its data, and VEST, a token whose holders receive a larger share of the swap router's price-improvement bonus, which the swap documentation describes as scaling with VEST held. When Vestige itself labels its own token's wallets, the resulting circulating-supply figure is shown ecosystem-wide; nothing is hidden, but the registry operator is not a neutral observer of the numbers it publishes. Finally, adoption is real but modest — a few hundred tokens is a small fraction of the ASAs issued on Algorand, and much of the visible use so far is Vestige's own properties.

The upshot

The Asset Manager is the most infrastructure-like product Vestige has shipped: it turns a token's identity into an auditable, creator-controlled on-chain record, and its value grows with the number of consumers — explorers, wallets, analytics tools — that choose to read it rather than maintain their own lists. That adoption is the open question. For now the registry is live, documented, growing, and checkable by anyone with an indexer; whether it becomes the ecosystem's standard source of truth depends on who else decides to use it.

Source

Source: https://vestigelabs.org/docs/vestigefi/Disclaimers/terms-of-service