Skip to main content

Goldsky

Proxy voting for tokenized securities

Talk to our team

What is proxy voting for tokenized securities?

Proxy voting for tokenized securities is how holders of tokenized shares or fund units vote at a meeting, or choose an option in a corporate action election, with each holder’s votes set by what they held at the record date; it’s also called tokenized shareholder voting.

Transfer agents and tokenization platforms run the holder side of it, because the proxy agent can only send ballots and count votes against a list of who held what on that date.

Goldsky turns the record date into a block and backfills every transfer up to it into your database, while building the holder list, sharing it and the tally stay with you and your proxy agent.

You can build the voting list two ways: backfill transfers up to the record block into your own database with a one-time Turbo Pipelines job, or query a subgraph register at the record block over GraphQL.

Who runs proxy voting for tokenized securities?

Transfer agents, tokenization platforms and fund administrators that keep tokenized registers and work with a proxy agent.

How the record date sets who can vote

The diagram follows one meeting or election, from the record date the issuer sets to the votes your proxy agent tallies, and shows who does each step. Your setup may differ.

Your business, step 1: Set the record dateThe issuer calls a meeting or election
Goldsky, step 2: FeedsFind the record blockThe block at the record date
Your business, step 4: Build the holder listEach holder’s position at the record date
Goldsky, step 3: TurboBackfill to the record blockEvery transfer up to it, in your database
Your business, step 5: Proxy voting agentCollect and tally votesYour proxy agent counts against the list
  • Goldsky
  • Your provider

Ways to build the voting list for tokenized securities

With the backfill, transfers land in your database and your team sums them into the list for your proxy agent; the subgraph keeps positions current and returns them for any block from a hosted endpoint.

Usual setupOption 1: Record-date backfill
Best for
Occasional votes, with the list kept in your database
Products
TurboFeeds
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 register
Best for
One chain, with a register you query for any date
Products
SubgraphsFeeds
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 the proxy voting list with a record-date backfill

A one-time pipeline copies every transfer of the token up to the record block into your database. Your team sums them into the holder list and shares it with your proxy agent.

When to backfill voters into your database

Votes come up a few times a year, you don’t keep a live register, and you want the list in a database you control for the proxy agent and your records.

What you’ll need

  • Goldsky Turbo
  • Goldsky Feeds
  • The token’s contract address and the chain it’s on
  • A database you run
  • A proxy agent that sends ballots and tallies votes
  • Your holder register, linking wallets to verified holders

  1. Set the record date

    Only holders on the record date can vote, so the date decides who gets a ballot.

    The issuer sets the meeting or election and its record date, and your team confirms the date with the proxy agent. If the date you snapshot differs from the one the proxy agent uses, ballots go to the wrong people.

  2. Find the record block

    Handled by Goldsky Feeds

    The record date is a clock time, but a chain keeps balances by block, so the time has to become a block number.

    Decide which moment counts, such as the close of business in the time zone the terms use, then take the last block at or before it on the chain where the token lives. A block from just after the cutoff puts late buyers on the list.

    The Feeds blocks endpoint returns the newest block at or before a time when you call it with timestamp_lte, sort=number_desc and limit=1.

    Turn a timestamp into a block (opens in a new tab)

  3. Backfill transfers to the record block

    Handled by Goldsky Turbo

    Positions on the record date have to be rebuilt from every transfer up to it.

    Every mint, burn and transfer of the token from its first block to the record block has to land in your database, with nothing after the cutoff. A gap in early history understates some holders’ votes.

    With Goldsky, you can run a Turbo Pipelines pipeline with job: true and a block_number limit in its source filter, so it backfills the token’s transfers up to the record block into your database and then exits.

    Run a pipeline as a one-time job (opens in a new tab)

  4. Build the holder list

    The proxy agent needs one line per holder with the position that sets their votes.

    Sum each wallet’s transfers into a position, drop empty wallets, link each wallet to its holder from your register, and share the list with your proxy agent. A wallet you can’t link to a verified holder needs a decision before ballots go out.

  5. Collect and tally votes

    The vote is decided by counting each holder’s choices against the position that sets their votes.

    Your proxy agent sends ballots, collects votes or elections and counts them against the holder list. Any correction to the list after ballots go out has to reach the agent before the tally closes.

What to know about backfilling voters to the record block

  • The job runs once per record date and exits, so nothing keeps running between meetings.
  • Summing transfers into positions at the record block is a query your team runs in your database once the backfill has finished.
  • The list sits in your database, so your access rules decide who sees it.
  • Getting the list to the proxy agent is your code, over whatever channel you agree with them.

Option 2: Build the proxy voting list from a subgraph register

A subgraph keeps the token’s register indexed all the time, and you query it at the record block over GraphQL for every holder’s position, from an endpoint Goldsky hosts.

When to read voters from a subgraph register

The token lives on one EVM chain and you already keep its register in a subgraph, or want one you can query at any block for votes, statements and reports.

What you’ll need

  • Goldsky Subgraphs
  • Goldsky Feeds
  • The token’s contract address and the chain it’s on
  • A subgraph that keeps each holder’s position, with its schema and mappings
  • A proxy agent that sends ballots and tallies votes
  • Your holder register, linking wallets to verified holders

  1. Set the record date

    Only holders on the record date can vote, so the date decides who gets a ballot.

    The issuer sets the meeting or election and its record date, and your team confirms the date with the proxy agent. If the date you snapshot differs from the one the proxy agent uses, ballots go to the wrong people.

  2. Find the record block

    Handled by Goldsky Feeds

    The record date is a clock time, but a chain keeps balances by block, so the time has to become a block number.

    Decide which moment counts, such as the close of business in the time zone the terms use, then take the last block at or before it on the chain where the token lives. A block from just after the cutoff puts late buyers on the list.

    The Feeds blocks endpoint returns the newest block at or before a time when you call it with timestamp_lte, sort=number_desc and limit=1.

    Turn a timestamp into a block (opens in a new tab)

  3. Read every holder at the record block

    Handled by Goldsky Subgraphs

    Holdings change all the time, so you need each holder’s balance as it stood at the record block, not today.

    The register has to return balances for a past block as well as the latest one. A register that only keeps current balances can’t say who held what on the record date once anyone has traded since.

    With Goldsky Subgraphs as the holder register, the task reads each holder’s balance at the record block over GraphQL, the same way the tokenized equities guide has its dividend task read the registry at a record-date block.

    Build a tokenized equities registry (opens in a new tab)

  4. Serve the list to your proxy agent

    Handled by Goldsky Subgraphs

    The proxy agent counts votes against the list, so it needs the list from a source both sides trust.

    Link each wallet to its holder from your register and give the agent the list, or access to it. Anyone who can query the list can see who holds what, so access has to be limited to the people running the vote.

    Subgraphs serves the register at a GraphQL endpoint. Turn on the private endpoint so each request needs an API token in the Authorization header.

    Set up public and private endpoints (opens in a new tab)

  5. Collect and tally votes

    The vote is decided by counting each holder’s choices against the position that sets their votes.

    Your proxy agent sends ballots, collects votes or elections and counts them against the holder list. Any correction to the list after ballots go out has to reach the agent before the tally closes.

What to know about reading voters from a subgraph

  • The register stays indexed, so a list for a new record date needs a query, not a backfill.
  • Your mappings keep each position, so the list comes back already summed.
  • The endpoint can require an API token, which keeps the holder list from being public.
  • A subgraph indexes one chain; a token on several chains needs one subgraph each and a merge in your code.

What you control

Your team
  • Set the record date
  • Build the holder list
Your providers
  • Proxy voting agent

Questions and answers

What are corporate action elections?

Corporate action elections are the choices holders make in an optional corporate action, such as taking a dividend in cash or in shares, or tendering shares into an offer. Each holder’s election applies to the position they held at the record date, and the agent running the action counts elections against the holder list. For tokenized securities, that list comes from the token’s balances at the record block.

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 run corporate actions

Use cases built the same way

Run proxy voting for tokenized securities 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