Skip to main content

Goldsky

Cross-chain automation

Talk to our team

What is cross-chain automation?

Cross-chain automation is taking an action on one blockchain when an event happens on another, such as releasing funds on the destination chain after a deposit or lock on the source; architects also call it cross-chain orchestration.

Chains and DeFi protocols with contracts on several chains run it because a user’s deposit or message starts on one chain and has to finish, exactly once, on another.

Goldsky Compose starts a task from the source-chain event, holds it until the block is deep enough and sends a signed call on the destination chain; the contracts, the confirmation rules and the reconciliation of both sides stay with you.

You can automate cross-chain actions two ways: a Compose task that acts on each source event while Turbo Pipelines records both chains in your database, or the same task on its own.

Who uses cross-chain automation?

Chains, bridges and DeFi protocols with contracts on several chains that move deposits or messages between them.

How an event on one chain triggers an action on another

The diagram follows one event from the source chain to the matching action on the destination chain, and shows who does each step. Your setup may differ.

Goldsky, step 2: ComposeWait for confirmationsRuns once the block is deep enough
Blockchains, step 1: Event on the source chainA deposit, lock or message lands
Goldsky, step 3: ComposeAct on the other chainA signed call on the destination chain
Blockchains, step 4: Destination updatesThe matching action lands on the second chain
Your business, step 6: Match every eventEach source event paired with its action
Goldsky, step 5: ComposeRecord both sidesSource and destination events, logged together
  • Goldsky

Ways to automate cross-chain actions

Adding the pipeline puts both chains’ events in your database, so matching each source event to its action is a query; on its own, the task’s run history is the only record.

Usual setupOption 1: Task plus two-chain record
Best for
Moving value, with every source matched to its action
Products
ComposeTurbo
Option 2: Event-triggered task
Best for
One event, one action, on EVM chains
Products
Compose

Option 1: Automate cross-chain actions with a task and a record of both chains

A task that Goldsky hosts runs for each source-chain event once its block is deep enough and sends the matching call on the destination chain. Pipelines write both chains’ events to your database, where you match each source event to its action.

When to keep a two-chain record beside the task

You move value between chains and need to show that every source event got exactly one destination action, for reconciliation, support or audit.

What you’ll need

  • Goldsky Compose
  • Goldsky Turbo
  • Contracts on both chains: one that emits the source event and one the task can call
  • A confirmation depth for each source chain
  • A database for both chains’ events
  • Matching queries and an owner for breaks

  1. Receive the event on the source chain

    The job starts when a user deposits, locks tokens or sends a message on the first chain.

    The event sits in a block that can still be replaced for a short time. Acting on it straight away risks releasing funds for a deposit that later disappears.

  2. Wait until the source event is final enough

    Handled by Goldsky Compose

    A reorg, when the chain replaces its newest blocks, can undo a source event, so the action waits until undoing it is unlikely.

    Pick a confirmation depth for each source chain, deeper where more value is at stake. Too shallow and a reorg can undo the source after you’ve acted; too deep and users wait longer than they need to.

    Goldsky Compose holds each event from an onchain_event trigger until its block is as many confirmations deep as you set, which needs parallel_processing: true on the trigger. If a reorg removes the event while it waits, the task never runs for it.

    Hold events for confirmations (opens in a new tab)

  3. Act on the destination chain

    Handled by Goldsky Compose

    The second half of the job is a signed call on the other chain, such as releasing or minting the matching amount.

    The call has to happen once per source event. A retry after a timeout that sends a second release pays the user twice.

    The task sends the call with writeContract. If the task restarts, a write that already finished returns its saved result instead of being sent again.

    How durable execution works (opens in a new tab)

  4. Complete the move on the destination chain

    Once the call is final, the user’s funds or message have arrived where they were going.

    The destination contract records the action and usually emits its own event. Until that block is final, the move isn’t finished.

  5. Record both chains’ events

    Handled by Goldsky Compose

    To show every source event got its action, you need both sides in one place.

    Source and destination events have to land in one database with the identifier that ties them together, such as a deposit ID or message hash. If the contracts don’t carry a shared identifier, matching falls back on amounts and timing, which breaks on identical transfers.

    With Goldsky, the task’s trigger can be a full Turbo Pipelines definition with a postgres sink beside its compose_task sink, so the events that start the task also land in your database. A second pipeline writes the destination chain’s events.

    Feed a task and a database (opens in a new tab)

  6. Match every source event to its action

    A source event with no destination action, or with two, is money owed or overpaid.

    Your query pairs each source event with its destination action and flags the rest. Breaks need an owner and a deadline, or they pile up until a user reports one.

What to know about recording both chains

  • The task acts and the database records; matching source to destination is a query you own.
  • Source events wait until their block is as deep as you set, which trades speed for protection against reorgs.
  • Tables keyed on a primary key follow reorgs, so the record stays in line with each chain.
  • There are two pieces to run, and in return a missing or doubled action shows up as a break in a query.

Option 2: Automate cross-chain actions with an event-triggered task

A task that Goldsky hosts runs for each source-chain event once its block is deep enough and sends the matching call on the destination chain. Its run history is the record of what it did.

When to use an event-triggered task on its own

Each source event causes one action, the source is an EVM contract the task can watch directly, and the task’s run history is enough of a record for you.

What you’ll need

  • Goldsky Compose
  • Contracts on both chains: one that emits the source event and one the task can call
  • A confirmation depth for each source chain
  • Someone who reviews failed runs

  1. Receive the event on the source chain

    The job starts when a user deposits, locks tokens or sends a message on the first chain.

    The event sits in a block that can still be replaced for a short time. Acting on it straight away risks releasing funds for a deposit that later disappears.

  2. Wait until the source event is final enough

    Handled by Goldsky Compose

    A reorg, when the chain replaces its newest blocks, can undo a source event, so the action waits until undoing it is unlikely.

    Pick a confirmation depth for each source chain, deeper where more value is at stake. Too shallow and a reorg can undo the source after you’ve acted; too deep and users wait longer than they need to.

    Goldsky Compose holds each event from an onchain_event trigger until its block is as many confirmations deep as you set, which needs parallel_processing: true on the trigger. If a reorg removes the event while it waits, the task never runs for it.

    Hold events for confirmations (opens in a new tab)

  3. Remember which events you’ve handled

    Handled by Goldsky Compose

    The same source event can reach the task again, and it must not cause a second action.

    Keep a record of each source event the task has acted on, keyed on something unique to it, such as its transaction hash and log index. Without it, a repeat delivery sends a second release.

    A collection keyed on the source event’s transaction hash and log index lets the task check for an earlier run before acting.

    Keep state in collections (opens in a new tab)

  4. Act on the destination chain

    Handled by Goldsky Compose

    The second half of the job is a signed call on the other chain, such as releasing or minting the matching amount.

    The call has to land once and stay landed. A call the destination chain drops in a reorg leaves the user’s funds stuck halfway.

    Goldsky Compose sends the call with writeContract, waits for the confirmations you set and replays it if a reorg on the destination chain removes it.

    Handle confirmations and reorgs (opens in a new tab)

  5. Complete the move on the destination chain

    Once the call is final, the user’s funds or message have arrived where they were going.

    The destination contract records the action and usually emits its own event. Until that block is final, the move isn’t finished.

  6. Review what each run did

    Handled by Goldsky Compose

    When a user asks where their funds are, the answer has to come from a record.

    Each destination transaction should trace back to the run and the source event that caused it. If it doesn’t, support has to piece a move together from two block explorers.

    Every call a Compose task makes is logged with its inputs and results, so each destination transaction leads back to the run and the event behind it.

    How Compose logs each call (opens in a new tab)

What to know about using a task on its own

  • There’s one piece to run: the trigger, the wait and the call all live in the task.
  • The record of each move is the task’s run log and any state it keeps in a collection, not a table in your own database.
  • A trigger set on a contract address watches one contract, on an EVM chain that task triggers support.
  • Showing that every source event got exactly one action means working from the run history.

What you control

Your team
  • Match every source event to its action

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 run protocol automation

Use cases built the same way

Automate cross-chain actions 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