Live Algorand governance proposal monitoring for the xGov ecosystem, posted publicly through @AFWalletWatcher X account.
Automated new-proposal alerts when proposals are created.
Recurring active-proposal summaries that provide: link to proposals forum discussions, link to proposals xGov voting page, total voters remaining, quorum threshold progress across all three categories (Voter Count, Vote Count & Approval Rate) for each active proposal, remaining time to vote per proposal or, if not live, until discussion ends.
Existing production usage with measurable public reach from March 20, 2026 through today (See Adoption Metrics).
Open-sourced repository submitted to Electric Capital with MIT License.
What Is AF Wallet Watcher’s Proposal Enhancement?
AF Wallet Watcher was originally, and continues to support as, a transparency service for officially labeled Algorand Foundation wallets activities. The project monitors on-chain activity and publishes X posts so the broader Algorand community can see important activity without manually crawling explorer pages or via word-of-mouth.
The daily Proposal Watcher & Proposal Summary extends that same transparency workflow to xGov proposals. It monitors the xGov registry, detects new proposal applications, formats proposal data into readable public summaries, and posts proposal updates from @AFWalletWatcher.
The tool exists to reduce information friction around governance participation. Instead of requiring every voter to manually inspect proposal applications or search scattered discussion channels, the watcher provides timely, standardized updates in the public feed where Algorand community members already follow ecosystem activity.
Live: Yes
Open-sourced: Yes
Metrics Available: Yes
Submitted to Electric Capital: Yes
Proposal Watcher Features
New proposal detection and public posting.
Active proposal summaries for proposals currently live for voting.
Vote status snapshots including proposal IDs and readable proposal metadata.
X API posting through OAuth 1.0a.
Algorand mainnet reads through a self-hosted Algorand node
Public metrics tracking through proposal-related posts.
Adoption Metrics
Enhancement Live since March 20, 2026
Proposal Post Count: 72
Proposal Post Likes: 345
Proposal Post Views: 12,937
Proposal Post Reposts: 65
(Above metrics captured 06/11/26)
Funding Request
The request is 20,000 Algo to support our commitment to continuous operation, maintenance, and public reporting for the Proposal Watcher & Proposal Summary.
Funds will support retroactive time spent in:
Maintenance of proposal parsing, formatting, and error handling.
Continued public reporting through @AFWalletWatcher.
Documentation and open-source upkeep.
Improvements to proposal summary clarity and coverage as governance tooling evolves.
Hosting costs for our scripts & node for reliable monitoring. ($25~/mo)
@Astoc1993 thank you for the proposal related to the xGov program.
While I appreciate the effort to try to bring more eyes to the xGov program this way, IMO the ask size is high w.r.t. traction and required effort to update the previously funded proposal, in particular considering the ask size for the initial Wallet Watcher was 25k ALGO, which had ca. 4x the traction.
While I understand that logic, the xGov budget is denominated in ALGO, which is why IMO it is necessary to consider the ALGO amount as well when evaluating proposals.
Algo amount for an enhancement must be relative to a former proposal for a similar usecase
good faith that this is a universal standard that is formally stated somewhere
this is something that is considered for all proposals
I would propose I lower the ask amount to 25,000 Algo with the arguments that:
W.R.T work done, I feel the research and implementation is in equal standing, the only shared logic, which is straightforward, is in crawling transactions per round in the proposal watcher portion (not the summary portion), vs. deciphering the exact globals and boxes that map to quorums and voters , as well as finding a way to present these nicely, and concisely, in a tweet
W.R.T engagement, although there is 4x less engagement, the tradeoff is that the benefits are greater for the community as these announcements target a critical part of our chain’s funding process which requires community participation. The audience is primarily xGov members, so naturally there may be less interest (generally and algorithmically) from users outside of our media bubble
W.R.T overhead, the API for X is no longer free, I will spend, based on what I’ve seen so far, at least $250~ per year to continue maintaining this. This is under the assumption that the fee model for the X API does not change or modify its API contract. If we ignore VPS costs it is $50~ per year. I also have an X premium subscription for the account which I believe is $8~ per month, so that’s an additional $80~ per year but that is a personal preference for increasing engagement for the account and not required. I hope this adds some precedence to the higher ask amount as well before I adjust.
Lastly there is the request of increased visibility needed from me as we have seen that if I am not present to monitor it consistently there is the potential for downtime paired with a lack of understanding of my preferred communication channels. To mitigate that risk I’ve returned to checking in on the account regularly. This is a personal cost to champion this usecase despite the low ask amounts in proposals relative to others.
I will await your thoughts on this and confirmed support on this (at least from you) before recreating the proposal on-chain, as I see resetting the ask amount is [understandably] still not an available feature.
Please note first again that I expressed only my opinion. There is no standard. Every proposal can make whatever ask and is evaluated on a case-by-case basis by the xGovs.
That said, even the 25k ALGO ask IMO is too much for the relatively small updates and the produced traction.
Please also note again that the program is supposed to fund only retroactive work, not future maintenance.
On the latter point, the initial proposal promoted Wallet Watcher as providing value in its maintenance, which turned out divisive due to experienced reliability issues. Expecting now the community to fund that part is counterintuitive.
Lastly, note that you can create a thread first, asking for community feedback. No need to create an on-chain proposal first.
I have to say this is a huge assumption if we’re speaking relatively, especially if we are going by algo amount request relativity.
To assist in mapping work if we want to dive deeper on a development level, and so we can get a concrete understanding if we are speaking relatively to the previous proposal, to affirm my standing that an equal amount of work has been done, what we need to look at is:
Note 1: I have modularized any reused functionality so we can clearly see that these new scripts are not duplicative, and for an easier indication that these were not relatively “small updates”— you will see this is especially true for proposal_summary_daily.py. The previous monitoring was done via transactions, the new features are based on application state of stateful programs.
Note 2: Not that that I would encourage using this indicator, but for anyone looking in that is non-technical, at a higher-level, without even looking at any of the logic, the sum of codelines between former features and new features is nearly equivalent at ~300 lines.
I know, but I just can’t help but state these things.
I have made several statements to this and public apologies, with all due respect I think this is an exaggerated claim at this point. If anything I am only cementing the fact that my claims that maintenance would be made still proves to be true. What people see on the outside is downtime, they don’t see blockers and work that has been done to address those same blockers. Perhaps I should include not only the work done in enhancing the watcher but the work done in restoring the service, which you will see in my reasoning below.
Reasoning for the downtime:
The script never stopped, we began receiving errors that were out of our control
The API contract for X changed
A fee-model was introduced to a previously free service which was a huge blocker and a personal decision was needed to decide on whether or not I would take on these costs
Communication preferences were not clear, and I was simply tagged 2 or 3 times on X, no other attempts for outreach were made.
My resolution steps:
Upon becoming aware, I quickly adjusted to the new API contract and began testing, and even scrapped together a discord alternative once I was informed that didn’t depend on the X API and instead discord.py (this is also in the repository, a discord version of the watcher which I did not include as it was sunset since only 2 or 3 users joined the discord, until I weighed out my options.)
I decided to begin paying for the API so that the bot could immediately be back online
Addressed every lashback comment on various platforms (X, Discord, these forums)
This is mostly a personal preference for the process.
With respect to your comments @uhudo — and hopefully with your understanding of the above, I’ve lowered the ask to 20,000.
I hope other xGov council members also note my above points in the previous comment and do not jump to generalized conclusions as we have seen in the past from previous community members (one of the most prominent and vocal against the watcher has since exploited his community for nearly five times the value I’m asking and left the ecosystem)
The proposal # in this post’s title and link has been updated/added here and in the proposal.