Who uses credit ratings published onchain?

Credit rating agencies that rate tokenized bonds, funds and notes, and want each rating readable by the contracts that hold them.

Goldsky

Credit ratings published onchain

Talk to our team

What are credit ratings published onchain?

Credit ratings published onchain are a rating agency’s current rating for a tokenized bond, fund or note, written to a contract on the chain the instrument lives on.

Rating agencies publish them because vaults and lenders that hold the instrument apply rules to its rating, such as which assets they accept and at what haircut, and they need the current rating where their contracts run.

When your ratings system calls it, a Goldsky Compose task writes the new rating to the chain; the rating decision and its publication policy stay with your committee.

How a credit rating gets onchain

The diagram follows one rating action from your committee to the contracts that read it on the chain, and shows who does each step. Your setup may differ.

Take a rating actionYour committee upgrades, downgrades or affirms

ComposePick up the ratingYour ratings system calls the task

ComposePublish the ratingWritten on each rated token’s chain

Contracts read the ratingVaults and lenders apply their own rules

Goldsky

Take a rating action
A rating changes only when your committee upgrades, downgrades or affirms it.
The committee decides the action and your ratings system records the rating, the instrument and the effective date. Only actions your publication policy allows should go onchain, and the policy decides when.
Set up a contract for the rating on each chain
Apps can only read the rating 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 rating and its date, and lets only your publishing wallet update it. If anyone can write to it, anyone can change the rating the apps read.
Pick up the rating action
Handled by Goldsky Compose
Ratings change on no fixed schedule, so publishing starts when a rating action is released.
Your ratings system calls the publishing job with the instrument and the new rating. The call has to be authenticated, or anyone could change a rating on the chain.
A Compose task with an http trigger and authentication: "auth_token" accepts the call only with a valid API token, and an ip_whitelist can limit it to your systems’ addresses.
Set up an HTTP trigger (opens in a new tab)
Publish the rating
Handled by Goldsky Compose
Vaults and lenders read the rating on the chain where the instrument lives, so the new rating is written there.
Write the rating and its effective date to the ratings contract, and wait until the update is confirmed. If a reorg drops it, the old rating stays in force on the chain until it’s sent again.
With Goldsky Compose, the task writes the rating with wallet.writeContract, waits for the confirmations you set and, with onReorg set to replay, sends it again if a reorg drops it.
Handle confirmations and reorgs (opens in a new tab)
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)
Contracts read the rating
Vaults and lenders apply their own rules to the rating, such as which instruments they accept and at what haircut.
Each contract reads the current rating and its date from the ratings contract on its chain. What it does with a downgrade is set by the contract’s owner.