Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.goldsky.com/llms.txt

Use this file to discover all available pages before exploring further.

Compose and Gelato Web3 Functions (W3F) have a lot of similarities and solve similar problems, but they work a bit differently. For the most part, anything you’ve done with W3F can be done in a similar fashion with Compose, but there are some differences to be aware of.

​
Terminology

A few naming differences to keep in mind:
  • Task — In Compose a “task” is a TypeScript file with your code logic. It can import from other files and libraries and must export a single main function. This is effectively the equivalent of a “function” in W3F terms.
  • Trigger — In Compose a “trigger” encompasses the concept of both “triggers” and “tasks” in W3F.

​
Configuration

Compose apps are completely configured within your code repository. All configuration is done in the manifest YAML file (compose.yaml). Compose apps are deployed with the CLI, and the manifest is responsible for provisioning infra and dependencies.

​
Triggers

Compose has similar triggering options to W3F with a few differences:
  • Compose doesn’t differentiate between cron and time intervals — it just uses cron expressions for time-based triggering.
  • Compose has HTTP triggers, allowing your application logic to trigger tasks and send payloads over HTTP with optional bearer token authentication.
  • Like W3F, Compose tasks can be triggered by onchain events. You declare them directly in your manifest with an onchain_event trigger (network, contract address, event signatures) — no separate pipeline to configure. See Task triggers.
  • For more complex event-driven flows than a single contract’s events can express, you can build a Turbo pipeline with a webhook sink pointed at a Compose HTTP trigger.
  • Compose doesn’t support per-block triggers out of the box. You can recreate this with a Turbo pipeline (webhook sink) that indexes every block and posts to an HTTP-triggered task.

​
Task authoring and output

All task authoring is done in TypeScript for Compose apps — we do not currently support authoring tasks in Solidity like W3F. Unlike W3F, Compose tasks don’t output onchain transactions by default. They can return a JSON payload when called through an HTTP trigger, but all other effects are done inside the task code. Tasks can execute any number of onchain transactions, make HTTP calls to external systems, store data in collections for use later or by other tasks, and so on. Since external interactions happen in code rather than as task output, Compose apps can include any number of them.

​
Monitoring

Both platforms have a web UI dashboard for monitoring, logs, and so on. Compose also has an event log that gives details about task execution steps and failures. This is useful for both auditing and debugging the behavior of Compose apps. The event log is built to be publicly shareable as an audit trail, but currently it’s only visible to users logged into a Goldsky project at app.goldsky.com. Compose does not currently have a notification system for app errors beyond proactively checking the UI and our own internal monitoring and on-call rotation for platform issues. However, logging can be set up within Compose apps to send to external systems. Compose doesn’t make assumptions about what constitutes a failure within a task run, allowing users to manually define success/failure conditions and wire up logging to existing systems. We are designing a system for task logic to define its own critical failure conditions, which would let us use our existing email notification system and flag Compose apps with critical failures in the dashboard. If this is a strict requirement, please contact us with your specific requirements.

​
Wallets, gas, and compute funding

Gas funding in Goldsky doesn’t rely on users depositing gas tokens in our system. Instead, transactions are sent from wallets created in code, and any number of wallets can be created within your Compose app. By default, wallets are Privy-managed smart wallets with built-in gas sponsorship enabled — gas is metered as you use it and paid for as part of your monthly Goldsky bill. Compose also lets you store your own EOA private keys as secrets and use those to create wallets. EOA wallets default to paying their own gas (so you must keep them funded), but you can opt into gas sponsorship per wallet by passing sponsorGas: true to evm.wallet({...}) — see the wallets reference. Compute costs are included in your monthly Goldsky bill, paid in fiat.