DEV Community: Jakhongir Tashpulatov

Gelato Web3 Functions shut down. Here's how to port yours

Jakhongir Tashpulatov — Mon, 19 Oct 2026 08:45:37 +0000

Gelato ended Web3 Functions and Automate on March 31, 2026. Every task created there stopped: the triggers, the recurring jobs, the logs. If a contract of yours depended on one, it has been waiting for an executor since spring.

We run Thyme Flow, which does the same kind of job: a TypeScript function that reads the chain, decides, and returns the calls to send. This post shows a real port, the few places where things differ, and how to hand the whole job to a coding agent.

The short version

Your decision logic does not change. Three things do:

The entry point: Web3Function.onRun(...) becomes defineTask({ schema, run }).
The provider: ethers via multiChainProvider becomes ctx.client, a read-only viem client.
One field name: callData becomes calls.

{ canExec: false, message } stays exactly as it was.

Before: a Gelato oracle function

import { Web3Function, Web3FunctionContext } from '@gelatonetwork/web3-functions-sdk'
import { Contract } from '@ethersproject/contracts'

const ORACLE_ABI = [
  'function lastUpdated() view returns (uint256)',
  'function updatePrice(uint256)',
]

Web3Function.onRun(async (context: Web3FunctionContext) => {
  const { userArgs, multiChainProvider, secrets } = context
  const provider = multiChainProvider.default()
  const oracle = new Contract(userArgs.oracle as string, ORACLE_ABI, provider)

  const lastUpdated = Number(await oracle.lastUpdated())
  if (Date.now() / 1000 < lastUpdated + 3600) {
    return { canExec: false, message: 'Time not elapsed' }
  }

  const price = await fetchPrice(await secrets.get('PRICE_API_KEY'))

  return {
    canExec: true,
    callData: [{
      to: userArgs.oracle as string,
      data: oracle.interface.encodeFunctionData('updatePrice', [price]),
    }],
  }
})

After: the same function on Thyme Flow

import { defineTask, z } from '@thyme-labs/sdk'
import { encodeFunctionData, parseAbi } from 'viem'

const abi = parseAbi([
  'function lastUpdated() view returns (uint256)',
  'function updatePrice(uint256)',
])

export default defineTask({
  schema: z.object({ oracle: z.address() }),
  async run(ctx) {
    const lastUpdated = await ctx.client.readContract({
      address: ctx.args.oracle,
      abi,
      functionName: 'lastUpdated',
    })
    if (Date.now() / 1000 < Number(lastUpdated) + 3600) {
      return { canExec: false, message: 'Time not elapsed' }
    }

    const price = await fetchPrice(ctx.secrets.PRICE_API_KEY)

    return {
      canExec: true,
      calls: [{
        to: ctx.args.oracle,
        data: encodeFunctionData({
          abi,
          functionName: 'updatePrice',
          args: [price],
        }),
      }],
    }
  },
})

Same check, same API call, same call returned. The arguments are now validated by a Zod schema before run starts, and the console renders a form from it.

Mapping the rest

Gelato	Thyme Flow
`userArgs` + `schema.json`	`ctx.args`, typed by Zod
`await storage.get(key)` / `storage.set(key, value)`	`ctx.storage.key = value` (plain JSON, not only strings)
`await secrets.get('KEY')`	`ctx.secrets.KEY`
`npx w3f test` with `userArgs.json`	`thyme run <task>` with `args.json`
`npx w3f deploy`, then create a task from the CID	`thyme upload <task> --tag v1`, then create an executable
Time interval and cron triggers	Interval (30 seconds to one day) and cron
On-chain event or every-block triggers	An interval that polls, with a block cursor in `ctx.storage`
Dedicated msg.sender	Your own Safe, through a role limited to the calls you allow

Where it is different

Calls come from a Safe you own. Gelato sent calls from its dedicated msg.sender. Flow sends them through a Zodiac Roles role on your Safe, limited to the contracts and functions you approve. Remove the role and access is gone. If your contract only accepted Gelato's sender, allow the Safe instead.
No event or block triggers. Poll on a short interval and return canExec: false when there is nothing new. Skipped runs send nothing.
Gas in USD. Mainnet gas is sponsored and charged to a prepaid USD balance. Testnet gas is free.

Let your coding agent do it

If you use Claude Code, Codex, Cursor or a similar agent, paste this into it from the repository that holds your Gelato functions:

Read https://flow.thymelabs.io/docs/skills/thyme-migrate-gelato/SKILL.md and follow it to port the Gelato Web3 Functions in this repository to Thyme Flow. If you support skills, save that file as a skill named thyme-migrate-gelato. Start by listing the functions and triggers you find, port one, run it locally, and ask me before uploading or scheduling anything.

The skill tells the agent to inventory first, port one function at a time, test each locally, and stop on anything that needs you: a contract that only accepts Gelato, fee transfers to Gelato, calls that send ETH, or a chain that is not enabled. Login approval and Safe permissions always stay with you.

Coming from Chainlink Automation instead?

Chainlink retired Automation v2.1 on July 31, 2026. If your contract implements checkUpkeep and performUpkeep, one small task can call them unchanged. The guide is here: Chainlink Automation to Thyme Flow.

Meet Thyme Gate

Jakhongir Tashpulatov — Sat, 10 Oct 2026 10:45:56 +0000

Every onchain app needs an RPC endpoint. Usually that's yet another vendor with its own dashboard, its own keys and its own bill, separate from the rest of your backend.

Thyme Gate is the RPC product in thyme/labs. It gives you a JSON-RPC endpoint per chain, with keys scoped to your project and usage you can actually read. It sits in the same workspace as our onchain automation (Flow) and hosted subgraphs (Atlas).

Keep your client, change the URL

There's no custom SDK or transport. If your code speaks JSON-RPC, it works with Gate.

1. Create a key

Keys belong to a project. Name one for each app or environment, such as orders-production or orders-staging, so you can see each one's traffic and revoke them separately.

2. Choose a network

Pick a mainnet or testnet. The console shows the exact HTTPS URL for every network available to your key.

3. Send a request

curl "$GATE_RPC_URL" \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Or with viem:

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: http(process.env.GATE_RPC_URL),
})

const block = await client.getBlockNumber()

Reads, logs and transaction submissions all go through the same interface. To switch chains, change the endpoint and the chain config.

Supported networks

Chain	Chain ID	Networks
Ethereum	1	Mainnet, Sepolia
Polygon	137	Mainnet, Amoy
Optimism	10	Mainnet
BNB Smart Chain	56	Mainnet
Unichain	1301	Sepolia

Need another chain? Email support@thymelabs.io and tell us which one.

See the traffic behind the bill

RPC bills are often a black box. Gate's console shows:

Requests and errors by network
Compute units by RPC method, so you can see what's driving cost
Traffic and last use per API key
Your free allowance through the billing cycle

If one method is eating your budget, you'll see it in the method breakdown instead of finding out on the invoice.

Keys you control

Keys are scoped to a project, and only workspace owners and admins can create or revoke them.
To rotate a key without downtime, create a new one, deploy the new URL, check that traffic moved, then revoke the old key.
Revoking a key stops future requests that use it.

One tip: the endpoint URL contains your key. Keep it in server-side config, not in a browser bundle, and redact it from logs and screenshots.

Need more throughput or a signed SLA? Talk to us about enterprise.

Try it

Get an endpoint: https://gate.thymelabs.io
Quickstart: https://flow.thymelabs.io/docs/gate/quickstart

Your client is ready. Give it an endpoint. What are you building? Tell us in the comments. 👇

Meet Thyme Atlas

Jakhongir Tashpulatov — Sat, 10 Oct 2026 10:43:46 +0000

If your app shows onchain data like balances, positions, trade history or vault TVL, you've probably either scanned blocks yourself or run a Graph Node. Both mean babysitting infrastructure instead of shipping features.

Thyme Atlas hosts your subgraphs. You deploy with the Graph CLI you already use, Atlas indexes your contracts on managed Graph Nodes, and you query decoded events and entity state over GraphQL. There's no node to run and no instance to size.

Atlas is part of thyme/labs, in the same workspace as our RPC (Gate) and onchain automation (Flow).

Keep the Graph CLI, change the node

Your subgraph.yaml, schema and mappings stay as they are. Atlas accepts the same build and IPFS upload that graph-cli already produces.

1. Create a subgraph

Name it in the console. It lives in a project, with the same members and billing as the rest of your workspace.

2. Create a deploy key

Deploy keys belong to the project. The secret is shown once, and revoking a key stops new deploys within seconds.

3. Run `graph deploy`

graph codegen && graph build

graph deploy my-subgraph \
  --node https://deploy.atlas.thymelabs.io/ \
  --ipfs https://ipfs.atlas.thymelabs.io/api/v0 \
  --deploy-key "$ATLAS_DEPLOY_KEY" \
  --headers "{\"Authorization\":\"Bearer $ATLAS_DEPLOY_KEY\"}" \
  --version-label v1

That uploads the build, creates a release and starts indexing.

One endpoint, keys you control

Every subgraph gets an HTTPS GraphQL endpoint. It works with Graph Client, Apollo, urql or plain fetch. Send a query key as a bearer token:

const res = await fetch(process.env.ATLAS_QUERY_URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${process.env.ATLAS_QUERY_KEY}`,
  },
  body: JSON.stringify({ query: '{ vaults(first: 5) { id tvl } }' }),
})

const { data } = await res.json()

You can scope a query key to a whole project or to a single subgraph.
Revoked keys stop working within seconds.
Every release has a GraphiQL playground, so you can test queries before you write code.

Ship the next version without downtime

Re-indexing usually means downtime or juggling two endpoints. In Atlas, each deploy is an immutable release that indexes alongside production:

You can follow indexing progress, health and errors for each release.
Once the new release has caught up, promote it. Your production endpoint switches to it.
If something looks wrong, roll back to the previous release in seconds.

Your app keeps querying the same URL the whole time.

Supported networks

Atlas indexes these chains from nodes we run ourselves. In subgraph.yaml, set the network to the name Graph Node expects:

Network	`network:` value	Chain ID
Ethereum	`mainnet`	1
Ethereum Sepolia	`sepolia`	11155111
Polygon	`matic`	137
Polygon Amoy	`polygon-amoy`	80002
Optimism	`optimism`	10
BNB Smart Chain	`bsc`	56
Unichain Sepolia	`unichain-testnet`	1301

Need another chain? Email support@thymelabs.io and tell us which one.

Indexing a large protocol or need dedicated capacity? Talk to us about enterprise.

Try it

Deploy a subgraph: https://atlas.thymelabs.io

Bring the subgraph, and we'll run the node. Got a subgraph you'd like to move over? Tell us in the comments. 👇

Meet Thyme Flow

Jakhongir Tashpulatov — Sat, 10 Oct 2026 10:34:34 +0000

A lot of onchain apps need something to happen on a clock: harvest rewards, rebalance a vault, top up a balance, close an expired position. The usual options are a cron box holding a hot private key, or a keeper network you have to fund and trust with your contracts.

We built Thyme Flow so you don't have to pick either. You write a TypeScript task that decides what to do. Flow runs it on a schedule and sends the calls from a Safe you own, through a role you can revoke whenever you want. We never hold the keys to your account.

How it works

1. Write a task

A task is plain TypeScript. It reads live chain state and returns the calls to send, or decides to skip this run. You never sign anything in your code.

import { defineTask, z } from '@thyme-labs/sdk'
import { encodeFunctionData, parseAbi } from 'viem'

const abi = parseAbi([
  'function harvest()',
  'function pendingRewards() view returns (uint256)',
])

export default defineTask({
  schema: z.object({
    vault: z.address(),
    minRewards: z.coerce.bigint(),
  }),
  async run(ctx) {
    const { vault, minRewards } = ctx.args
    const pending = await ctx.client.readContract({
      address: vault, abi, functionName: 'pendingRewards',
    })

    // Skip this run: not worth the gas yet.
    if (pending < minRewards) {
      return { canExec: false, message: `${pending} pending` }
    }

    return {
      canExec: true,
      calls: [{
        to: vault,
        data: encodeFunctionData({ abi, functionName: 'harvest' }),
      }],
    }
  },
})

The task context gives you what you need:

ctx.args: typed inputs, validated against your Zod schema
ctx.client: a viem client for chain reads
ctx.secrets: only the project secrets bound to this executable
ctx.storage: JSON state that persists between runs

A run that returns canExec: false sends no transaction. One run can return up to 32 calls, which are executed atomically in one transaction.

2. Run it locally

npm install -g @thyme-labs/cli
thyme init my-automation
thyme run harvest-rewards --simulate

The CLI runs your task in a local sandbox and simulates the returned calls against a real RPC. Nothing is signed or broadcast.

3. Upload it

thyme upload harvest-rewards --tag v1

This bundles the task into an immutable, checksummed release. A tag can't be overwritten, so you always know which code is running.

4. Schedule it

In the console, create an executable. You pick the Safe it runs from, its arguments and secrets, and when it runs:

Cron: any standard cron expression. The console reads it back in plain words before you save.
Interval: from every 30 seconds up to once a day.
Webhook: up to ten named, secret URLs per executable. Each request body is validated against your task's schema.

Flow handles the schedule, the signing and the gas from there. Every run shows up in the execution logs, with its decision, calls and transaction hash.

How it stays safe

Automation that can move funds needs a tight trust model. Here's ours.

Your Safe stays yours

Your wallet owns the Safe. Flow gets a scoped executor role through the Zodiac Roles module, and that role can only:

call the contract addresses and functions you allowlist
send calls with zero native value, and never delegatecall

The executor can't widen its own role or administer your Safe. Only you, as the owner, can approve a broader scope, and you sign that change yourself.

Revoke any time

Remove the role or the module from your Safe and Flow can't submit anything, ever. That's a normal Safe transaction, and it doesn't need our permission. Pausing an executable in the console stops runs too.

Check before you sign

When you set up a Safe profile, the console checks the deployed contract code against pinned hashes before it asks for your signature.

You don't have to take our word for it, either. thyme verify roles-profile independently rebuilds the setup from pinned Safe and Zodiac Roles versions, then checks the signature request or the deployed contracts against the allowlist you intended. It never calls the Thyme API.

Declare what your code may call

A task can ship a permissions.json that lists the contracts and functions it needs:

{
  "calls": [
    { "target": { "arg": "vault" }, "function": "harvest()" }
  ]
}

Flow checks that your Safe's role covers these calls before you can enable an executable. At runtime, any call outside the declaration is rejected before it's submitted. The manifest isn't a grant: only your signed Safe scope can give access.

Secrets stay out of your code

Secrets live in a vault, not in your bundle. You bind each one to the executables that need it, and Flow redacts known secret values from logs.

Isolated runs

Every cloud run executes in an isolated sandbox with a 30-second timeout. Each executable's storage is versioned and locked, so overlapping runs can't overwrite each other's state.

An honest caveat

Roles scopes restrict the target contract and function, not the arguments. If you allow transfer or approve, the task chooses the recipient and amount. Only allow functions you'd trust your task with, and keep only the funds the automation needs in the Safe.

Works with your coding agent

Paste one prompt into Claude Code, Codex, Cursor or another coding agent, and it learns the thyme CLI. It can write and test a task, upload it, create the executable, set the schedule and read run logs.

Creating a Safe profile, or widening what it may call, still needs your signature in the console.

Try it

Start building: https://flow.thymelabs.io
Quickstart: https://flow.thymelabs.io/docs/getting-started/quickstart
SDK and CLI (open source, MIT): https://github.com/thyme-labs/sdk

Flow is part of thyme/labs, which also offers RPC (Gate) and hosted subgraphs (Atlas) in the same workspace.

What would you automate first? Tell us in the comments. 👇

DEV Community: Jakhongir Tashpulatov

Gelato Web3 Functions shut down. Here's how to port yours

The short version

Before: a Gelato oracle function

After: the same function on Thyme Flow

Mapping the rest

Where it is different

Let your coding agent do it

Coming from Chainlink Automation instead?

Links

Meet Thyme Gate

Keep your client, change the URL

1. Create a key

2. Choose a network

3. Send a request

Supported networks

See the traffic behind the bill

Keys you control

Try it

Meet Thyme Atlas

Keep the Graph CLI, change the node

1. Create a subgraph

2. Create a deploy key

3. Run graph deploy

One endpoint, keys you control

Ship the next version without downtime

Supported networks

Try it

Meet Thyme Flow

How it works

1. Write a task

2. Run it locally

3. Upload it

4. Schedule it

How it stays safe

Your Safe stays yours

Revoke any time

Check before you sign

Declare what your code may call

Secrets stay out of your code

Isolated runs

An honest caveat

Works with your coding agent

Try it

3. Run `graph deploy`