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.
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
| Usual setupOption 1: Stream to your warehouse | Option 2: Wallet data API | |
|---|---|---|
| Best for | Whole protocols and many wallets, kept current | One wallet at a time, scored when a user applies |
| Products | Turbo | Feeds |
| What you run | The destination: your database, queue or bucket, or a Postgres database Goldsky hosts | Nothing; you call an endpoint and keep what you need |
| What you write | Pipeline YAML and SQL; TypeScript transforms when needed | REST requests |
| Where your data lives | In your own database or systems | Hosted by Goldsky |
| How results reach you | Pushed to you | Returned when you call |
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.
Load the protocol’s full history
Handled by Goldsky TurboA 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 a source at the earliest block (opens in a new tab)start_at: earliest, and keep writing new ones to your warehouse.Track the balances of the wallets you watch
Handled by Goldsky TurboA 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
Track balances for a set of addresses (opens in a new tab)_gs_evm_get_balancesonly when a transfer touches the wallet, and upsert one row per wallet. Token balances come from thebalancesdatasets, with no RPC calls.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.
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.
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.
Fetch the wallet’s transfer history
Handled by Goldsky FeedsHow 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
Read the transfers endpoint reference (opens in a new tab)fromandtoto cover the period your model reads.Fetch its current balances
Handled by Goldsky FeedsWhat 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
Read the balances endpoint reference (opens in a new tab)include_unknown_price=trueto include tokens without a price.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.
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.
More use cases that stream chain data to your systems
- Blockchain data in your own warehouseStream decoded chain data into your own warehouse for BI.
- Power a blockchain data productFeed a resold data product with multi-chain data and fast backfills.
- Blockchain indexing for app backendsKeep an app’s database in sync with the chain.
- Onchain data for index and benchmark calculationsSupply the onchain fundamentals an index or benchmark provider calculates from.
- How to build a subgraphWrite a schema and mappings for your contracts and serve the index over a hosted GraphQL API.
- Speed up subgraph indexing and queriesCut the time a subgraph takes to sync, reindex and answer queries.
- Replace in-house blockchain ETL and cut its costRetire your own nodes and ETL jobs and load the same chain data tables from a managed pipeline.
Use cases built the same way
- Stablecoin admin action logRecord every mint, burn, freeze, clawback and role change with its time and signer for risk and audit review.
- NCUA stablecoin reporting dataReport supply, mint and burn, and holder figures for a stablecoin issued by a credit union subsidiary under the NCUA’s proposed rules.
- Onchain data for finance and BI reportingLoad onchain activity into the warehouse so finance and BI teams can report on it.
- Unauthorized tokenization monitoringFind tokens that claim to represent your security without your consent.
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.