Skip to main content

Goldsky

Onchain primary issuance and allocations

Talk to our team

What is onchain primary issuance?

Onchain primary issuance is selling new shares, fund units or bonds by minting them as tokens straight to investors’ wallets, at launch or in a tokenized IPO.

Transfer agents and tokenization platforms track it because every mint creates a holder in the register, and the units minted have to match the allocations set when the book closed.

Goldsky records each mint with its wallet and amount in your database; verifying investors, setting allocations and minting stay with you and your issuance platform.

You can record onchain primary issuance two ways: stream every mint into your database with Turbo Pipelines, or have a Goldsky subgraph index the mints and serve them over GraphQL.

Who runs onchain primary issuance?

Transfer agents, tokenization platforms and issuers that sell new shares, fund units or bonds by minting them to investors.

How onchain primary issuance reaches the register

The diagram follows one offering from the investor checks to the tie-out of every allocation against its mint, and shows who does each step. Your setup may differ.

Your business, step 1: KYC/KYB providerVerify investorsEach subscriber cleared before allocation
Your business, step 2: Set final allocationsThe book closes; each investor’s shares fixed
Your business, step 3: Issuance platformMint shares to investorsYour issuance platform mints to each wallet
Goldsky, steps 4–5: TurboRecord every mintWallet and amount, in your database
Your business, step 6: Tie out allocationsEvery allocation matched to its mint
  • Goldsky
  • Your provider

Ways to record onchain primary issuance

Mint records from the pipeline land in your database next to the allocation list, so the tie-out is a query; the subgraph keeps the mints and holders behind a GraphQL endpoint your tie-out job calls.

Usual setupOption 1: Stream to your database
Best for
Allocations tied out in your own database, on any number of chains
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 holder index
Best for
One chain, mints and holders queried from an 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

Option 1: Record onchain primary issuance by streaming mints

A pipeline decodes every mint of the new token and writes the wallet and amount to your database, next to the allocation list. Your team ties each allocation to its mint there.

When to stream mints into your database

The allocation list and the register sit in your own database, or the offering mints on more than one chain.

What you’ll need

  • Goldsky Turbo
  • An identity verification provider
  • An issuance platform that mints the shares
  • The token’s contract address and ABI on each chain
  • A database for the mint rows and the allocation list

  1. Verify investors

    Only investors the issuer has checked can be allocated shares, so every subscriber is verified before the book closes.

    Your identity verification provider checks each subscriber, and the wallet they’ll receive shares in is recorded against their identity. A wallet added after allocation, or one that was never checked, means a mint to someone the register can’t name.

  2. Set final allocations

    When the book closes, each investor’s number of shares is fixed, and that list is what the mints must match.

    The allocation list names each investor, their wallet and the units they get. It has to be final before minting starts, or the tie-out compares the chain against a moving target.

  3. Mint shares to investors

    Minting creates the new shares and puts them in each investor’s wallet, which is the moment the issue happens on the chain.

    Your issuance platform mints each allocation to its investor’s wallet. A mint that fails, or goes to the wrong wallet, leaves the register and the allocation list out of step until someone fixes it.

  4. Record every mint

    Handled by Goldsky Turbo

    Each mint is the record that an investor received their shares, so it has to reach the register with its wallet and amount.

    A mint is a transfer from the empty (zero) address, so every one of them has to be decoded and written with the receiving wallet, the amount and the transaction. A mint that’s missed leaves an allocation looking unfilled.

    With Goldsky, a Turbo Pipelines SQL transform keeps the token’s transfers whose sender is the zero address and writes each one to a database table with a primary_key.

    Filter transfers with SQL (opens in a new tab)

  5. Correct mint records after a reorg

    Handled by Goldsky Turbo

    When the chain replaces its newest blocks, a mint you recorded can disappear and be sent again.

    The records have to follow the chain, removing a mint the reorg undid and adding it back when it’s included again. If they don’t, the tie-out passes an allocation the chain no longer shows.

    Turbo Pipelines passes reorg corrections through as deletes and updates, and a database sink with a primary_key applies them to the same rows.

    How reorgs reach your database (opens in a new tab)

  6. Tie out allocations against mints

    The issue is complete when every allocation has a matching mint and every mint has an allocation.

    Match each mint to one allocation by wallet and amount, in your database. An allocation with no mint, or a mint with no allocation, is a break that has to be explained before the register is booked.

What to know about streaming mints into your database

  • Goldsky runs the pipeline; you own the database and the tie-out query.
  • Mints land next to the allocation list, so matching them is a join in your database.
  • Tables with a primary key take reorg corrections as updates and deletes.
  • The same pipeline keeps recording transfers after the offering, so the register stays current.

Option 2: Record onchain primary issuance with a hosted index

You write a schema and mappings that record each mint and holder, and Goldsky indexes the token and serves them at a GraphQL endpoint. Your tie-out job queries the mints and compares them with the allocation list.

When to use a hosted index for an offering

The offering mints on one EVM chain and you’d rather query the mints and holders from an API than keep rows in your own database.

What you’ll need

  • Goldsky Subgraphs
  • An identity verification provider
  • An issuance platform that mints the shares
  • A code repository for the schema and mappings
  • Your allocation list and register system of record

  1. Verify investors

    Only investors the issuer has checked can be allocated shares, so every subscriber is verified before the book closes.

    Your identity verification provider checks each subscriber, and the wallet they’ll receive shares in is recorded against their identity. A wallet added after allocation, or one that was never checked, means a mint to someone the register can’t name.

  2. Set final allocations

    When the book closes, each investor’s number of shares is fixed, and that list is what the mints must match.

    The allocation list names each investor, their wallet and the units they get. It has to be final before minting starts, or the tie-out compares the chain against a moving target.

  3. Mint shares to investors

    Minting creates the new shares and puts them in each investor’s wallet, which is the moment the issue happens on the chain.

    Your issuance platform mints each allocation to its investor’s wallet. A mint that fails, or goes to the wrong wallet, leaves the register and the allocation list out of step until someone fixes it.

  4. Index every mint and holder

    Handled by Goldsky Subgraphs

    The tie-out needs each mint with its wallet and amount, and the register needs each holder’s balance after the offering.

    Your mapping code records a mint for every transfer from the zero address and updates the holder it went to. Indexing has to start at the token’s deployment block, or the first mints are missing.

    Goldsky Subgraphs runs your mapping code from the start block you set and keeps the records current as new blocks arrive. If you deploy with the no-code wizard, it looks up the start block when it can.

    Deploy a subgraph to Goldsky (opens in a new tab)

  5. Roll back holdings undone by a reorg

    Handled by Goldsky Subgraphs

    When the chain replaces its newest blocks, a transfer the index already counted can disappear.

    The index has to drop the changes those blocks made, so each holder’s balance goes back to what it was. If it doesn’t, the register can show shares in a wallet that never received them.

    Subgraphs stores every version of a record with a block_range showing the blocks it’s valid for, and rows are removed only when a reorg rolls them back. Webhooks on the record carry the same block_range, so your systems can tell a rollback from an ordinary change.

    How record versions track reorgs (opens in a new tab)

  6. Query the mints for the offering

    Handled by Goldsky Subgraphs

    Your tie-out job reads the mints from the index to compare them with the allocation list.

    The job queries every mint of the token since the offering opened. Allocation and holder data isn’t public, so the endpoint should require a key on every request.

    Every subgraph gets a GraphQL endpoint in Subgraphs. Turn on the private endpoint and each request needs an API token in the Authorization header.

    Set up a private endpoint (opens in a new tab)

  7. Tie out allocations against mints

    The issue is complete when every allocation has a matching mint and every mint has an allocation.

    Match each mint to one allocation by wallet and amount, in your database. An allocation with no mint, or a mint with no allocation, is a break that has to be explained before the register is booked.

What to know about recording an offering in a hosted index

  • Goldsky runs the index and its endpoint; your tie-out job pulls the mints when it runs.
  • The allocation list stays in your systems, so the match runs in your code after each query.
  • Each index follows one chain, so an offering on several chains needs one per chain.

What you control

Your team
  • Set final allocations
  • Tie out allocations against mints
Your providers
  • KYC/KYB provider
  • Issuance platform

Questions and answers

What is a digital bond?

A digital bond is a bond issued and settled as a record on a distributed ledger instead of only through a traditional securities depository; it’s also called a tokenized bond. Supranational issuers have issued them in live tests and governments are piloting them, on ledgers run by securities depositories and banks, in some cases settling in central bank money. Recording each mint from chain data works only where the bond’s tokens are issued on a chain you can read.

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

Record onchain primary issuance in the 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