Goldsky

Reconcile tokenized and book-entry positions

Talk to our team

What it is

Reconciling tokenized and book-entry positions means checking, holder by holder, that the token balances on the chain match the book-entry or custody records the tokens mirror; it’s securities position reconciliation with a token on one side.

Transfer agents, tokenization platforms and custodian banks run it because either record can drift, through a transfer the books missed or a booking with no transfer behind it, and the official record has to be right.

Goldsky can rebuild every holder’s balance at the cutoff, compare it with the positions your transfer agent or custodian sends and flag each break; resolving it stays with whoever keeps the books.

How tokenized and book-entry positions are reconciled

The diagram follows one reconciliation from the cutoff you pick to the break your team resolves, and shows who does each step. Your setup may differ.

Pick a cutoffEnd of day, or any date you choose

ComposeStart the snapshotYour task launches a one-off pipeline

TurboLoad transfers to cutoffEvery transfer up to that block

Transfer agent or custodianSend book-entry positionsYour transfer agent or custodian reports

ComposeSum each holder’s balanceToken positions at the cutoff

ComposeCompare position by positionToken balances against book entries

Resolve the breakFixed with whoever keeps the books

ComposeFlag any breakMismatches reach your operations team

Goldsky
Your provider

How to reconcile tokenized and book-entry positions

A task that Goldsky hosts starts a one-off pipeline that loads every transfer of the token up to your cutoff, sums each holder’s balance, fetches the book-entry positions and compares them holder by holder. Breaks go to your operations team.

What you’ll need

Goldsky Compose
Goldsky Turbo
A transfer agent or custodian that can report book-entry positions at a cutoff
A database for the snapshot of token transfers
A mapping from each holder’s wallet to their book-entry account
An operations queue or alert endpoint for breaks

Pick the cutoff
Both records have to be compared at the same moment, so the reconciliation starts with an agreed cutoff.
Choose the cutoff, usually end of day, and the block on the token’s chain that matches it. If the books and the snapshot use different cutoffs, transfers in between show up as breaks.
Start the snapshot
Handled by Goldsky Compose
The token side is rebuilt fresh for each cutoff, so nothing needs to run between reconciliations.
The run starts a backfill bounded at the cutoff block and waits for it to finish. A backfill still running when the comparison starts reports holders with missing transfers.
With Goldsky, a Compose task can start a Turbo Pipelines job with turbo.createJob, poll it until it completes and delete it afterwards.
Manage pipelines from a task (opens in a new tab)
Load every transfer up to the cutoff
Handled by Goldsky Turbo
A holder’s balance at the cutoff is the sum of every transfer in and out of their wallet up to that block.
Load the token’s full transfer history from its first block to the cutoff block, with nothing after it. Missing early history understates every balance it touches.
Turbo Pipelines job mode runs the backfill once and exits, with the token address and a block_number bound in the source filter so the job stops at the cutoff.
Run a one-time backfill job (opens in a new tab)
Sum each holder’s balance at the cutoff
Handled by Goldsky Compose
The reconciliation compares positions, so the transfers become one balance per holder.
Add up credits less debits for each wallet and drop wallets with a zero balance. Mints and burns move to and from the zero address, which has to be left out of the holder list.
The job writes the transfers to the Postgres database behind your Compose app, and the task sums each holder’s credits and debits there with a SQL query, the same way Goldsky’s corporate-actions guide builds its holder snapshot.
Run SQL from a task (opens in a new tab)
Report book-entry positions at the cutoff
The other side of the reconciliation is the official record the token mirrors.
Your transfer agent or custodian reports each account’s position as of the same cutoff. Positions reported at a different time, or without an account reference you can map to a wallet, can’t be compared one to one.
Compare position by position
Handled by Goldsky Compose
Each holder’s token balance should equal their book-entry position.
Map each wallet to its account and compare the two balances, in the same units. A holder present on only one side is a break as much as a holder whose balances differ.
Compose reads the book-entry positions from your provider’s API with fetch, and each request and response is recorded in the task’s run alongside the comparison.
Make auditable requests with fetch (opens in a new tab)
Flag every break
Handled by Goldsky Compose
Each mismatch needs someone who can look at both records.
Send each break with the holder, both balances and the cutoff. A list of differences with no inputs means rebuilding the check before investigating it.
The same Compose task posts the breaks to your operations endpoint, and its run log keeps the snapshot, the positions it fetched and the result together.
How Compose logs each run (opens in a new tab)
Resolve the break
The official record has to be right, so every break ends with one side corrected.
Your team works with whoever keeps the books to find the transfer or booking one side missed. Fix the record that’s wrong; changing the token to match a booking error moves the problem instead of solving it.

What you control

Your team: Pick the cutoff
Resolve the break
Your providers: Transfer agent or custodian

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