Stablecoin mint and redemption monitoring
What is stablecoin mint and redemption monitoring?
Stablecoin mint and redemption monitoring is recording every mint and every burn of your token, on each chain it’s issued on, as they happen; engineers call these mint and burn events.
Issuers, issuance platforms and custodian banks run it because outstanding supply, the reserves behind it and every report on them start from that record.
Goldsky’s Turbo Pipelines decode each mint and burn, deliver it to your database or message queue and keep supply per chain in your database, while minting and booking each event stay with your treasury team.
You can build it two ways: stream every mint and burn into your own database or message queue with Turbo Pipelines, or index them in a hosted subgraph on each chain that you query over GraphQL.
Who uses stablecoin mint and redemption monitoring?
Stablecoin issuers, the platforms that issue coins for other brands, and custodian and crypto-native banks that mint and redeem tokens for their clients.
How stablecoin mint and redemption monitoring works
The diagram follows client funds from the moment they land in your reserve account, through the mint and a later redemption on the chain, to the entry your treasury team books. Your setup may differ.
Ways to monitor stablecoin mints and redemptions
A pipeline lands every mint and burn in a database or queue you run and keeps supply per chain in your database; a subgraph keeps the events and a running supply in a hosted index, one per chain.
- Best for
- Every event on many chains, in your own database or queue
- 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
- Best for
- A few EVM chains, queried from a hosted API
- 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
| Usual setupOption 1: Stream to your database | Option 2: Hosted subgraph | |
|---|---|---|
| Best for | Every event on many chains, in your own database or queue | A few EVM chains, queried from a hosted API |
| 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 |
Receive the client’s funds
A mint starts when a client sends dollars to buy tokens, and those dollars become the reserves behind them.
Treasury confirms the funds have settled in the reserve account before any tokens are created. Minting against funds that haven’t arrived puts tokens in circulation with nothing behind them.
Mint the tokens
New tokens are created by calling the token’s contract, through an issuance platform or from a contract you run yourself.
The mint goes to the client’s wallet, on the chain they asked for, for the amount that was funded. Each mint needs a reference your treasury can tie back to the client’s payment, or the books can’t say which dollars sit behind which tokens.
Record mints and redemptions on each chain
Mints add to supply on the chain where they happen, and redemptions take it away when holders burn tokens to cash out.
Each chain records only its own mints and burns, so no single chain shows the whole supply. For a short time the newest blocks can still be rewritten, so an event seen once can still change.
Decode every mint and burn
Handled by Goldsky TurboThe chain stores events as encoded logs, so each one has to become a readable record with its amount, wallet, chain and transaction.
Every chain your token is on has to be covered, from the contract’s first event if you need history. A chain left out, or a contract upgrade nobody updated the decoder for, leaves supply short without any error.
With Goldsky, one Turbo Pipelines pipeline can read your contract’s logs on each chain, decode them with
Decode custom contract events (opens in a new tab)_gs_log_decodeand combine the chains withUNION ALL, tagging each row with its chain. A standard ERC-20 token can use the curated transfers dataset instead, where a mint is a transfer from the zero address and a burn is a transfer to it.Deliver each event to your database or queue
Handled by Goldsky TurboTreasury and reporting systems need the events where they already work: as rows in a database, or as messages on a queue.
Each event needs a stable ID, because delivery can repeat after a restart and an event booked twice overstates supply. Whatever reads a queue has to check that ID before acting.
Turbo Pipelines writes each event to a database table keyed on its
Set up the Kafka sink (opens in a new tab)id, or publishes it to a Kafka topic with the operation in adbz.opheader, so consumers can tell a new event from a correction.Correct events undone by a reorg
Handled by Goldsky TurboSometimes a chain replaces its newest blocks (a reorg), and a mint or burn you recorded can disappear.
Your records have to follow the chain when that happens, or supply includes tokens that were never issued. Keeping booking separate from the raw events lets a correction land before it reaches the ledger.
Reorg corrections come through Turbo Pipelines as updates and deletes. A database sink with a
How reorgs reach your sinks (opens in a new tab)primary_keyapplies them to the same rows, and a Kafka consumer receives the correction messages and applies them itself.Keep supply per chain
Handled by Goldsky TurboSupply is mints minus burns, and finance needs it per chain and in total.
Burns count as negative amounts, with the token’s decimals applied the same way on every chain. A chain the pipeline doesn’t read is missing from the total without any error.
Turbo Pipelines’
Keep running totals in your database (opens in a new tab)postgres_aggregatesink keeps a runningsumper chain in a table in your database, updated as each event arrives and corrected when a reorg removes one.Pay the redeeming client
A redemption is finished when the client has their money back, not when the tokens are burned.
Your reserve bank sends the payout by wire, or over the local payment rail for the token’s currency, to the bank account the client registered. Keep the payout reference with the burn it settles, because those two records are what the ledger and the reserve report tie together.
Book each event in your ledger
The pipeline’s record says what happened on the chain; the ledger records what it means for the books.
Treasury books each mint and redemption once, against the client payment or payout it belongs to, and checks supply per chain against the ledger. If the two disagree, the difference has to be found before the next reserve report.
What to know about streaming mint and burn events
- Goldsky runs the pipeline and keeps supply per chain; you own the database or queue it writes to.
- Events are pushed to you as blocks arrive, so nothing in your systems polls the chain.
- A database table with a primary key takes reorg corrections as updates and deletes, and supply drops a mint or burn a reorg removes; queue consumers receive correction messages and apply them.
- Delivery is at least once, so whatever reads the events checks each event’s ID before booking it.
Receive the client’s funds
A mint starts when a client sends dollars to buy tokens, and those dollars become the reserves behind them.
Treasury confirms the funds have settled in the reserve account before any tokens are created. Minting against funds that haven’t arrived puts tokens in circulation with nothing behind them.
Mint the tokens
New tokens are created by calling the token’s contract, through an issuance platform or from a contract you run yourself.
The mint goes to the client’s wallet, on the chain they asked for, for the amount that was funded. Each mint needs a reference your treasury can tie back to the client’s payment, or the books can’t say which dollars sit behind which tokens.
Record mints and redemptions on each chain
Mints add to supply on the chain where they happen, and redemptions take it away when holders burn tokens to cash out.
Each chain records only its own mints and burns, so no single chain shows the whole supply. For a short time the newest blocks can still be rewritten, so an event seen once can still change.
Define the mint and burn records
A subgraph needs to know which contract events count as mints and burns, and what to store for each.
The schema sets the records, such as one per event and one for each chain’s supply, and the mappings are the code that fills them in. A token that mints by transferring from the zero address needs mappings that read its transfers, since it has no separate mint event.
Index every mint and burn from the first block
Handled by Goldsky SubgraphsSupply is the sum of every mint and burn since the contract was deployed, so indexing starts at that block.
Each event runs through your mappings, which add it to the running supply, and new blocks are added as they arrive. A start block set too late skips early mints and leaves supply short with no error.
You deploy the subgraph to Goldsky Subgraphs with
Deploy a subgraph to Goldsky (opens in a new tab)goldsky subgraph deploy, once per chain, and it keeps each index current as new blocks arrive.Query mints, burns and supply
Handled by Goldsky SubgraphsTreasury systems read the records by sending queries to an endpoint.
Supply data usually isn’t meant for everyone, so the endpoint should require a key. Your systems query each chain’s endpoint and add the results up for a cross-chain total.
Every subgraph in Subgraphs gets a hosted GraphQL endpoint, and you can turn on the private one so each request needs an API token in the
Set up private endpoints (opens in a new tab)Authorizationheader.Push each change to treasury, rollbacks included
Handled by Goldsky SubgraphsBooking systems need to hear about new events, and about events a reorg (the chain replacing its newest blocks) has undone.
A receiving endpoint has to tell a new record from a rollback and ignore repeats. Booking a rolled-back mint leaves supply higher than the chain shows.
Subgraph webhooks send an
Set up subgraph webhooks (opens in a new tab)INSERT,UPDATEorDELETEpayload for each entity change, and each version carries ablock_range, so your code can tell a reorg rollback from a new event.Pay the redeeming client
A redemption is finished when the client has their money back, not when the tokens are burned.
Your reserve bank sends the payout by wire, or over the local payment rail for the token’s currency, to the bank account the client registered. Keep the payout reference with the burn it settles, because those two records are what the ledger and the reserve report tie together.
Book each event in your ledger
The index says what happened on the chain; the ledger records what it means for the books.
Treasury books each mint and redemption once, against the client payment or payout behind it, and checks the cross-chain supply against the ledger. A difference left unexplained turns up again in the next reserve report.
What to know about indexing mints and burns in a subgraph
- Each chain needs its own subgraph, so a cross-chain total means querying each one and adding them up.
- Your mapping code decides what’s stored, including the running supply, and changing it means deploying and indexing again.
- Your systems pull from the GraphQL endpoint, and webhooks can push each change if you need them.
- Goldsky hosts the index and the endpoint; booking events in your ledger stays in your code.
Related jobs
Decide what counts toward the threshold
The Act measures a stablecoin’s consolidated total outstanding issuance, so the issuer has to know which tokens that total includes.
Your counsel decides which chains, contracts and wallets count, for example whether tokens the issuer holds itself are outstanding. A total built on a different reading than the one your regulator applies can put the threshold date in the wrong place.
Start from supply per chain
Handled by Goldsky TurboOutstanding issuance changes only when tokens are minted or burned, and the supply per chain your pipeline keeps already adds those up as they happen.
The check is only as complete as that record. Every chain the coin is on has to be in it from the contract’s first block, and a chain added later has to join before its first mint, or the total comes out short without any error.
Turbo Pipelines can keep the running totals from its
Keep running totals in Postgres (opens in a new tab)postgres_aggregatesink in the Postgres database behind your Compose app, so the scheduled task reads them where they land, already corrected when a reorg (the chain replacing its newest blocks) removes a mint or burn.Check the total against the threshold
Handled by Goldsky ComposeThe threshold applies to the stablecoin as a whole, so the chains have to be added together and compared on a schedule.
Each check adds up the per-chain totals by your counsel’s rules and compares the result with $10 billion and with the warning levels below it. Keep each check’s result, so the trend toward the threshold can be shown later.
With Goldsky, a Compose task on a cron trigger reads the per-chain totals with
Query your app’s database (opens in a new tab)ctx.db.queryand applies your warning levels; each query is logged on the run.Warn your team before the threshold
Handled by Goldsky ComposeReaching the threshold starts the clock, so the issuer needs time to plan before it happens.
Send warnings at the levels you agreed to people who can act, with the total and each chain’s share. A warning sent only when the threshold is crossed leaves no time to prepare.
The same Compose task posts the figures to your alerting endpoint with
Make auditable HTTP requests (opens in a new tab)ctx.fetch, and the request and its response are recorded on the run.Record the date the threshold is reached
The 360 days to move to federal oversight, or the stop on new issuance, run from the day the stablecoin passes $10 billion, so that date has to be provable.
Keep the date, the total and the check that found it, along with the per-chain figures behind it. Which path to take, and whether to seek a waiver, is the issuer’s decision with its regulators.
What you control
- Your team
- Receive the client’s funds
- Book each event in your ledger
- Your providers
- Issuance platform
- Reserve bank
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
- Proof of reserves for stablecoinsKeep a per-chain record of mints, burns and supply, and check it against reserves.
- Continuous proof of reservesCompare onchain supply with reported reserves on a schedule, then publish the ratio or alert on a gap.
- Daily stablecoin supply by chain for PS-01 reportsKeep the daily per-chain supply, issued, redeemed, issuer-held, frozen and lost figures that feed the weekly OCC PS-01 report.
- Month-end stablecoin supply for reserve reportsProduce the month-end supply across all chains that the monthly reserve report and its examination need.
- Stablecoin redemption spike alertsAlert when redemption requests in a single 24-hour period pass 10% of a brand’s outstanding issuance, the point at which the OCC must be told within 24 hours.
- MiCA daily usage cap for stablecoinsTrack the quarterly average of daily transactions and their value against the 1M transactions and €200M a day limits, and warn well before an issuer must stop issuing.
- Supply data for stablecoin issuance platformsGive an issuance platform one view of supply across every coin and chain it runs.
- Stablecoin depeg and manipulation alertsAlert the issuer when its coin trades off peg in its own pools or pool activity looks like manipulation, on every chain it runs on.
- Tokenized money market funds in stablecoin reservesTrack stablecoin reserves held as tokenized money market fund shares and check them against the reserve record.
Use cases built the same way
- Onchain shareholder register for transfer agentsKeep a transfer agent’s official register of a tokenized fund or stock in step with onchain transfers.
- Authorize and capture stablecoin paymentsHold a buyer’s stablecoins in an escrow contract at checkout, capture them to the merchant as orders ship, void what can’t be filled and refund after capture.
- Programmable escrow for B2B stablecoin paymentsHold a buyer’s stablecoin payment until delivery, a milestone or a deadline, then release it to the seller or refund the buyer.
- Cross-chain transfer trackingSee every cross-chain stablecoin transfer as settled, in flight or stalled, and catch the stuck ones.
Monitor stablecoin mints and redemptions 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.
Robinhood
HyperEVM
Arc
Solana
Ethereum
Polymarket
Base
Tempo
Bitcoin
