Goldsky

Daily stablecoin supply by chain for PS-01 reports

Talk to our team

What it is

A daily per-chain stablecoin supply ledger is the record of how much of a token is outstanding on each chain at each day’s close, split into issued, redeemed, held by the issuer, frozen and lost; teams also call it stablecoin supply by chain.

Payment stablecoin issuers supervised by the OCC need it for Schedule A of the weekly PS-01 report, which asks for those figures for every day of the week.

Goldsky decodes every mint, burn and freeze and reads the balances of the wallets you list into your warehouse, while the daily totals, the call on which wallets count as lost and the report itself stay with your team.

How a daily per-chain stablecoin supply ledger is built

The diagram follows one day’s supply changes on each chain, and your list of special wallets, through to the daily ledger behind the Schedule A figures. Your setup may differ.

List special walletsIssuer, frozen and lost wallets you classify

Supply changesMints, burns and freezes on every chain

TurboDecode every eventMints, burns and freezes, per chain

TurboTrack listed balancesRead at the block of each change

Total each dayIssued, redeemed, held and frozen, per chain

TurboLand it in your warehouseEvery event and balance, per chain

Keep the daily ledgerSchedule A figures for the weekly report

Goldsky

How to keep a daily per-chain stablecoin supply ledger

A pipeline decodes every mint, burn and freeze of your token on each chain and reads the balances of the wallets you list each time they change, then lands it all in your warehouse. Your SQL turns those rows into each day’s figures.

What you’ll need

Goldsky Turbo
Your token’s contract address on each chain
Your list of issuer, frozen and lost wallets, and the policy that classifies them
A data warehouse or database
Your weekly reporting process

Classify issuer, frozen and lost wallets
Some tokens in circulation are held by the issuer, frozen by order or lost for good, and the report counts them apart from the rest.
Your policy decides which wallets belong in each class, and the list has to change as soon as a wallet’s class does. A frozen wallet missing from the list is counted as ordinary supply until someone notices.
Record mints, burns and freezes on each chain
Supply moves when tokens are minted or burned, and a freeze takes tokens out of use without changing supply.
Each chain records only its own events, so a figure per chain needs each chain read separately. For a short time the newest blocks can still be rewritten, so the day’s close should be taken once its last blocks have settled.
Decode every mint, burn and freeze
Handled by Goldsky Turbo
The daily figures are built from events, so each one has to become a record with its amount, wallet, chain and block.
Every chain, and every event type the contract emits, has to be covered from the contract’s first block. A freeze event the decoder ignores leaves the frozen line wrong in every report after it.
With Goldsky, one Turbo Pipelines pipeline can decode your contract’s events on each chain with _gs_log_decode and combine them with UNION ALL, each row tagged with its chain and block.
Decode events on several chains (opens in a new tab)
Track the listed wallets’ balances
Handled by Goldsky Turbo
The issuer-held, frozen and lost figures are the balances of the wallets on your list, read whenever they change.
Each balance has to be read at the block where it changed, so the day’s figure is exact. Polling every listed wallet on a timer misses changes between polls and costs more as the list grows.
Your list can live in a Turbo Pipelines dynamic table, which lives in a Postgres database, and dynamic_table_check() keeps only events that touch a listed wallet. _gs_eth_call then reads that wallet’s balanceOf at the event’s block.
Watch wallets with dynamic tables (opens in a new tab)
Land the events and balances in your warehouse
Handled by Goldsky Turbo
The daily figures are built with SQL, so the events and balances need to sit where your analysts query.
Rows carry chain, block, time and transaction, so each day’s figure can be traced to the events behind it. A reorg (the chain replacing its newest blocks) can undo a recorded event, so the daily query applies corrections before it totals.
Turbo Pipelines can write the rows to S3 as Parquet files, partitioned by chain and date with partition_columns, for your warehouse to read. Reorg corrections arrive in the same stream as rows marked by the _gs_op column.
Write Parquet files to S3 (opens in a new tab)
Total each day per chain
Schedule A asks for each figure at each day’s close, per chain.
Your SQL sums mints and burns up to the close and takes each listed wallet’s last balance before it, chain by chain. The close time and time zone have to be fixed in writing, because a figure cut at a different hour won’t match the reserve side.
Keep the daily ledger for the weekly report
The weekly report is filed from these daily figures, and every later supply number has to agree with them.
Store each day’s figures once they’re final, along with the query that produced them. If a figure changes after filing, record the change and its reason too.