ASA Stats Token utilization discussion

[ipaleka]

ASA Stats Token utilization initial document draft is just published in Chanell's wiki!

ASA Stats Token utilization

it brings a structure for the monetization of the ASA Stats project and it is expected that the document becomes a basis for designing the ASA Stats official marketing campaign, as well as that it becomes a core of all API designing and development discussions.

Please use this thread to discuss the utilization document, as well as to suggest its changes when needed.

The utilization document doesn't bring any exact policy the ASA Stats community should follow in order to bring awareness and increase users' adoption. Depending on the topic, some of those policies can take place inside the utilization document, while the better fit for some others is marketing campaign design discussion and the documents that such a discussion should produce.

Last but not least, by publishing this document we're transforming into a token project and we have abandoned our anti-shill policy.

[wxivd]

Congratulations to all of us for reaching this next level. Thank you @ipaleka for the inspiration, dedication and the working model you have established.

I spent the evening reading through, trying to grasp the utility and the scope for each of the subscription tiers. To that end, I share with you a screenshot of subscription tiers diagram I created using draw.io.

The content is available on the following Link. Each list (container) features the functionalities of the respective subscription tiers. The items in the list have collapse/expand function to facilitate the consolidation of information for the each of comparison and to allow more details where needed.

[ipaleka]

Staking reward per tire does not increase in a fixed percentage increase. Could that potentially favour on tier over another in terms of staking rewards?

Bear in mind that it is expected that staking ASASTATS on some platform always brings more rewards to the hodlers than spending on our subscription tiers. So staking/refunding is just a benefit for the people who are willing to spend their money on something that ASA Stats offers - subscription tiers aren't an alternative to staking.

[ipaleka]

I infer that the statement means the Asastatser tier get "the get up to three user bundles consisting of up to eight addresses" (Intro Tier) + in addition to

Please feel free to proofread that sentence (and the similar sentences from the rest of the tiers).

My intention has been to not repeat the same over and over. In this particular case you mentioned, an Asastatser subscriber gets "up to five user bundles consisting of up to ten addresses" and that set is bigger than "three user bundles consisting of up to eight addresses", the latter set is inside the first.

[wxivd]

In this particular case you mentioned, an Asastatser subscriber gets "up to five user bundles consisting of up to ten addresses" and that set is bigger than "three user bundles consisting of up to eight addresses", the latter set is inside the first.

I interpreted "on top of" = in addition to. In a mathematical sense that means the items in previous tier + the items in next tier, but I get your point

[ipaleka]

In this particular case you mentioned, an Asastatser subscriber gets "up to five user bundles consisting of up to ten addresses" and that set is bigger than "three user bundles consisting of up to eight addresses", the latter set is inside the first.

I interpreted "on top of" = in addition to. In a mathematical sense that means the items in previous tier + the items in next tier, but I get your point

And I get your point too, yes, mow I understand. :)

We need to change those parts in a way that, maybe, they include the verbal noun "extending".

[ipaleka]

Staking reward per tire does not increase in a fixed percentage increase. Could that potentially favour on tier over another in terms of staking rewards?

Bear in mind that it is expected that staking ASASTATS on some platform always brings more rewards to the hodlers than spending on our subscription tiers. So staking/refunding is just a benefit for the people who are willing to spend their money on something that ASA Stats offers - subscription tiers aren't an alternative to staking.

I guess the project evolved to the phase where our governance staking is self-sustainable with the help of the Tinyman incentive program.

[dragmz]

The "Possibility to develop and publish ASA Stats user widgets" seems like an optional feature rather than something that fits a tier.

Developers might be interested in developing user widgets (any chances for earning ASASTATS here for developers?) but don't need the other (e.g. Trader) features.

[ipaleka]

The "Possibility to develop and publish ASA Stats user widgets" seems like an optional feature rather than something that fits a tier.

Developers might be interested in developing user widgets (any chances for earning ASASTATS here for developers?) but don't need the other (e.g. Trader) features.

We're here to discuss and adjust everything that doesn't fit us from the draft. :)

Widgets will be either free to use or our users need to pay for their use. Some of them will be free because the development is trivial, the others will be free because the third-party developers decided so based on their business model, while some will be free because we sponsor their development and our interest is that they are free.

Yes, the plan is to create an infrastructure where third-party developers can earn ASASTATS if our users use their widgets. The methodology is yet to be discussed here, but the following point from the draft emphasizes one aspect:

If a developer selects a monthly price for a widget that is smaller than the user's total supplied subscription amount then the subscriber is able to select the user widget for usage.

The quote implies that there is no additional payment, just like the Cluster tier subscribers are allowed to use every widget. We should define a process in such cases, either that we set that there's no earnings for developers for a widget that fits a tier's subscription, or that they get some small percentage of the widget's price if the widget price fits in a tier subscription amount. They get a bigger percentage when the widget price doesn't fit inside the subscription amount.

but don't need the other (e.g. Trader) features.

That's kind of emphasized in that section's beginning: "Trader is a tier for trading professionals and hobbyists, as well as for other Algorand enthusiasts who want to take advantage of the possibilities this tier offers.

My opinion is that allowing them to earn ASASTATS requires their financial involvement in the project. Our tiers are defined in those nice 5000 tenfolds and IMO adding a development tier that breaks the harmony doesn't sound ok. We can add an additional tier with the same price as the Trader, but that would be disadvantageous for both parties afaic.

[ipaleka]

Btw, nothing stops us from changing that tier name from "Trader" to "Professional"...

[ipaleka]

Here are a few topics that haven't been included in the draft yet:

• bandwidth throttling and rate-limiting

  The current draft doesn't define any limitations for the users. It is expected that we define those values for the anonymous users and the first three tiers. The Cluster tier limits are indirectly set by defined hardware resources, so our task regarding API is simplified in that regard: we only have to define two levels for the Asastatser and the Trader tier. That brings us to possibly quite a simple solution of setting two categories of values.

• real-time data updating

  The draft doesn't define the first tier that will have real-time data updating (without refresh). Our choice is obvious and simple: either Asastatser or Trader tier.

• subprojects of our special interest

  The draft doesn't define how we're going to be positioned for the development of the subprojects we are interested in as a company/brand. It is yet to be discussed and define whether such a topic even fits into this document or into a marketing design document. Nevertheless, one of such topics is the development of a mobile app that uses our API and mirrors the website's functionalities. We have a few options to select from:

  • we develop it by ourselves under our name
  • we pay for its development under our name
  • we sponsor its development under our name
  • we sponsor its development by a third party that will make their own brand using our API
  • we completely leave it to the market, counting that someone will eventually make it

[ipaleka]

Draft v0.1.1

• "staking rewards" phrase changed to "refund"
• added "buy" functionality to the trading widget section

[ipaleka]

By Aromatic-Ad3922 on Reddit:

---

Love ASA Stats! One of my most used alogrand apps. Maybe holding a certain amount of stats can open up options for custom themes, fonts, etc. maybe partnering with other algorand projects like vestige, nft projects like goanna, apes, etc? But out all the apps out there only asa stats shows the most accurate representation of portfolio through all staking, LPs, etc

---

Our initial utilization document draft brings an option to select a theme starting from Asastatser tier. It is yet to be discussed what would be changed on the website by a different theme, but colors and fonts would certainly be included.

And about partnerships, we are looking for some in this initial development phase when we're ready to emphasize some project's features more than it's usual. After we develop our user widget system, everybody will be able to create a user widget that our users can select and show on their pages.

As of today, we don't really have a mechanism that will allow one party to create a user widget that would be denied to some other party. So, for example, if Al Goanna wants that their NFTs in our user pages have some extra data related to Al Goanna that will be possible to implement through a user widget. At the same time, nothing stops some other NFT creator to do the same with their own user widget.

[ipaleka]

by moloch10 and ipaleka in Discord:

---

How will the widgets work in general? Will there be a "grid system" and each widget occupies a space? Will they be drag / drop? AJAX refresh per widget?

---

Everything is yet to be discussed, just like everything else. I do have some general ideas, but public discussion is always smarter than an individual. :)

Responsive design is a must, so widget should occupy space based on its settings, not a fixed space. The actual laying of the widgets will depend on the framwork, maybe it uses flexbox and so we'd use defined flexbox policy to place our widgets...

Will they be drag / drop?

If we develop the system well then such an editor's functionality should be easy to implement.

AJAX refresh per widget?

Dunno for sure, as of today it's planned to subscribe to a websocket that signals rerendering of a page section.

---

Also, will these widgets only be available for use in asastats.com or will a user be given a block of code that they can use anywhere they want to render said widgets?

---

As of now, we do not have plans for exposing our user widgets system outside of the asastats.com website.

Basically, we have two levels of distinction for using ASA Stats:

• our website

  To improve UX, among other things, we're going to add our user widgets system.

• our API

  Anyone is able to use our API and that way simulate a specific user widget's behavior.

Also, I should add some other things that maybe aren't obvious at first:

• everyone is allowed to publish and maintain their own website using ASA Stats API

• once when we open-source our codebase, there will exist only one requirement for using that codebase to run your own website spending your hardware resources under let's say algodata.website: you have to use ASASTATS as a currency for payments! You don't need to pay anything to anybody, you just have to use ASASTATS (respectively Algorand Smart Contract owned and copyrighted by ASA Stats DAO) as currency in bills to your clients.

[ipaleka]

Draft v0.1.2

- "Trader" tier was renamed to "Professional".

[wxivd]

I would like to debate the idea of considering ASA Stats token held and LP provided for access to ASA Stats premium features.

I have been inspired by Vestige model, yet to crystallise, regarding VEST holder tiers, that is access to premium features depending on VEST holdings per account. with 4x weighting factors for LP provided

Pros and Cons

Pros

• This model creates demand for holding tokens and providing liquidity
• ASA Stats secures deep liquidity and the value of ASA Stats token appreciates
• ASA Stats would be able to grow LP in various LP programmes
• Investors gain access to premium service without directly paying for it. This would be ideal for a sector of investors.

Cons

• Subscription is key to generate sources of income for sustainable growth and development
• Subscription is key to join decision making process through DAO

Suggestions

Provide access to advanced features using defined criteria and tailored process

1. The model is in isolation of DAO vote right
2. Limited advanced features in line with pros and cons. i.e create parallel path for Intro and ASASTARTER but not for Professional and Cluster tiers
3. Define a list of supported LP platforms. This way we can branch out to the various DeFi solution on Algorand
4. Place a cap on total TVL per platform once target is reached, we focus on second in line

The simplicity of revoking access to advanced features once tokens are sold or LP withdrawn is advantageous

This model can be considered temporary until it achieve its goals. Early supporters get to keep the advanced features whereas new investors will not have this option/opportunity in future.

Providing that this model maintains the limited advanced features, Professional and Cluster tiers would still need to subscribe which generate sources of income. Furthermore, since a parallel path is suggested, Intro and ASASTARTER who wishe to gain DAO votes can subscribe still.

[ipaleka]

Interesting idea that is surely worth discussing and analyzing.

The main consideration is that we should find a way to fulify the only condition we have set - ASASTATS is the only currency possible! So, if we want this to work in any phase, we may for example create an incentive program where liquidity providers are rewarded with ASASTATS supplied to the ASA Stats Permission ASC on behalf of the liquidity provider account.

I guess any other similar idea should be processed that way, with an incentive program where we/admpool supply ASASTATS for permission ASC instead of the subscriber. Like, another example, the artist(s) we hire to create our NFTs, instead of paying them directly the full amount, we may supply a full or partial amount in ASASTATS on their behalf and they get both our professional services and future governance seat.

[ipaleka]

---

XY — Today at 1:18 AM
Hey bud!
Love ASAstats, use it myself all the time (my team too)
would you be open to cooperation?

---

ipaleka — Today at 1:21 AM
Hi! We're open for cooperation, of course, but we discuss everything in public if it's related to ASA Stats.

---

XY — Today at 1:22 AM
Hm, what's your approach? As I understand you would be the main developer, no?
I'm not really interested in ASAstats, more the developers behind it :)

---

ipaleka — Today at 1:23 AM
Yes, I'm the main developer and I'm pretty much busy with ASA Stats for the next at least 12 months (https://github.com/asastats/docs/blob/main/roadmap.md).
On the other hand, all of ASA Stats code will be open-sourced next year...
If that's what you need. 🙂

---

XY — Today at 1:26 AM
To me it would be unfair if you did all the work and then we integrated it, so I thought we could join forces
It's no secret that we would like to have the functionality on ASA Stats but youre so far ahead that it will take months for us to implement what you already have
And obviously you're a great developer and an expert in interacting with the chain
My proposal would be for you to join us and help design + implement the architecture in our backends

• if you'd like to, maybe some other stuff, pretty much a full time position

---

ipaleka — Today at 1:29 AM
We're going to publish our mobile app in two weeks time and it will use our API. I suggest that you read our utilization document (https://github.com/asastats/channel/wiki/ASA-Stats-Token-utilization) and realize that ASA Stats is created exactly for the people and organizations like yours, 🙂

---

XY — Today at 1:29 AM
What do you think?
Hm, so your utility proposal is to hold the ASA in order to access the data interfaces?

---

ipaleka — Today at 1:32 AM
That Cluster tier brings hardware and bandwidth resources ten times higher than ASA Stats website currently has got and need. Pretty much vast majority of eventual providers in Algorand ecosystem would be satisfy with the Professional tier (around our resources right now).

---

XY — Today at 1:33 AM
But that would still rely on your architecture and we would not have a way to fix any logic - either use ASAStats exactly as it is, or not use it at all

---

ipaleka — Today at 1:33 AM
We're going to develop and deploy the Permission ASC and ASA Stats engine/code will use its value to define users permissions. In order to get that level permission you have to use ASASTATS.

---

XY — Today at 1:34 AM
Okay, I completely understand and that's a neat idea - we're doing it already with VEST and our API, where to access some endpoints your wallet needs to be above a threshold

---

ipaleka — Today at 1:35 AM
Once you mature you just fork ASA Stats engine code and create your own Kubernetes cluster. Free of charge, the only condition is that you have to use our Permission ASC, respectively that you use ASASTATS as the only method of payment.

---

XY — Today at 1:36 AM
Okay, I understand
May I ask a personal question?

---

ipaleka — Today at 1:37 AM
Yep. On the other hand, may I copy/paste this conversation in our public channel (won't use your name)?

---

XY — Today at 1:37 AM
Of course, it would be fine
I wanted to ask what is your motivation behind this project

---

ipaleka — Today at 1:39 AM
To provide a product that will help Algorand to become The blockchain once the mankind settles on Moon, isn't that obvious?! 😂

---

XY — Today at 1:40 AM
Hm, so are you personally invested into Algorand and it is financial?
When it comes to actually helping Algorand grow, joining forces would definitely be the answer (imo)

---

ipaleka — Today at 1:43 AM
Nothing like that, ASA Stats was the very first portfolio tracker on Algorand and community accepted it well, so the decision was to make DAO of it. I didn't invest anything but my time and hard work and I hope the vested ASASTATS I'm getting as a Team member will cover my efforts one day. That's all.

---

XY — Today at 1:44 AM
Hm, alright - so what I'm proposing would be for you to get your hard work covered monthly instead of one day haha
You'd also get a fair share of our token
I'm also happy to jump on call if you'd prefer that

---

ipaleka — Today at 1:46 AM
I understand you completely, but please read our utilization document and roadmap first. Every dApp on Algorand wil be covered by ASA Stats and every part of our engine will be accessible by the ASA Stats API. I'm offering you the same for 10-20 times less money...

---

XY — Today at 1:49 AM
Integrating something like this would most likely not be available to us - you'd be giving us ready-made values
exact statistics of a wallet
and we need a way of reading and understanding specific SCs to calculate for example wallet value over time
so either way we would always look for a way to interpret the state, not a way to know the values - the state is often not even up to date, we collect transaction deltas and this way try to understand past states of the application
Which is why I'm more interested in your development skills than the ASAStats engine - you already spent countless hours trying to understand Algorand SCs
We could do the same, but instead if we work together, we could create something awesome and you would be sufficiently paid for your skills

---

ipaleka — Today at 1:54 AM
Your work can be covered and it's planned that such a work take place inside our user widgets system.
I'm not getting rid of ASA Stats, the only way we can cooperate besides your company using our API is that your company buys ASA Stats under my conditions (continued development as planned until DAO takes over).

[ipaleka]

XY — Today at 1:57 AM
Not asking to get rid of ASA Stats, simply asking for you to consider your options - you are doing that work for free with no promise of it ever becoming profitable
and we could really use someone with your skills
But I completely understand if you're dedicated to the project - if you'd not like to join us, we should work together to create some sort of standard
and maybe a joint database of "app id, type, standard"

---

ipaleka — Today at 2:00 AM
I'm open to everything that aligns with ASA Stats roadmap and plans, and creating a standard is surely among those topics.

Tho I have to ask why using our API isn't a good option for you? We'll for example provide example code and bandwidth for our Professional tier that can save all the dApps from 1000 addresses every block into Postgres database.

---

XY — Today at 2:02 AM
It would simply be impossible to make this many requests

lets say a wallet uses 5 defi apps

i will fetch last 10k transactions for it to generate a value over time

who knows how many api calls i would need to make to fetch states at intervals

and that would only be one wallet, while we in theory support every active one

this was raised many times when we tried to implement DEXes - especially with Humble

they also asked us to send a request to their API, but it made no sense when we can decode it ourselves

---

ipaleka — Today at 2:06 AM
If you can change your business model to not use data from the past, only for the time after users "subscribe" to your service, then we can have you covered completely, up to millions of addresses in real-time.

[ipaleka]

XY — Today at 2:07 AM
that would mean we cant fetch history for a wallet that just connected
and thats a limitation that hurts UX

---

ipaleka — Today at 2:08 AM
Probably, but bear in mind that you can't get not even close to perfect accuracy with Indexer, the only way you can get accurate data is if you "subscribe".
And not having accurate data is The bad UX...

---

XY — Today at 2:09 AM

Probably, but bear in mind that you can't get not even close to perfect accuracy with Indexer, the only way you can get accurate data is if you "subscribe".

how do you mean?

---

ipaleka — Today at 2:11 AM
As a simple example, you can't get a Lofty property price through the Indexer.

---

XY — Today at 2:12 AM
oh, for those cases we would simply not include in the over-time chart
but things like asset holdings, LP values, borrows & lends
theyre easily trackable backwards

---

ipaleka — Today at 2:13 AM
And nobody can assure anyone that Lofty-ish type of financial investments won't be 90% of all Algorand based investments in 2024....

---

XY — Today at 2:14 AM
we would then make workarounds
tracking prices for all lofty properties does not sound like an enormous amount of work

---

ipaleka — Today at 2:14 AM
And that workaround is to "subscribe" to the service. 🙂

---

XY — Today at 2:14 AM
sounds about right :)

---

ipaleka — Today at 2:14 AM
I'm not talking about Lofty per se, I'm talking about thousands of projects that use blockchain the similar way.

---

XY — Today at 2:15 AM
if it's not in a smart contract state, is it really on chain?
or, user wallet state for that matter

---

ipaleka — Today at 2:17 AM
Best UX doesn't care if it's on or off - a user has got an account and they need to know its value.

---

XY — Today at 2:17 AM
That is true, not going to argue

[ipaleka]

XY — Today at 2:17 AM
Well, I suppose the best way for us to work together would be to create an open source repository with:
a) a list of static app ids + a way to get dynamic app ids
b) types of applications (dex pools, lending, farms, staking etc.) and their standarized parsed output (for example, dex pool: price, amount a, amount b, fee, lp token id, etc.)
c) python code snippets for each of the available solutions (algofi, folks finance) to get them from their on-chain state to standarized output

Would that be sufficient?

of course in c) it would take parsing of application state and wallet local state (edited)

we should probably divide c into two steps actually, global and local

---

ipaleka — Today at 2:24 AM
Well, our plan was that we start with open-sourcing of our code around June, 2023. Until then, we can prepare standard format like you pointed out.

---

XY — Today at 2:26 AM
Hm, that would probably not work for us since we need those states quickly (especially for counting VEST in farms)
but I'll get started on something and when you want to join just let me know

---

ipaleka — Today at 2:29 AM
We can help and join creating the standard for data presentation from the day one, that's out of question, it's just that we'd go out with our content around June (or a few months before, dunno).

Whatever happens, be sure that we'll reach you if you successfully deploy in order to create a user widget from your service with historic data for an account. https://github.com/asastats/channel/wiki/FeaturesDependentOnHistoricData https://github.com/asastats/channel/wiki/FeaturesDependentOnUserWidgets

---

XY — Today at 2:41 AM
Sure thing, I'll let you know if we manage to do something in this direction

Coming back to buying ASA Stats on your terms, what would be your +/- number?
Purely out of curiosity

---

ipaleka — Today at 2:45 AM
Well, we're going to have some sponsoring talks in the next few days and weeks. If nothing happens I can reach you afterward and give you a number.

---

XY — Today at 2:47 AM
Sounds good - I truly believe it would be the best & most profitable solution for both of us if we joined but I won't push further - let me know if you'd be interested

---

ipaleka — Today at 2:47 AM
I will, thank you for your time and your consideration! 🙂

---

XY — Today at 2:48 AM
Likewise and all the best :)

[ipaleka]

From our Twitter DM:

---

Hey! This is Phil from Alammex - a DEX aggregator for ASA swaps. Great job on your project, I use it quite often. :) I just wanted to let you know that we recently exposed APIs/SDKs for aggregated trading, in case you have any plans of supporting asset conversions to ALGO or USDC (eg. a feature to convert entire portfolio to ALGO/USDC). There is also a referral program, where developers who leverage the APIs for trading earn 50% of any commissions. Have a great day :)

---

Hi!

Our roadmap (https://github.com/asastats/docs/blob/main/roadmap.md), respectively our utilization (https://github.com/asastats/channel/wiki/ASA-Stats-Token-utilization) imply having such a function in a form of our user widget (point 16. of our roadmap).

We'll sponsor development of such a user widget as that represents pretty much the core of our Professional tier.

But, for the user widget purpose we'd use third parties services only for actual swapping/trading, the input arguments for those services/actions will be collected and prepared from our Maximum Value Engine.

Btw, here's an excerpt from "ASA Stats goals" document:
https://github.com/asastats/channel/wiki/Goals

The goal is to allow a professional user, with a help of the ASA Stats partners, for example to convert all of their ASA from all of their accounts (thousands or millions; maximum is to be yet defined by the research presented in this proposal) into ALGO if their total sum drops below some defined amount in ALGO. The ultimate goal is to do that in two blocks: the first block to withdraw all the ASA from the locked accounts, and the first and the second block to sell them on AMMs/DEXes for the maximum price.

P.S. everything in ASA Stats is transparent, I hope you don't mind transferring this chat to a public space at #166 (comment). I'll delete the comment if you want.

[PhilGabardo]

Hey! Currently, no, this is not possible. Is there a reason you'd prefer to use the ASA stats engine over Alammex? Alammex is able to compute optimal routing using liquidity across all DEXes, and intermediate pools.

[dragmz]

Hey! Currently, no, this is not possible. Is there a reason you'd prefer to use the ASA stats engine over Alammex? Alammex is able to compute optimal routing using liquidity across all DEXes, and intermediate pools.

The reason is we've got the relevant data already so it doesn't really make sense to request it from your API.

There's no built-in trading functionality (other than potentially implemented in user widgets) planned in ASA Stats afaik so having ASA Stats as a data provider + Alammex as a layer that knows how to talk to markets would be a decent integration for the trading tool I'm working on at https://github.com/dragmz/goas-release.

[ipaleka]

Hey! Currently, no, this is not possible. Is there a reason you'd prefer to use the ASA stats engine over Alammex? Alammex is able to compute optimal routing using liquidity across all DEXes, and intermediate pools.

Bear in mind that our decision to not use intermediate pools right now is just a business decision, we are able to provide them for @dragmz and any other usage whenever we decide/want.

What we won't ever develop in ASA Stats is actual wallet connecting for the purpose of creating actual transactions directly in ASA Stats Engine - we are going to develop our user widgets system for the purpose.

So, extending your functionalities set to what @dragmz suggested can pave the way for our partnership regarding our trading user widget, but even more important is that if we establish such a developing communication then you become an obvious partner prospect for our main monetization purpose - connecting to and executing an application call to our Permission ASC we're going to develop and deploy.

[marucat27]

This is very interesting thread that I'm only reading up on now. If say we did have a trading widget even maybe an Alammex widget, would this be available to all Asa stats users of a certain paid tier or only the user who creates the widget or works with Asa stats to develop the widget? I'm wondering if the widgets area would be like a broad set of widgets that users of various tiers could select from or if it's more like personalized user widget?

[ipaleka]

Everything is open to the discussion, while this particular functionality is set to be available for the Proffesional tier:

• possibility to select the trading user widget and related capabilities

  Every ASA amount in a subscriber's account can be added to the trading widget in full or partially. That implies a possibility to add an ASA amount to at least the following sections of the trading user widget identified by the following buttons:

  • sell

    For an ASA's balance amount.

  • unstake and claim

    For an ASA locked in a staking program.

  • unstake, claim and sell

  • remove liquidity and sell

  • unstake, claim, remove liquidity and sell

    For the LP tokens locked in a farming program.

  • buy

    For this functionality to be possible, we're going to add some functionalities into the API that is not applicable to show on the website.

[ipaleka]

From our Twitter DM by @madamczyk0:

Hi, I'm reaching out from SubQuery Network, the largest open source on-chain data indexer for the Polkadot ecosystem. We have recently completed integration with Algorand. Maybe ASA Stats Team would be interested in using an indexed and aggregated data within your dApps? We could have a call to give you a quick demo, if you're interested? I could also send you some docs. Let me know what you think 🙂

---

Hi!

We don't need your services right now, but after we develop our user widgets system then such a need can arise.

We'll reach you after we develop our user widgets system.

Best regards!

[ipaleka]

By Scott | FlippingAlgos.xyz in Discord:

---

well ive got a nice little NextJS setup im already working with i can show a bunch of examples but you likely seen it for staking.buttcoin.cc so its 100% open source solution.. nextjs/chakra ui/graphql style setup.. im deploying on vercel so free hosting unless you get hella popular and my raffle site going decent and i havent even hit 20% on the vercel yet. .i really got this dialed in.. its scalable AF and using like NO resources.. super clean
and im using lambda/python script on a secure aws setup to handle the backend / sends
happy to do a call or a demo or share a REPO or w/e you want.. also open to doing customizations / something one off unquie for just ASAStats... its open source so really skys the limit here the tech stack is strong so can take it just about anywhere

---

[ipaleka]

Hello Scott!

Let me explain in short what our Permission ASC is supposed to do.

Every existing governor's address (around 60 for now) is hard-coded with a corresponding permission integer value (representing their number_of_votes * 1_000_000). Permission ASC has to return that exact value after a governor's address is queried against it.

If a user has staked ASASTATS in an amount larger than 500,000 then they qualify for governance. Permission ASC has to return a value after that address is queried against it. To calculate that value the staked amount is divided by 10 (representing months minus 2 months free) and calculated against a hard-coded array.

So the minimum monthly staking qualified for governance is 50,000 ASASTATS and for each 50,000 staked user gets a permission value of 64,721,359,550. If a user stakes 500,000 or more per month then dApp should return 161,803.398,875. For a monthly amount of 5,000,000 that value is 3,236,067.977,500.

If an existing governor stakes ASASTATS then the returned value is a sum of hard-coded and "staking" value.

After 12 months, if a user has staked more than 50,000 ASASTATS per month, their permission value is hard-coded into Permission ASC just like other existing governors.

[ipaleka]

By Milesmile in Discord:

I just buying whenever to support project and committing LP on tinyman V2. I hoping V2 LP will still qualify for the governance rewards. Is that the case?

---

By ipaleka

It's not the case right now. Nevertheless, nobody qualifies for governance right now, so everything is subject to change.
The primary condition for Permission ASC is only one: to accept only ASASTATS. That will be the only condition for DAO to take over the project at the end of this year, the ASA Stats DAO will be obligated to follow that rule.
So, every rewards system has to comply to that. If you stake Tinyman LP tokens and get rewarded in ASASTATS, you just simply have to stake those funds to Permission ASC.

[ipaleka]

Hello Ivica,

I am Vilijan, the founder of Asalytic (https://www.asalytic.app/).

In the past year and a half I have been building Asalytic, with the goal of extracting on-chain NFT data and present it to the user in order to help them make better informed decision before buying their next NFT. The most interesting part of Asalytic for me is the portfolio analysis, where I analyze all the NFT activity from a given wallet.

...

1. I am curious to know whether you have an API that exposes the DeFi data for a given wallet?
2. If you do have an API, I am curious to know how much this costs?

---

Hi Vilijan, thanks for your kind words! Whatever we achieve in the future, we have to announce that to the ASA Stats community. I'll prepare an answer to you, but I need to have your confirmation that you're willing to listen our community voice about too.

---

wawa. — Today at 3:40 PM
Aha, I see. Thanks for the clarification.
I am curious regarding the DeFi data, do you extract it on-chain or do you use other 3rd party APIs?

---

ipaleka — Today at 3:42 PM
We use API only for webshops like Rand and FIFA+ and soon to be in NFT section lofty.ai. Everything else is real time onchain.

---

Amazing, that is what I thought just wanted to double check

---

[ipaleka]

---

wawa. — Today at 3:37 PM

Aha, ok.

I believe for the very initial DeFi integration I would need only something like array of asset objects like:

[{asa_id: int, asa_name: str, amount: float, algo_value: float, asset_image: str}]

This would be an initial implementation on my side. Afterwards, perhaps adding more and more details where users can see all the individual swaps that they performed for each asset
So the next step for me is to buy 500k ASA Tokens and stake them in order to get a token?

---

ipaleka — Today at 3:48 PM

I believe for the very initial DeFi integration I would need only something like array of asset objects like:

[{asa_id: int, asa_name: str, amount: float, algo_value: float, asset_image: str }]

This would be an initial implementation on my side. Afterwards, perhaps adding more and more details where users can see all the individual swaps that they performed for each asset

Well, I guess it would be beneficial for both of us that we create such an endpoint that will present minimal piece of information...

So the next step for me is to buy 500k ASA Tokens and stake them in order to get a token?

I guess so, tho I can't give any guarantee on bandwidth for that initial tier in the future. However, I'd send you an API token and you can fully test your implementation with it.

Our community's discussion should bring an outcome about your obligations after an implementation on your website hits production (for example, here's a related comment in it: #166 (reply in thread)). As I said, once the DAO takes over those obligations will be kind of none, it's just that your bandwidth will be restricted, but DAO can make a vote on specific cases like yours.

---

[ipaleka]

---

wawa. — Today at 4:00 PM
1)

I am not familiar with how the DAO works and how will work. I completely understand that in the future the API tiers will be controlled and voted by the community. Though, If by then the DeFi section is live on Asalytic using your API I would expect a notifications before any changes in the bandwidth, etc.

Regarding the endpoint, as you mentioned I believe a custom endpoint that will provide only the limited data that is needed for Asalytic will be the best solution for both parties. I assume that is not much work from your side.

I saw the comment by your community. I will happily mention on Asalytic that all the DeFi data is taken by ASA Stats and also provide links to your website.

---

[ipaleka]

I emphasized that comment as it brings that "obligations" part to the topic, nothing has been decided yet. After the discussion warms up, I'll reach you and present its final outcome(s).

I believe I can prepare such a reduced endpoint in a couple of days.

[ipaleka]

---

kerrilija — Today at 3:56 PM in Discord:

How can we be sure he won't share the API key with someone else?

---

ipaleka — Today at 4:08 PM

We can't have a mechanism that will ensure that, tho we can develop some code that will check for usage and eventually restrict it to some IPs.

---

[ipaleka]

---

wawa. — Today at 4:11 PM

I just joined your discord, and see that you copy-paste everything there. Perhaps it is better if we continue talking there?

---

ipaleka — Today at 4:13 PM

The major problem is that Discord isn't a public space and eventually everything ends up in void, so someone needs to c/p important discussions to a proper public space like GitHub is. But of course, it will be easier if you and me continue in our Discord. 🙂 https://discord.com/channels/906917846754418770/914540797054025788/1083767726687911967

---