The problem
GovTool's backend reads exclusively from a self-hosted cardano-db-sync PostgreSQL database. Every query is raw SQL embedded at compile time, and the whole application assumes direct database access.
That decision made sense in 2023, when Conway-era governance data was not available anywhere else. It costs us a lot now:
- Contributors cannot run GovTool. To bring the stack up you need a Cardano node and a db-sync instance. Blockfrost's own self-hosting guide puts the realistic requirement at 64 GB RAM, 8+ CPU cores, 250+ GB of SSD at 80k IOPS. Almost nobody is going to do that to fix a frontend bug, and an AI coding agent certainly will not.
- We carry operational risk that other people already carry better. Running and resyncing db-sync is a real job. Several community teams do it full time, at scale, with better uptime than we can justify staffing for.
- It is a single point of failure with no fallback. If our db-sync is behind or down, GovTool is down. There is no second source to fail over to.
Meanwhile the ecosystem has matured. Conway governance data is now served by multiple independent providers. We should be able to use them.
Proposal
Introduce a chain data provider interface in the backend, with interchangeable adapters behind it. GovTool's own API surface does not change; what changes is where the data comes from.
GovTool API
|
ChainDataProvider (interface)
|
+-- DbSyncProvider (today's SQL, kept)
+-- KoiosProvider
+-- BlockfrostProvider (also covers Dolos and self-hosted RYO)
+-- CexplorerProvider
+-- CardanoscanProvider
+-- ...
Two things make this real rather than decorative:
- A conformance test suite that runs identically against every adapter. An adapter is done when it passes. This is also how we find out where providers genuinely differ.
- Configuration, not a fork. Which provider is in use is a config value rather than a build. Operators choose what they are willing to run — and, as below, we would like end users to be able to choose too.
This should land alongside the TypeScript backend rewrite rather than before it — reimplementing the data layer twice would be wasteful.
Letting the user choose the provider
A second idea, and the reason this is worth doing well rather than quietly: make the data provider something the end user selects in the GovTool UI.
The teams running Cardano's data infrastructure do a large amount of unglamorous work that GovTool would otherwise be quietly free-riding on. If a user can see that their DRep list was served by Koios, or by Cexplorer, and can switch to another, those teams get visible credit and traffic they can point at. That seems like the right relationship to have with the people whose infrastructure we depend on.
It also has practical benefits: no single provider outage takes GovTool down for a user who can switch, and it makes our own dependency legible rather than hidden.
How this could work:
- Route through our backend first, with the provider as a parameter. API keys stay server-side, CORS stays simple, and every adapter is exercised by real traffic. Direct browser-to-provider calls are the more decentralised end state but bring key handling and CORS problems that are not worth solving on day one.
- Show the source. Attribution in the UI wherever provider-sourced data is displayed, linking back to the provider. Credit is the point.
- Show freshness. Providers sync at different rates. Displaying each provider's tip height, and flagging when the selected one is behind, turns an invisible failure into visible information.
- Remember the choice per user, with a sensible default for anyone who never touches the setting.
One caveat worth stating plainly: this is a governance tool, and the numbers on screen inform how people vote. If a user can choose where those numbers come from, the interface has to be honest about which source produced them. Provider attribution is therefore not only credit, it is provenance — and it should be visible rather than buried in a settings page.
Candidate providers
Surveyed August 2026, in no particular order. We intend to reach out to these teams individually rather than rank them here — the notes below are only to record what we found, and corrections are welcome.
- Koios — community-run cluster, PostgREST over db-sync. The strongest governance coverage we found:
drep_list, drep_info, drep_metadata, drep_updates, drep_history, drep_voting_power_history, drep_votes, drep_delegators, drep_epoch_summary, committee_info, committee_votes, proposal_list, voter_proposal_list, proposal_voting_summary, proposal_votes, vote_list, pool_votes, treasury_withdrawals, plus totals, epoch_params, tx_status and account_info for everything else. Free, no key for basic use, self-hostable via the Guild Operators stack. Notably drep_info is a bulk POST, which maps directly onto our drep/voting-power-list endpoint instead of becoming an N+1.
- Blockfrost — the most widely adopted REST API, with governance endpoints for DReps, their votes, metadata and updates, proposals and proposal metadata, and the constitutional committee. Free tier plus paid. The API shape is also self-hostable through
blockfrost-backend-ryo, though that still needs db-sync underneath.
- Dolos (TxPipe) — a lightweight Rust "data node" that tracks DReps and proposals and serves a Blockfrost-compatible API among others. This is the cheap self-hosting path, and because it speaks Blockfrost's API it shares that adapter.
- Cexplorer — an established independent explorer with a dedicated governance section and an API covering DReps and governance data. Requires a key.
- Cardanoscan (StricaHQ) — explorer with a documented REST API including governance data, with SDKs available. Some governance endpoints appear to sit behind their Pro tier.
- Demeter.run — managed hosting for db-sync, Kupo, Ogmios and Dolos. Not a different data source so much as a way to keep the current SQL path without operating the machine ourselves.
- SyncGovHub — a governance-specific API covering DReps, proposals and vote rationales. Narrower than the general-purpose providers, and worth understanding before assuming it fits.
- Maestro — surveyed, but we found no governance endpoints in their documentation as of August 2026. Listed for completeness in case that is out of date.
Also noted, though not a drop-in for our use case: Cardano Rosetta Java has added Conway-era governance support through the Mesh API, which may matter to anyone integrating GovTool data via that route.
Where this will not map cleanly
Being honest about the hard parts, because they decide whether this is a month or a quarter:
- Search across DRep metadata. The DRep Directory searches names that come from off-chain metadata. Providers serve metadata per DRep; none offer full-text search across all of them. This needs a small local index no matter which provider we use.
- Sorting and paging over derived sets. Our proposal list is sorted and paged with a given DRep's vote status attached. In SQL that is a join. Over REST it is N+1 unless we materialise it locally.
- The
seed parameter on drep/list, which gives a stable shuffle of the directory, is a SQL trick that has no REST equivalent and will need reimplementing.
- Our bespoke network metrics.
get-network-metrics.sql computes aggregates that no provider exposes directly. Some of these may need to move to a local rollup, or be dropped if nobody uses them.
- Rate limits. Local SQL is effectively unmetered; provider tiers are not. Caching stops being an optimisation and becomes a requirement.
None of these are blockers. All of them argue for the same design: providers for the primitives, a thin local index for the things that genuinely need one.
Suggested phasing
- Extract the interface and move today's SQL behind a
DbSyncProvider. No behaviour change, no user-visible difference. Land the conformance suite here.
- Koios adapter first. Best governance coverage, bulk queries, community-run, free to develop against — the strongest test of whether the abstraction holds.
- Blockfrost adapter second, which brings Dolos and RYO along with it.
- Local index for search, shuffle and the aggregates that do not map.
- Flip the default local dev setup to a provider, so
docker compose up needs no chain infrastructure at all. This is the change that makes GovTool contributable.
- Expose the provider selector in the UI, with attribution and sync-height display, once there are at least two adapters worth choosing between.
Keeping DbSyncProvider maintained matters — anyone already running db-sync should not be forced off it, and it stays our reference implementation for correctness.
Questions
- To the teams behind the projects listed above: we will reach out individually, but the open invitation stands — would you be willing to talk through GovTool's access patterns? We would rather design against what your systems are good at than discover the mismatches in production. If GovTool's traffic is a meaningful load, we should discuss that up front.
- To anyone running GovTool themselves: which provider would you actually want, and is there one you could not use?
- On the provider selector: does surfacing this to end users seem useful, or is it a setting almost nobody will touch? We think the attribution is worth it regardless, but we would rather hear that we are wrong now.
- On defaults: should the hosted gov.tools keep running its own db-sync for independence, while contributors and self-hosters default to a provider? There is a reasonable argument that the public instance of a governance tool should not depend on a single commercial API.
- Have we missed a provider? Particularly any community project serving governance data that we have not listed.
References
The problem
GovTool's backend reads exclusively from a self-hosted
cardano-db-syncPostgreSQL database. Every query is raw SQL embedded at compile time, and the whole application assumes direct database access.That decision made sense in 2023, when Conway-era governance data was not available anywhere else. It costs us a lot now:
Meanwhile the ecosystem has matured. Conway governance data is now served by multiple independent providers. We should be able to use them.
Proposal
Introduce a chain data provider interface in the backend, with interchangeable adapters behind it. GovTool's own API surface does not change; what changes is where the data comes from.
Two things make this real rather than decorative:
This should land alongside the TypeScript backend rewrite rather than before it — reimplementing the data layer twice would be wasteful.
Letting the user choose the provider
A second idea, and the reason this is worth doing well rather than quietly: make the data provider something the end user selects in the GovTool UI.
The teams running Cardano's data infrastructure do a large amount of unglamorous work that GovTool would otherwise be quietly free-riding on. If a user can see that their DRep list was served by Koios, or by Cexplorer, and can switch to another, those teams get visible credit and traffic they can point at. That seems like the right relationship to have with the people whose infrastructure we depend on.
It also has practical benefits: no single provider outage takes GovTool down for a user who can switch, and it makes our own dependency legible rather than hidden.
How this could work:
One caveat worth stating plainly: this is a governance tool, and the numbers on screen inform how people vote. If a user can choose where those numbers come from, the interface has to be honest about which source produced them. Provider attribution is therefore not only credit, it is provenance — and it should be visible rather than buried in a settings page.
Candidate providers
Surveyed August 2026, in no particular order. We intend to reach out to these teams individually rather than rank them here — the notes below are only to record what we found, and corrections are welcome.
drep_list,drep_info,drep_metadata,drep_updates,drep_history,drep_voting_power_history,drep_votes,drep_delegators,drep_epoch_summary,committee_info,committee_votes,proposal_list,voter_proposal_list,proposal_voting_summary,proposal_votes,vote_list,pool_votes,treasury_withdrawals, plustotals,epoch_params,tx_statusandaccount_infofor everything else. Free, no key for basic use, self-hostable via the Guild Operators stack. Notablydrep_infois a bulk POST, which maps directly onto ourdrep/voting-power-listendpoint instead of becoming an N+1.blockfrost-backend-ryo, though that still needs db-sync underneath.Also noted, though not a drop-in for our use case: Cardano Rosetta Java has added Conway-era governance support through the Mesh API, which may matter to anyone integrating GovTool data via that route.
Where this will not map cleanly
Being honest about the hard parts, because they decide whether this is a month or a quarter:
seedparameter ondrep/list, which gives a stable shuffle of the directory, is a SQL trick that has no REST equivalent and will need reimplementing.get-network-metrics.sqlcomputes aggregates that no provider exposes directly. Some of these may need to move to a local rollup, or be dropped if nobody uses them.None of these are blockers. All of them argue for the same design: providers for the primitives, a thin local index for the things that genuinely need one.
Suggested phasing
DbSyncProvider. No behaviour change, no user-visible difference. Land the conformance suite here.docker compose upneeds no chain infrastructure at all. This is the change that makes GovTool contributable.Keeping
DbSyncProvidermaintained matters — anyone already running db-sync should not be forced off it, and it stays our reference implementation for correctness.Questions
References