Skip to main content

Goldsky

Tokenized private credit marks

Talk to our team

What are tokenized private credit marks?

Tokenized private credit marks are the valuations of the loans behind an onchain private credit vault or note, written to the chain so contracts can read them; the contract is sometimes called a private credit oracle.

Private credit funds and asset managers publish them because the vault’s share price, and any loan that takes the shares as collateral, depends on the latest approved value of the book.

A Goldsky Compose task reads the marks your valuation committee approved and writes them to each chain you use; valuing the loans and approving the marks stay with you.

Who publishes tokenized private credit marks?

Private credit funds and asset managers that run onchain lending vaults or issue tokenized notes backed by a loan book.

How private credit marks get onchain

The diagram follows one set of marks from the valuation of the loans to the vault prices that update on the chain, and shows who does each step. Your setup may differ.

Your business, step 1: Valuation agentValue the loansYour valuation agent marks the book
Your business, steps 2–3: Approve the marksYour valuation committee signs off
Goldsky, step 4: ComposeFetch the approved marksYour task reads them on schedule
Goldsky, steps 5–6: ComposePublish the marksWritten to each chain you use
Blockchains, step 7: Vault prices updateLenders and vault contracts read the value
  • Goldsky
  • Your provider

How to publish tokenized private credit marks

A TypeScript task that you write and Goldsky hosts runs on a schedule, reads the marks your valuation committee approved and writes them to the vault or note contract on each chain you use. Each call it makes is retried and logged.

What you’ll need

  • Goldsky Compose
  • A valuation agent that marks the loan book
  • An endpoint that returns only approved marks
  • A contract for the marks on each chain you use

  1. Value the loans

    A private credit vault is worth what its loans are worth, and loans have no market price to read.

    Your valuation agent marks each loan, or the book as a whole, under the fund’s valuation policy and as of a stated date. Marks without a date can’t be told apart from the ones before them.

  2. Approve the marks

    Under the fund’s valuation policy, marks are signed off before anyone relies on them.

    Your valuation committee reviews and approves the marks, and only approved marks become available to publish. If draft marks can reach the chain, lenders may act on a value the committee later changes.

  3. Set up a contract for the marks on each chain

    Apps can only read the marks 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 marks and its date, and lets only your publishing wallet update it. If anyone can write to it, anyone can change the marks the apps read.

  4. Fetch the approved marks on schedule

    Handled by Goldsky Compose

    The chain shows new marks only when someone writes them there, so a job has to pick them up after each approval.

    The job reads from a source that returns only approved marks, on a schedule that matches your valuation cycle. If a run fails and nobody is alerted, the old marks stay in place while the book has moved.

    A Compose task with a cron trigger reads the approved marks through context.fetch, which retries a failed call with backoff.

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

  5. Publish the marks to each chain

    Handled by Goldsky Compose

    Vaults and lenders read the marks on their own chain, so each chain gets the same values.

    Each chain is written separately, so one failing chain doesn’t block the others, and every update has to stick after a reorg. Wait for the confirmations you set before treating an update as published.

    With Goldsky Compose, the task writes each chain with wallet.writeContract, can wait for confirmations, and with onReorg set to replay sends a dropped update again.

    Handle confirmations and reorgs (opens in a new tab)

  6. 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)

  7. Update vault prices

    The vault’s share price and any loan against its shares follow the latest marks.

    Vault contracts and lenders read the marks from the contract on their chain. They should check the date of each mark and treat an old one as stale.

Related jobs

How to report an onchain loan waterfall

Report how each borrower payment into an onchain lending pool splits between fees, lenders and tranches.

A pipeline decodes every loan payment, fee and distribution from a lending pool’s contracts into your warehouse, from the pool’s first block on. Your team builds the waterfall report from those rows and ties it to the servicer’s records.

What you’ll need

  • Goldsky Turbo
  • The addresses and ABIs of the pool, loan and fee contracts
  • A data warehouse or object store
  • The pool’s terms: fee rates, tranches or share classes, and the order they’re paid in
  • The servicer’s or administrator’s payment records, to tie out against

  1. Borrowers repay into the pool

    A loan waterfall starts from each payment a borrower makes, so every report begins with those payments.

    A payment can carry principal, interest and fees in one transfer to the pool’s contracts. In some lending pools the contracts split it on arrival: service fees to the pool manager and the protocol, a management fee out of the interest, and the net interest to lenders.

  2. Write down the order of payment

    Who is paid first decides who absorbs a shortfall, so the report needs the pool’s order of payment.

    In a tranched pool the senior tranche is paid and redeemed before the junior one, and the junior tranche takes the first loss. Take these rules from the pool’s documents, because the chain shows the payments but not always why one party came first.

  3. Load the pool’s full history

    Handled by Goldsky Turbo

    Period reports and cumulative figures need every payment since the pool opened.

    Start at the block where each contract was deployed and move on to new blocks without a gap at the switch. A missing range shows up later as interest that never seems to have reached lenders.

    Goldsky’s Turbo Pipelines reads a dataset from the start of its history with start_at: earliest and keeps streaming new blocks, so one pipeline covers the backfill and the live data.

    Set where a pipeline starts (opens in a new tab)

  4. Decode payments and fees into columns

    Handled by Goldsky Turbo

    Analysts need principal, interest and each fee as separate amounts, not encoded logs.

    Decode each payment, fee and distribution event with its contract’s ABI, keep token amounts at full precision, and store the transaction hash on every row so each figure traces back to the chain. Rows a reorg (the chain replacing its newest blocks) removes have to come out of the report too.

    A Turbo Pipelines SQL transform decodes the pool’s logs with _gs_log_decode() and your ABIs, and the pipeline writes Parquet files to an S3 bucket your warehouse loads, where reorg corrections arrive as records to apply.

    Decode logs with an ABI (opens in a new tab)

  5. Build the waterfall report

    Investors and lenders want to see, for each period, what came in and where it went.

    Total each period’s principal, interest and fees, then allocate them in the pool’s order of payment to each tranche or share class. These totals and allocations are warehouse queries, because a pipeline can’t group rows across a period.

  6. Tie out to the servicer’s records

    The chain and the servicer’s books describe the same loans, and investors rely on them agreeing.

    Match each period’s onchain payments to the servicer’s or administrator’s payment records. A payment in one record and not the other is a break to explain before the report goes out.

What you control

Your team
  • Approve the marks
  • Set up a contract for the marks on each chain
Your providers
  • Valuation agent

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 tokenized private credit marks 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