Skip to main content

Goldsky

Tokenized money market fund dividends paid as new tokens

Talk to our team

What are tokenized money market fund dividends?

Tokenized money market fund dividends are the income a money market fund pays to holders of its tokenized shares as extra tokens, each holder’s share worked out from their balance at the record time.

Because the fund keeps each token at $1, income can’t raise the price, so it arrives as more tokens, as it does in tokenized Treasury funds that keep a $1 token.

Asset managers and their transfer agents run a distribution every period, and each holder’s new tokens have to match both their balance at the record time and the income per share the fund administrator declared, or the token register stops agreeing with the fund’s books.

With Goldsky, you can run each distribution as a Compose task that snapshots holders with a one-time Turbo Pipelines job and mints their dividends, or as a Compose task that reads holders at the record block from a subgraph register.

Who pays tokenized money market fund dividends?

Asset managers running tokenized money market and Treasury funds, and the transfer agents that keep their registers.

How tokenized money market fund dividends are paid as new tokens

The diagram follows one distribution, from the income your fund administrator calculates to the mints recorded in your books, and shows who does each step. Your setup may differ.

Your business, step 1: Fund administratorCalculate the yieldYour fund administrator sets income per unit
Goldsky, step 2: FeedsFind the record blockThe block at the record time
Your business, step 4: Work out new tokensEach holder’s share of the income
Goldsky, step 3: ComposeSnapshot every holderA one-off backfill, summed per holder
Goldsky, step 5: ComposeMint each holder’s yieldFrom a wallet the token lets mint
Blockchains, step 6: Yield lands as tokensEach holder’s balance grows by their share
Your business, step 7: Record the distributionMints tied to the income declared
  • Goldsky
  • Your provider

Ways to pay tokenized money market fund dividends as new tokens

For each distribution, the one-time job rebuilds every holder’s balance from the chain and leaves nothing running afterwards; the subgraph keeps the register indexed all the time, so the task only queries it at the record block.

Usual setupOption 1: Snapshot task
Best for
Periodic distributions, with no register to maintain
Products
ComposeTurboFeeds
Option 2: Subgraph register
Best for
One chain, with a register you also use for reporting
Products
ComposeSubgraphsFeeds

Option 1: Pay tokenized money market fund dividends as new tokens with a snapshot task

A TypeScript task that Goldsky hosts takes one distribution from the record time to the last mint: it finds the record block, starts a one-time pipeline to rebuild every holder’s balance, works out each holder’s new tokens and sends each mint.

When to snapshot fund holders with a one-time job

You don’t keep a live register you can query at a past block, or you want each distribution’s holder list rebuilt from the chain and deleted once it’s paid.

What you’ll need

  • Goldsky Compose
  • Goldsky Turbo
  • Goldsky Feeds
  • The income per unit and record time from your fund administrator
  • Mint permission on the fund token, held by your key or by your tokenization platform
  • A signing service for that key, with an approval policy
  • Your fund accounting records
  • A database for the snapshot and mint records

  1. Set the income per unit

    Every holder’s new tokens are worked out from one figure: how much income the fund earned for each unit in the period.

    Your fund administrator calculates the period’s net income per unit and the record time it applies to. If that figure is revised after minting starts, some holders are paid on the old number and the fund’s supply no longer matches its books.

  2. Find the record block

    Handled by Goldsky Feeds

    The record time is a clock time, but a chain keeps balances by block, so the time has to become a block number.

    Decide which moment counts, such as the close of business in the time zone the terms use, then take the last block at or before it on the chain where the token lives. A block from just after the cutoff puts late buyers on the list.

    The Feeds blocks endpoint returns the newest block at or before a time when you call it with timestamp_lte, sort=number_desc and limit=1.

    Turn a timestamp into a block (opens in a new tab)

  3. Snapshot every holder at the record block

    Handled by Goldsky Compose

    Holdings change all the time, so you need a fixed list of who held how much at the record block.

    Each balance is rebuilt from every mint, burn and transfer of the token from its first block up to the record block, then summed per wallet. Missing early history understates some balances, and counting blocks after the cutoff pays people who bought late.

    With Goldsky, the task can start a one-time Turbo Pipelines job with ctx.turbo, backfill the token’s transfers up to the record block into a table, sum them per holder in SQL, then delete the job.

    Start a Turbo job from a task (opens in a new tab)

  4. Work out each holder’s new tokens

    Income is shared pro rata, in proportion to each holder’s units, and the new tokens have to add back up to the income declared.

    Convert each holder’s income into units at the fund’s price per unit, by rules your fund documents set. Rounding has to be settled in those rules: if every share is rounded down and the remainder never assigned, the minted total falls short of the distribution.

  5. Mint each holder’s yield

    Handled by Goldsky Compose

    The distribution happens when the new fund tokens are created in each holder’s wallet.

    Each mint is signed by whoever holds mint permission on the token, under an approval policy: your own key, or your tokenization platform minting from the amounts you send it. A retry must never mint twice to the same holder for the same period.

    Compose can send each mint through a webhook wallet, which has a signing endpoint you host sign it as a UserOperation (the transaction format smart-account wallets use), plus a one-time EIP-7702 authorization the first time it sends on a chain, then submits it; or it can pass the amounts to your platform’s API with fetch. If the task restarts, calls that already succeeded aren’t made again.

    Sign writes through your own endpoint (opens in a new tab)

  6. Settle the mints on the chain

    The chain is the shared record, so the distribution counts once the mints are in blocks.

    Each holder’s balance grows by their share. Until enough blocks sit on top of a mint, a reorg (the chain replacing its newest blocks) can still drop it, so check each mint again before the period closes.

  7. Record the distribution

    The fund’s books have to show the income declared and the new units issued for it, holder by holder.

    Tie each mint’s transaction to the snapshot, the income per unit and the approval. The units minted should equal the declared income at the price per unit; any difference is a break to explain before the period closes.

What to know about snapshotting holders with a one-time job

  • Nothing runs between record dates: each run starts its own job and deletes it once the holder list is read.
  • The list is rebuilt from the chain’s transfers every time, so it doesn’t depend on a register anyone kept in between.
  • Summing transfers into balances at the record block is a SQL query in your task, run once the one-time job has finished.
  • You write and own the task code; Goldsky hosts it, retries failed calls and logs each one.

Option 2: Pay tokenized money market fund dividends as new tokens from a subgraph register

A subgraph keeps the fund token’s register, every holder’s balance, indexed all the time. A task queries it at the record block over GraphQL, works out each holder’s new tokens and mints them.

When to read fund holders from a subgraph register

The fund token lives on one EVM chain and you keep, or want, a register you can query at any block for statements and reports as well as distributions.

What you’ll need

  • Goldsky Compose
  • Goldsky Subgraphs
  • Goldsky Feeds
  • The income per unit and record time from your fund administrator
  • Mint permission on the fund token, held by your key or by your tokenization platform
  • A signing service for that key, with an approval policy
  • Your fund accounting records
  • A subgraph that keeps each holder’s balance, with its schema and mappings

  1. Set the income per unit

    Every holder’s new tokens are worked out from one figure: how much income the fund earned for each unit in the period.

    Your fund administrator calculates the period’s net income per unit and the record time it applies to. If that figure is revised after minting starts, some holders are paid on the old number and the fund’s supply no longer matches its books.

  2. Find the record block

    Handled by Goldsky Feeds

    The record time is a clock time, but a chain keeps balances by block, so the time has to become a block number.

    Decide which moment counts, such as the close of business in the time zone the terms use, then take the last block at or before it on the chain where the token lives. A block from just after the cutoff puts late buyers on the list.

    The Feeds blocks endpoint returns the newest block at or before a time when you call it with timestamp_lte, sort=number_desc and limit=1.

    Turn a timestamp into a block (opens in a new tab)

  3. Read every holder at the record block

    Handled by Goldsky Subgraphs

    Holdings change all the time, so you need each holder’s balance as it stood at the record block, not today.

    The register has to return balances for a past block as well as the latest one. A register that only keeps current balances can’t say who held what on the record date once anyone has traded since.

    With Goldsky Subgraphs as the holder register, the task reads each holder’s balance at the record block over GraphQL, the same way the tokenized equities guide has its dividend task read the registry at a record-date block.

    Build a tokenized equities registry (opens in a new tab)

  4. Work out each holder’s new tokens

    Income is shared pro rata, in proportion to each holder’s units, and the new tokens have to add back up to the income declared.

    Convert each holder’s income into units at the fund’s price per unit, by rules your fund documents set. Rounding has to be settled in those rules: if every share is rounded down and the remainder never assigned, the minted total falls short of the distribution.

  5. Mint each holder’s yield

    Handled by Goldsky Compose

    The distribution happens when the new fund tokens are created in each holder’s wallet.

    Each mint is signed by whoever holds mint permission on the token, under an approval policy: your own key, or your tokenization platform minting from the amounts you send it. A retry must never mint twice to the same holder for the same period.

    Compose can send each mint through a webhook wallet, which has a signing endpoint you host sign it as a UserOperation (the transaction format smart-account wallets use), plus a one-time EIP-7702 authorization the first time it sends on a chain, then submits it; or it can pass the amounts to your platform’s API with fetch. If the task restarts, calls that already succeeded aren’t made again.

    Sign writes through your own endpoint (opens in a new tab)

  6. Settle the mints on the chain

    The chain is the shared record, so the distribution counts once the mints are in blocks.

    Each holder’s balance grows by their share. Until enough blocks sit on top of a mint, a reorg (the chain replacing its newest blocks) can still drop it, so check each mint again before the period closes.

  7. Record the distribution

    The fund’s books have to show the income declared and the new units issued for it, holder by holder.

    Tie each mint’s transaction to the snapshot, the income per unit and the approval. The units minted should equal the declared income at the price per unit; any difference is a break to explain before the period closes.

What to know about reading fund holders from a subgraph

  • The subgraph runs all the time, so the register is ready when a record date comes and also serves statements and reports.
  • Your mappings keep each balance, and a mistake in them shows up in every snapshot until it’s fixed and the subgraph reindexed.
  • A subgraph indexes one chain, so a token issued on several chains needs one per chain and a merge in your code.
  • The task’s payment code, retries and log are the same as with a one-time job.

What you control

Your team
  • Work out each holder’s new tokens
  • Record the distribution
Your providers
  • Fund administrator

Questions and answers

What is a rebase token?

A rebase token is one whose contract changes every holder’s balance in place to pass on yield or track a price, without any transfer or mint to the holder. Tokenized funds that pay yield as new tokens do the opposite: each holder receives a separate mint for their share, so every distribution is a transaction the fund can tie to a holder, a record date and the income declared. The fund’s documents say which method a token uses.

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 run corporate actions

Pay tokenized money market fund dividends as new tokens 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