Who needs Basel cryptoasset disclosure data?

Global and regional banks that hold or issue cryptoassets, and the platforms that issue tokens for banks.

Goldsky

Basel cryptoasset disclosure data

Talk to our team

What is Basel cryptoasset disclosure data?

Basel cryptoasset disclosure data is the period-end figures a bank takes from the chain for the disclosure framework the Basel Committee published in July 2024: how much of each cryptoasset it held at the reporting date.

The framework had an implementation date of January 1, 2026, and its standard tables and templates ask for qualitative information on cryptoasset activities and figures on the capital and liquidity requirements for those exposures, so holdings have to be read at the right moment before they’re sorted into the standard’s groups.

Goldsky reads your balances at the block at each period end, or at every change if you stream them; your team classifies each exposure and completes the tables.

You can gather Basel cryptoasset disclosure data two ways: stream your holdings into your warehouse with Turbo Pipelines, or read them at each reporting date with the Feeds Blocks API and Edge RPC.

How Basel cryptoasset disclosure data is gathered

The diagram follows your holdings from each change on the chain to the disclosure your finance team completes, and shows who does each step. Your setup may differ.

TurboRead balances at each changeHoldings at that block

Holdings changeTokens move in and out of your wallets

Set the reporting datePeriod end for your disclosures

TurboKeep the historyBeside your other regulatory data

Total at the dateLatest figures before the date, by asset

Classify each exposureInto the Basel standard’s groups

Complete the disclosureTables and templates, from your figures

Goldsky

Ways to gather Basel cryptoasset disclosure data

Streaming keeps a history of holdings you can total at any period end; reading at the reporting date runs only when you report, and a new date means another read.

Usual setupOption 1: Stream balances

Best for: A full history, totaled at any period end
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: Read balances at a date

Best for: A known set of wallets and tokens, read at each reporting date
Products: Feeds Edge
What you run: Your own client code
What you write: JSON-RPC calls, and the decoding of what comes back
Where your data lives: Read from the chain
How results reach you: Returned when you call

Ways to gather Basel cryptoasset disclosure data
	Usual setupOption 1: Stream balances	Option 2: Read balances at a date
Best for	A full history, totaled at any period end	A known set of wallets and tokens, read at each reporting date
Products	Turbo	Feeds Edge
What you run	The destination: your database, queue or bucket, or a Postgres database Goldsky hosts	Your own client code
What you write	Pipeline YAML and SQL; TypeScript transforms when needed	JSON-RPC calls, and the decoding of what comes back
Where your data lives	In your own database or systems	Read from the chain
How results reach you	Pushed to you	Returned when you call

Option 1: Gather Basel cryptoasset disclosure data by streaming balances to your warehouse

A pipeline reads your holdings at the block of every change and keeps the history in your warehouse, so your finance team can total and classify them at any reporting date.

When to stream holdings

You hold cryptoassets across many wallets or chains, or report at several dates, and want a full history to total at any period end.

What you’ll need

Goldsky Turbo
Your wallet addresses and, if you issue a token, its contract addresses
A warehouse, or an object store it reads from
Your reporting tools
Your bank’s classification of each cryptoasset under the Basel standard

Let holdings change
Tokens move in and out of your wallets, and if you issue a token, its supply changes with each mint and burn.
Every change is recorded in a block. A disclosure at quarter end has to reflect every change up to its cutoff.
Read balances at each change
Handled by Goldsky Turbo
A figure read at the block of each change gives a history you can total at any date later.
Each time one of your wallets moves, or the token’s supply changes, the new figure is read at that block. A figure read days later can’t be tied to the moment it describes.
A Turbo Pipelines transform can call _gs_eth_call with balanceOf(address)(uint256) or totalSupply()(uint256) at each event’s block, so every row carries the figure as it stood then.
Read state at a block in SQL (opens in a new tab)
Keep the history beside your regulatory data
Handled by Goldsky Turbo
Your finance team works from data it controls, next to the other figures in the disclosure.
Each row carries the wallet or token, chain, block and time. Corrections after a reorg arrive as rows of their own, and your warehouse applies them.
With Goldsky, the pipeline can write each row as Parquet to an S3-compatible bucket that your warehouse reads, partitioned by date.
Write rows to S3 as Parquet (opens in a new tab)
Set the reporting date
Disclosures are made as of a date, usually quarter end.
Your finance team fixes the date and the time on it that counts as the cutoff, the same on every chain. Different cutoffs on different chains make the totals disagree with each other.
Total at the date
Each figure is the latest value at or before the cutoff, added up by asset.
Your team takes the last balance or supply before the cutoff for each wallet and token and totals them by asset. A wallet that didn’t change that quarter still counts, at its last value.
Classify each exposure
The Basel standard treats cryptoassets by group, and the disclosure reports them that way.
Your team decides which group each token belongs to, such as whether a stablecoin meets the criteria for the preferential Group 1b treatment, and applies it to the totals. The chain gives you amounts; the classification is your bank’s judgment.
Complete the disclosure
The disclosure is your bank’s statement under the Basel Committee’s framework.
Your finance and regulatory teams fill in the standard tables and templates, including the capital and liquidity figures for your cryptoasset exposures, and publish them. The data gives you the onchain amounts; it doesn’t decide what the disclosure must contain or make it complete.

What to know about streaming holdings

Goldsky records balances as they change; classifying exposures and the capital figures stay with your bank.
Totals at a reporting date are queries in your warehouse.
Reorg corrections arrive as records your warehouse applies.

Option 2: Gather Basel cryptoasset disclosure data by reading balances at the reporting date

At each reporting date, your job looks up the block at the cutoff on each chain, reads your balances at that block, and totals them.

When to read holdings at the reporting date

You hold or issue a known set of tokens on EVM chains and need figures only at each reporting date.

What you’ll need

Goldsky Feeds
Goldsky Edge
Your wallet addresses and token contract addresses
A scheduled job of yours that runs the reads
A warehouse or database for the results
Your bank’s classification of each cryptoasset under the Basel standard

Let holdings change
Tokens move in and out of your wallets, and if you issue a token, its supply changes with each mint and burn.
Every change is recorded in a block. A disclosure at quarter end has to reflect every change up to its cutoff.
Set the reporting date
Disclosures are made as of a date, usually quarter end.
Your finance team fixes the date and the time on it that counts as the cutoff, the same on every chain. Different cutoffs on different chains make the totals disagree with each other.
Find the block at the cutoff
Handled by Goldsky Feeds
Chains count in blocks, not dates, so the cutoff has to become a block number on each chain.
Use the last block at or before the cutoff on each chain. A block after it includes changes from the next period.
Goldsky’s Blocks feed turns a time into a block: sorted by number_desc with one row, it returns the newest block at or before that time.
Look up a block by time (opens in a new tab)
Read balances and supply at that block
Handled by Goldsky Edge
The figures at the cutoff block are what you held and issued at the reporting time.
Every wallet and token is read at the same block on its chain. Reading at the chain’s newest block mixes in later changes.
Over Edge RPC, eth_call runs balanceOf or totalSupply against the cutoff block and returns the figure as it stood then.
Read contract state at a block (opens in a new tab)
Total and store the figures
The disclosure reports totals by asset, and you’ll need to show where they came from.
Your job sums the results by asset and stores them with the block numbers it read. Keeping the blocks lets anyone rerun the reads and get the same figures.
Classify each exposure
The Basel standard treats cryptoassets by group, and the disclosure reports them that way.
Your team decides which group each token belongs to, such as whether a stablecoin meets the criteria for the preferential Group 1b treatment, and applies it to the totals. The chain gives you amounts; the classification is your bank’s judgment.
Complete the disclosure
The disclosure is your bank’s statement under the Basel Committee’s framework.
Your finance and regulatory teams fill in the standard tables and templates, including the capital and liquidity figures for your cryptoasset exposures, and publish them. The data gives you the onchain amounts; it doesn’t decide what the disclosure must contain or make it complete.

What to know about reading holdings at the reporting date

Your job makes the calls and the totals; Goldsky serves the block lookup and the reads.
You get figures at each date only; if you need another date, a new read works for any past block.
Reading at a block that’s already final means no reorg corrections to apply.

How to keep evidence for Basel stablecoin classification

Keep the supply, redemption and price record that supports a bank’s Basel classification of each stablecoin it holds.

A pipeline loads each stablecoin’s mint and burn history from its first block and keeps it current in your warehouse. Your risk team tracks supply and redemptions there, next to the issuer’s reserve reports and market prices, and runs the bank’s tests.

What you’ll need

Goldsky Turbo
The contract address of each stablecoin you hold, on every chain it’s issued on
A warehouse, or an object store it reads from
The issuer’s reserve reports or attestations
Market prices for each stablecoin from a data vendor
Your bank’s classification method under the Basel standard

List the stablecoins you hold or plan to buy
Each stablecoin is classified on its own, and the standard asks for an assessment before the bank buys one.
Your risk team lists every stablecoin the bank is exposed to, with each chain it’s issued on and its contract address there. A chain left off the list leaves part of the supply out of every figure that follows.
Record every mint and burn
Handled by Goldsky Turbo
Mints and burns show how much is outstanding and how the issuer has met redemptions over time.
Each issuance and redemption is recorded with its amount, chain, block and time, from the token’s first block to today. A history that starts late can’t show how the stablecoin behaved in past periods of stress.
A Turbo Pipelines source set to start_at: earliest reads a chain’s history from the start and carries on with new blocks, and _gs_log_decode with the token’s ABI turns its raw logs into mint and burn rows in SQL.
Decode logs with SQL functions (opens in a new tab)
Keep the history beside your risk data
Handled by Goldsky Turbo
Your risk team works from data the bank controls, next to the other inputs to its tests.
Each row carries the token, chain, block and time, so any supply figure can be traced back to the chain. Corrections after a reorg (the chain replacing its newest blocks) arrive as rows of their own, and your warehouse applies them.
With Goldsky, the pipeline can write each row as Parquet to an S3-compatible bucket that your warehouse reads, partitioned by date.
Write rows to S3 as Parquet (opens in a new tab)
Set supply against the issuer’s reserves
Reserves are held off the chain, so their value and make-up come from the issuer’s published reports.
The issuer publishes reports on the assets backing the stablecoin at a date, examined by an accounting firm. Your team compares them with the supply onchain at the same date, since the standard asks for reserves worth at least the peg value of every token outstanding, at all times.
Track the market price against the peg
The preferential treatment depends on the stablecoin keeping a stable relationship to the asset it tracks.
Your data vendor supplies prices from the markets where the stablecoin trades, over the same periods as your supply history. Gaps in the price series weaken any test run on it.
Run the tests and keep the file
The bank decides the classification, and its supervisor can ask to see how it got there.
Your risk team runs the redemption and basis risk tests on these series, records the classification and keeps the data, method and results together. The data shows what happened; whether a stablecoin qualifies is the bank’s judgment, and its supervisor can override it.