Skip to main content

Goldsky

Publish tokenized fund NAVs and marks onchain

Talk to our team

What it is

Publishing a tokenized fund’s NAV onchain means writing the net asset value per unit, as the fund administrator strikes it, to each chain the fund is issued on; the contract that holds it is often called a NAV oracle.

Asset managers and tokenization platforms publish it because wallets, lending markets and other contracts that hold the fund can only read a value that’s on the chain.

A Goldsky Compose task fetches each new NAV on a schedule and sends one signed update per chain, recording every call; the NAV itself stays with your administrator.

Who it’s for

Asset managers and tokenization platforms whose funds are held in wallets and used by lending markets on one or more chains.

How a tokenized fund’s NAV gets onchain

The diagram follows one NAV from the administrator’s strike to the apps that read it on each chain, and shows who does each step. Your setup may differ.

Your business, step 1: Fund administratorStrike the NAVYour fund administrator calculates it
Your business, step 2: Set up NAV contractsOne contract on each chain
Goldsky, step 3: ComposeFetch the new NAVYour task calls the NAV source on schedule
Your business, step 4: Pause on a bad NAVHold publishing until it is fixed
Goldsky, steps 5–7: ComposePublish to each chainOne signed update per chain
Blockchains, step 8: Apps read the NAVThrough a standard price-feed interface
  • Goldsky
  • Your provider

How to publish a tokenized fund’s NAV onchain

A TypeScript task that you write and Goldsky hosts runs on a schedule, reads the latest NAV from your administrator’s endpoint and writes it to the NAV contract on every EVM chain the fund is on. Each call it makes is retried and logged.

What you’ll need

  • Goldsky Compose
  • A fund administrator that publishes each NAV at an endpoint you can call
  • A NAV contract on each chain, such as one with a standard price-feed interface
  • A process for pausing publication when the NAV is wrong

  1. Strike the NAV

    The NAV per unit is the fund’s official value, and only the administrator calculates it.

    Your fund administrator values the fund’s assets, for a fund or exchange-traded product holding crypto-assets often at a licensed benchmark’s daily reference price, and publishes the NAV with the time it applies to. If the endpoint can return a value that hasn’t been signed off, the chain can show it too.

  2. Set up a contract for the NAV on each chain

    Apps can only read the NAV from a contract on their own chain, so each chain needs one that stores it.

    Deploy a contract on each chain that stores the latest NAV and its date, and lets only your publishing wallet update it. If anyone can write to it, anyone can change the NAV the apps read.

  3. Fetch the new NAV on schedule

    Handled by Goldsky Compose

    The chain shows a NAV only when someone writes it there, so a job has to pick up each new value as the administrator publishes it.

    The job runs as often as the NAV changes, usually hourly or daily, and has to cope with the source being briefly unavailable. If a run fails and nobody is alerted, the chain keeps showing an old NAV.

    With Goldsky, a Compose task with a cron trigger calls your administrator’s endpoint through context.fetch, which retries a failed call with backoff before it gives up.

    Call external APIs from a task (opens in a new tab)

  4. Pause publishing when the NAV is wrong

    If the source has a known problem, writing its value onchain spreads the error to every app that reads it.

    Agree a flag your operations team can set at the source to stop publishing, and have the job skip the write, without raising an error, while it’s set. Pausing this way needs no code change and no redeploy.

  5. Publish to each chain

    Handled by Goldsky Compose

    Holders and apps on every chain should see the same NAV, so each new value is written to the contract on each chain.

    Each chain is written separately, so one that’s slow or failing doesn’t hold up the others, and the next run catches it up. The value is scaled to the contract’s decimal format before it’s written.

    Goldsky Compose sends one wallet.writeContract call per chain from the same task, run together with Promise.allSettled, so a failure on one chain doesn’t stop the rest.

    Send transactions from a task (opens in a new tab)

  6. Confirm each update on the chain

    Handled by Goldsky Compose

    An update is in place once enough blocks sit on top of it, and a reorg can drop one that looked done.

    Wait for the confirmations you set before treating the update as published, and send it again if a reorg removes it. Otherwise apps can go on reading the previous NAV with nobody aware it was replaced.

    A Compose write can wait for a set number of confirmations and, with onReorg set to replay, sends the transaction again with a fresh nonce if a reorg drops it.

    Handle confirmations and reorgs (opens in a new tab)

  7. Keep a record of every update

    Handled by Goldsky Compose

    If an app or an auditor asks why a value was on the chain, the answer has to come from records of what was read and written.

    The record ties each value on the chain to the source response it came from, the time it was read and the transaction that wrote it. Without it, rebuilding one update means searching logs on each side by hand.

    Every call a Compose task makes, including each fetch from your source and each transaction it sends, is logged for auditing. If a run is interrupted, calls that already finished aren’t repeated, so a write isn’t sent twice.

    How Compose logs each call (opens in a new tab)

  8. Apps read the NAV

    Wallets, lending markets and other contracts value the fund from the contract on their chain.

    A contract that follows a standard price-feed interface, such as AggregatorV3Interface, can be read by existing integrations without changes. Apps should check the value’s date and treat an old one as stale.

What you control

Your team
  • Set up a contract for the NAV on each chain
  • Pause publishing when the NAV is wrong
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 publish data onchain

Use cases built the same way

Publish a tokenized fund’s NAV onchain 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