Goldsky

Track stablecoin issuers and competitors onchain

Talk to our team

What it is

Tracking stablecoin issuers and competitors onchain means following each token’s supply through its mints and burns, and who holds it, so you can compare issuers on the same figures.

Issuers, issuance platforms, banks and asset managers do it to see where a rival’s supply is growing, on which chains and among which holders, using the public record on each chain.

Goldsky streams the decoded mints and burns into your warehouse and can rebuild holder lists at any block, while your team sums supply, builds the comparison and runs the dashboards.

You can track stablecoin issuers and competitors two ways: stream mints, burns and holder snapshots into your warehouse with Turbo Pipelines, or keep a subgraph per token that holds its supply behind a GraphQL API.

How tracking stablecoin issuers onchain works

The diagram follows issuers minting and burning their tokens through to your team’s dashboards comparing them. Your setup may differ.

TurboStream mints and burnsEvery issuer’s supply changes, into your warehouse

Issuers mint and burnRival tokens’ supply changes

TurboSnapshot the holdersEach token’s transfers up to a chosen block

Build the comparisonSupply and holder share, summed per issuer

Serve your dashboardsYour API feeds the team’s screens

Goldsky

Ways to track stablecoin issuers and competitors

Streaming puts every token’s events in your warehouse for your analysts to compare in SQL; a subgraph per token keeps supply and events behind a hosted GraphQL API.

Usual setupOption 1: Stream to your warehouse

Best for: Many tokens across chains, compared in your own warehouse
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 per token

Best for: A few tokens, for an analyst without a warehouse
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

Ways to track stablecoin issuers and competitors
	Usual setupOption 1: Stream to your warehouse	Option 2: Subgraph per token
Best for	Many tokens across chains, compared in your own warehouse	A few tokens, for an analyst without a warehouse
Products	Turbo	Subgraphs
What you run	The destination: your database, queue or bucket, or a Postgres database Goldsky hosts	Nothing; Goldsky runs indexing, storage and the API
What you write	Pipeline YAML and SQL; TypeScript transforms when needed	A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives	In your own database or systems	Hosted by Goldsky
How results reach you	Pushed to you	You query; changes are pushed

Option 1: Track stablecoin issuers by streaming to your warehouse

A pipeline streams each token’s decoded mints and burns into your warehouse, and a one-time job rebuilds holder balances at the block you choose. Your team sums supply and holder share per issuer and serves the dashboards.

When to stream issuers’ supply to your warehouse

You compare many tokens across chains and want the raw events in your own warehouse, next to your other market data.

What you’ll need

Goldsky Turbo
A list of the tokens you track, by contract address on each chain
A warehouse or analytics database
A dashboard or internal API your team reads from

Record issuers’ mints and burns
A stablecoin’s supply changes only when its issuer mints new tokens or burns redeemed ones, so those events are the supply history.
On most tokens, a mint is a transfer from the zero address and a burn is a transfer to it, and some contracts also emit their own events. You need them for every token and chain you track, or one issuer’s supply looks flat when it isn’t.
Stream decoded mints and burns into your warehouse
Handled by Goldsky Turbo
Analysts need each supply change as a row with the token, chain, amount and time.
The stream has to cover every tracked contract and correct rows when a reorg replaces a block. Missing one chain’s contract understates that issuer.
Goldsky’s Turbo Pipelines can filter a chain’s ERC-20 transfers to your token addresses, keep mints and burns with a SQL WHERE on the zero address, and write them to ClickHouse or another warehouse sink.
Filter stablecoin transfers (opens in a new tab)
Snapshot the holders at a chosen block
Handled by Goldsky Turbo
Holder share needs each wallet’s balance at one fixed point, so every token is measured at the same moment.
Balances are rebuilt from every transfer up to the block you pick. Using different blocks for different tokens makes one issuer look larger only because it was measured later.
A one-time Turbo Pipelines job can backfill each token’s transfers up to the block you choose into a table, as in the corporate-actions guide, then exit.
Run a one-time backfill job (opens in a new tab)
Build the comparison
The comparison is what the team acts on: supply per issuer and chain, and how holders are spread.
In your warehouse, sum mints minus burns per token and chain for supply, and credits minus debits per wallet for holder balances. Group tokens by issuer so bridged or multi-chain versions of one token count once.
Serve the dashboards
Strategy and sales teams read the comparison on screens, not in the warehouse.
Your API or dashboard tool reads the comparison tables. Show the block or time each figure was taken at, so nobody compares a live number with an old snapshot.

What to know about streaming issuers’ supply to your warehouse

You own the warehouse tables, the sums and the dashboards; Goldsky runs the pipelines.
Supply and holder share are totals, which your team computes in the warehouse.
Holder lists come from a job you run for a chosen block, so you decide how often to take one.

Option 2: Track stablecoin issuers with a subgraph per token

You deploy a subgraph for each token you follow. It records the token’s transfers, mints and burns and keeps the totals its mappings maintain, behind a hosted GraphQL API your team queries.

When to track issuers with a subgraph per token

You follow a few tokens and want queryable supply data without running a warehouse.

What you’ll need

Goldsky Subgraphs
A list of the tokens you track, by contract address
A dashboard or notebook that can query GraphQL

Record issuers’ mints and burns
A stablecoin’s supply changes only when its issuer mints new tokens or burns redeemed ones.
On most tokens, a mint is a transfer from the zero address and a burn is a transfer to it. Each token you track needs its contract on every chain covered.
Index each token’s events
Handled by Goldsky Subgraphs
Each token’s transfers, mints and burns need to be stored as records you can query.
Give the indexer each token’s address and the events to keep. A wrong address or a missing chain leaves that issuer out of the comparison.
The goldsky subgraph init wizard builds a no-code subgraph from a contract address, fetches the ABI and deploys it, with no mapping code to write.
Create a no-code subgraph (opens in a new tab)
Keep a running supply total
Handled by Goldsky Subgraphs
Supply is the sum of every mint minus every burn, so someone has to keep that sum.
The total has to update on each mint and burn and roll back when a reorg removes one. A subgraph written from source can keep the total in its mapping code, which then becomes yours to maintain.
Subgraphs runs the mapping code you deploy from source with goldsky subgraph deploy, so a handler can update a supply record on every mint and burn.
Deploy a subgraph from source (opens in a new tab)
Query supply over GraphQL
Handled by Goldsky Subgraphs
Your team needs the figures in its dashboards or notebooks.
Each subgraph has its own GraphQL endpoint, so a dashboard comparing issuers queries each one and lines the results up by time. Take each figure at the same block, or the comparison is off.
Each deployed subgraph gets its own hosted GraphQL endpoint, which a dashboard or notebook can query directly.
How Subgraphs serve data (opens in a new tab)
Build the comparison
The team acts on supply per issuer side by side.
Your dashboard groups tokens by issuer and compares supply over time. Holder share across many wallets is harder to get this way, so add it from a warehouse if the team needs it.

What to know about a subgraph per token

Goldsky hosts each subgraph and its API; you deploy and query them.
A no-code subgraph indexes events without code; a running supply total needs mapping code you write.
Each token is its own subgraph, so comparing many tokens means querying many endpoints.

What you control

Your team: Build the comparison
Serve the dashboards

Security and deployment

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

Use cases built the same way