Goldsky

Stablecoin depeg and manipulation alerts

Talk to our team

What it is

Stablecoin depeg alerts tell an issuer when its coin trades away from its peg on decentralized exchanges (DEXs), or when trading in its pools looks like an attempt to push the price.

Stablecoin issuers and issuance platforms watch for this because an off-peg price can lead holders to redeem, and the team needs time to check liquidity before that happens.

Goldsky decodes every swap in your coin’s pools, writes it to your database and sends a webhook for each trade outside your price band, while the rules about volume over time and the response stay with your team.

How stablecoin depeg alerts work

The diagram follows trades from your coin’s DEX pools to your team acting on an alert, and shows who does each step. Your setup may differ.

TurboDecode each swapPool, amounts and implied price

Trades hit the poolsSwaps in your coin’s DEX pools

TurboWrite every swapRows in your database

TurboFlag off-peg tradesSwaps outside your band, sent by webhook

Watch flow by windowVolume and net flow against your limits

Act on the alertYour team checks liquidity and redemptions

Goldsky

How to set up stablecoin depeg alerts

Goldsky runs a pipeline that decodes every swap in your coin’s DEX pools, writes each one to your database and sends a webhook for any swap that trades outside your band. Your team watches volume and net flow over time from the stored rows.

What you’ll need

Goldsky Turbo
The list of DEX pools that trade your coin
A price band you set around the peg
A database for the swap rows
A webhook endpoint that reaches your on-call team
Your limits for volume and net flow over a time window

Trades hit your coin’s pools
A DEX pool sets the price of your coin by the trades made against it, so that’s where a depeg shows first.
Each trade is a swap recorded in a block on the chain. Some pools are small enough that one large swap moves the price a long way, which is why every pool that trades your coin belongs on the list.
Decode each swap
Handled by Goldsky Turbo
A raw swap record is encoded, so it has to be read into pool, amounts and price before anyone can judge it.
Each swap’s amounts in and out give the price it traded at. Pools built on different exchange designs record swaps differently, so each design needs its own decoding, and a pool you can’t decode is one you can’t watch.
In Turbo Pipelines, _gs_log_decode() reads Swap events with the pool contract’s ABI, and the same SQL can work out the implied price from the decoded amounts.
Decode logs with an ABI (opens in a new tab)
Write every swap to your database
Handled by Goldsky Turbo
Patterns over time, like heavy one-way selling, only show up when every swap is kept.
Each swap is stored once with pool, direction, amounts, price and block, and corrected if a reorg (the chain replacing its newest blocks) undoes it. Repeated rows inflate volume and can raise a false alarm.
Goldsky writes each swap to a database table keyed on its id, so a repeated delivery overwrites the same row and reorg corrections update or delete it.
How repeats and reorgs reach your sinks (opens in a new tab)
Flag swaps outside your price band
Handled by Goldsky Turbo
A single trade far from the peg is the earliest sign something is wrong, so it should reach a person right away.
The rule looks at one swap at a time: is its price outside the band you set? The alert goes out when the swap is first seen, not once it’s final, so your endpoint has to handle a correction for a swap that a reorg undid.
A second SQL transform in Turbo Pipelines keeps only swaps whose implied price falls outside your band and sends each one to a webhook sink, which retries until your endpoint accepts it.
Set up the webhook sink (opens in a new tab)
Watch volume and net flow over time
Manipulation often looks like steady pressure across many trades, which no single swap shows.
Your database sums volume and net flow per pool over a rolling window and compares them with your limits. These rules look across many rows and across time, so they run in your own scheduled queries.
Act on the alert
An alert is only useful if someone with authority looks at it and decides what to do.
Your team checks liquidity, redemptions and the pools involved, and follows the playbook you agreed in advance. Deciding who acts at night or on a weekend before the first alert saves the time it takes to find them.