Skip to main content

Goldsky

Investor statements from a tokenized register

Talk to our team

What it is

Investor statements from a tokenized register show each investor what they held at the end of a month or quarter and what it was worth, built from the token’s own transfer history.

Transfer agents, asset managers and private credit funds send them because investors and auditors expect a statement that matches the register on a fixed date.

Goldsky finds the last block of the period and gives you every transfer up to it; summing holdings, valuing them at the period NAV and sending statements stay with your team.

You can build investor statements two ways: copy every transfer up to the closing block into your warehouse with a one-time Turbo Pipelines job, or query a Goldsky subgraph for each holder’s balance at that block.

Who it’s for

Transfer agents, asset managers and private credit funds that report holdings to investors in a fund or note issued as a token.

How investor statements are built from a tokenized register

The diagram follows one reporting period from its close to the statements in your investor portal, and shows who does each step. Your setup may differ.

Your business, step 1: Close the periodMonth or quarter end, as the fund sets
Goldsky, step 2: FeedsFind the closing blockThe last block at or before period end
Your business, step 4: Sum each investor’s holdingsBalances at period end, from the transfers
Goldsky, step 3: TurboBackfill to that blockEvery transfer up to it, in your warehouse
Your business, step 5: Fund administratorStrike the period NAVYour fund administrator prices each unit
Your business, step 6: Issue investor statementsHoldings valued and shown in your portal
  • Goldsky
  • Your provider

Ways to produce investor statements from a tokenized register

The one-time job copies raw transfers into your warehouse for your team to add up, while the subgraph keeps every version of each holder’s balance and returns them at the closing block.

Usual setupOption 1: Backfill to your warehouse
Best for
Statements built in your warehouse from the full history
Products
TurboFeeds
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: Query a hosted index
Best for
One chain per token, read at any past block from an API
Products
SubgraphsFeeds
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: Produce investor statements by copying transfers to your warehouse

A one-time pipeline copies every transfer of the token up to the closing block into your warehouse and then stops. Your team adds up each investor’s holdings there and values them at the period NAV.

When to backfill transfers to your warehouse

Your reporting already runs in a warehouse, and you want the full transfer history behind each statement kept with your own records.

What you’ll need

  • Goldsky Turbo
  • Goldsky Feeds
  • The token’s contract address on each chain it’s issued on
  • A warehouse or object storage for the transfer rows
  • A fund administrator who strikes the period NAV
  • An investor portal or statement delivery system

  1. Close the reporting period

    A statement shows holdings at one moment, so the fund fixes the date and time the period ends.

    The cutoff is set by the fund’s documents, usually month or quarter end, with a time zone. A cutoff that shifts by an hour can move a transfer into the wrong period, and the statement won’t match the register.

  2. Find the closing block

    Handled by Goldsky Feeds

    The chain counts time in blocks, so the period end has to become the number of the last block at or before it.

    Each block carries a timestamp, and the closing block is the newest one at or before the cutoff. A block just after the cutoff pulls in transfers from the next period.

    Feeds turns a time into a block: call its blocks endpoint with timestamp_lte set to the cutoff, sort=number_desc and limit=1, and it returns the newest block at or before that time.

    Look up a block by time (opens in a new tab)

  3. Copy every transfer up to the closing block

    Handled by Goldsky Turbo

    Holdings at period end are the sum of every transfer up to that block, so the statement needs the token’s full history to that point.

    The copy has to start at the token’s first block and stop at the closing block. One that stops early misses the last transfers of the period, and one that keeps running mixes in the next period.

    Goldsky can run Turbo Pipelines as a one-time job with job: true: filter the source to the token’s address with block_number <= the closing block, and the job exits once it has written that range, for example as Parquet files to S3.

    Run a one-time backfill job (opens in a new tab)

  4. Sum each investor’s holdings

    The statement shows units held at period end, so each investor’s transfers are added up to one balance.

    Your warehouse sums the units received and sent by each wallet up to the closing block, then groups wallets by the investor they belong to. Count each transfer ID once, so a row written twice doesn’t double a holding.

  5. Strike the period NAV

    A statement shows what holdings are worth, so each unit needs the value the fund set for the period end.

    Your fund administrator calculates the NAV per unit as of the same cutoff. A NAV from a different date values the holdings at the wrong price, even when the unit counts are right.

  6. Issue investor statements

    The statement is what the investor sees: their units at period end, the NAV and the value.

    Each investor’s units are multiplied by the period NAV and published in your portal or sent by your usual channel. Keep the closing block and the source data with each statement, so an auditor can rebuild any figure.

What to know about backfilling transfers to your warehouse

  • The job runs once per period and stops when it reaches the closing block, so nothing keeps running between statements.
  • Your warehouse gets transfers, not balances; summing them per investor is a query your team owns.
  • The job is bounded by a block filter on the source, which works on chains whose datasets support fast scan.
  • Object storage sinks don’t remove duplicates, so your queries should count each transfer ID once.

Option 2: Produce investor statements from a hosted holder index

A hosted index keeps every version of each holder’s balance, so your reporting job queries it for the balances at the closing block over GraphQL. There’s no transfer history to copy or sum.

When to query a hosted index for statements

The token is on one EVM chain and you want period-end balances by holder from an API, without keeping the transfer history yourself.

What you’ll need

  • Goldsky Subgraphs
  • Goldsky Feeds
  • The token’s contract address and the network it runs on
  • A code repository for the schema and mappings
  • A fund administrator who strikes the period NAV
  • An investor portal or statement delivery system

  1. Close the reporting period

    A statement shows holdings at one moment, so the fund fixes the date and time the period ends.

    The cutoff is set by the fund’s documents, usually month or quarter end, with a time zone. A cutoff that shifts by an hour can move a transfer into the wrong period, and the statement won’t match the register.

  2. Find the closing block

    Handled by Goldsky Feeds

    The chain counts time in blocks, so the period end has to become the number of the last block at or before it.

    Each block carries a timestamp, and the closing block is the newest one at or before the cutoff. A block just after the cutoff pulls in transfers from the next period.

    Feeds turns a time into a block: call its blocks endpoint with timestamp_lte set to the cutoff, sort=number_desc and limit=1, and it returns the newest block at or before that time.

    Look up a block by time (opens in a new tab)

  3. Keep the holder history in the index

    Handled by Goldsky Subgraphs

    To read balances as they stood at a past block, the index has to keep every earlier version of each holder’s balance.

    Your mapping code keeps a balance per holder, and the index stores each change with the blocks it was valid for. If old versions are pruned to save space, balances before the pruned point can’t be read back.

    Goldsky Subgraphs keeps historical record versions for time-travel queries at old blocks. Set prune: never in the subgraph so the full history stays available for every period.

    Choose how much history to keep (opens in a new tab)

  4. Read holdings at the closing block

    Handled by Goldsky Subgraphs

    The statement needs each holder’s balance as it stood at the end of the period, not today.

    Your reporting job queries the index for every holder’s balance at the closing block number. Holder data isn’t public, so each request carries a key.

    Subgraphs serves the index at a GraphQL endpoint, and a time-travel query returns records as they were at a given block. Turn on the private endpoint so each request needs an API token.

    Query a private endpoint (opens in a new tab)

  5. Strike the period NAV

    A statement shows what holdings are worth, so each unit needs the value the fund set for the period end.

    Your fund administrator calculates the NAV per unit as of the same cutoff. A NAV from a different date values the holdings at the wrong price, even when the unit counts are right.

  6. Issue investor statements

    The statement is what the investor sees: their units at period end, the NAV and the value.

    Each investor’s units are multiplied by the period NAV and published in your portal or sent by your usual channel. Keep the closing block and the source data with each statement, so an auditor can rebuild any figure.

What to know about statements from a hosted index

  • The index returns balances for past blocks only if it keeps its full history, so its pruning setting has to keep it.
  • Balances come back per wallet; grouping wallets by investor stays in your reporting job.
  • Each index follows one chain, so a fund on several chains needs one per chain and your own step to combine them.

What you control

Your team
  • Close the reporting period
  • Sum each investor’s holdings
  • Issue investor statements
Your providers
  • Fund administrator

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 keep a holder register

Use cases built the same way

Produce investor statements from a tokenized register 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