[Pre-proposal discussion] The ASA Stats Tracker Stack: Fork-and-deploy open-source infrastructure for Algorand portfolio trackers

Governance Discussions
,
1

Hey everyone,

Before submitting our next xGov proposal on-chain, we’re opening this thread to gather community feedback first - following the process the xGov Council recommends: discuss the draft here, refine it together, and only then create the on-chain proposal, where parameters like the ask amount can no longer be changed. The lesson from our Permission dApp proposal (where locked parameters met changed market conditions) is exactly why this thread exists. Nothing below is final.

In one sentence: with this release, the entire user-facing codebase of www.asastats.com - the website frontend, the user widgets system, and the mobile application - becomes open-source, and anyone can fork it and deploy their own branded Algorand portfolio tracker in an afternoon.

What we’re releasing

  1. frontend (github.com/asastats/frontend) - the complete Django codebase serving www.asastats.com today: portfolio pages, accounts, subscriptions, wallet authentication (Pera, Defly, Lute, and EVM wallets via WalletConnect), configurable blockchain explorers (Allo, Lora, Pera Explorer, Algo Surf), and full Ansible provisioning for single-server deployment.
  2. widgets (github.com/asastats/widgets) - a manifest-and-registry system for pluggable interactive components, with a documented contract for third-party widget developers. Implemented so far: the Historic Data widget (fetch a portfolio’s state for any moment or block in the past, presented just like the real-time website), swapping through smart routers (Folks Finance and Haystack implemented, with a selectable default router; LiquiHog, Vestige, and Pact planned, and eventually our own smart router), and user settings (currently a preferred blockchain explorer: Allo, Lora, Pera Explorer, Algo Surf).
  3. mobileapp (github.com/asastats/mobileapp) - the ASA Stats mobile application, written in Flutter and already live on the Google Play Store and the Apple App Store.

A fork doesn’t run an indexer or integrate DeFi protocols - it connects over a documented, token-authenticated HTTP API to the ASA Stats engine for all portfolio data, and gets free access to our CDN (cdn.asastats.com): 3 million ASA/NFT images and 71 GB of Algorand data.

This continues the mission from our whitepaper and builds on our previously funded work (xGov-70, xGov-141, and the recently approved Rewards Suite proposal) and our previous open-source releases (Permission dApp, Rewards Suite).

Pull request in the Open Dev Data repository for the frontend and widgets repositories

Pull request in the Open Dev Data repository for the mobileapp repository

Why we think it deserves funding

  • It’s a production system, not a prototype. The exact code in these repositories serves www.asastats.com today, after four years of operation.
  • Engineering standards: 100% unit test coverage across ~2,350 Python, ~600 JavaScript, and ~80 TypeScript tests (wallet connection and nonce flows), plus initial sets of 24 functional and 18 integration tests, with GitHub Actions running suites, ansible-lint, and Molecule provisioning scenarios on every commit.
  • It removes the ecosystem’s highest barrier - the data layer - for anyone who wants to build a portfolio or analytics product on Algorand.
  • The widgets vision: we want the widgets system to become a frontend for any Algorand dApp - staking, lending, any DeFi protocol - and we’re ready to help and even sponsor widget development for dApps that don’t have their own UI, so developers can focus on smart contracts.
  • Adoption is genuinely easy: nearly 150 ASA Stats DAO governors already hold API access sufficient to run a tracker; we’ll provide API tokens to anyone wanting to investigate or bootstrap a fork, and we’re prepared to donate ASASTATS to cover the minimal tier for adopters (Asastatser, ~0.25 USDC/month).
  • We’ll prove the claim on video: the release will be accompanied by a walkthrough where we deploy a brand-new, custom-branded tracker from scratch - fresh domain, cheap VPS, fork, one Ansible playbook run - to a live HTTPS website.

The engineering effort behind this was substantial: separating a four-year-old production monorepo into clean open-source repositories, designing the public API boundary, extracting proprietary logic into the engine, rewriting deployment for single-host forks, and bringing everything to 100% coverage under modern CI.

What we’re asking you (the point of this thread)

These are the parameters we want to settle here, before they get locked on-chain:

  1. The ask amount. We’re considering 200,000–300,000 ALGO, calculated from the actual time and work involved. Given how xGov 2.0’s sliding-scale quorum interacts with the ask size - and our previous experience with parameters locked under different market conditions - we’d genuinely like your input on what sizing the community considers appropriate for this scope.
  2. Retroactive vs. forward scope. xGov now emphasizes retroactive funding for open-source work with demonstrated value. Should this proposal be framed purely retroactively (the completed release), or include a forward component (third-party widget SDK, additional in-house widgets, fork support)? Or should the forward work be a separate, later proposal?
  3. What would convince you? Which details, metrics, or demonstrations would you want to see in the on-chain proposal - more on the API contract and its guarantees for forks? The widget development contract? The deployment video before or after submission?
  4. Anything missing or unclear about the architecture, the fork model, or the API access story for adopters.

We’ll update this draft based on the discussion - exactly as we did with the Permission dApp proposal, where community feedback directly improved the repositories - and once parameters are settled, we’ll submit on-chain and open the official proposal thread linking back here.

Thanks in advance for your time and feedback!

Ivica & Eduard, ASA Stats team

2

This is an interesting proposal, particularly the open-source mobile application and reusable ASA portfolio infrastructure.

I’m with Gem Wallet, an open-source multichain mobile wallet that currently supports holding, sending, and receiving ALGO and Algorand Standard Assets. Algorand WalletConnect support is not yet available in Gem Wallet, so we would not currently be able to test the connection flow.

From your experience integrating Pera, Defly, Lute, and WalletConnect, which Algorand connection and signing standards would a new wallet need to implement to work reliably with ASA Stats and its forks? It would also be helpful to understand the minimum transaction methods and mobile deep-link behavior you expect from compatible wallets.

I can pass those requirements to our development team as concrete ecosystem feedback.

3

Besides the xChain integration that is out of scope here, ASA Stats uses TxnLab’s use-wallet for wallet connections. I believe the ideal path for your project is to implement a use-wallet adapter.

For projects that aren’t purely TypeScript-based, our own wallet implementation is definitely worth checking out. ASA Stats is a Django-based project, and we use Vite alongside our API to handle the use-wallet connection flow.

Regarding mobile flow, we rely on use-wallet and its SDK to handle the deep-link round-trips back to the browser. If Gem Wallet implements WalletConnect 2, use-wallet supports it natively.

I highly recommend joining the NFDomains Discord. TxnLab has a dedicated #use-wallet channel there where you can get all the specific technical answers you need. I really believe that’s by far the best way for your team to continue with the implementation.

4

Thanks, this is very helpful. The distinction between implementing a dedicated use-wallet adapter and adding Algorand support through WalletConnect 2 gives us a clearer path to investigate.

I’ll pass along the use-wallet documentation, ASA Stats implementation, and the NFDomains #use-wallet channel to our developers. If Algorand dApp connectivity becomes something we can prioritize, we’ll follow up there with the implementation-specific questions.

Appreciate you pointing us in the right direction.

5

Thank you for following the new proposed guidelines and starting a proactive discussion before an on-chain proposal is open!

I support the proposal’s direction because I think it ASA Stats frontend has provided great value to users throughout the years.

Regarding your questions on what would convience me would be any metrics regarding the product usage (e.g. current, historical or aggregated visits of the frontend). Similarly, I wasn’t aware of its mobile version. Could you comment how old it is and how many times was it downloaded?

Regarding the widget, similarly I wasn’t aware of it. Do you have any metrics on its use?
W.r.t. to retroactive vs. forward scope, I personally would strongly suggest to keep it retroactive to comply with programs T&C. Moreover, I would suggest to make multiple proposals limited in scope, in particular if you think the products provide value also when used individually.

Regarding the usefulness of what is being provided in this proposal my only concern (if I understand the proposal correctly) is its usefulness in case ASA Stats engine / API is shut down. Could you comment if/how the work is/would be useful also in such a case?
Could you also comment what would be needed in order to open-source also the engine?
I think doing that would better address the statement that the proposal removes the ecosystem’s highest barrier - the data layer.

6

Thank you for your comment and the kind words in it! :heart:

The ASA Stats Mobile was published almost 4 years ago (Play Store and App Store). I don’t have the exact download metrics right now (we can prepare that info for the official proposal); I believe there have been around 1-2K individual users. Our API v1.0 was created solely for the use of the mobile app (the website hadn’t been using any API at that time). Now every part of the ASA Stats uses API v2, the mobile app too.

We just introduced the open source user widgets repository, tho we published the historic data user widget last year as the first/initial widget in the repo. This announcement took place after we developed another user widget - swapping through smart routers. There’s a generic `swapcore` widget, and it is the basis for the currently implemented Folks and Haystack smart routers that derive from it.

Nothing in the official proposal would imply yet-to-be-written code. Here in this thread, we just use some marketing language to explain that the main goal is to have a UI - in the form of a user widget - for all the valid Algorand dApps. :slight_smile:

ASA Stats has been online for 4 years and 9 months. Three times the site was down for about an hour or two, and also we had two major issues with stalled data that lasted for 16 hours (the first one when Algorand Inc. had issues with the Node upgrade and fast catchup wasn’t working) and the second one that lasted for 10 hours (that New Year’s Day when AlgoNode Indexer went down after Orange hit the Mainnet). The proposal is retroactive for the code that has already been published, but the plan is to use the funds to power up another dedicated server that will prevent all the errors besides the Indexer unavailability.

Could you also comment what would be needed in order to open-source also the engine?

I guess the best answer here is to copy/paste a reply to the same question we got on Reddit:

Once the ASA Stats DAO completely takes over the project - currently it only owns the copyright on code - a voting session will be conducted on whether the backend remains closed-source.

Based on the state of the Algorand ecosystem in recent years and the overall interest of the ASA Stats DAO, staying closed-source pretty much ensures continued development of the project, its API, and comprehensive portfolio tracking on Algorand in general.

Last but not least, staying closed-source opens the door to long-term profit and/or an exit for the ASA Stats DAO. For me, as a representative of the ASA Stats Team, the primary and pretty much the only objective is to do everything possible in that regard. :slight_smile: