Skip to main content

Goldsky

Supply data for stablecoin issuance platforms

Talk to our team

What is supply data for stablecoin issuance platforms?

Supply data for stablecoin issuance platforms is one record of every mint and burn across all the coins a platform issues for its brands, on every chain, with each coin’s supply worked out from it; platforms sell the service itself as stablecoin as a service or white-label stablecoins.

The platform needs that record to report on each program and show every brand its own supply, and each new coin or chain adds contracts it has to follow.

Goldsky decodes every brand’s mints and burns, merges the chains into one stream and lands it in your warehouse, while the per-brand totals and the API your brands use stay yours.

You can build it two ways: stream every coin’s mints and burns into your warehouse with Turbo Pipelines, or run a hosted subgraph for each coin and chain that keeps supply and serves it over GraphQL.

Who uses supply data for stablecoin issuance platforms?

Stablecoin issuance platforms that run coins for other brands, including bank issuance platforms, and the branded issuers that launch coins through them, such as payments and consumer brands moving to a dollar token of their own.

How an issuance platform tracks supply across its brands

The diagram follows one brand’s mint or burn, on any chain, to the supply figure your API shows that brand. Your setup may differ.

Your business, step 1: Register each coinIts contracts on every chain
Blockchains, step 2: A brand mints or burnsAny coin you run, on any chain
Goldsky, step 3: TurboMerge every chainOne stream of each coin’s mints and burns
Your business, step 5: Total supply per brandAcross every chain the coin runs on
Goldsky, step 4: TurboLand it in your warehouseHistory per coin and chain
Your business, step 6: Serve your brandsYour API shows each brand its supply
  • Goldsky

Ways to track supply for every coin on an issuance platform

One pipeline puts every coin’s mints and burns from every chain in a single warehouse table for your SQL; with subgraphs, each coin on each chain gets its own hosted index that your brands’ API queries and adds up.

Usual setupOption 1: Stream to your warehouse
Best for
Many coins and chains, in one warehouse table
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: Hosted subgraphs
Best for
A few coins on a few EVM chains, no 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

Option 1: Track supply for every coin on an issuance platform with a warehouse stream

One pipeline decodes the mints and burns of every coin you issue on every chain, merges them into one stream tagged by coin and chain, and lands it in your warehouse. Your SQL keeps each brand’s supply and your API serves it.

When to stream every coin into one warehouse

You run many coins across many chains and want one table to report from, with new coins and chains added to the same pipeline as brands launch.

What you’ll need

  • Goldsky Turbo
  • The contract address of each coin on each chain
  • A data warehouse
  • A record of which brand owns each coin
  • The API or dashboard your brands use

  1. Register each coin and its contracts

    Only contracts you know about can be followed, and each one has to map to a brand.

    Keep one list of every coin, chain and contract address, with the brand it belongs to, and update it before a coin goes live. A contract with no brand attached produces supply nobody can report on.

  2. Mint and burn each brand’s coin

    Each brand’s supply changes whenever its coin is minted for a client or burned in a redemption, on any chain it’s on.

    Each coin has its own contract on each chain, so a platform with many brands has many contracts to follow. A coin launched on a new chain without telling the data team is missing from supply until someone notices.

  3. Decode and merge every chain

    Handled by Goldsky Turbo

    Supply per brand needs one stream of mints and burns from every coin and chain, each tagged with where it came from.

    Every row has to carry its coin, chain, amount, block and transaction. A chain added with a different column layout breaks the merged table or drops rows without warning.

    With Goldsky, a Turbo Pipelines pipeline can read each chain as its own source, decode mints and burns, and merge them with UNION ALL, adding a constant chain column to each part.

    Merge chains in one pipeline (opens in a new tab)

  4. Land the history in your warehouse

    Handled by Goldsky Turbo

    Reporting and the brands’ API read from the warehouse, so every event needs to be there with its history.

    Keep every event from each contract’s first block, so supply can be rebuilt for any date. Delivery can repeat after a restart, so each row keeps a stable ID that your SQL counts once.

    Turbo Pipelines can write the merged stream to ClickHouse, which collapses repeated rows on the primary_key and applies reorg deletes, or to S3 as Parquet files partitioned by coin and chain.

    Set up the ClickHouse sink (opens in a new tab)

  5. Total supply per brand

    Each brand wants one figure: its coin’s supply across every chain.

    Your SQL sums mints minus burns per coin and chain, then per brand. Checking the result against each contract’s total supply from time to time shows up a missing event or a missing chain.

  6. Show each brand its supply

    Brands check their supply, and some publish it, so the platform gives each one its own view.

    Your API or dashboard reads from the warehouse and shows each brand only its own coins. Showing the same figures the platform reports to supervisors avoids two versions of one number.

What to know about streaming every coin into one warehouse

  • Goldsky runs the pipeline; the warehouse, the per-brand totals and the brand-facing API are yours.
  • Keeping coin contracts in a dynamic table lets a new coin on an existing chain be picked up without a redeploy; a new chain still means a new source.
  • Rows carry coin, chain and block, so any brand’s figure can be traced to its events.
  • In a warehouse table keyed on the row ID, reorg corrections replace the rows they affect; in append-only files they arrive as rows of their own for your SQL to apply.

Option 2: Track supply for every coin on an issuance platform with hosted subgraphs

You deploy a subgraph for each coin on each chain. Each one indexes the coin’s mints and burns, keeps its supply and serves both at a GraphQL endpoint Goldsky hosts, and your brands’ API queries those endpoints and adds the chains together.

When to use hosted subgraphs for brand supply

You run a few coins on a few EVM chains and would rather query hosted endpoints than run a warehouse.

What you’ll need

  • Goldsky Subgraphs
  • The contract address and deployment block of each coin on each chain
  • A code repository for the schema and mappings
  • A record of which brand owns each coin
  • The API or dashboard your brands use

  1. Register each coin and its contracts

    Only contracts you know about can be followed, and each one has to map to a brand.

    Keep one list of every coin, chain and contract address, with the brand it belongs to, and update it before a coin goes live. A contract with no brand attached produces supply nobody can report on.

  2. Mint and burn each brand’s coin

    Each brand’s supply changes whenever its coin is minted for a client or burned in a redemption, on any chain it’s on.

    Each coin has its own contract on each chain, so a platform with many brands has many contracts to follow. A coin launched on a new chain without telling the data team is missing from supply until someone notices.

  3. Define the supply records

    Each subgraph needs to know which events change supply and how to store them.

    One schema for every coin keeps queries the same across brands: a record per mint and burn, plus a supply figure per coin. Giving each coin its own layout means your API needs separate code for each.

  4. Index each coin on each chain

    Handled by Goldsky Subgraphs

    Each coin’s supply comes from every mint and burn since its contract was deployed.

    Indexing starts at each contract’s deployment block. A start block set too late leaves supply short without any error.

    Goldsky Subgraphs runs the same mapping code for every coin, deployed with goldsky subgraph deploy once per coin and chain, and keeps each index current as blocks arrive.

    Deploy a subgraph to Goldsky (opens in a new tab)

  5. Serve supply over GraphQL

    Handled by Goldsky Subgraphs

    Your API reads each coin’s supply by querying an endpoint.

    A brand’s supply data usually shouldn’t be open to anyone, so endpoints should require a key. Your API adds each coin’s chains together before showing a brand its total.

    Every subgraph in Subgraphs gets a hosted GraphQL endpoint; turn on the private endpoint and each request needs an API token in the Authorization header.

    Set up private endpoints (opens in a new tab)

  6. Show each brand its supply

    Brands check their supply, and some publish it, so the platform gives each one its own view.

    Your API queries each coin’s endpoints, adds up the chains and shows each brand only its own coins. If one endpoint falls behind, the total does too, so show the block each figure was read at.

What to know about tracking brand supply with subgraphs

  • Each coin on each chain is its own subgraph, so the number to deploy and watch grows with every launch.
  • Your API adds the chains together for each brand’s total.
  • The schema and mappings decide what’s stored, and changing them means deploying and indexing again.
  • Goldsky hosts the indexes and endpoints; the brand-facing API stays yours.

What you control

Your team
  • Register each coin and its contracts
  • Total supply per brand
  • Show each brand its supply

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 track supply and reserves

Use cases built the same way

Track supply for every coin on an issuance platform 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