Goldsky

Keep tokenized stocks backed one to one

Talk to our team

What it is

Keeping tokenized stocks backed one to one means checking that the tokens in circulation, on every chain they’re issued on, match the shares held in custody for them; issuers also call it proof of reserves for tokenized stocks.

Tokenized stock venues and tokenization platforms run the check because each token is a claim on one share, and a gap means some holders own tokens with no share behind them.

Goldsky records every mint and burn in your database, keeps the supply on each chain there and runs a scheduled task that compares supply with your custodian’s count, then alerts your team or pauses minting on a gap, while custody, the share count and resolving a break stay with you.

You can build it two ways: keep every mint and burn and the supply on each chain with Turbo Pipelines and check the totals with a scheduled Compose task, or have the Compose task read total supply on each chain over Edge RPC.

How tokenized stock supply is checked against shares in custody

The diagram follows supply from each mint or burn to the break your operations team resolves, with the custodian’s share count feeding the comparison, and shows who does each step. Your setup may differ.

Issuance platformMint or burn tokensYour issuance platform changes supply

TurboWrite supply per chainEvery mint and burn, and the running total

CustodianReport shares heldThe custodian counts the underlying

ComposeCompare supply to holdingsOn schedule, supply against the custody count

Resolve the breakYour ops team reconciles, then resumes

ComposeAlert and pause on gapsMinting can pause if your contract allows

Goldsky
Your provider

Ways to check tokenized stock supply against custody

A ledger of every mint and burn lets you trace a gap to the change that opened it, while reading total supply gives one current figure per chain and nothing to run but the task.

Usual setupOption 1: Supply ledger and check

Best for: Several chains, with every supply change on record
Products: Turbo Compose

Option 2: Scheduled supply check

Best for: A few chains, with no pipeline or database
Products: Compose Edge

Ways to check tokenized stock supply against custody
	Usual setupOption 1: Supply ledger and check	Option 2: Scheduled supply check
Best for	Several chains, with every supply change on record	A few chains, with no pipeline or database
Products	Turbo Compose	Compose Edge

Option 1: Keep tokenized stocks backed one to one with a supply ledger and scheduled check

Goldsky runs a pipeline that writes every mint and burn on each chain to your database and keeps the supply on each chain there, and a scheduled task compares those totals with your custodian’s share count, then alerts your team or pauses minting when they differ.

When to keep a supply ledger and check it on a schedule

The token is issued on several chains and you want every mint and burn on record, so a gap can be traced to the change behind it.

What you’ll need

Goldsky Turbo
Goldsky Compose
An issuance platform that mints and burns the tokens
A custodian or broker that reports the shares held over an API
Pause permission on the token contract for the task’s wallet, if the check should pause minting
An alerting endpoint your operations team watches
A database for the supply ledger

Mint or burn tokens
Supply changes when your issuance platform mints tokens for a buyer or burns them on a redemption.
Each mint should follow shares arriving in custody, and each burn shares leaving. When the two happen at different times, supply and custody differ for a while, and the check has to allow for that window.
Record every mint and burn
Handled by Goldsky Turbo
A full record of supply changes on each chain shows which change opened a gap, as well as whether there is one.
Every mint and burn, on every chain the token is issued on, has to land once with its amount, chain and transaction. A chain left out makes supply look lower than it is, which can hide a real gap.
A Turbo Pipelines pipeline can pick mints and burns out of the token’s transfers (those from or to the zero address) and write each to your database keyed on its id, with reorg corrections applied to the same rows.
Track supply from mints and burns (opens in a new tab)
Keep the supply on each chain
Handled by Goldsky Turbo
The comparison needs one supply figure per chain, kept current between checks.
Each mint has to add to its chain’s supply and each burn take away, and a mint or burn a reorg removes has to come back out. A bridged token can be counted twice, once where it’s locked and once where it’s minted, so your rules have to say which side counts when the chains are added together.
The same pipeline can write mints as positive amounts and burns as negative ones to Turbo Pipelines’ postgres_aggregate sink, which keeps running totals in a Postgres database: group by token and chain with sum on the amount, and keep the _gs_op column so a mint or burn a reorg deletes comes off the total.
Keep running totals in your database (opens in a new tab)
Report the shares held
The other side of the check is how many shares the custodian holds for token holders.
Your custodian or broker reports the share count for each stock, usually over an API, with the time it applies to. A count with no time can’t be compared fairly with supply that changed since.
Compare supply with the shares held
Handled by Goldsky Compose
The check answers one question on a timer: does every token have a share behind it?
Add the chains together and compare the total with the custodian’s count for each stock, allowing for mints and burns still in transit under your rules. Figures taken at different moments produce false breaks, which teach the team to ignore alerts.
A Compose task on a cron trigger can fetch the supply totals from your database’s API and the custodian’s count with fetch, compare them, and log every input with the result.
Set up cron triggers (opens in a new tab)
Alert and pause on a gap
Handled by Goldsky Compose
A gap needs a person straight away, and minting more tokens while it’s open can make it bigger.
Send an alert with the stock, both figures and the difference, and stop new minting until someone has checked. A pause works only if the token contract has one and the checking wallet is allowed to use it.
Goldsky Compose can post the alert to your endpoint and, when the token gives the task’s wallet a pause role, call the pause function in the same run. Durable execution carries the pause through a restart.
Learn about task wallets (opens in a new tab)
Resolve the break
Someone has to find out why supply and custody differ and fix it before minting resumes.
Your operations team traces the gap to a mint, burn or custody movement, corrects the side that’s wrong and lifts the pause. Keep each break and its cause on record, because auditors and the custodian will ask for that history.

What to know about a supply ledger with a scheduled check

The ledger holds each mint and burn with its transaction, so a break can be traced to the change that caused it.
Supply is kept per chain as mints and burns arrive, and corrected when a reorg removes one.
The check runs on a timer, so a gap shows at the next run, and the custodian’s count is as fresh as its last report.
A pause happens only if the token contract has one and the task’s wallet holds the role.

Option 2: Keep tokenized stocks backed one to one with a scheduled supply check

A TypeScript task that Goldsky hosts runs on a timer, reads total supply from the token contract on each chain, compares it with your custodian’s share count, and alerts your team or pauses minting on a gap.

When to read total supply on a schedule

The token is on a few EVM chains, one current supply figure per chain is enough, and you’d rather run one TypeScript codebase than a pipeline and a database.

What you’ll need

Goldsky Compose
Goldsky Edge
An issuance platform that mints and burns the tokens
A custodian or broker that reports the shares held over an API
Pause permission on the token contract for the task’s wallet, if the check should pause minting
An alerting endpoint your operations team watches

Mint or burn tokens
Supply changes when your issuance platform mints tokens for a buyer or burns them on a redemption.
Each mint should follow shares arriving in custody, and each burn shares leaving. When the two happen at different times, supply and custody differ for a while, and the check has to allow for that window.
Run the check on a schedule
Handled by Goldsky Compose
A timer makes sure supply is checked even when nobody is looking.
Choose an interval that fits how often tokens are minted and burned and how often the custodian reports. Checking far more often than the custodian reports compares new supply with an old count.
With Goldsky, the check is a Compose task on a cron trigger, and every read, comparison and alert in a run is logged together.
Set up cron triggers (opens in a new tab)
Read total supply on each chain
Handled by Goldsky Edge
The token contract’s total supply is the number of tokens in circulation on that chain.
Read it at a stated block on each chain, so the figure can be repeated and compared. A read from a node that has fallen behind returns an old supply without any error.
Edge RPC serves eth_call for totalSupply() at a block number or tag, and checks responses across providers so a lagging one doesn’t return stale data.
Read contract state with eth_call (opens in a new tab)
Report the shares held
The other side of the check is how many shares the custodian holds for token holders.
Your custodian or broker reports the share count for each stock, usually over an API, with the time it applies to. A count with no time can’t be compared fairly with supply that changed since.
Compare supply with the shares held
Handled by Goldsky Compose
The check answers one question on a timer: does every token have a share behind it?
Add the chains together and compare the total with the custodian’s count for each stock, allowing for mints and burns in transit under your rules. Figures taken at different moments produce false breaks.
The Compose task fetches the custodian’s count with fetch, which retries failed reads, and keeps both figures in the run’s log beside the result.
Make logged HTTP requests (opens in a new tab)
Alert and pause on a gap
Handled by Goldsky Compose
A gap needs a person straight away, and minting more tokens while it’s open can make it bigger.
Send an alert with the stock, both figures and the difference, and stop new minting until someone has checked. A pause works only if the token contract has one and the checking wallet is allowed to use it.
Goldsky Compose can post the alert to your endpoint and, when the token gives the task’s wallet a pause role, call the pause function in the same run. Durable execution carries the pause through a restart.
Learn about task wallets (opens in a new tab)
Resolve the break
Someone has to find out why supply and custody differ and fix it before minting resumes.
Your operations team traces the gap to a mint, burn or custody movement, corrects the side that’s wrong and lifts the pause. Keep each break and its cause on record, because auditors and the custodian will ask for that history.

What to know about checking total supply on a schedule

Each run sees one supply figure per chain, with no history of the mints and burns behind it.
There’s no database to keep; the timer and the task are all that run.
Tracing a break to its cause needs another source, such as your issuance platform’s records.

What you control

Your team: Resolve the break
Your providers: Issuance platform
Custodian

Questions and answers

Are tokenized stocks backed by real shares?

Some are and some aren’t; it depends on how the issuer builds the token. A backed token is issued against a share that a custodian or broker holds, one token per share, while other products give exposure to the price with no share held for each token. For a backed token, the test is whether supply on every chain matches the shares in custody, which the issuer can check on a schedule and publish or alert on.

Security and deployment

SOC 2 Type IIIndependently audited security controls.
Dedicated infrastructureSingle-tenant options for production workloads.
Data residencyCloud, on-premises or co-located.

Use cases built the same way