Skip to main content

Onchain data for risk ratings and scoring

What is onchain data for risk ratings and scoring?

Onchain data for risk ratings and scoring is the deposit, borrowing, repayment and balance history that a model uses to rate a DeFi protocol or vault, or to score a borrower’s wallet; the work is also called DeFi risk assessment.

Rating providers, data firms and risk vendors need a protocol’s full history and its current balances before a model can produce a score, and lenders and protocols act on the result.

Goldsky loads that history and keeps the balances of the wallets you watch current in tables your models read, while the model, the methodology and the rating stay yours.

You can build it two ways: stream protocol history and watched-wallet balances into your warehouse with Turbo Pipelines, or fetch one wallet’s transfers and balances from the Feeds API when you score it.

Who uses onchain data for risk ratings and scoring?

DeFi risk rating providers, crypto data and analytics firms, and transaction monitoring vendors that score protocols, vaults or wallets.

How onchain history reaches a risk rating model

The diagram follows one rating from choosing the protocol, vault or wallet to the score lenders and protocols use, and shows who does each step. Your setup may differ.

Your business, step 1: Pick what to rateA protocol, vault or borrower wallet
Your business, step 4: Run your rating modelYour methodology produces the score
Goldsky, step 2: TurboLoad the full historyDeposits, borrows and repayments, into your warehouse
Goldsky, step 3: TurboTrack live balancesBalances of the wallets you watch
Your business, step 5: Publish the ratingLenders and protocols use your score
  • Goldsky

Ways to feed risk ratings and scoring models

The pipeline covers whole protocols, decoded from their contracts, and keeps your warehouse tables current; the Feeds API returns one wallet’s token transfers and latest balances when your scoring service calls it, without protocol events.

Best for
Whole protocols and many wallets, kept current
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
Best for
One wallet at a time, scored when a user applies
Products
Feeds
What you run
Nothing; you call an endpoint and keep what you need
What you write
REST requests
Where your data lives
Hosted by Goldsky
How results reach you
Returned when you call

Option 1: Feed risk ratings and scoring models by streaming history to your warehouse

A pipeline loads every deposit, borrow and repayment from the contracts you rate into your warehouse and keeps it current, alongside a table of current balances for the wallets you watch.

When to stream rating data into your warehouse

You rate whole protocols or vaults, or score many wallets at once, and your models need decoded contract history next to your own data.

What you’ll need

  • Goldsky Turbo
  • The contracts and ABIs of the protocols or vaults you rate
  • A warehouse or database your models read
  • A list of the wallets you watch
  • Your rating model and methodology
  1. Pick what to rate

    A rating covers one protocol, vault or wallet, and that choice decides which contracts and addresses matter.

    List the contracts behind each protocol or vault, and the wallets you score. A vault that routes deposits through a contract you didn’t list looks smaller and safer than it is.

  2. Load the protocol’s full history

    Handled by Goldsky Turbo

    A rating looks at how a protocol behaved over time, through stress as well as calm, so it needs every past event.

    Deposits, borrows, repayments and liquidations since launch are decoded and loaded, then kept current. A missing period of stress leaves the model scoring a protocol it has never seen under pressure.

    With Goldsky, a Turbo Pipelines pipeline can decode your protocol’s events with its ABI from the first block, using start_at: earliest, and keep writing new ones to your warehouse.

    Start a source at the earliest block (opens in a new tab)
  3. Track the balances of the wallets you watch

    Handled by Goldsky Turbo

    A score can weigh what a wallet holds now, not only what it has done.

    Each watched wallet needs one current balance per token, updated when it changes. Polling every wallet on a timer costs more as the list grows and still misses changes between polls.

    Turbo Pipelines can hold the wallets in a dynamic table, read a native balance with _gs_evm_get_balances only when a transfer touches the wallet, and upsert one row per wallet. Token balances come from the balances datasets, with no RPC calls.

    Track balances for a set of addresses (opens in a new tab)
  4. Run your rating model

    The model turns history and balances into a score people can compare.

    Your methodology reads the data, computes its inputs and produces the score. Keep the data each score was built on, so a rating can be explained when someone challenges it.

  5. Publish the rating

    Lenders, protocols and vault curators use the score to set limits or decide where to deposit.

    You publish it through your product, an API or onchain, with the date it was computed. A rating with no date reads as current long after the data behind it has changed.

What to know about streaming rating data

  • You own the warehouse and its schema; Goldsky runs the pipelines that write to it.
  • Contract events are decoded from your ABIs, so protocol actions such as liquidations are covered, not only token transfers.
  • A native-token balance is read again only when a transfer touches the wallet, so gas spent without a transfer shows up at the next one.
  • Keyed tables take reorg corrections as updates and deletes, so the model reads the chain as it stands.

Option 2: Feed risk ratings and scoring models with a wallet data API

Your scoring service calls the Feeds transfers and balances endpoints for a wallet when it needs a score, and gets back that wallet’s token transfers and latest balances across chains. There’s no pipeline or warehouse to set up.

When to use a wallet data API for scoring

You score one borrower wallet at a time, when a user applies, and token transfers and current balances are enough for your model.

What you’ll need

  • Goldsky Feeds
  • Your scoring model
  • An application flow that supplies the wallet to score
  • Storage for the data each score used
  1. Pick the wallet to score

    A borrower score is about one wallet, usually the one an applicant connects or names.

    Confirm the applicant controls the wallet before scoring it, for example with a signed message. A score on a wallet the applicant doesn’t control rates someone else’s history.

  2. Fetch the wallet’s transfer history

    Handled by Goldsky Feeds

    How a wallet has moved money over time, such as steady repayments or sudden outflows, is what a wallet score looks at.

    The history has to cover every chain the wallet uses and include tokens with no market price. A score built on one chain, or only on tokens with a market price, misses activity the borrower has elsewhere.

    Feeds returns a wallet’s native and ERC-20 transfers across chains from its transfers endpoint, newest first, with the counterparty and the USD value at transfer time. Use from and to to cover the period your model reads.

    Read the transfers endpoint reference (opens in a new tab)
  3. Fetch its current balances

    Handled by Goldsky Feeds

    What the wallet holds now shows what it could repay.

    Read balances when you score and store them with the score. A total that leaves out tokens with no price is a lower bound, so the model should know which holdings it couldn’t value.

    Goldsky Feeds returns the wallet’s latest native and ERC-20 balances across chains from its balances endpoint, with USD values and a wallet total. Set include_unknown_price=true to include tokens without a price.

    Read the balances endpoint reference (opens in a new tab)
  4. Run your rating model

    The model turns history and balances into a score people can compare.

    Your methodology reads the data, computes its inputs and produces the score. Keep the data each score was built on, so a rating can be explained when someone challenges it.

  5. Publish the rating

    Lenders, protocols and vault curators use the score to set limits or decide where to deposit.

    You publish it through your product, an API or onchain, with the date it was computed. A rating with no date reads as current long after the data behind it has changed.

What to know about scoring with a wallet data API

  • The API covers a wallet’s native and ERC-20 transfers and balances; protocol events such as borrows and liquidations aren’t in it.
  • Balances are the latest only, so a score can’t use what a wallet held at a past block.
  • Your service pulls one wallet per request, so data reaches the model only when you ask.
  • USD values can be missing for tokens with no price and can change on a later request, so store what each score used.

What you control

Your team
  • Pick what to rate
  • Run your rating model
  • Publish the rating

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

Feed risk ratings and scoring models with onchain data on 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.

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status