Skip to main content

Goldsky

Smart contract and wallet monitoring

Talk to our team

What is smart contract and wallet monitoring?

Smart contract and wallet monitoring is watching the contracts you deployed and the wallets you control for attacks and unexpected changes, such as a large outflow or an admin setting changed by a caller you didn’t expect.

Banks, stablecoin issuers and custody providers that run contracts or hold funds onchain set it up as part of security operations, so their team hears about suspicious activity as it happens and can act on it, for example by pausing the contract.

Goldsky decodes activity on the addresses you list, alerts your team when a rule trips and can run a task that pauses the contract under rules you set; which activity counts as an attack, whether to pause automatically and when to resume stay with your security team.

You can build it two ways: a Turbo Pipelines pipeline that decodes activity on your contracts and wallets and calls a Compose task to pause, or a subgraph on your contracts that sends a webhook for each sensitive event, which starts the same kind of task.

Who uses smart contract and wallet monitoring?

Global banks, stablecoin issuers and custody and wallet infrastructure providers that run their own contracts or hold funds onchain.

How smart contract monitoring catches an attack and pauses

Follow one suspicious transaction on your contract from the chain to the pause, then to your security team’s review and unpause. Your setup may differ.

Goldsky, step 1: TurboKeep the watch listYour contracts and wallets to watch
Blockchains, step 2: Suspicious activityFunds move or a contract setting changes
Goldsky, step 3: TurboWatch your addressesYour contracts and wallets, decoded live
Goldsky, step 4: TurboRaise the alarmA rule trips; a webhook alerts your team
Goldsky, step 5: ComposePause the contractOptional; its wallet needs the pause role
Blockchains, step 6: Contract pausedFurther transfers or payouts stop
Your business, step 7: Investigate and resumeYour security team reviews, then unpauses
  • Goldsky

Ways to monitor your smart contracts and wallets

The pipeline reads activity on any address you list, plain wallets included, and applies your rule in SQL; the subgraph indexes your own contracts’ events through mappings, and the rule lives in the task its webhook starts.

Usual setupOption 1: Stream, alert and pause
Best for
Contracts and wallets, with rules on single events
Products
TurboCompose
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: Subgraph webhooks and a task
Best for
A few of your own contracts, described in a schema
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 your smart contracts and wallets with a streaming pipeline

A pipeline Goldsky runs decodes every event on the contracts and wallets you list, applies your rule to each one, and sends a match to your alerting tool and to a Compose task that can call your contract’s pause function.

When to watch your contracts with a streaming pipeline

You watch plain wallets as well as contracts, add addresses often, and can write each rule as a condition on one event.

What you’ll need

  • Goldsky Turbo
  • Goldsky Compose
  • Your contract and wallet addresses
  • Your contracts’ ABIs, to decode their events
  • An alerting or paging tool with a webhook endpoint
  • A pause function on your contract, and a policy on who may call it

  1. Keep a watch list of your contracts and wallets

    Handled by Goldsky Turbo

    You can only catch activity on addresses you’re watching, so the list comes first.

    Your security team lists every contract you deployed and every wallet that holds funds or admin rights, on each chain, and keeps the list current as you deploy and rotate. A wallet left off the list can be drained without anyone being alerted.

    With Goldsky, the list can be a Turbo Pipelines dynamic table, which lives in a Postgres database. Add a new contract’s address and the running pipeline starts watching it.

    Learn about dynamic tables (opens in a new tab)

  2. Suspicious activity hits your contract

    An attack shows up onchain as transactions: funds moving out, or a setting changed.

    The transaction is public once it’s in a block, and more transactions in the same attack can follow in the next blocks. The newest blocks can still be replaced for a short time (a reorg), so what you see first isn’t final.

  3. Decode activity on your addresses

    Handled by Goldsky Turbo

    Raw transactions have to become named events and values before a rule can read them.

    Every event touching a watched address has to be decoded with the contract’s ABI into fields such as the function, the caller and the amount. An event the decoder doesn’t recognize can’t trip any rule, so the ABIs have to stay current with each upgrade.

    Turbo Pipelines decodes each log with _gs_log_decode() and the contract’s ABI, and keeps only those from addresses on your watch list using dynamic_table_check().

    Decode logs in SQL (opens in a new tab)

  4. Raise the alarm when a rule trips

    Handled by Goldsky Turbo

    Your security team has to hear about a suspicious event while the attack may still be under way.

    A rule is a condition on one event, such as an outflow above a threshold or an admin call from an unexpected caller, and every match goes to your alerting tool with the transaction attached. Rules about something missing, or a total over time, need a scheduled check instead.

    Goldsky can filter the decoded rows with your rule in a SQL transform and post each match to your alerting tool through a webhook sink, one request per match.

    Set up the webhook sink (opens in a new tab)

  5. Pause the contract under your rules

    Handled by Goldsky Compose

    A pause stops further transfers or payouts while your team works out what happened.

    Pausing takes a transaction from a wallet that holds the pause role, so decide in advance whether a task may pause automatically, and on which rules. If you’d rather not give any automated wallet that role, keep the alert and have a person pause.

    A second webhook sink can call a Compose task’s HTTP trigger; the task checks the alert against your rules and calls the pause function from a Compose wallet that holds the role. Compose carries the call through brief failures and traces each step for the incident review.

    Send calls from a Compose wallet (opens in a new tab)

  6. The contract is paused

    Once the pause transaction is in a block, the contract refuses the calls the pause covers.

    What stops depends on how your contract implements the pause, so check which functions it blocks before you rely on it. Transactions included before the pause have already gone through.

  7. Investigate and resume

    Someone has to work out what happened and decide when it’s safe to carry on.

    Your security team reviews the alert, the decoded events and the record of what the task did, fixes the cause, then unpauses through your normal approval process. Resuming before the cause is fixed leaves the contract open to the same attack.

What to know about watching contracts with a pipeline

  • A rule in the pipeline looks at one row at a time, so conditions on totals or time windows, such as outflows over a day, belong in a scheduled task or your own systems.
  • The alert fires when a transaction is seen, before it’s final, and the webhook receiver gets a correction record if a reorg removes it.
  • Pausing automatically means giving the task’s wallet the pause role on your contract; you can keep the alert and pause by hand instead.
  • Goldsky runs the pipeline and the task; the addresses, the rules and the decision to resume are yours.

Option 2: Monitor your smart contracts with a subgraph and webhooks

A subgraph Goldsky hosts indexes your contracts’ events into records, and a webhook sends each new or changed record on its way to a Compose task. The task applies your rule, alerts your team and can call your contract’s pause function.

When to monitor contracts with subgraph webhooks

You watch a few of your own contracts, already describe their events in a subgraph schema, or want the same index to serve your app’s queries.

What you’ll need

  • Goldsky Subgraphs
  • Goldsky Compose
  • Your contracts’ addresses, ABIs and deployment blocks
  • A subgraph schema and mappings for the events you watch
  • An endpoint that receives the webhook and starts the task
  • A pause function on your contract, and a policy on who may call it

  1. Describe the events to watch

    A subgraph only records the events its mappings handle, so you choose them up front.

    Your team writes a schema for the records to watch, such as admin changes and large withdrawals, and mappings that create one from each event. An event you leave out of the mappings is invisible to every alert built on this index.

  2. Suspicious activity hits your contract

    An attack shows up onchain as transactions: funds moving out, or a setting changed.

    The transaction is public once it’s in a block, and more transactions in the same attack can follow in the next blocks. The newest blocks can still be replaced for a short time (a reorg), so what you see first isn’t final.

  3. Index your contracts’ events

    Handled by Goldsky Subgraphs

    Each event has to become a record before anything can react to it.

    Indexing has to keep up with new blocks and follow reorgs, so a record from a replaced block is rolled back. Indexing that falls behind delays every alert queued after it.

    Goldsky Subgraphs runs your mappings on each new block and keeps every version of a record with its block_range, which is how a reorg rollback shows up.

    Index onchain data with subgraphs (opens in a new tab)

  4. Send each change toward the task

    Handled by Goldsky Subgraphs

    The task can only act on events it hears about.

    Each new or changed record goes out with its operation (insert, update or delete), so the receiver can tell a fresh event from a rollback. Changes can arrive out of order, so the receiver keys its work on the record ID and block.

    You can attach a webhook to the entity in Subgraphs with a --secret, point it at an endpoint of yours that checks the secret, and have that endpoint call the Compose task’s HTTP trigger.

    Set up subgraph webhooks (opens in a new tab)

  5. Decide and pause under your rules

    Handled by Goldsky Compose

    A pause stops further transfers or payouts while your team works out what happened.

    The task checks the event against your rule, alerts your team and, if the rule says so, sends the pause transaction from a wallet that holds the pause role. Whether any automated wallet gets that role is your security team’s decision.

    Compose runs the rule as TypeScript, calls your alerting tool with fetch and sends the pause with writeContract from a Compose wallet; every call is logged on the task run.

    Send calls from a Compose wallet (opens in a new tab)

  6. The contract is paused

    Once the pause transaction is in a block, the contract refuses the calls the pause covers.

    What stops depends on how your contract implements the pause, so check which functions it blocks before you rely on it. Transactions included before the pause have already gone through.

  7. Investigate and resume

    Someone has to work out what happened and decide when it’s safe to carry on.

    Your security team reviews the alert, the decoded events and the record of what the task did, fixes the cause, then unpauses through your normal approval process. Resuming before the cause is fixed leaves the contract open to the same attack.

What to know about monitoring with subgraph webhooks

  • The webhook fires on record changes your mappings make, so an event the mappings ignore never reaches the task.
  • A reorg arrives as a change to a record’s block_range, which the task has to tell apart from an ordinary update.
  • Watching a new contract means changing the subgraph and deploying a new version.
  • The rule is TypeScript in the task, so it can call your other systems before deciding to pause.

What you control

Your team
  • Investigate and resume

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 monitor transactions

Use cases built the same way

Monitor your smart contracts and wallets 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