[xGov-3240198097] ASA Stats Permission dApp

[ipaleka]

Hey everyone, this is the official discussion thread for the ASA Stats Permission dApp xGov proposal ASA Stats Permission dApp | xGov .

https://github.com/asastats/permission-dapp/

This proposal builds upon the successfully funded proposals xGov-70 and xGov-141 (Securing ASA Stats API high availability for the next 2 years). Our primary motivation remains unchanged: to secure development funding for the Algorand ecosystem’s only portfolio tracking API provider. Furthermore, the new xGov system aligns perfectly with the core ASA Stats mission defined in our whitepaper — to gradually open-source the ASA Stats codebase.

Pull request in the Crypto Ecosystems repository

About

The Permission dApp (Mainnet) enables the ASA Stats engine to retrieve permission values, which control access to additional features for all ASA Stats subscribers and DAO Governors.

Beyond permissions, the dApp also records the number of votes for each ASA Stats DAO governor and is designed to serve as the foundation for future DAO voting sessions.

Background

Beginning with the initial Open Letter and continuing through the latest update, a total of 141 governors have been selected for the ASA Stats DAO over the last four years.

Each of these official documents defines the exact number of votes for every governor. These seat votes are maintained in the Permission dApp repository within JSON files associated with the corresponding documents. The number of votes per governor seat correlates directly with its permission value at a 1:1,000,000 ratio.

ASA Stats users subscribed to a dApp on the Subtopia.io platform receive additional service permissions based on predefined values.

Until June 2025, all participants in the official ASA Stats governance staking programs also had access to additional features, and their permission values were similarly recorded in the Permission dApp.

How It Works

• Smart Contract: The creation code is located in the contract module, which outputs the contract to the artifacts directory.

• Deployment: Code for deploying the contract on Mainnet or Testnet is in the deploy module.

• Initial Data Population: The code for the initial population of the dApp’s Algorand boxes with DAO governor data is in the foundation module.

• Data Updates: The code for updating the dApp’s Algorand boxes with data from subscription dApps and staking programs is in the network module.

Why It’s Useful

While this dApp was built to track ASA Stats DAO votes and permissions, the codebase is designed to be adaptable for any project that requires measurable on-chain statuses to be tracked. If you have a use case in mind, I’m happy to help you adapt it for your needs!

• Comprehensive Testing: All code is fully covered by unit tests. Additional integration tests, focused on dApp security, run on Algorand Testnet.

• Continuous Integration: The repository uses GitHub Actions to test every commit against three different Python versions.

• Full Documentation: The codebase is well-documented, and the documentation is automatically built with each commit and hosted on the Read The Docs platform.

[ArbBot]

I’m confused — this looks like basic wrappers for a generic box read/write wrote in pyteal. Not even using more modern standards. It seems to be the wrong direction in general. Where do you get any value add?

[uhudo]

One of the requirements for xGov proposal is that it is submitted to the Electric Capital repo. I don’t see your particular project in this repo. Can you please add it? You can use: Crypto Ecosystems

Nvm. I’ve just seen it is awaitng to be merged.

[ipaleka]

@ArbBot

I’m confused — this looks like basic wrappers for a generic box read/write wrote in pyteal. Not even using more modern standards. It seems to be the wrong direction in general.

Yes, the TEAL/pyTeal part of the repository is basically that. The ASA Stats project doesn’t need any other on-chain capabilities besides retrieving users’ data.
The focus is completely on security, the pyTeal code does exactly what we need, while unit tests and especially integration tests are there to bring trust in the dApp.

The Permission dApp in this iteration simply doesn’t need any other feature. The whole ASA Stats project had been developed by YAGNI and KISS principles, and the Permission dApp is absolutely on the same track.

@ArbBot

Where do you get any value add?

If you comprehend this proposal as “give me money for this simple smart contract I wrote” then you’re right.

Let me try to explain my take on the same.

There’s a smart contract that has a crucial role in the functioning of one of the most complex and prominent projects in the ecosystem. The dApp has limited functionalities because the project currently doesn’t require any additional on-chain functionality. Once the ASA Stats DAO takes over the project, the Permission dApp will be updated with some other functions required by the voting dApp. The initial plan was to create a decentralized chainlink network that runs ASA Stats engines and updates current DAO seats statuses, but, following the KISS principle in the organizational mean too, we’d probably go with adding another call to our SystemD service with another funtion in network module from this repository that updates the users’ boxes with their seat address current value. On top of that, we’d need to change a few constants in the config module, deploy a new dApp on Mainnet, and point the ASA Stats engine to use the new dApp - all of that with 0% of downtime.

I spent a lot of time contemplating the features of this dApp. Many smarter people in the ecosystem could probably come up with a better solution, but I don’t have the funds or charisma to make them spend time on this problem.

Nevertheless, I’m almost certain that the dApp part should remain simple as it is now. I’m not a security expert, but if you ask me, those integration tests are pretty capable.

The repo is fully covered by unit-tests. Ok, some of them look like pro forma additions, but many others aren’t. This proposal is for an open-source repository, which implies updates and improvements. The project is built upon each commit through GitHub workflows, and that is one of the most significant parts of its future integration as a Git submodule inside the open-source main repository (it is now used as a submodule inside a private repo). Also, all the code is well documented, and the documentation is available online, which is also in accordance with future integration plans.

This repository is a robust and probably trustworthy source for any organization in the ecosystem that wants to integrate any type of members’ statuses/hierarchy/… on-chain. Once ASA Stats DAO takes over the project, the repository will be updated with the users’ current seat address value fetched from the ASA Stats engine, and I can think of other projects using such an on-chain functionality.

Last but not least, this isn’t only about the Permission dApp repository itself, and I clearly emphasized that at the very top of the post: this proposal would be used to fund development of the ASA Stats project and its API in the future. The initial plan from November 2021. was to sell ASA Stats Token from the project’s development pool for the purpose, but due to awful market circumstances from January 2022 until the present day, I vetoed it to protect our early investors, and no token has ever been sold. Previous xGov sessions proved that the ASA Stats project has the potential to be funded in ways other than that.

[aper_nft]

How the project uses the grant funds is at its discretion; however, the amount must be calculated strictly based on the proposed scope. Including estimates for future work does not count as retrospective. Furthermore, the scope should be limited to fully completed functionalities.

[ipaleka]

@aper_nft

How the grant funds are used is at the discretion of the project; however, the calculation of the amount must be carried out strictly within the scope proposed. Presenting an amount that includes future considerations is not retrospective.

Of course, the amount presented is calculated solely on this repository code. Or to say, on the effort, time, and knowledge used for its completion and publishing as an open-source repository.

I suppose these official threads are not just for the Council members themselves, but rather for them and the xGovernors. So think of that part you’re referring to as a marketing move.

[ipaleka]

@ArbBot

I’m confused — this looks like basic wrappers for a generic box read/write wrote in pyteal.

I assume many readers could form an opinion solely from this part of this comment without looking into the repository or by reading the whole proposal, so I have to emphasize the following fact:

the repository is indeed named after the Permission dApp (smart contract) this quote refers to, but the smart contract code itself represents no more than 5% or 10% of the repository code and the functionality it brings.

[Mredgarcross]

I’ve read the proposal and can see both perspectives. The Permission dApp does look like a simplified access layer, but sometimes minimalism isn’t a weakness — it’s a sign of sound engineering logic. In the Algorand ecosystem, projects often drown in overengineering, so the KISS principle actually feels appropriate here.

At the same time, from a strategic point of view, this dApp can be seen as a foundation for future DAO mechanics within ASA Stats. It would be great to see a roadmap outlining which specific features are planned for the DAO phase and whether a smart contract audit through the Foundation is being considered.

Essentially, this is a case where the code represents only a small part of the value — what really matters is architectural transparency and a solid testing base. The question isn’t about how complex the contract is, but how much trust it earns.

[ipaleka]

@Mredgarcross

At the same time, from a strategic point of view, this dApp can be seen as a foundation for future DAO mechanics within ASA Stats. It would be great to see a roadmap outlining which specific features are planned for the DAO phase and whether a smart contract audit through the Foundation is being considered.

Thank you for your whole comment, especially for the quoted part. An issue has been created in our official channel on GitHub.

As of now, planned updates come to a single one explained in this comment. That implies updating users’ boxes with a value that defines how many votes (as a percentage) a seat address can submit in the voting session.

The whole process is yet to be defined in our community. I guess we can come out with something like tracking the percentage from the voting session official announcement up until the voting day, when we would freeze the value to the median value.

I can’t confirm the actual voting implementation right now, but it is expected that the value derived from those two values (value = max_votes * percentage/100) from our dApp’s Algorand box for a user would be enough data for any voting dApp provider to implement a voting session.

The issue I just created also implies researching the smart contract’s audit, I really don’t know anything about the process. The rule of thumb is that if someone else sponsors the audit, we’d definitely have one.

[aper_nft]

This Forum thread is open not only to proposers, xGov, and xGov Councils, but also to Algorand users who may not have voting rights, and participation in the discussion is open to all users. I see one of the roles of the xGov Councils as reviewing proposals and fostering discussion so that xGov members with voting rights can obtain the necessary information for voting in a shorter amount of time, without being misled by mere lip service.

Now, whether something is open-source is a prerequisite for the grant, but in practice, what is evaluated is the actual track record: how it has been used and what benefits it has brought to the ecosystem. This track record is assessed retrospectively.
Regarding the functionalities covered by the current scope, how have they been used outside of the ASA Stats service? To be honest, this track record is being discussed in terms of potential future use, which I believe makes it inappropriate as a target for a retroactive grant. Even if it is said that the knowledge will be shared with other projects in the future, no one has actually received that knowledge yet, right?

[ipaleka]

@aper_nft

Even if it is said that the knowledge will be shared with other projects in the future, no one has actually received that knowledge yet, right?

I created the first version of the dApp and afterwards spent almost two full days trying to figure out why the user box name doesn’t exactly translate to the user address. The problem is in this line that adds a byte when the abi.String is used. So a little bird told me to use a different data type and my boxes lived long after in harmony.

Basically, if there were any Permission dApp-ish repo, I would have just seen the example in PyTeal and tried it. In other words, there was no open-source resource in PyTeal that creates a smart contract for creating an Algorand box that corresponds to the user’s public Algorand address. Now we have it.

There was no open-source resource in Python that is shipped with integration tests for the Algorand Testnet to write and delete Algorand boxes. Now we have it, together with the utility functions to list them or delete them all.

There was no open-source resource in Python that showed how a Cometa dApp’s staking value can be fetched from the smart contract. Now we have it.

There was no open-source resource in Python that showed how to fetch data from Subtopia.io smart contract. Now we have it.

How many Algorand open-source projects create and build documentation and/or have CI/CD workflows?

Ok, you do have those “metrics” entries in the proposal form, but how do you measure these things from above?

And finally, I’m ready to be involved in a deeper discussion here with you about the true meaning of the “retroactive grant” term. My opinion/stance has been that retroactive is the other part of the binary world, where the opposite term is “in advance”. I mean, I believe the vast majority of the first four xGov sessions’ proposals can be put in that latter category.

[aper_nft]

@ipaleka

Basically, if there were any Permission dApp-ish repo, I would have just seen the example in PyTeal and tried it. In other words, there was no open-source resource in PyTeal that creates a smart contract for creating an Algorand box that corresponds to the user’s public Algorand address. Now we have it.

There was no open-source resource in Python that is shipped with integration tests for the Algorand Testnet to write and delete Algorand boxes. Now we have it, together with the utility functions to list them or delete them all.

There was no open-source resource in Python that showed how a Cometa dApp’s staking value can be fetched from the smart contract. Now we have it.

There was no open-source resource in Python that showed how to fetch data from Subtopia.io smart contract. Now we have it.

The above is precisely the part you should emphasize as a benefit that the community and ecosystem can gain from the outcomes within the scope of this proposal. These are the points that voters with voting rights will particularly focus on when making their decisions.

If you want to use the code itself as a reference, the number of Stars, Watches, or Forks could serve as helpful quantitative indicators. If no such numbers exist, you would submit it as is. Without numerical data, some voters might question whether it has truly provided any benefit.

The definition of “Retroactive” is provided in the xGov GitHub documentation. Please refer to the link below.

Proposal - xGov Beta Architecture

Funding Types
The Proposals have two different funding types:

Retroactive

Claim: “I have done X, which has benefited the Algorand ecosystem because of Y metrics, I would like to receive Z as compensation for the work”.

Positive outcome: funding is immediately disbursed if the Proposal is approved by the xGov Committee vote, and the xGov Council does not apply a veto according to the terms and conditions.

Proactive (NOT AVAILABLE YET)

Claim: “I want to do X, it has the potential Y for the Algorand ecosystem, I would like to receive Z staggered behind these milestones”.

Positive outcome: funding will be disbursed if the Proposal is approved by the xGov Committee vote, after milestone reviews from the xGov Council, and if the xGov Council does not apply a veto according to terms and conditions.

[ipaleka]

@aper_nft

The above is precisely the part you should emphasize as a benefit that the community and ecosystem can gain from the outcomes within the scope of this proposal. These are the points that voters with voting rights will particularly focus on when making their decisions.

I didn’t add those parts to the proposal description, additional information, or metrics sections. Can we agree that this discussion thread and my comment you’re referring to are an official part of the proposal, and so the benefits for the community are indeed listed?

@aper_nft

If you want to use the code itself as a reference, the number of Stars, Watches, or Forks could serve as helpful quantitative indicators. If no such numbers exist, you would submit it as is. Without numerical data, some voters might question whether it has truly provided any benefit.

Yes, I’m aware of that problem, and that’s the reason why I crafted the initial post in a way that I believe would attract voters.

@aper_nft

The definition of “Retroactive” is provided in the xGov GitHub documentation. Please refer to the link below.

Retroactive

Claim: “I have done X, which has benefited the Algorand ecosystem because of Y metrics, I would like to receive Z as compensation for the work”.

You are right that no other services have benefited yet from the Permission dApp, tho this thread should have a marketing role, so maybe some projects would benefit from it before the official voting starts.

Here’s an excerpt from my proposal’s adoption metrics section:

• Data for a total of 141 Algorand addresses is permanently locked in the dApp’s user boxes.
• A total of 1630 staking programs’ entries had been collected and evaluated, from a total of 407 Algorand accounts.

The ecosystem consists of projects, code, and people - 141 members of the ecosystem benefited from the Permission dApp.

Besides those 141, some other people have benefitted from the dApp: among those 1630 staking programs are other people/addresses who didn’t end up becoming ASA Stats DAO governors, but during their staking, they were able to benefit from additional ASA Stats features.

[ipaleka]

@aper_nft

The definition of “Retroactive” is provided in the xGov GitHub documentation. Please refer to the link below.

Btw, this confirms what I said in the comment you replied to: there are only two options, retroactive and proactive.

Is it possible that this means that there’s no institute of quantity measurement available to the Council to mark some retroactive proposal invalid? That the Council is able to invalidate a retroactive proposal only based on its (low) quality?

[simonb]

@ipaleka

Is it possible that this means that there’s no institute of quantity measurement available to the Council to mark some retroactive proposal invalid? That the Council is able to invalidate a retroactive proposal only based on its (low) quality?

this is from teh docs: ”The xGov Council MAY apply a veto against approved Proposals according to the terms and conditions of the xGov process.”

So in short - Council does not officially have power to reject proposal based on it’s quality.
Only if proposal is not aligned with TnC. That being said council’s comments do probably carry some extra weight (for xgovs who are looking for some guidance or suggestions on how to vote) when sharing their opinion.

Just FYI, we have ongoing discussions regarding some nuisances with current xgov TnCs, where proposals that are a no-brainer(e.g. even your mom knows that this thing benefits the eco) for getting funding, they could still unfortunately be interpreted as not aligned with current TnC. And for some of these discrepancies to show we had to wait for some proposals to actually get posted.

While i can’t speak for everyone, I’m pretty sure, all of the council members will do our best to identify, argue and suggest these changes to AF and xgov team.

[scholtz]

I wonder why the xgov state states its rejected

I see that it has passed the public quorum vote

I dont see any link for discussons going from ASA Stats Permission dApp | xGov page to this forum thread.

and i see in this thread at the top

[ipaleka]

@scholtz

wonder why the xgov state states its rejected
…
I see that it has passed the public quorum vote

Take a look here:

[xGov][Beta] Enrolling as an xGov and Voting on Proposals

Enrolling as an xGov An xGov is an Algorand address that has: Acquired voting power derived from consensus participation; and Enrolled as an xGov in this platform by paying the one-time enrollment fee of 10* Algo. This fee may be adjusted to account for Algo price fluctuation. Acquiring Voting Power Voting power is calculated by looking at all blocks produced during an observation window of 3,000,000 blocks, always starting at the top of the millionth block. For example, the 3,000,000 blocks…

xGov Quorum

This is the democratic quorum, where one xGov = one Vote. It is the attention that a proposal needs to be valid. Abstaining (or “Null” votes) affects this quorum.

Approval thresholds
Small (2,500 to 25,000 Algo ) - 30%
Medium (25,001 to 100,000 Algo) - 50%
Large (100,001 to 200,000 Algo) - 70%

Vote Quorum

This is the weighted quorum of all the xGov Committee voting power. Abstaining (or “Null” votes) affects this quorum.

Small (2,500 to 25,000 Algo ) - 50%
Medium (25,001 to 100,000 Algo) - 60%
Large (100,001 to 200,000 Algo) - 70%

Majority Approved

A proposal must receive at least 51% of the votes to be approved.

It has failed to get 50% of “Approval threshold”. dragmz explained to me using the dApp values: voted_members has to be greater (or >=, dunno) than committee_members / 2.

@scholtz

I dont see any link for discussons going from ASA Stats Permission dApp | xGov page to this forum thread.

I suppose it is removed once the voting ended.

[scholtz]

i still do not get it .. does it mean that xgovs just did not vote on this so it got rejected? why there is no explanation from the xgovs here why this should be rejected?

also, is there any discussion on who controls the 80% of the community votes? is it folks or defly, or af or silvio? i think i saw like participation like 5% and suddenly it changed to over 80% or something like that..

[ipaleka]

@scholtz

i still do not get it .. does it mean that xgovs just did not vote on this so it got rejected?

Yep, this proposal needed 95 xGovernors to vote in order to pass.

@scholtz

why there is no explanation from the xgovs here why this should be rejected?

That’s not in accordance with democratic principles; nobody has to explain why they don’t want something to pass.

When there’s a quorum, abstention from voting is another option, in addition to yes and no. However, in the vast majority of democracies abstention typically means no.

@scholtz

also, is there any discussion on who controls the 80% of the community votes? is it folks or defly, or af or silvio? i think i saw like participation like 5% and suddenly it changed to over 80% or something like that..

Yep, a whale voted yes for all three proposals and confirmed the second and third badges in them.

Dunno about the controlling, I am not interested in lobbying besides the usual discussions inside the ASA Stats community. I’ll resubmit this one with an amount that is in Tier 1 (30% threshold) and have fingers crossed for the best!

[scholtz]

thx for info.. i thought that the xGov quorum is the xGov council members quorum.. now i understand

how is the AF going to ensure that all xGovs vote in all proposals?