Skip to main content

Goldsky

Cross-chain message relaying

Talk to our team

What is cross-chain message relaying?

Cross-chain message relaying is delivering each message a bridge or messaging protocol carries, such as a token transfer or a contract call, to its destination chain together with the proof the protocol signed; it’s the job a bridge relayer or executor does.

Protocol teams, apps that deliver their own messages and relay providers run it, because on most protocols a message isn’t executed until someone submits it and pays the destination gas, and since the destination contract checks the proof itself, the relayer decides how fast messages arrive, not whether they’re valid.

With Goldsky, Turbo Pipelines records each message your app sends, and a Compose task fetches each proof once the protocol signs it and delivers it from a gas-sponsored wallet; for USDC moved through Circle’s protocol, see completing cross-chain USDC transfers.

Who uses cross-chain message relaying?

Bridge and messaging protocol teams, apps that deliver their own cross-chain messages, and relay providers; acting on one chain when any event happens on another is cross-chain automation.

How a cross-chain message gets relayed

The diagram follows one message from the source chain to its execution on the destination chain, and shows who does each step. Your setup may differ.

Goldsky, step 2: TurboRecord each messageYour app’s messages, in the app’s database
Blockchains, step 1: Send a messageThe source contract emits it
Goldsky, step 3: ComposeFetch the proofChecked until the protocol signs it
Goldsky, steps 4–5: ComposeDeliver the messageSimulated, then sent with gas sponsored
Blockchains, step 6: Run on the destinationThe contract checks the proof and runs it
Your business, step 7: Follow up on stuck messagesMessages that never arrive
  • Goldsky

How to relay cross-chain messages

A pipeline records each message your app sends through a bridge or messaging protocol, and a scheduled task that Goldsky hosts fetches each message’s proof once the protocol has signed it, then delivers both to the destination contract. Completing cross-chain USDC transfers walks through the same job for Circle’s CCTP.

What you’ll need

  • Goldsky Compose
  • Goldsky Turbo
  • A bridge or messaging protocol whose destination contract accepts a message with its proof from your wallet
  • The protocol’s source contract and message event on each chain you send from
  • Access to the protocol’s attestation or proof API over HTTP
  • Someone who looks into messages that stay undelivered

  1. Send a message on the source chain

    A user’s transfer or your app’s call starts on one chain as a message addressed to a contract on another.

    The protocol’s source contract records the message and emits an event with it, such as a burn for a token transfer. Until the message is delivered on the other chain, the user’s funds or instruction are in flight.

  2. Record each message to deliver

    Handled by Goldsky Turbo

    A message nobody records is never delivered, and the user’s funds stay stuck between chains.

    Keep the messages you’re responsible for, such as your app’s own, with the identifier the protocol tracks them by. A list built only from a live connection to a node can miss messages sent while the connection was down.

    With Goldsky, a Turbo Pipelines pipeline reads the protocol’s source contract on each chain, keeps your app’s messages with a SQL filter and writes them to a table in your Compose app’s Postgres database, in a schema of its own. A message a reorg undoes is deleted from the table.

    How reorgs reach your tables (opens in a new tab)

  3. Fetch the proof once the protocol signs it

    Handled by Goldsky Compose

    The destination contract accepts a message only with the protocol’s proof that it was sent, such as an attestation or a set of signatures.

    The protocol signs a message only after the source chain reaches the finality it requires, so the proof isn’t ready straight away and the relayer keeps checking until it is. Some protocols return message bytes that differ from the source event, and the relayer has to submit the bytes the proof covers.

    A Compose task on a cron trigger, as often as every second, reads the undelivered messages with ctx.db.query and requests each proof with ctx.fetch, which retries failed calls and records each response on the run. A message whose proof is still pending waits for the next run.

    Call an API from a task (opens in a new tab)

  4. Check the delivery before paying gas

    Handled by Goldsky Compose

    A delivery that reverts or repeats still costs gas.

    Most protocols let anyone deliver a message, so another relayer may have delivered it first. Confirm the call would succeed before sending it.

    Goldsky Compose wallets can simulate the delivery call against current state, so a message already delivered or a call that would revert is never sent.

    Simulate a call before sending (opens in a new tab)

  5. Deliver the message and its proof

    Handled by Goldsky Compose

    The message takes effect when the destination contract verifies the proof and runs it, such as minting the transferred tokens.

    Delivery needs gas on the destination chain, so a relayer serving many chains usually keeps native tokens on each of them. The destination contract checks the proof itself, so a relayer can delay a message but can’t forge one.

    The task sends the call with writeContract from a Compose smart wallet, whose gas is sponsored and paid through your Goldsky bill and whose nonces Compose manages, so the task keeps no native tokens on each chain. With onReorg set to replay, a delivery a reorg removes is sent again.

    How Compose wallets pay gas (opens in a new tab)

  6. Run the message on the destination chain

    Once the destination contract accepts the message, the user’s funds or instruction have arrived.

    The contract marks the message delivered, so a second delivery reverts with an error saying so. A relayer should count that error as a success and stop retrying.

  7. Follow up on undelivered messages

    A message that never arrives is a user’s money stuck between chains, and the user will ask where it is.

    Messages pending well past the protocol’s usual time, or failing on every run, need a person: a proof may have expired and need reissuing, or the destination call may revert for a reason the relayer can’t fix.

What you control

Your team
  • Follow up on undelivered messages

Questions and answers

What is a crypto relayer?

A crypto relayer is a service that takes a message one blockchain produced, such as a bridge transfer, and submits it on another chain with the proof the protocol signed, paying that chain’s gas. On most bridges and messaging protocols anyone can relay, because the destination contract checks the proof itself: a relayer can delay a message but can’t forge one. Protocol teams, apps and independent providers all run relayers.

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

Relay cross-chain messages 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