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.
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.