MVP feature selection for API: introductory general discussion

[ipaleka]

What set of existing ASA Stats features should we consider as a Minimum Viable Product (hereafter referred to as "MVP") for the initial proof of concept (hereafter referred to as POC) for our ASA Stats API?

Some initial notes from a prior discussion in the ASA Stats Discord:

• MVP stands for "Minimum Viable Product" - the least amount of features needed to be considered a wholly functional set in an initial release or proof of concept.
• Features for consideration should already exist within the ASA Stats product.
• API is an acronym for "Application Programming Interface" which is a software intermediary that allows two applications to communicate with one another. It is the interface that external sites could use to leverage ASA Stats features.

P.S. discussion created by @AlgoRhythMatic

[ipaleka]

by @Temitopeishola

From my own view
MVP simply means "minimum viable product" is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. A focus on releasing an MVP means that developers potentially avoid lengthy and unnecessary work.

API is an interface that allows two unrelated systems to interact with each other (in the same sense that a restaurant server enables the customer and the chef to interact).
API enables you to interact with our exchange programmatically (via software instead of a human interface), allowing you to obtain real time market data, make trades, and manage your account.

[ipaleka]

by @dragmz link

Anyway, do we know what's the purpose of the MVP here, i.e. who are the potential users of the MVP specifically? What I'm suggesting here is to try listing the potential users and their use cases, then we should be able to define the scope of the MVP.

[bear1bear2bear3]

This is probably a smart way to get started.
I think that the main users are "professional or seasoned traders", as mentioned in a few other posts. We might need further descriptions of what such traders want or need i guess

[ipaleka]

This is probably a smart way to get started. I think that the main users are "professional or seasoned traders", as mentioned in a few other posts. We might need further descriptions of what such traders want or need i guess

Yes, that's definitely our ultimate goal. The problem we may encounter in this phase is the fact that those people and companies need ready-to-use tools, so we probably should focus on their feedback, but communicate and search for the developers ready to create those tools from our API.

A little explanation: we won't have trading tools implemented directly on our site. We will have defined events and alarms, probably always used in the form of user widgets, but the actual action will be taken either by users themselves or by the third party code.

[AlgoRhythMatic]

I agree this is the way. In Product Management terms, I would consider this exercise as seeking to model the "User Experience". Brainstorming for this should consider every type of potential user, and every type of potential use case, and then whittling down to the least common set that we feel provides the best experience for all.

[AlgoRhythMatic]

The problem we may encounter in this phase is the fact that those people and companies need ready-to-use tools, so we probably should focus on their feedback, but communicate and search for the developers ready to create those tools from our API.

Observing initiative and response results here (and at day job), I believe it is often easier for some users to identify what they don't want or refine and comment on some improvement of something that is offered in front of them vs. arriving at some amount from a blank check. As such, I think it is preferable for us to identify what we *think the users want (based on what we ourselves want) as a initial set of presentation, and then allow for users to confirm, add, or deny the results.

[ipaleka]

by TemiTope Yes MVP discussion relate to DAO discuss.

Nope. DAO discussions related only to the establishment and functioning of the future company, owned and maintained by the DAO governors. Regular official discussions related to ASA Stats should be conducted in the ASA Stats Channel.

[ipaleka]

by @Temitopeishola

Can we get asastats roadmap? @ipaleka

https://github.com/asastats/docs/blob/main/roadmap.md

[wxivd]

Features for consideration should already exist within the ASA Stats product

Do we have a list of the existing features available within ASA Stats product?

[ipaleka]

I'm going to update our roadmap the next week with this information. I guess we should group those implemented functionalities under the corresponding status/phase, separating beta/alfa functionalities.

[dragmz]

Use case 1 - Algostake

Algostake has a list of Qualified Stakes, i.e. stakes for which there are corresponding assets found in a connected wallet.

ASA Stats might provide them with an information about assets locked on other apps (Yieldly, Algofi, etc.) so they could list them as potentially (if unlocked) Qualified Stakes.

Must-have API features:

• List assets for a given account: asset index, balance (so they can test against their required min. balance); this includes balances for LP assets (missing feature?)
• For each asset, return an information if the asset is available on the account or locked at some service; if it's locked then provide a URL where the asset can be unlocked manually so Algostake could display it as a link

Nice to have API features:

• Filter assets by their index so the returned data contains information only for the assets that are of interest to Algostake

Notes

• Lots of potential here but currently there are very little or none such assets due to not much pools on Yieldly or very specific *-STBL pools on Algofi.

[wxivd]

The following describes two use-class, each followed by use case scenarios:

Use class 1: User defined entity and relationship management

Entity Relationship Model defines data elements and their relationship for a specified software system.
Define: model entities, their attributes and relationships among entities.

Group A = Liquidity Pools / ASA Staking
Entities:

• LP Service Providers: Tinyman, Algofi, Pact.fi, YLDY
• Staking Service Providers: YLDY, STKE, Algodoggo, Algofund
• LP (ASA pairs) / ASA staking pools
• TLV
• Volume traded
• Fees
• APR / APY

Entity/relationship

• Display available service providers
• Compare similarities: Data consolidation

Use-case: scripting engine
Asset management tools / ASASTATS premium tools for Investors:

• Display potential investment options of assets held in wallet. CONVERSLY new staking projects may want to be featured as available option
• LP/ASA Staking return on investment across different services (Asset held in wallet vs provisional amount)
• ASA Swap value across AMMs: account for swapping amount (exchange value of 25-50% Asset = X Algo to account for low liquidity pools)

Group B = Asset /Portfolio Tracking
Entities:

• Wallet Classifier: Project, Enterprise, Individual, LP
• Asset Class: Tokens / NFT
• Total supply
• Number of opt-in
• Number of asset Holders
• Amount held: percentage of total supply / top X holders

Entity/relationship

Use-case: scripting engine

• Projects creating LP (ASA pairs collaboration) may want to be featured in Portfolio > list possible pairings of assets held in wallet for LPs.
• Tracking tool of percentage change: number of holders / amount held / Project LP > Notification tools
• Index of wallets holding a given ASA by number of opt-in, holders, amount held
• Asset performance tool: two or more ASA comparison (total supply, distribution metrics)

Use Class 2: Graph Based Diagramming

Entity/relationship

• Entity Attributes from Group A / Group B
• Time factor (change over-time)
• Different Benchmarks (Algo/ USD)

Use-case

• Develop Feedback tools for Service Providers: as we have seen in NFT marketplace, one may take over another by listed NFT/Trading volume. Developing a tool that provide Entity Attributes VS time factor could provide projects with reliable / specific metrics for performance assessments / market share.
• Information providers / Indexers: Market researchers tools, Prediction & Data Analysis

There are countless possibilities, this was intended to brainstorm ideas. Some features may not be available and therefor could be add to feature-request if you find it viable.

[wxivd]

Another use-case: Group B: Staking Rewards

Optimisation tool for selecting the minimum balance qualifying for staking rewards (also airdrop).

Background

• ASA Projects set a minimum amount of ASA held in wallet to qualify for staking rewards on Algostake.
• Specifying the minimum-balance is arbitrary.
• An optimisation tool is needed by Project owners / Staking service providers: Algostake

Solution

• List wallets holding a given ASA by number of opt-in, holders, amount held.
• ASA holding-balance across wallets: Measure Minimum, Q1, Q2=Median, Q3, Maximum . IQR Interquartile range.
• Define minimum-balance: Value between Q1 - Median. with two tailored approaches, lower minimum to increase distribution, higher minimum drives purchasing powers (attainable by target group asset holders)

Rationale

• Setting minimum-balance incentivise asset holders to satisfy the criteria.
• ASA Project owners would have better tool to satisfy the objectives:
  • A: Marketing,
  • B: Increase distribution,
  • C: Stabilise/improve the ASA price due to increased demand.

Hypothesis
Choosing an accurate minimum-balance would improve A, B, C.

[ipaleka]

Among MVP functionalities with use-case, the optimal value for tokens functionalities will be implemented this month on our website.

https://github.com/asastats/channel/wiki/Goals

The current price will be retrieved from all the available AMMs and DEXes in a way that brings the maximum value for the user asset. This will be achieved by calculating current liquidities and/or volumes for that asset on all AMMs and DEXes, and by calculating the optimal amounts that should be sold on each of the AMMs or DEXes to the users.

[ipaleka]

by motuwagon in Discord:

I took the MVP question and explanation of what mvp is as, what is the smallest thing ASA stats does and still be a viable product.
I was trying to clarify with a example of what ASA stats does but in a more limited way and still be useful to a user. And what a user could do with that information. Something a user would spend ASA stats token for this service.
Not the team getting in to prediction but another entity using the information stats generates to use for algorithm prediction.
Is that what you were asking for?

It's not that actually. A user will always have those things that are available to them right now on the website. Among those functionalities that are available now, for the MVP purpose we have to abstract some of them that are:

1. robust and having a decent update system
2. valuable and/or interesting enough for the third-party developers and hobbyists to use
3. reasonably easy to implement by us

After we define those functionalities, then we'll start with developing our API. Here's an example from our Discord discussion:

For example, if they want to fetch amount of XET staked in Yieldly's XET-XET pool for the address ABCDEF..GHIJKL, they can call https://api.asastats.com/ABCDEF..GHIJKL/yieldly/xet-xet/ and our engine will return to them the following JSON:

{
  "address": "ABCDEF..GHIJKL",
  "Yieldly": {
    "XET-XET": {
      "asset_id": 283820866,
      "amount": 15000
    }
  }
}

The same goes for token values. For example, based on this comment they will be able to send a GET request using the following endpoint:

https://api.asastats.com/ABCDEF..GHIJKL/OPUL/

and our API can return to them the following JSON:

{
    "address": "ABCDEF..GHIJKL",
    "OPUL": {
        "Tinyman": {
            "amount": 75232522,
            "URL": "https://app.tinyman.org/#/swap?asset_in=287867876&asset_out=0",
        },
        "AlgoDEX": {
            "amount": 12000000,
            "URL": "https://app.algodex.com/trade/287867876",
        },
        "Algofi": {"amount": 12767478, "URL": "https://app.algofi.org/swap"},
    },
}

That's because that account has got exactly 100,00 OPUL and we evaluated the optimum amounts to be sold on each platform to get the maximum value from that 100 OPUL.

[ipaleka]

P.S.
There will be no restrictions whatsoever in MVP (or to say in the first phase/period).
The advanced/professional tiers from our Roadmap are not directly connected to the API, besides the fact that free tier users probably won't have an access to API. Our highest tiers' users can use and benefit from ASA Stats without ever directly accessing our API. Those professional services will be implemented directly on the website, sometimes in the form of professional user widgets developed by the third parties that only the highest tier users have access to.

[moloch10]

Maybe I'm being too simplistic, but a call that returns all assets and their values; basically what's seen when opening Stats. Then after its launch, there can be a schedule where every x units of time, a new call will be released.
If there's enough community involvement, users can vote on what they want to be worked on next.

[ipaleka]

Maybe I'm being too simplistic, but a call that returns all assets and their values; basically what's seen when opening Stats.

That's the ultimate goal - or to say the plan - for the stable and final release.

This discussion is about MVP, or to quote this comment:

Among those functionalities that are available now, for the MVP purpose we have to abstract some of them that are:

1. robust and having a decent update system
2. valuable and/or interesting enough for the third-party developers and hobbyists to use
3. reasonably easy to implement by us

[moloch10]

This discussion is about MVP

My first line is my suggestion, "a call that returns all assets and their values; basically what's seen when opening Stats."

[ipaleka]

My first line is my suggestion, "a call that returns all assets and their values; basically what's seen when opening Stats."

You can't have those values without fetching everything, and fetching everything implies unreliable and non-robust data (alpha, beta, not fully tested, etc).

[moloch10]

You can't have those values without fetching everything, and fetching everything implies unreliable and non-robust data (alpha, beta, not fully tested, etc).

Hmm, I don't understand why it'd be unreliable but ok, you know what's behind the scenes.

[ipaleka]

You can't have those values without fetching everything, and fetching everything implies unreliable and non-robust data (alpha, beta, not fully tested, etc).

Hmm, I don't understand why it'd be unreliable but ok, you know what's behind the scenes.

Me knowing the ASA Stats engine's characteristics doesn't connect with that. This is a no hidden information discussion and every aspect of it is based on that fact, I'm just a person who can't stop thinking of ASA Stats in an awake state for the last half of a year, and so I can provide much more information than others - every engine's imperfection is well known or it should be reported as a bug or a feature update.

For example, we haven't implemented Choice Coin voting yet and our Algofi staking program updates every two hours.

[wxivd]

Advanced features for ASA Stats users

A: Selling optimisation: Display maximum selling amount of ASA held in wallet on available AMMs: that account for less than 5% change in price.
B: Portfolio value optimisation:

• For each ASA, display Sum of ASA values from A.
• Options to include/exclude LP balance.

C: Colour coding: Percentage Drop/increase in ASA price.

Tier 1: Free for ASA Stats holders of given amount (500 K).
Tier 2: Pro membership, Fixed dollar value in ASA Stats, paid annualy.

Advanced features for Project Owner: B2B Lead Generation

A: NFT Projects: Display utility NFTs (investment opportunity), to asset holders, potential customers, (HDL, STKE, ALCH, ACORN, CoffeeDAO). Thus creating lead awareness, education, conversion.

Information provided for ASA Stats users:

• NFT project page
• Utility: Staking Reward / DAO
• Minting price / Secondary market price: real time price / tracking new listing provide opportunity to snap good price.
• Number of holders

D: advanced feature for ASA Stats user: Provide option to opt out thus giving control to choose displayed items.

Business Model:
Portal for NFT Projects: Track number of clicks per month/week..etc, (Hyperlink to NFT marketplace from ASA Stats website).
New NFT sales in a given time (1-week), from ASA Stats user wallets would create lead conversion. Win-win scenario.

1. ASA Stats gains a (fixed, percentage) profit form New NFT sales.
2. NFT projects pay a subscription fees/ fixed fee per project highlighted (ideal choice).
3. Free service for project owners holding ASA Stats of given amount (1 M ASA Stats) for given duration.

[wxivd]

AlgoxNFT marketplace displays the following information for a given wallet address (creator or random asset owner)

https://algoxnft.com/address/45LDVA6A44QD2PNWNAPGGDQESXNOY36HJC6UZXZNMIAYLXUYD4DGRAMNNA

• Number of wallet views
• Balance (Algo)
• Total value (algo) of NFTs purchased on site
• Total value (algo) of NFTs sold on site
• Asset: display wallet NFTs

These are very basic functions of portfolio view which we can help improve. I see potential for ASA Stats to provide API service to NFT marketplaces aiming to enhance the presentation and valuation of assets held in given wallet on the marketplace site. These can be tailored for

1- Private access, signed-in accounts to NFT marketplaces

• Private information for wallet owners focusing on NFTs held.
• Paves the way for marketplace developed features for NFT owners enabling them to highlight given NFTs by order, price, display on the NFT platform, thus enhancing sales potential.

2- Public access portfolio view on NFT marketplace targeting potential NFT buyers.

• Ability to create a list of wallet addresses a buyer may be interested in

I think this kind of approach opens doors for collaboration with NFT marketplaces. They may be interested in funding the development of such features using our API service.

[wxivd]

Advanced features to activate pro-membership

A: we would be encouraging developers to build tools using our API.
B: such tools are related to our scope: ASA and NFT valuation and price information.
C: two ends: single wallet view to global view

Currently we list assets based on value. This is common approach and shared among other portfolio trackers. Thos following are potentially advanced features. Looking for distinct use case of ASA Stats portfolio view:

1- List assets by global token distribution among holders. Four categories for asset display (A - D) in portfolio view.

• Category A: list assets held in wallet, for each asset included, the top 100 asset holders collectively hold up to 35% of total supply
• Category B, C and D, each list assets based on global distribution at 51%, 75%, more than 75% respectively

2- List assets by project liquidity (for simplicity, based on one pool holding the largest liquidity across all AMMs).

These are meant to provide sensitive and specific indicator of asset price stability/volatility.

3- Display a list of Opt-in ASA with 0 balance and total Algo locked in wallet

4- ASA explorer tool. Explore wallets of Top holders for a given asset. Idea stems from
https://yldy-estimator.joshlmao.com/staking-pools

• Top LP providers
• Top Asset holders
• Top NFT holders by collection

5- Compare overlap in assets (percentage of asset allocation) between own wallet and a given wallet.

[wxivd]

Advanced feature to maximise investment value

This idea stems from the maximum value engine.

Suppose an investor wants to get into a new project. Which exchange shall the investor utilise for maximum value?

Develop a Widget that enables the investor to enter:

1. Amount of investment (Algo)
2. ASA of choice

The engine displays the maximum value of investment by displaying the amount that should be bought from each AMM.

[wxivd]

Holder balance on Blockchain explorers and Charting tools

As staking services thrive on Algorand blockchain, it becomes harder to track accurately the number and the balance of token holders.

AlgoExplorer: Holders tab

Take ASA Stats Token on AlgoExplorer for example. The first address by balance is Yieldly distribution pool ASASTATS-ASASTATS. Problems to solve:

• The balance in the pool does not belong to the pool but to many individuals like yourself.
• As more people stake their tokens, the "Holder" metric becomes less sensitive and misleading at times. This applies for number of holders and balance of each holder.

This takes us to

Charting tools

Take ASA Stats Token on Tinychart.

The metic down on the RHS "Top Asset Holders - Supply owned" does not represent accurate information either (in terms of assessing asset distribution for investment purposes). Second top holder is Yieldly distribution pool ASASTATS-ASASTATS (Same as AlgoExplorer). Problem here:

• Distribution metric is skewed. It groups holders by to 10, 25, 50, 100. Whereas staking pool hold tokens the belong to hundreds of accounts.

Solution:
ASA Stats track holders' balance accurately, There is a need to differentiate between "Holders" and "Owners".

[AlgoRhythMatic]

While reading through various MVP proposals from @SCN9A here, I find myself agreeing and wondering - what next? How do we move from a series of ideas to a confirmed list of prioritized MVP issues? Short of active discussions on each proposal here, is there potentially a way to vote based on a list? Just trying to brainstorm how we could refine these ideas, and keep the discussions moving.

[ipaleka]

I'm not ready yet to be completely focused on this topic (and I can't afford to be superficially involved) and dunno for sure, but I'll analyze proposals and bring back technical side perceptions about what is achievable or not for the MVP (in the meaning of time and resources). Together with other functionalities in MVP added by me and the others during the discussion, we'll create conceptual documentation for the MVP and the development starts based on that documentation.

I guess the rest of the functionalities for the API will get a section under https://github.com/asastats/channel/wiki/DependentFeatures.

[ipaleka]

We just announced that the premium API users will be automatically selected as the DAO governors:

---

Opinion: @asastatscom has the simplest, yet most concise Algorand wallet info. Has every info I need in one UI w/o a click. Kudos 🐊

Wish @PeraAlgoWallet models something similar in mobile UI than its current ver.

We're about to start with the API development this month and the end product will offer all the website's functionalities. Premium API customers will be automatically selected as the DAO governors (owners of the project). For @PeraAlgoWallet we can prepare 5CP + 7WN k8s cluster.

---

[dragmz]

I'd like to see a simple total account value in ALGO, e.g.:
/ABCD...EFGH/value/algo => 10

[moloch10]

I'd like to see a simple total account value in ALGO, e.g.: /ABCD...EFGH/value/algo => 10

Agreed

[ipaleka]

Agreed

I expected your comment here as that goes in line with your "having all" suggestion. :)

Well, the implementation of all the systems in v0.5 engine is going well, I suppose we can leave Beta soon and so kind of we'd be ready to present all the implemented dApps and other apps in a reliable way. I guess that implies that we indeed can have all non-NFT data in MVP.

[ipaleka]

Of course, EVERYBODY is invited to take a part in our discussions, let alone our governors.

[moloch10]

I expected your comment here as that goes in line with your "having all" suggestion. :)

I'm that predictable 🤣🤣

[ipaleka]

I expected your comment here as that goes in line with your "having all" suggestion. :)

I'm that predictable roflrofl

I'll rather use the "reliable" attribute... :)