ARC used for decoding on-chain local and global states into meaningful information

[grzracz]

@ipaleka

This discussion should start, for example, by defining what defines a need for a dApp to be included in the standard rather than just presenting “STKE” or “LEND” as something people will use as a starting point.

“What is staking?” simply has to be among the first topics for this discussion.

Any smart contract that holds custody of user funds & saves this data in local state/application state would be valid for decoding. The main assumption should be that local wallet state can be decoded to asset amounts in custody for that wallet. The categories I have used in UsageType are placeholders & there will probably be many additions to those types. It is purely for categorization & easier user display.

@ipaleka

You guys may use that code from @grzracz, but don’t expect that we in ASA Stats will ever use it, we have got our own codebase (just like a few of you have your own) and we don’t have a need or time to refactor it into something that we don’t know yet if it’s better or worst than what we already have.

I am also not expecting the ASAStats team to simply jump into the repo. I have created & published it so we can start working on it ourselves with hopefully more people joining as time goes on. Since there is nothing but templates there right now, it is expected for you to ignore the repo until further notice.
Although, I think my approach is very atomic compared to the code of ASAStats - the main purpose of each ApplicationType is to simply return assets in custody without further integration.

I have updated the repo to TypeScript today (to support both languages) & will continue working on it. If there is a better solution found I will be open to suggestions but for now there is none and it seems like a good start.

@k13n

Figuring out how to make sense of the global/local state of a new protocol is certainly a problem that we also faced and it would be great if there was a better way to get this done. We’d be happy to join and help with drafting such a standard.

Great to have you here, glad you are open for participation. Please take a look into this repo for my approach at the “standard” which would be an ApplicationType class for each of the standardized Smart Contracts getting deployed. If you have suggestions as to what would need to be added to such a class (or the output fields), feel free to open a PR.

GitHub - vestigefi/StateDecoding: Repository used for gathering &...

@k13n

It would be interesting to hear from protocol creators as well. What would we as protocol integrators expect them to provide to facilitate our work?

I think simply explaining their wallet state and application state keys would be most beneficial. Most of them do not even mention these in their docs. It would also be useful to have ABIs for these states whenever possible (especially with states that are memory bytes).

[ipaleka]

Any smart contract that holds custody of user funds & saves this data in local state/application state would be valid for decoding.

What about non-ASC staking systems? ARC that should emerge from this shouldn’t skip those providers imo.

What about rewards from those contacts? Do we create a barrier and define that those funds aren’t user’s or we make an exception for rewards?

The categories I have used in UsageType are placeholders & there will probably be many additions to those types. It is purely for categorization & easier user display.

My point is that we can define them pretty much all in advance, without bringing even more confusion with some repo that is destined to not stand test of time.

LEND means nothing and it’s a burden until we bring a final analysis and bunch of members inside LEND category, if we even would have the LEND category.

Although, I think my approach is very atomic compared to the code of ASAStats - the main purpose of each ApplicationType is to simply return assets in custody without further integration.

And that brings us again to the unanswered question: what we are trying to achieve?

My position is that we should try to create an ARC. If nothing, then because the thread is entitled that way and few of us were motivated to join because of that title. If that’s not the case then let’s create another thread and let’s start working on code that will outcome with a code that portfolio tracking providers can use.