Skip to main content

Goldsky

Stablecoin redemption spike alerts

Talk to our team

What it is

Stablecoin redemption spike alerts tell an issuer when redemption requests in a single 24-hour period pass 10% of a coin’s outstanding supply; risk teams also call this redemption monitoring.

Under the OCC’s rule for payment stablecoin issuers, crossing that level means notifying the OCC within 24 hours, so treasury and compliance need to know as soon as it happens and have the figures ready.

Goldsky decodes every burn on every chain and streams it to your database, while the requests your redemption system logs before tokens are burned, the rolling 24-hour rule, the alert and the notice stay with your team.

You can build it two ways: stream every burn into your database with Turbo Pipelines and run the 24-hour rule there, or index burns in a hosted subgraph that keeps redemption totals and pushes each change to your backend.

Who it’s for

Payment stablecoin issuers and the platforms that issue coins for other brands, along with their treasury and compliance teams.

How a stablecoin redemption spike alert works

The diagram follows redemptions from holders burning tokens on the chain to your team’s notice to the OCC. Your setup may differ.

Goldsky, step 2: TurboDecode every burnRedemptions on every chain
Blockchains, step 1: Holders redeemTokens burned to cash out
Your business, step 5: Total the day’s requestsOver 10% of supply in 24 hours
Goldsky, steps 3–4: TurboStream to your databaseOne row per redemption
Your business, step 6: Notify the OCCWithin 24 hours of passing it
  • Goldsky

Ways to set up stablecoin redemption spike alerts

Streaming lands one row per burn in your database, where your SQL sums any 24-hour window across chains; the subgraph keeps redemption totals on each chain and pushes each change to your backend by webhook, which adds the chains together.

Usual setupOption 1: Stream to your database
Best for
Many chains, with the 24-hour rule in your own SQL
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 subgraph
Best for
A few EVM chains, totals pushed to your backend
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: Watch stablecoin redemptions by streaming burns to your database

A pipeline decodes every burn of your token on each chain and writes one row per redemption to your database. A query you schedule sums the last 24 hours against supply and alerts your team when the total passes 10%.

When to stream redemptions to your database

Your coin is on several chains, and you want the 24-hour rule in SQL you control, next to the supply and reserve figures it’s checked against.

What you’ll need

  • Goldsky Turbo
  • Your token’s contract address on each chain
  • A database for redemption rows
  • A scheduler for the 24-hour query, and an alerting channel
  • Your process for notifying the OCC

  1. Holders redeem tokens

    A holder cashes out by redeeming tokens with the issuer, and the redeemed tokens are burned.

    Each burn lowers supply on the chain where it happens, and a run on the coin shows up as many burns across chains at once. For a short time the newest blocks can still be rewritten, so a burn seen once isn’t final yet.

  2. Decode every burn

    Handled by Goldsky Turbo

    Each redemption has to become a record with its amount, chain, time and transaction before it can be counted.

    Every chain the coin is on has to be covered, with amounts kept at full precision. A chain left out makes the 24-hour total look smaller than it is.

    With Goldsky, one Turbo Pipelines pipeline can read your token’s burns on each chain, from its burn events or from the curated transfers dataset where the recipient is the zero address, and combine the chains with UNION ALL.

    Read burns from EVM sources (opens in a new tab)

  3. Stream each redemption to your database

    Handled by Goldsky Turbo

    The 24-hour rule is a query, so every redemption has to be a row in a database it can read.

    Rows need a stable ID, so a repeated delivery overwrites instead of counting twice. Carrying the supply at the burn’s block on each row gives the rule the figure it’s measured against.

    Turbo Pipelines writes each burn to a database table keyed on id, and _gs_eth_call can add the token’s totalSupply() at the same block to the row.

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

  4. Correct redemptions undone by a reorg

    Handled by Goldsky Turbo

    Sometimes a chain replaces its newest blocks (a reorg), and a burn you counted can disappear.

    The 24-hour total has to follow the chain, or a reorg can push it over the threshold on burns that didn’t happen.

    Reorg corrections come through Turbo Pipelines as updates and deletes, and a database sink with a primary_key applies them to the same rows.

    How reorgs reach your sinks (opens in a new tab)

  5. Check the rolling 24-hour total

    The rule is about a window, so something has to add up the last 24 hours again and again.

    Run a query on a schedule that sums the redemption requests your redemption system logged over the last 24 hours, checked against the burns across chains, divides by outstanding supply measured the way your policy and counsel set, and alerts your team when it passes 10%. The rule counts requests received, and burns can come later, so burns alone can miss a breach in progress. How often it runs sets how late you can hear about a breach.

  6. Notify the OCC within 24 hours

    Once redemptions pass the threshold, the issuer has 24 hours to tell the OCC.

    Treasury and compliance confirm the figures, then file the notice with the redemptions behind it. Waiting for the next daily report to spot the breach can use up most of that time.

What to know about streaming redemptions to your database

  • Goldsky lands the rows; the rolling 24-hour sum, the threshold and the alert run in your database and scheduler.
  • How soon you hear about a breach depends on how often your query runs.
  • Tables keyed on the row ID take reorg corrections as updates and deletes, so a burn a reorg undoes drops out of the sum.
  • The same rows support the notice: the query that fired can list every redemption behind it.

Option 2: Watch stablecoin redemptions with a hosted subgraph and webhooks

A subgraph on each chain indexes every burn and keeps running redemption totals in records you define, such as one per hour. A webhook sends each change to your backend, which adds up the last 24 hours across chains and alerts your team.

When to watch redemptions with a hosted subgraph

Your coin is on a few EVM chains, and you’d rather have totals kept in a hosted index and pushed to your backend than run a database for every redemption.

What you’ll need

  • Goldsky Subgraphs
  • Your token’s contract address and deployment block on each chain
  • A code repository for the schema and mappings
  • A backend endpoint that receives webhooks and runs the 24-hour rule
  • Your process for notifying the OCC

  1. Holders redeem tokens

    A holder cashes out by redeeming tokens with the issuer, and the redeemed tokens are burned.

    Each burn lowers supply on the chain where it happens, and a run on the coin shows up as many burns across chains at once. For a short time the newest blocks can still be rewritten, so a burn seen once isn’t final yet.

  2. Define the redemption records

    The subgraph has to know which events are burns and how to add them up.

    The schema sets the records, such as one per burn and one per hour of redemptions, and the mappings fill them in. Hourly records let your backend sum any 24 hours without reading every burn.

  3. Index every burn and keep the totals

    Handled by Goldsky Subgraphs

    Each burn has to be counted as soon as it’s indexed, so the totals stay current.

    Indexing starts at the contract’s deployment block, so redemption history is complete. A start block set too late leaves the totals short with no error.

    Goldsky Subgraphs runs your mappings on each chain, deployed with goldsky subgraph deploy, and keeps each index current as new blocks arrive.

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

  4. Push each change to your backend

    Handled by Goldsky Subgraphs

    Your backend needs to hear about new redemptions without querying every chain on a timer.

    Each change has to arrive with enough detail to tell a new burn from a rollback after a reorg (the chain replacing its newest blocks). A backend that treats a rollback as a new burn counts it twice.

    Subgraph webhooks send an INSERT, UPDATE or DELETE payload for each entity change, and each version carries a block_range that marks rollbacks.

    Set up subgraph webhooks (opens in a new tab)

  5. Check the rolling 24-hour total

    The rule is about a window, so something has to add up the last 24 hours again and again.

    Your backend sums the redemption requests your redemption system logged over the last 24 hours, checked against the burns across every chain, divides by outstanding supply measured the way your policy and counsel set, and alerts your team when it passes 10%. The rule counts requests received, and burns can come later, so burns alone can miss a breach in progress. If one chain’s webhooks stop arriving, the burn figures look smaller than they are, so watch for gaps too.

  6. Notify the OCC within 24 hours

    Once redemptions pass the threshold, the issuer has 24 hours to tell the OCC.

    Treasury and compliance confirm the figures, then file the notice with the redemptions behind it. Waiting for the next daily report to spot the breach can use up most of that time.

What to know about watching redemptions with a subgraph

  • Each chain has its own subgraph, so your backend adds the chains together for the 24-hour total.
  • Your mapping code decides how redemptions are bucketed, and changing it means deploying and indexing again.
  • The webhook sends every change, and a rollback after a reorg arrives as a change to the record’s block_range, which your backend has to apply.
  • The rule, the threshold and the alert run in your backend.

What you control

Your team
  • Check the rolling 24-hour total
  • Notify the OCC within 24 hours

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

Set up stablecoin redemption spike alerts 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