xGov-156 - Open Source ARC53 Tooling

id: 156
period: 3
title: Open Source ARC53 Tooling
author: krby.algo (@kylebeee)
company_name: Akita
category: dApps
focus_area: Defi
open_source: Yes
amount_requested: 25000
status: Final


This proposal aims to build out & open source tooling for decentralized self-soveriegn project details on Algorand. ARC53 is a community page spec that enables projects & companies with onchain assets to trustlessly share details about their business for exploration by the community and other business entities on-chain. NFT marketplaces, wallets, and other dapps can utilize this spec to enable users to explore projects & companies on-chain. This proposal aims to build out open source tooling to enable this spec to be easily utilized by the community.


Krby (https://twitter.com/kylebeeeee) has been a full time software engineer for over 7 years and has been spending his evenings building Akita for the better part of the last 2 years following the original dev teams departure. He’s built a number of massive features for the Akita community including a staking platform, discord payment & verification bot (integrated with NFD’s), Yoink Ball (an in person king of the hill game utilizing Freeze & Clawback) and a permissionless Community spec (ARC-53).

Experience with Algorand

For nearly the last 2 years Krby has been spending his evenings building on Algorand. From writing smart contracts to building the base components of a longer term vision; a social platform built ontop of Algorand, NFDs, subscriptions & the community page spec. To date he’s delivered an astounding amount of value to the Algorand / Akita community and has been the driving force behind the growth of the Akita platform:

  • The most flexible staking platform on Algorand
  • A discord bot that enables payments, verification, and more
  • Yoink Ball, an in person game of king of the hill utilizing Freeze & Clawback
  • Author of ARC53, a permissionless community spec that enables NFT and project exploration with some of the best UX on Algorand
  • A shuffle system for Akita Omnigems where the NFTs have no data attached to them before sale
  • Co-Author of ARC58, the Abstracted Account spec.

Present Proposal

This proposal aims to build open source tooling for parsing & caching ARC53 community data. This will enable dapps to easily integrate and display consistent information about projects & companies on-chain. Open source libraries will be written in Golang & Typescript.

Benefits for the community

Projects & Businesses on Algorand currently deal with a centralized and fragmented landscape when it comes to sharing information about their business. ARC53 allows them to share this information in a verifiable and trustless manner thats easily consumable for dapps like NFT marketplaces, explorers, etc. Creating tooling for these dapps to more easily adopt the spec will enable a more consistent & convenient experience for users across the ecosystem. As an example, we have many NFT marketplaces and if you want to launch a collection you will need to go fill out repitive forms on each marketplace, if ARC53 we’re easy to integrate with, you would have automatic propegation of your project details across the ecosystem.

Additional information

  1. Can you expand a bit more about what you are proposing to build? I understand what issue ARC53 is supposed to address. I’m not a dev, so I’m just not sure I understand what you are building in relation to it.

  2. My understanding is that ARC53 is not yet final and adopted. Is that correct? If so, is there a danger in building tools around an ARC that is not adopted? What happens if the ARC changes while you are building (or worse, after you are done)?


Yes, specifically this is a proposal to build out and open source the code that does all the heavy lifting for finding the info on chain and saving it as well as tracking the chain for updates to the community info that projects publish.

Its new and this proposal is meant to lower the barrier for businesses to adopt this standard and help create seamless consistency across any places where token/nft collection and other info is displayed.

I proposed it as a living standard so i hope it does change overtime, it’s meant to be expanded upon, customized and added to. There’s a version number baked into it so if/when changes are made it’s easy to distinguish between the new and old.

I think you can reason about this similarly to nft standards in that it felt like everyone had to implement parsing and caching code on their own and it was a lot of redundant work for a lot of people. Similarly, every explorer/marketplace currently has to build all this extra infra for collections/projects to submit the information manually to them and its just a ton of extra work for everyone involved with lots of room for creating inconsistencies and errors. The goal of this xgov proposal is to help make this standard substantially easier to adopt and thus alleviate all that extra work currently being done while improving the experience of creators that want to share information about themselves and their projects.


Thanks Krby. Appreciate you, and I’m not picking on you. I’ve tried to go through every single proposal and provide some type of feedback or question.

I assume that if the ARC changes, someone will just need to fork your code at that time and modify it to meet the ARC change.

1 Like

XGOV-156 is fulfilled & makes this standard much easier to adopt for both ecosystem builders & projects that need to share this information with those platforms.

Is a block watcher & API server for the ARC53 standard, it indexes the data it finds on-chain that follows the ARC as well as updates it.

is a web app that makes it easy for projects to create their ARC53 JSON file for them to upload to IPFS & attach to their provider contract.

You can use the client app here

1 Like

@krby.algo might be me, but can’t seem to find ARC53 in the github repo (unless the branch name is something totally different). Do you have a direct link to the ARC?

1 Like

I was able to clone the git and get the ARC53 tooling running. It did take some setting up with MariaDB but krby helped me slog through all that. Overall after I got background stuff working on Windows, krby’s tooling ran with no issues. Seems like a powerful tool to help keep track of assets on-chain without needing to use the algod indexer constantly.

1 Like

Hey, Yep!

Its not merged so still an open PR

I have tested the app and see that if you input the various parameters it will generate a json file. In my test, I skipped many of the fields and input the word “hello” for addresses, etc – the app still created a json file with the partial and invalid info. As the ARC specifies that no fields are required except the version parameter, what is the minimum requirements for a valid NFT collection?

Even if you revisit this and add validators per field, I’m struggling to see how this advances the primary issues around NFT collections which relate to verification.

You say that json info can be verified by Providers - “Providers are smart contracts that have the capability of verifying multiple wallets”

If you add 10 team members’ addresses to your json, and we assume that a provider builds the necessary infrastructure to somehow verify these team members, how does it prove the association of the team members to any pre-existing ASAs within a collection?

I understand that this ARC is just a metadata declaration, and verification is beyond the scope of the proposal, but a declaration without a verification process does not advance us to a solution.

Meanwhile, there is an alternate ARC proposal that specifies a metadata schema and a robust verification process for NFT collections – its called ARC-40.

Here is the Git

And the forum post
ARC-40: Standards and Validation Workflows for Mutable Asset Sets

ARC-40 goes far beyond ARC-53 and provides a fully integrated verification solution. The json schema within ARC-40 is precisely tailored to the needs of the verification process - these 2 components have to work together! We have already commenced building a tool to generate and verify ARC-40 NFT collections.

The fact that the community is willing to fund tooling for an ARC proposal that is not approved and does not advance us to a solution, while a far more practical solution is ignored, demonstrates the issues that we have within xGov around assessing value to the ecosystem. BTW, the ARC-40 proposal has had no feedback from the community except a single downvote from Krby.

One more thing… You have recently added this text to the ARC proposal:
“Providers that support this standard will be listed on the ARC compatibility matrices site.”

I looked for a sample ‘ARC compatibility matrices’ in other ARCs and could not find one. What is this matrix and is it intended to link to proprietary providers or is it intended to specify technical / backwards compatibilities?

1 Like