Skip to main content

Goldsky

Crypto-backed lending collateral monitoring

Talk to our team

What is crypto-backed lending collateral monitoring?

Crypto-backed lending collateral monitoring is tracking each loan a client takes against their crypto on a lending protocol: the collateral, the debt and how close the loan is to liquidation.

Exchanges and consumer apps offering these loans have to warn a client before the protocol sells their collateral, and prices can move that far between two loan events.

Goldsky records the protocol’s loan events and positions for your clients, or checks health on a schedule, while the margin limits and the call to the client stay with you.

You can build it two ways: stream the lending protocol’s events and positions into your database with Turbo Pipelines, or index the protocol with Subgraphs and recheck loan health on a schedule with a Compose task.

Who uses crypto-backed lending collateral monitoring?

Crypto exchanges, neobanks and consumer finance apps that let clients borrow stablecoins against the crypto they hold.

How crypto-backed loans are monitored

The diagram follows one loan from its approval to a call for more collateral, and shows who does each step. Your setup may differ.

Your business, step 1: Approve the loanA client borrows against their crypto
Your business, step 2: Wallet or custody providerPost the collateralSigned into the lending protocol
Blockchains, step 3: Loan opensCollateral locked, stablecoins borrowed
Your business, step 6: Check loan healthCollateral valued at the protocol’s oracle price
Goldsky, steps 4–5: TurboTrack loan and collateralProtocol events and positions, in your database
Your business, step 7: Call for more collateralThe client tops up or repays
  • Goldsky
  • Your provider

Ways to monitor crypto-backed loan collateral

Your risk system checks loan health from your database with the pipeline, while the subgraph and scheduled task read health from the protocol and send an alert when a loan crosses your limit.

Usual setupOption 1: Stream to your database
Best for
Loan events and positions beside your risk system
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
Option 2: Index and scheduled check
Best for
One protocol deployment, with scheduled alerts
Products
SubgraphsCompose
What you run
Nothing; Goldsky runs indexing, storage and the API
What you write
A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives
Hosted by Goldsky
How results reach you
You query; changes are pushed

Option 1: Monitor crypto-backed loans by streaming protocol events to your database

A pipeline decodes the lending protocol’s events for your clients’ addresses and reads each position at the block it changed, writing both to your database. Your risk system checks loan health from there.

When to stream lending events to your database

Your risk system already runs on your own database, and you want every loan, deposit and repayment kept there beside the client’s other records.

What you’ll need

  • Goldsky Turbo
  • A custodian that signs collateral deposits and borrows
  • The lending protocol’s contract addresses and ABI
  • A database your risk system reads
  • A scheduler for health checks between loan events

  1. Approve the loan

    A client borrows against their crypto, so the terms are set before any collateral moves.

    Your credit team sets how much the client can borrow against each asset and the point at which you’ll ask for more collateral. Those limits are tighter than the protocol’s own liquidation point, or the protocol sells the collateral before you’ve had a chance to warn the client.

  2. Post the collateral to the lending protocol

    The loan runs on a lending protocol (a set of contracts that lend against deposits), so the collateral has to be deposited there.

    Your custodian signs the deposit and the borrow from the address you hold for the client. Use one address per client if you can; collateral from many clients in one position can’t be told apart on the chain.

  3. Open the loan on the chain

    The protocol locks the collateral and sends the borrowed stablecoins to the client’s address.

    The protocol records the deposit and the borrow as events, and from then on it can sell the collateral if its value falls below the protocol’s threshold. That sale happens on the chain whether or not your systems noticed the price move.

  4. Record every loan event

    Handled by Goldsky Turbo

    Deposits, borrows, repayments and liquidations each change a loan, and your records need all of them.

    Every event for your clients’ addresses is decoded into a row with the client, asset, amount and block. A missed repayment overstates the debt; a missed liquidation leaves you calling a client about collateral that’s already gone.

    In Turbo Pipelines, _gs_log_decode with the ABI from _gs_fetch_abi decodes the protocol’s raw logs in SQL, and a dynamic table of client addresses keeps only your clients’ events.

    Decode contract events (opens in a new tab)

  5. Read the position after each event

    Handled by Goldsky Turbo

    Events say what changed; the protocol’s own record says where the loan stands afterwards.

    After each event, the client’s collateral and debt are read from the protocol at that block. Adding up events yourself misses interest that builds up between them.

    With Goldsky, the same pipeline can call the protocol’s position view at the event’s block with _gs_eth_call and write the result to your database next to the event.

    Call contracts from SQL (opens in a new tab)

  6. Check each loan’s health

    A loan is healthy while the collateral is worth enough more than the debt, and that changes every time prices move.

    Your risk system compares collateral and debt at the price the protocol uses, from its oracle (the contract that feeds it prices), against your own margin limit. Prices move without any loan event, so the check has to rerun on a schedule as well as after each event.

  7. Call for more collateral

    Before the protocol liquidates, you give the client the chance to add collateral or repay.

    The client is told how much to add and by when, and the loan is watched until they act. If nobody acts, the protocol can sell the collateral, often with a penalty, and the client loses more than the top-up would have cost.

What to know about streaming lending events

  • The pipeline sees loan events, so positions update when a client acts, not when prices move.
  • Health checks between events are your scheduled job, against the protocol’s oracle price.
  • Tables keyed on a primary key take reorg corrections as updates and deletes.
  • Goldsky runs the pipeline; you own the risk rules and the margin calls.

Option 2: Monitor crypto-backed loans by indexing the protocol and checking health on a schedule

A subgraph indexes the lending protocol and serves its loans over GraphQL. A scheduled task reads each loan’s health from the protocol and alerts your team when one crosses your limit.

When to index the protocol and check health with a task

Your loans run on one lending protocol deployment, and you want health checked on a schedule and alerts sent, without building that into your own risk system.

What you’ll need

  • Goldsky Subgraphs
  • Goldsky Compose
  • A custodian that signs collateral deposits and borrows
  • The lending protocol’s contract addresses and ABI
  • An endpoint or channel that receives alerts

  1. Approve the loan

    A client borrows against their crypto, so the terms are set before any collateral moves.

    Your credit team sets how much the client can borrow against each asset and the point at which you’ll ask for more collateral. Those limits are tighter than the protocol’s own liquidation point, or the protocol sells the collateral before you’ve had a chance to warn the client.

  2. Post the collateral to the lending protocol

    The loan runs on a lending protocol (a set of contracts that lend against deposits), so the collateral has to be deposited there.

    Your custodian signs the deposit and the borrow from the address you hold for the client. Use one address per client if you can; collateral from many clients in one position can’t be told apart on the chain.

  3. Open the loan on the chain

    The protocol locks the collateral and sends the borrowed stablecoins to the client’s address.

    The protocol records the deposit and the borrow as events, and from then on it can sell the collateral if its value falls below the protocol’s threshold. That sale happens on the chain whether or not your systems noticed the price move.

  4. Index the protocol’s loans

    Handled by Goldsky Subgraphs

    Your team and your task need one place to ask which loans exist and what each one holds.

    The protocol’s events are turned into loan records, from the contract’s first block to now, and served for queries. Records that skip early history show loans with no opening deposit.

    Goldsky Subgraphs runs subgraph mappings over the protocol’s events and serves the resulting loan records at a hosted GraphQL endpoint, with webhooks if you want changes pushed.

    Index a protocol with Subgraphs (opens in a new tab)

  5. Recheck loan health on a schedule

    Handled by Goldsky Compose

    Collateral values move with the market, so health has to be read again even when nothing happens on the loan.

    For each open loan, the check reads the protocol’s own health figure, which uses its oracle price. A check that only runs after loan events misses the price drop that matters most.

    A Compose task with a cron trigger can read each loan’s health from the protocol contract through Edge RPC, using typed classes generated from the protocol’s ABI.

    Schedule a task with cron (opens in a new tab)

  6. Alert your team when a loan crosses your limit

    Handled by Goldsky Compose

    The point of watching is to reach the client before the protocol liquidates.

    An alert names the loan, the client, the health figure and the limit it crossed, and goes where your team will act on it. Alerts that repeat every run for the same loan get ignored, so record which ones you’ve already sent.

    With Goldsky Compose, the task can post the alert to your endpoint with fetch, and each call and its response are recorded in the run’s log.

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

  7. Call for more collateral

    Before the protocol liquidates, you give the client the chance to add collateral or repay.

    The client is told how much to add and by when, and the loan is watched until they act. If nobody acts, the protocol can sell the collateral, often with a penalty, and the client loses more than the top-up would have cost.

What to know about indexing the protocol and checking on a schedule

  • The subgraph answers queries about loans; it doesn’t check health on its own.
  • The task checks health at the times you schedule, so the interval sets how soon you hear about a drop.
  • The rule for an alert lives in the task’s code, so changing it is a deploy.
  • Goldsky hosts the subgraph and runs the task; you own the limits and the margin calls.

What you control

Your team
  • Approve the loan
  • Check each loan’s health
  • Call for more collateral
Your providers
  • Wallet or custody provider

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 track staking and lending

Use cases built the same way

Monitor crypto-backed loan collateral 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