Skip to main content

Goldsky

DAO delegate dashboards and voting power analytics

Talk to our team

What it is

DAO delegate dashboards and voting power analytics show, for a token-governed DAO, how much voting power each delegate holds, who delegated it, how it moves and how often each delegate votes.

DAOs and foundations commission them so token holders can compare delegates before delegating, and so governance teams can spot concentrated power and measure delegate programs.

Goldsky decodes the delegation and vote events from the DAO’s token and governor contracts and keeps their full history current for you; offchain votes, participation rates and the dashboards stay with your team.

You can build a DAO delegate dashboard two ways: stream the token and governor events into your warehouse with Turbo Pipelines, or index them in a subgraph that serves delegates and votes over GraphQL.

Who it’s for

DAOs and chain foundations, the governance contributors and analytics firms they fund, and delegates tracking their own record.

How a DAO delegate dashboard gets built

The diagram follows one delegation from the holder’s onchain choice to the delegate pages token holders compare. Your setup may differ.

Your business, step 2: Offchain voting platformRecord offchain votesGasless votes, weighted by tokens
Goldsky, step 3: TurboDecode governance eventsFrom the token and governor contracts
Blockchains, step 1: Holders delegate and voteDelegation, voting power and vote events
Your business, step 5: Work out voting powerPer delegate, with delegators, over time
Goldsky, step 4: TurboLand them in your warehouseFrom the token’s first block
Your business, step 6: Match votes to proposalsParticipation rate per delegate
Your business, step 7: Build delegate dashboardsDelegate pages and program reports
  • Goldsky
  • Your provider

Ways to build a DAO delegate dashboard

Streaming puts the full delegation and vote history in your warehouse for analysts to query in SQL; a subgraph keeps delegates, voting power and votes behind a hosted GraphQL API your app queries.

Usual setupOption 1: Stream to your warehouse
Best for
Governance analysis and program reports in SQL
Products
Turbo
What you run
The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write
Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives
In your own database or systems
How results reach you
Pushed to you
Option 2: Subgraph over the DAO contracts
Best for
The DAO’s own delegate pages, queried live
Products
Subgraphs
What you run
Nothing; Goldsky runs indexing, storage and the API
What you write
A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives
Hosted by Goldsky
How results reach you
You query; changes are pushed

Option 1: Build a DAO delegate dashboard by streaming governance events to your warehouse

A pipeline decodes the DAO’s delegation and vote events and lands their full history in your warehouse. Your team works out voting power and participation per delegate there and builds the dashboards.

When to stream governance events to your warehouse

You analyze governance across proposals and over time, such as how concentrated voting power is or what a delegate program achieved, and want offchain votes in the same tables.

What you’ll need

  • Goldsky Turbo
  • The DAO’s token and governor contract addresses and ABIs
  • A data warehouse
  • Offchain votes from your voting platform, if the DAO uses one
  • A dashboard tool

  1. Holders delegate and vote

    In a token-governed DAO, holders delegate their voting power to delegates, who vote on proposals.

    The token emits DelegateChanged when a holder picks a delegate and DelegateVotesChanged when a delegate’s voting power changes, and the governor emits VoteCast for each vote. A delegate page’s onchain figures all come from these events.

  2. Record offchain votes

    Many DAOs also hold gasless, token-weighted votes offchain, often to test support before an onchain proposal.

    Those votes never reach the chain, so pull them from the voting platform and store them with each proposal. Leave them out and a delegate who votes mostly offchain looks inactive.

  3. Decode delegation and vote events

    Handled by Goldsky Turbo

    Raw logs have to be decoded into delegator, delegate, voting power and vote before anyone can count them.

    Decode each contract’s logs with its interface (ABI), and include every governor contract the DAO has used, or votes cast on an older one go missing.

    Goldsky’s Turbo Pipelines decodes each contract’s logs in a SQL transform with _gs_log_decode and the contract’s ABI, which _gs_fetch_abi can fetch from a block explorer.

    Decode contract events (opens in a new tab)

  4. Land the full history in your warehouse

    Handled by Goldsky Turbo

    Voting power today is the result of every delegation since the token launched.

    Load events from the token’s first block and keep new ones flowing into the same tables. When the chain replaces recent blocks in a reorg, events from those blocks have to be corrected, or a delegation that never settled shows up.

    A Turbo Pipelines job mode pipeline backfills a fixed block range once and exits, a live pipeline writes new events to your warehouse, and sinks with a primary_key apply reorg corrections to the same rows.

    Backfill history with job mode (opens in a new tab)

  5. Work out voting power per delegate

    Voting power and delegator counts are what token holders compare first.

    Take each delegate’s latest voting power from the voting-power events and count the holders currently delegating to them. Show power as a share of all votable tokens, and keep the daily series to show how concentrated power is over time.

  6. Match votes to proposals

    Participation shows whether a delegate uses the voting power they were given.

    Join each vote, onchain and offchain, to its proposal, and count the share of proposals each delegate voted on since their first vote. If you label delegates active or inactive, publish the threshold.

  7. Build delegate dashboards

    Token holders choose delegates, and governance teams judge delegate programs, from these pages.

    Show each delegate’s voting power, delegators, votes and participation, with the time the data was last updated. Programs such as delegate incentives also need reports over a set period.

What to know about streaming governance events

  • Goldsky runs the pipeline; you own the warehouse tables, the participation maths and the dashboards.
  • Offchain votes come from the voting platform and join the onchain events in your warehouse.
  • Sinks with a primary key apply reorg corrections as updates to the same rows.

Option 2: Build a DAO delegate dashboard with a subgraph

You deploy a subgraph over the DAO’s token and governor contracts. Its mappings keep each delegate’s voting power, delegators and votes as records, and Goldsky serves them over a hosted GraphQL API your delegate pages query.

When to use a subgraph for delegate dashboards

You’re building the DAO’s own delegate pages and want them to query delegates and votes directly, without running a warehouse.

What you’ll need

  • Goldsky Subgraphs
  • The DAO’s token and governor contract addresses and ABIs
  • Mapping code for delegate and vote records
  • Offchain votes from your voting platform, if the DAO uses one
  • A front end that queries GraphQL

  1. Holders delegate and vote

    In a token-governed DAO, holders delegate their voting power to delegates, who vote on proposals.

    The token emits DelegateChanged when a holder picks a delegate and DelegateVotesChanged when a delegate’s voting power changes, and the governor emits VoteCast for each vote.

  2. Record offchain votes

    Many DAOs also hold gasless, token-weighted votes offchain, often to test support before an onchain proposal.

    Those votes never reach the chain, so pull them from the voting platform and store them with each proposal. Leave them out and a delegate who votes mostly offchain looks inactive.

  3. Index delegations and votes

    Handled by Goldsky Subgraphs

    Each event becomes a record your pages can query, such as a delegate with their current voting power.

    The mappings update a delegate’s record on every delegation and voting-power event and store each vote against its proposal. Index from the token’s first block, so current power reflects every past delegation.

    Subgraphs runs the mapping code you deploy from source with goldsky subgraph deploy, so a handler can update a delegate’s record on every event.

    Deploy a subgraph from source (opens in a new tab)

  4. Serve delegates over GraphQL

    Handled by Goldsky Subgraphs

    Your delegate pages need the records behind an API they can query.

    Query only the fields each page shows, and show when the data was last updated.

    With Goldsky, each deployed subgraph gets a hosted GraphQL endpoint, and subgraph webhooks can push each new delegation or vote record to your backend.

    Use GraphQL endpoints (opens in a new tab)

  5. Match votes to proposals

    Participation shows whether a delegate uses the voting power they were given.

    Join each vote, onchain and offchain, to its proposal, and count the share of proposals each delegate voted on since their first vote. If you label delegates active or inactive, publish the threshold.

  6. Build delegate pages

    Token holders compare delegates on these pages before they delegate.

    Show each delegate’s voting power, delegators, votes and participation, with the time the data was last updated.

What to know about a subgraph for delegate dashboards

  • Goldsky hosts the subgraph and its API; you write and maintain the schema and mappings.
  • Subgraphs index EVM chains, and latency grows on contracts with very frequent events.
  • Offchain votes stay outside the index, so your app adds them.

What you control

Your team
  • Work out voting power per delegate
  • Match votes to proposals
  • Build delegate dashboards
Your providers
  • Offchain voting platform

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that analyze onchain activity

Use cases built the same way

Build a DAO delegate dashboard with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status