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

Hello,
There are now several Smart Contracts in the ecosystem that all do related tasks (farming, staking, lending). In order to monitor them all, the only thing required would be:

  • a method to parse the local state (found in the user wallet);
  • a method to parse the global state (found in the application);
    into actual usable information.

What I am proposing would be a creation of an ARC that specifies the outputs of those functions given the input of application state.
Ideally, those methods would also not use any additional indexer/node calls as to avoid spamming the network.
The only thing they have in common thus far is that they can all be reversed back to asset balances (positive or negative).
A good starting point would be:

from typing import TypedDict, Optional

class StateOutputARC(TypedDict):
    asset_balances: dict # { asset_id: asset_balance (no decimals) }
    from: Optional[int] # unix timestamp
    to: Optional[int] # unix timestamp
    round_from: Optional[int]
    round_to: Optional[int]

def fetch_applications() -> list[int]:
    application_ids = []
    # fetch a list of applications that adhere to below state parsing specification
    # this function can call any indexer/node endpoint (preferable) or off-chain API
    return application_ids

def parse_state(state: dict) -> StateOutputARC:
    state_output = {"asset_balances": {}}
    # parse each key of state to find meaningful information
    # in case of local state, just return a list of user asset balances
    # in case of global state, return the entirety of SC information
    # this function should work with partial state and handle errors in case of partial state misses
    # in case of smart contracts written in Reach (or any other language that optimizes their state memory), 
    # this memory needs to be parsed from given state, without additional calls
    return state_output

I believe this would be very beneficial to user experience since integration of different Smart Contracts into their portfolio would become trivial. This is so far a pretty big problem and having a standard would simplify the development of new solutions - as the main developer of Vestige, this would become especially useful for me as well as any new product seeking to include these applications into their UI.

I am curious to hear your feedback.

9 Likes

I think this a good idea generally, I think it makes sense in the ARC for the full ApplicationSpec which has yet to be drafted but the issue for discussion is here: Discussion: Extended Application Specification · Issue #118 · algorandfoundation/ARCs · GitHub

I PR’d a change to beaker to specify how to decode a given state value here:

3 Likes

I’m not sure adding it to ARC4 would make sense. This is more specific to the piece of code that would handle parsing of the application than the application itself - a general standard so a huge open-source repository with these snippets of code could be created, developed by SC owners & then easily integrated by other developers.
For anyone that wants their SCs widely integrated this would be a must-have.
The general problem is that everyone has their own idea of how their state should look like, but that means any new SC is a completely new problem to solve. Most of the developers don’t even explain their state in docs so it is literally a trial-and-error process until it works.
The alternative right now is to have each of the parties create their own system for this (new lending protocol? every portfolio tracker needs to spend development time to understand its state) which is insanity when we will account for the growth of the ecosystem.

I’m not sure adding it to ARC4 would make sense.

Definitely, the ApplicationSpec would contain the ARC4 spec but with additional information like, for example, how to interpret given state values.

Additionally it should provide things like expected default arguments or other hints to help client applications.

The version of the application spec that Beaker is currently producing can produce an autogenerated TypeScript client using GitHub - algorand-devrel/beaker-ts

I completely agree with the goal of allowing a complete stranger to easily use and understand an application they’ve never seen before.

Check out beaker/beaker-ts and please do comment on the app spec issue if you have any other thoughts on it

1 Like

Hi @grzracz !

New/existing ARC won’t solve the problem. Nobody uses ARC and with the growth of the ecosystem that nobody will become even smaller. We have got ASA swapping providers and some of them don’t even fill the note, let alone use appropriate ARC-2.

ARC19 is used because it solves people’s problems. dApp providers don’t have a problem with their dApps not being categorized, we who use their dApps have such a problem instead.

Afaic, the only way to solve such a problem is the way we in ASA Stats have planned to do: by open sourcing our codebase and so allowing the users of dApps (like we are) to not spend their time on developing.

Your motivation is benevolent and we in ASA Stats would be glad to assist you in defining the standard to be used in our codebase for exposing various dApps. Nevertheless, as I already told you, our business model can’t keep up with open-sourcing our codebase before the next summer.

@grzracz
I agree with the fact that we need an ARC with some “Mandatory” function inside Apps.
Like they have for ERC-721 for example.

You can start to write an ARC for this, just be sure to respect ARC-4 & ARC-22 (ABI for Read Only).

@ipaleka If you can share with me which ARC is not correctly used, it will be helpful, so please hit me up.

@ipaleka If you can share with me which ARC is not correctly used, it will be helpful, so please hit me up.

I linked an example discussion above:

We have got ASA swapping providers and some of them don’t even fill the note, let alone use appropriate ARC-2.

Here’s an excerpt from it:

Some of those providers like Atomixwap provide a custom note, but others like Swapper don’t.

Can you provide us an example here of a dApp and/or dApp provider on Algorand that uses ARC to identify itself or its dApp?

We have, for example FIFA-collect with
tx: CS5B5YZJHLDBYLTDRV5E35HGAUGGGXMQRFIGF3X5QZJUBZL7KLZA

AlgoMart/v1:j{"t":"ctpf","a":888995843,"s":["arc2"]}

But now that I am looking at it, we need to spread this ARC-2, it is not used by every dApps.

Thanks for sharing this point.

But now that I am looking at it, we need to spread this ARC-2, it is not used by every dApps.

Yes, that’s the starting point for sure. ARC2 implementation is trivial and still people don’t use it. We have managed to bypass that problem for most dApps, but for some of them like those swap providers there is no way to identify them.

And that’s an enormous problem for our NFT engine in ASA Stats as swapping NFTs is just another sell and if we have got a sold price for one of the items in swap then we can define the price for the counterpart(s) in the swap. And providing that information to our future AI NFT price engine will increase our NFT price information accuracy a lot.

The problem @grzracz brought to the table is kind of learning to fly while we still struggle to walk. As I already said, a new ARC won’t solve dApp providers’ problem - it will only help the projects who analyze those dApps - so they will avoid using it. The Foundation needs to find a way to motivate the providers to implement a new ARC. And the same goes with ARC2…

Thanks for sharing this point.

You’re very welcome, thanks for understanding!

1 Like