Onchain Automation

goldsky-io/goldsky-agent/skills/onchain-automation

作者 goldsky-ioaa52f88312de無授權條款12 個星標收錄於 2026年10月9日更新於 2026年10月9日儲存庫今天更新

Route event-driven onchain automation that detects activity, applies logic, and submits a transaction in response. Use for 'when X happens onchain, do Y', monitor-and-execute workflows, smart contract calls triggered by events, keepers, protocol automation, auto-claiming or compounding rewards, liquidations, rebalancing, and settlement automation. Combine Turbo/Subgraphs/Mirror for detection with Compose for decisions and execution, including wallets, gas sponsorship, and writeContract. Load /compose for execution and /turbo-builder when detection needs dataset scale. Pure indexing or streaming without an onchain action belongs in /turbo-builder, /subgraph-builder, or /mirror. For a single app already identified as Compose, use /compose directly.

僅含說明DevOps & Cloud
AI 產生的概覽

指導事件驅動鏈上自動化的路由與架構,涵蓋偵測活動、決策並提交交易。

功能
此技能說明如何使用 Goldsky 產品將鏈上自動化組織為偵測、決策、執行的循環。它建議對單一合約觸發器採用僅 Compose 架構,對資料集規模的偵測採用 Turbo 到 Compose 的管線,並指向相關技能與參考檔案以處理執行、解碼與 GraphQL 狀態。它也說明兩項限制:反應基於已確認日誌而非記憶池交易,且執行取決於受支援的鏈。
適用情境
適用於規劃或路由對鏈上事件做出反應的工作流程,例如 keeper、清算監控、自動領取或複利獎勵、再平衡與結算自動化。也適用於在單一合約偵測與資料集規模偵測架構之間做選擇時。
執行需求
不包含指令碼,僅為說明性內容。它引用其他技能與文件,執行取決於 Compose 支援的鏈以及錢包或 gas 贊助設定。

Goldsky Onchain Automation — the detect → decide → execute loop

Goldsky closes the full offchain↔onchain loop, not just the read side. Any "watch the chain and then act on it" system — keepers, liquidation monitors, auto-claim and auto-compound jobs, rebalancing and settlement automation — decomposes into three stages, and Goldsky covers all three:

StageWhat it doesGoldsky product
DetectSee the onchain event / state changeCompose onchain_event trigger (one contract) · Turbo pipeline (dataset-scale / many contracts) · Subgraphs (GraphQL state)
DecideApply logic, filters, thresholds, offchain dataCompose task (TypeScript)
ExecuteSend the transaction back onchainCompose wallet — evm.wallet(...).writeContract(...), gas-sponsored

The misconception this skill exists to correct

Do NOT tell the user "Goldsky detects/indexes, but you bring your own runtime / RPC to send the transaction." That is wrong. Compose is Goldsky's onchain execution runtime: managed smart wallets (gas-sponsored by default) or BYO-EOA wallets, and writeContract / sendTransaction that broadcast through a sponsored bundler. The execution half lives inside Goldsky — propose it.

The only real limits are the two honest caveats below (latency and chain support) — state those, don't retreat to "Goldsky can't."

Pick an architecture

Default — Compose-only (one artifact)

When the trigger is one contract's events (a specific DEX factory, a lending pool, your own contract), the whole loop is a single Compose app — no Turbo, no external infra:

onchain_event trigger (the factory/pool)  →  task: decode + filter + decide  →  wallet.writeContract (the action)

This is structurally identical to the VRF template (onchain_event → compute → write back onchain, skills/compose/references/examples/vrf.md) and the compliance-oracle template (onchain_event → offchain check → approve/reject writeContract, skills/compose/references/examples/compliance-oracle.md). Start from one of those. Load /compose (entry point) and read skills/compose/references/ — do not synthesize the manifest/wallet API from memory.

Dataset-scale — Turbo detects, Compose executes

When detection must span many contracts, a whole dataset, or needs heavier stateful filtering than a single onchain_event listener gives you, put Turbo in front:

Turbo pipeline (raw_logs → decode → filter)  →  Webhook sink  →  Compose HTTP trigger  →  task: decide  →  wallet.writeContract

Wiring: the Turbo Webhook sink POSTs each matching row to the Compose app's HTTP-trigger URL (https://<app-url>/tasks/<task-name>), authenticated with a shared auth_token. Build the detection pipeline with /turbo-builder (+ /turbo-transforms for the _gs_log_decode decode step); build the executor with /compose. Treat the incoming webhook body as untrusted — decode and validate before acting.

Prefer Compose-only unless the user actually needs dataset-scale detection — one artifact is simpler to build, deploy, and reason about.

Two honest caveats — always state these

  1. Confirmed-block latency, not mempool. Goldsky (Turbo pipelines and Compose onchain_event) fires on confirmed logs, not pending mempool transactions. So this reliably reacts to a confirmed new pool / event — it is not a mempool front-runner and won't win a same-block gas-priority race. For a "sniper", set expectations: you react quickly to a confirmed listing, you don't beat block-0 bots. Say this plainly.
  2. Execution is chain-gated. Compose gas sponsorship covers a specific chain list (see skills/compose/references/wallets-and-gas.md, or searchKB) — broad EVM coverage, but not every chain. Before promising the full loop, check the target chain:
    • Supported → smart wallet, gas-sponsored, nothing for the user to fund.
    • viem knows it but it's not sponsored → BYO-EOA with sponsorGas: false; the user funds the address with native gas token.
    • Compose can't reach it at all → be honest: detection still works (Turbo/Subgraphs), but execution needs a Compose-supported chain or external infra for that chain specifically. Frame it as a per-chain gap, never as "Goldsky can't execute."

What Goldsky is NOT (here)

  • Not a trading strategy or PnL engine — the user brings the decision logic; Compose runs it.
  • Not a mempool/front-running system (caveat 1).
  • Not a custody solution — wallet-key handling follows the normal Compose wallet/secret rules (skills/compose/references/wallets-and-gas.md).

Route from here

  • Execution / any Compose app → /compose (load first) + skills/compose/references/.
  • Event-driven write-back template → skills/compose/references/examples/vrf.md; gated approve/reject → skills/compose/references/examples/compliance-oracle.md.
  • Dataset-scale detection pipeline → /turbo-builder + /turbo-transforms.
  • GraphQL state to poll → /subgraph-builder.
  • Fast RPC for the user's own offchain reads → /edge.

來源與署名

來源:goldsky-io/goldsky-agent位於skills/onchain-automation提交aa52f88

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架