[Pre-Proposal Discussion] PolkAudit — Open-Source Governance Audit Dashboard

Hi Polkadot community,

I’m building PolkAudit, an open-source governance transparency stack for Polkadot. It indexes finalized relay-chain blocks, maintains a structured audit trail in PostgreSQL, and exposes governance data, KPIs, and exports through a secured API and Next.js dashboard.

I’m opening this thread to share the working MVP, gather technical and governance feedback from the community, and refine a Phase 1 treasury proposal before submitting a formal OpenGov referendum.

Phase 1 ask: USD 10,000 equivalent in DOT
Duration: 8 weeks
License: Apache 2.0
Repository: GitHub - ViSa-Innovations/polkaudit · GitHub
Live dashboard: https://app.polkaudit.xyz

The project is already running as a public MVP. The proposed Phase 1 funding is intended to harden what exists, extend OpenGov parsing and backfill capabilities, improve verification and CI, and validate the tooling with an ecosystem pilot.

Before taking this on-chain, I’d like the community to review the scope, architecture, deliverables, and funding request—and challenge anything that should be improved.


Problem

Polkadot OpenGov and treasury activity are transparent on-chain, but turning that activity into a repeatable, auditable dataset for reporting and analysis still requires significant work.

Governance information spans blocks, extrinsics, events, referenda, voting, and treasury activity. Existing explorers and governance interfaces are valuable for discovering and interacting with this information, while PolkAudit is focused on a different layer: indexing, preserving, structuring, and exporting governance evidence for downstream analysis and accountability.

PolkAudit aims to make it easier for ecosystem teams, grantees, reviewers, and community members to:

  • trace indexed governance activity back to finalized chain data;
  • inspect the health and progress of the indexing pipeline;
  • query structured governance and treasury data through an API;
  • export evidence in reusable CSV/JSON formats; and
  • build repeatable reporting and audit workflows on top of that data.

The intention is to complement existing governance interfaces and explorers, not replace them.


What exists today (MVP)

PolkAudit already has a working end-to-end pipeline:

Polkadot RPC → Indexer → PostgreSQL → FastAPI → Next.js dashboard → CSV/JSON exports

Currently implemented:

  • Live indexing of finalized Polkadot relay-chain blocks
  • Extrinsic audit trail stored in PostgreSQL
  • Stats API exposing indexed blocks, extrinsics, and latest indexed block
  • Dashboard with Overview, Proposals, Treasury, Exports, and Settings views
  • CSV proposal export and Overview JSON export
  • Deployment documentation for the current cloud architecture

Current public demo architecture:

GCP Cloud Run (indexer) → Neon PostgreSQL → GCP Cloud Run (API) → Vercel (dashboard)

The public dashboard and API documentation are available through the project links provided at the beginning of this post.

Current MVP limitation

The indexing pipeline is live, but the governance-specific dataset is still being expanded. Proposal, voting, and treasury KPIs depend on the indexer encountering and correctly parsing the relevant OpenGov activity, such as Referenda.submit, ConvictionVoting.vote, and treasury-related calls/events.

As a result, some governance views may currently contain sparse data even while finalized-block indexing is operating normally.

Closing this gap is one of the primary deliverables of Phase 1: extending the OpenGov parsers and adding backfill tooling so that governance evidence can be populated and verified across historical block ranges.


Evidence & verification

The MVP, source code, architecture, and deployment documentation are available for community review.

The GitHub repository contains the source code together with the architecture documentation, deployment documentation, draft treasury proposal, screenshots, and sample exports. API documentation is also available from the deployed project.

I welcome technical review of the repository and live deployment. If you find discrepancies between the documentation, dashboard, API, or on-chain data, please raise them in this thread or as a GitHub issue.

What Phase 1 funding enables — 8 weeks / USD 10,000 equivalent in DOT

Milestones

M1 — Demo hardening & verification (Weeks 1–2)

  • Harden the existing public dashboard and API deployment
  • Publish/run verification scripts for the deployed MVP
  • Document reproducible verification steps
  • Publish the first Phase 1 progress report on this Forum thread

Acceptance: Public dashboard and API operational; documented verification steps/scripts available in the repository and passing against the deployed MVP.

M2 — OpenGov parsing & historical backfill (Weeks 3–4)

  • Extend parsing for relevant OpenGov proposal, voting, and treasury activity
  • Implement tooling to backfill governance data from historical finalized blocks
  • Populate governance evidence in the public demo from a documented block range
  • Document supported pallets/calls/events and known limitations

Acceptance: A documented historical block range can be processed and produces governance records that can be inspected through the database/API/dashboard and traced back to source chain data.

M3 — CI, release & reproducibility (Weeks 5–6)

  • Establish passing GitHub CI for the Phase 1 codebase
  • Publish v0.1.0-mvp
  • Update technical documentation, screenshots, and sample exports
  • Publish a demo video showing the end-to-end workflow

Acceptance: Public v0.1.0-mvp release available; CI passing; documentation and demo evidence published in the repository.

M4 — Ecosystem validation & final reporting (Weeks 7–8)

  • Onboard at least one ecosystem team as a design-partner pilot
  • Gather and document pilot feedback
  • Address agreed high-priority issues that fit within Phase 1 scope
  • Publish the final Phase 1 report and proposed Phase 2 scope

Acceptance: At least one documented pilot completed, feedback/results published where the participant permits, and a final Phase 1 report posted publicly.

Budget

Total Phase 1 request: USD 10,000 equivalent in DOT

  • Development and engineering: $5,500
  • Infrastructure (database, cloud compute, RPC and related services): $2,000
  • Documentation and demo materials: $1,000
  • Security, testing and quality: $1,000
  • Contingency: $500

Total: $10,000

I currently propose milestone-based delivery across the four milestones above. Before submitting the OpenGov proposal, I would particularly welcome community feedback on whether the payment structure should be 25% per milestone or weighted according to the engineering effort and acceptance criteria of each milestone.

The final treasury request would be denominated as the appropriate DOT amount for the USD 10,000 ask, with the beneficiary address and conversion basis stated explicitly in the referendum.


What is NOT in Phase 1

To keep the first treasury request focused and deliverable within 8 weeks, Phase 1 does not include:

  • Multichain or parachain indexing
  • AI-generated recommendations or voting recommendations
  • Enterprise compliance automation
  • A paid managed-hosting product

These are intentionally outside the current treasury ask. Potential Phase 2 work will be based on the results of Phase 1, pilot feedback, and community priorities rather than being assumed in advance.


Who benefits

PolkAudit is intended as reusable public infrastructure rather than tooling for a single proposal or organization.

  • Parachain and DAO treasury teams — structured governance data, KPIs, and reusable exports for internal reporting
  • Grant recipients and funded teams — data that can support transparent milestone and treasury reporting
  • Auditors and governance reviewers — structured, queryable evidence instead of repeatedly reconstructing activity from raw chain data
  • Ecosystem voters — additional tools for independently examining governance and treasury activity
  • Developers and researchers — an open API and PostgreSQL-based data model that can support additional governance tooling and analysis

Because the core stack is open source, the resulting indexing, parsing, API, and export capabilities can also be reused or extended by other ecosystem projects.


Team

Vijay (Vijaya Babu Bollavarapu) — Founder, ViSa Innovations

I am currently the primary maintainer and developer of PolkAudit and am responsible for the architecture, indexer, backend API, dashboard, deployment, and project documentation.

Phase 1 is intentionally scoped as a solo-maintainer delivery. Where specialist review is useful—for example, security or technical review—the associated costs are included within the Phase 1 budget rather than presented as additional core team members.

Contact: hello@polkaudit.xyz
Developer profile: Vijay / Vijaya Babu Bollavarapu on GitHub

Development activity and Phase 1 deliverables will remain publicly reviewable through the PolkAudit repository and milestone updates on this Forum thread.


Open-source & public-good commitment

PolkAudit is being developed as open infrastructure that the Polkadot community can inspect, run, reuse, and extend.

  • Apache 2.0 licensed core code
  • Public GitHub repository with development history and releases
  • Open interfaces using standard PostgreSQL and HTTP APIs rather than a proprietary data format
  • Public verification through source code, API documentation, deployment documentation, and reproducible verification steps
  • Public milestone reporting on this Forum thread during Phase 1

Treasury funding would support development of the open-source core described in the Phase 1 milestones. The resulting indexing, OpenGov parsing, backfill, API, and export capabilities will remain publicly available under the project’s open-source license.

A future managed or hosted service may be offered separately, but development of a paid managed-hosting product is not part of this treasury request.


Questions for the community

Before turning this into an on-chain treasury proposal, I’d particularly value feedback on:

  1. Scope: Are the four Phase 1 milestones appropriately scoped for an 8-week first delivery? Is anything essential missing or unnecessary?
  2. Funding: Does a USD 10,000 equivalent total request seem proportionate to the proposed deliverables? Would you prefer equal 25% milestone weighting or effort-based weighting?
  3. OpenGov coverage: Which governance pallets, calls, events, or historical data should be prioritized for the Phase 1 parser and backfill work?
  4. Verification: What evidence would you want to see before considering each milestone complete?
  5. Pilot: Is any parachain team, collective, grantee, governance reviewer, or other ecosystem team interested in participating as a free Phase 1 design partner?
  6. Future priorities: If Phase 1 proves useful, which capabilities would provide the most ecosystem value next—for example scheduled reporting, alerts, or parachain-specific indexing?

Critical feedback is welcome, particularly on the scope, technical approach, measurable acceptance criteria, and treasury amount. I’d rather address concerns here before submitting anything on-chain.


Next steps

  1. Keep this pre-proposal discussion open for approximately 1–2 weeks and collect community feedback
  2. Revise the scope, milestones, budget, and acceptance criteria where appropriate based on that feedback
  3. Publish the finalized proposal details and clearly document the DOT conversion basis and beneficiary address
  4. If community feedback supports proceeding, submit the treasury proposal through Polkadot OpenGov
  5. If approved, deliver against the agreed milestones and post progress and verification evidence publicly on this thread

Thanks for taking the time to review PolkAudit.

I’m particularly interested in hearing from people who work with OpenGov data, treasury reporting, governance analysis, or ecosystem grants, as well as teams that may be interested in the Phase 1 pilot.

I’m happy to answer technical questions, discuss the architecture, or clarify any part of the proposed scope before taking this on-chain.