Goldsky

Tokenized fund subscriptions and redemptions across chains

Q: Who tracks tokenized fund subscriptions and redemptions across chains?

Asset managers with tokenized funds, the transfer agents that keep their share registers, and the tokenization platforms that issue the shares.

Talk to our team

What are tokenized fund subscriptions and redemptions across chains?

Tokenized fund subscriptions and redemptions across chains are the money moving into and out of a fund whose shares are tokens, such as a tokenized money market or Treasury fund, recorded as share mints and burns on every chain the fund is issued on; asset managers call them tokenized fund flows.

Asset managers, transfer agents and tokenization platforms track them so fund accounting can reconcile net flows and shares outstanding for the whole fund, which no single chain can show.

With Goldsky, you can stream every chain’s share mints and burns into your database with Turbo Pipelines, or index them in a hosted subgraph on each chain and query it over GraphQL.

How tokenized fund flows are tracked across chains

The diagram follows an investor’s subscription, and a later redemption, to the reconciliation of the fund’s flows and shares on each chain. Your setup may differ.

Investor subscribesCash arrives for new fund shares

Transfer agentMint fund tokensYour transfer agent mints on the investor’s chain

TurboDecode every chainMints and burns in one stream

Shares mintedSubscriptions settle as mints

Shares redeemedRedemptions settle as burns

Reconcile the fundAgainst the register and cash

TurboStream each flowOne row per mint and burn

TurboKeep net flows per chainBy chain and day, in your database

Goldsky
Your provider

Ways to track tokenized fund flows across chains

Streaming puts every chain’s share mints and burns, and running net flows per chain, in your database next to fund accounting; a subgraph keeps each chain’s flows in a hosted index that your systems query and combine.

Usual setupOption 1: Stream to your database

Best for: Many chains, every flow next to fund accounting
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: Hosted subgraph

Best for: A few EVM chains, read from a hosted API
Products: Subgraphs
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

Ways to track tokenized fund flows across chains
	Usual setupOption 1: Stream to your database	Option 2: Hosted subgraph
Best for	Many chains, every flow next to fund accounting	A few EVM chains, read from a hosted API
Products	Turbo	Subgraphs
What you run	The destination: your database, queue or bucket, or a Postgres database Goldsky hosts	Nothing; Goldsky runs indexing, storage and the API
What you write	Pipeline YAML and SQL; TypeScript transforms when needed	A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives	In your own database or systems	Hosted by Goldsky
How results reach you	Pushed to you	You query; changes are pushed

Option 1: Track tokenized fund flows across chains by streaming to your database

A pipeline decodes every share mint and burn of your fund on each chain, streams them as rows to your database and keeps net flows per chain and day there. Fund accounting reconciles them with the register.

When to stream fund flows to your database

The fund is on several chains, and fund accounting needs every subscription and redemption as a row next to the transfer agent’s records.

What you’ll need

Goldsky Turbo
The fund token’s contract address on each chain
A transfer agent or tokenization platform that mints and burns shares
A database
Your fund accounting system

Take the investor’s subscription
An investor buys into the fund by sending cash, and the shares come afterwards.
The subscription is accepted under the fund’s rules, such as cut-off times and eligibility, before any shares exist. Shares minted for cash that hasn’t settled leave the fund owed money by an investor who already holds shares.
Mint the fund’s shares
The transfer agent creates the investor’s shares as tokens on the chain the investor uses.
The mint has to carry a reference the transfer agent can tie to the subscription. Without one, fund accounting sees shares appear but can’t say whose cash paid for them.
Settle subscriptions and redemptions on the chain
Subscriptions settle as share mints and redemptions as burns, on whichever chain each investor holds shares.
Each chain shows only its own part of the fund. For a short time the newest blocks can still be rewritten, so a mint seen once isn’t final yet.
Decode mints and burns on every chain
Handled by Goldsky Turbo
Each mint and burn has to become a record with its amount, wallet, chain and transaction before it can be reconciled.
Every chain the fund is on has to be covered, and a new chain added before shares are issued there. A chain left out shows up as shares outstanding that don’t add up to the register.
With Goldsky, one Turbo Pipelines pipeline can read each chain as its own source and combine their mints and burns with UNION ALL, tagging each row with its chain.
Merge chains in one pipeline (opens in a new tab)
Stream each flow to your database
Handled by Goldsky Turbo
Fund accounting works from tables, so every flow has to land as a row it can query.
Rows need a stable ID, because delivery can repeat after a restart and a flow counted twice overstates net subscriptions.
Turbo Pipelines writes each mint and burn to a database table keyed on id, so a repeated delivery overwrites the same row.
Set up the Postgres sink (opens in a new tab)
Keep net flows per chain and day
Handled by Goldsky Turbo
Fund accounting reconciles net subscriptions per chain and day, and shares outstanding per chain.
Redemptions count as negative amounts, and the day has to follow the fund’s cut-off rather than midnight on the chain, or a late flow lands in the wrong day.
With Goldsky, the Turbo Pipelines postgres_aggregate sink keeps a running sum per chain and day in your database, with the day set in the pipeline’s SQL, updated as each flow arrives; keep the _gs_op column in that SQL so a flow a reorg deletes comes off the total.
Keep running totals in your database (opens in a new tab)
Correct flows undone by a reorg
Handled by Goldsky Turbo
Sometimes a chain replaces its newest blocks (a reorg), and a mint or burn you recorded can disappear.
Your tables have to follow the chain when that happens. Otherwise shares outstanding include a mint that no longer exists, and the register and the chain disagree.
Reorg corrections come through Turbo Pipelines as updates and deletes. A database sink with a primary_key applies them to the same rows, and the running flows take a removed row back out.
How reorgs reach your sinks (opens in a new tab)
Reconcile the fund
The fund’s books, the transfer agent’s register and the chain have to agree on net flows and shares outstanding.
Your team compares net flows per chain and day, and shares outstanding per chain and in total, with the register and the cash movements. A difference means a missed chain, a late mint or a booking error, and it has to be explained before the fund’s next valuation.

What to know about streaming fund flows to your database

Goldsky runs the pipeline and keeps the running flows; the database, the reconciliation and the fund’s books are yours.
Rows arrive as blocks are produced, so fund accounting can see the day’s flows before the close.
Tables keyed on the row ID take reorg corrections as updates and deletes, and the running flows drop a mint or burn a reorg removes.
Tying a mint to an investor’s subscription is a join in your database against the transfer agent’s records.

Option 2: Track tokenized fund flows across chains with a hosted subgraph

You deploy a subgraph for the fund token on each chain, which indexes every share mint and burn, keeps running flows and serves them at a GraphQL endpoint Goldsky hosts. Your systems query each chain and combine the results.

When to use a hosted subgraph for fund flows

The fund is on a few EVM chains, and your team would rather query a hosted API than run a database for every mint and burn.

What you’ll need

Goldsky Subgraphs
The fund token’s contract address and deployment block on each chain
A transfer agent or tokenization platform that mints and burns shares
A code repository for the schema and mappings
Your fund accounting system

Take the investor’s subscription
An investor buys into the fund by sending cash, and the shares come afterwards.
The subscription is accepted under the fund’s rules, such as cut-off times and eligibility, before any shares exist. Shares minted for cash that hasn’t settled leave the fund owed money by an investor who already holds shares.
Mint the fund’s shares
The transfer agent creates the investor’s shares as tokens on the chain the investor uses.
The mint has to carry a reference the transfer agent can tie to the subscription. Without one, fund accounting sees shares appear but can’t say whose cash paid for them.
Settle subscriptions and redemptions on the chain
Subscriptions settle as share mints and redemptions as burns, on whichever chain each investor holds shares.
Each chain shows only its own part of the fund. For a short time the newest blocks can still be rewritten, so a mint seen once isn’t final yet.
Define the flow records
The subgraph needs to know which events are subscriptions and redemptions, and what to keep for each.
A record per mint and burn, plus running totals per day, lets fund accounting read flows without summing every event. Daily totals kept in mappings use the chain’s block time, so the day boundary has to match the fund’s cut-off.
Index every share mint and burn
Handled by Goldsky Subgraphs
Flows and shares outstanding come from every mint and burn since the fund token was deployed.
Indexing starts at the token’s deployment block on each chain and then keeps up with new blocks. A start block set too late leaves early subscriptions out with no error.
You deploy the subgraph to Goldsky Subgraphs with goldsky subgraph deploy, once per chain, and it indexes from the start block you set.
Deploy a subgraph to Goldsky (opens in a new tab)
Query each chain’s flows
Handled by Goldsky Subgraphs
Fund accounting reads the records by querying each chain’s endpoint.
Fund flow data isn’t meant for the public, so the endpoint should require a key. Each query should note the block it was answered at, so figures from different chains can be lined up.
Each subgraph in Subgraphs has a hosted GraphQL endpoint, which you can make private so every request needs an API token.
Set up private endpoints (opens in a new tab)
Reconcile the fund
The fund’s books, the transfer agent’s register and the chain have to agree on net flows and shares outstanding.
Your systems add up each chain’s net flows and shares outstanding, then compare them with the register and the cash movements. A reorg (the chain replacing its newest blocks) can change recent figures, so reconcile against blocks that have settled.

What to know about tracking fund flows with a subgraph

Each chain is its own subgraph, so a fund-wide figure means querying each one and adding them up.
Your mapping code decides what’s stored, such as daily flow totals, and changing it means deploying and indexing again.
Your systems pull from the endpoint, and webhooks can push each change if you need them.
Goldsky hosts the index; the reconciliation and the fund’s books stay with your team.

What you control

Your team: Take the investor’s subscription
Reconcile the fund
Your providers: Transfer agent

Questions and answers

What is a tokenized fund?

A tokenized fund is an investment fund whose shares are issued as tokens on a blockchain instead of only as entries in a transfer agent’s register. Investors subscribe and redeem much as they would with any fund, and their shares are minted to or burned from their wallets. The fund’s assets, valuation and legal structure work as usual; the token changes how shares are held, moved and recorded.

What is a tokenized money market fund?

A tokenized money market fund is a money market fund, investing in short-term government debt and similar assets, whose shares are issued as tokens. Investors can hold the shares in a wallet and move them onchain. Some stablecoin issuers hold these shares as part of their reserves, which is one reason the funds often run on several chains at once. Each share mint and burn on those chains is a subscription or redemption the fund has to reconcile.

What are tokenized treasuries?

Tokenized treasuries are US Treasury bills and bonds, or shares in a fund that holds them, issued as tokens on a blockchain. Many are shares in a tokenized Treasury or government money market fund: investors subscribe and the fund mints shares to their wallets, then burns them when the investor redeems. Because these funds often run on several chains, each chain’s mints and burns are part of the flows the fund reconciles.