Learn how to use AppKit by Reown to enable wallet connections and interact with any EVM network. With AppKit, you can provide seamless wallet connections, including email and social logins, on-ramp functionality, smart accounts, one-click authentication, and wallet notifications, all designed to deliver an exceptional user experience.

Configure a wallet connection modal and enable interactions with any EVM network.

This guide takes approximately 10 minutes to complete.

In this section, you'll learn how to set up the development environment to use AppKit with EVM.

For this tutorial, we'll be using Next.js, though you can use any other framework compatible with AppKit.

AppKit is available on eight frameworks, including React, Next.js, Vue, JavaScript, React Native, Flutter, Android, iOS, and Unity.

Now, let’s create a Next app. In order to do so, please run the command given below:

npx create-next-app@latest appkit-example

The above command creates a Next app and sets the name of the Next app as “appkit-example”.

Now, we need to install AppKit and other dependencies that we need for our app to function as expected. For this tutorial, we will be using “wagmi” as our preferred Ethereum library. However, you can also use 

npm install @reown/appkit @reown/appkit-wagmi-adapter wagmi @tanstack/react-query

You can also use other package managers such as 

Now, we need to get a project Id from Reown Cloud that we will use to set up AppKit with Wagmi config. Navigate to 

 and sign in. If you have not created an account yet, please do so before we proceed.

After you have logged in, please navigate to the “

” section of the Cloud and click on “

Now, enter the name for your project and click on “

”. Reown Cloud will now create a new project for you which will also generate a project Id.

You will notice that your project was successfully created. On the top left corner, you will be able to find your Project Id. Please copy that as you will need that later.

Introduction

Before we build the app, let’s first configure our 

 file. On the root level of your code directory, create a new file named 

Open that file and create a new variable 

. You will assign the project Id that you copied in the previous step to this environment variable that you just created. This is what it will look like:

NEXT_PUBLIC_PROJECT_ID = <YOUR_PROJECT_ID_HERE>

 Please make sure you follow the best practices when you are working with secret keys and other sensitive information. Environment variables that start with 

 will be exposed by your app which can be misused by bad actors.

On the root level of your code directory, create a new folder named 

 and within that folder, create a new code file named 

. Now, paste the code snippet shared below inside the code file, i.e., 

import { EVMWagmiClient } from "@reown/appkit-adapter-wagmi";
import { cookieStorage, createStorage } from "wagmi";
import { mainnet, arbitrum } from '@reown/appkit/networks'

// Get projectId from https://cloud.reown.com
export const projectId = process.env.NEXT_PUBLIC_PROJECT_ID;

export const networks = [mainnet, arbitrum]

if (!projectId) throw new Error("Project ID is not defined");

// Set up the Wagmi Adapter (config)
export const wagmiAdapter = new WagmiAdapter({
  storage: createStorage({
    storage: cookieStorage
  }),
  ssr: true,
  networks,
  projectId
})

export const config = wagmiAdapter.wagmiConfig

So what's happening in the above code? Let's understand it step-by-step:

First, we need to import the necessary functions from their respective packages.

Now, we need to create a context provider to wrap our application in and initialize AppKit.

'use client'

import { wagmiAdapter, projectId } from '@/config'
import { createAppKit } from '@reown/appkit/react' 
import { mainnet, arbitrum } from '@reown/appkit/networks'

import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
import React, { type ReactNode } from 'react'
import { cookieToInitialState, WagmiProvider, type Config } from 'wagmi'

// Set up queryClient
const queryClient = new QueryClient()

if (!projectId) {
  throw new Error('Project ID is not defined')
}

// Set up metadata
const metadata = { //this is optional
  name: "appkit-example",
  description: "AppKit Example - EVM",
  url: "https://exampleapp.com", // origin must match your domain & subdomain
  icons: ["https://avatars.githubusercontent.com/u/37784886"]
}

// Create the modal
const modal = createAppKit({
  adapters: [wagmiAdapter],
  projectId,
  networks: [mainnet, arbitrum],
  metadata: metadata,
  features: {
    analytics: true, // Optional - defaults to your Cloud configuration
    email: true, // default to true
    socials: ['google', 'x', 'github', 'discord', 'apple', 'facebook', 'farcaster'],
    emailShowWallets: true, // default to true
  },
  themeMode: 'light'
})

function ContextProvider({ children, cookies }: { children: ReactNode; cookies: string | null }) {
  const initialState = cookieToInitialState(wagmiAdapter.wagmiConfig as Config, cookies)

  return (
    <WagmiProvider config={wagmiAdapter.wagmiConfig as Config} initialState={initialState}>
      <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
    </WagmiProvider>
  )
}

export default ContextProvider

Let’s understand what is happening in the above code:

First, we import the necessary functions from their respective packages. After this, we need to create the modal component for our app.

 - This object contains information about our application that will be used by AppKit. This includes the name of the app, the description, the url and the icons representing our app. 

 - this is called to initialize the AppKit component, which handles the user interface for connecting to blockchain wallets. The function is configured with various options, such as the app's metadata, theming, and enabling features like analytics and onramp services.

: Provides blockchain and wallet connection context to the app.

Now, let’s create the layout for our app. In 

, remove the existing code and paste the code snippet given below.

import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

import { headers } from "next/headers"; // added
import ContextProvider from '@/context'

export const metadata: Metadata = {
  title: "AppKit Example App",
  description: "Powered by Reown"
};

export default function RootLayout({
  children
}: Readonly<{
  children: React.ReactNode
}>) {
  const cookies = headers().get('cookie')

  return (
    <html lang="en">
      <body className={inter.className}>
        <ContextProvider cookies={cookies}>{children}</ContextProvider>
      </body>
    </html>
  )
}

For our app to have the UI with which your users can interact, you need to set a simple UI and configure the modal. Since, we have already set up AppKit, you can use 

 which will serve as a “Connect Wallet” button or you can build your own custom button using the 

 file and remove the existing boilerplate code, and then replace it with the code snippet given below.

"use client";
import { useAccount } from "wagmi";

export default function Home() {
  const { isConnected } = useAccount();

  return (
    <main className="min-h-screen px-8 py-0 pb-12 flex-1 flex flex-col items-center">
      <header className="w-full py-4 flex justify-between items-center">
        <div className="flex items-center">
          <img src="/reown-logo.png" alt="logo" className="w-35 h-10 mr-2" />
          <div className="hidden sm:inline text-xl font-bold">Reown - AppKit EVM</div>
        </div>
      </header>
      <h2 className="my-8 text-2xl font-bold leading-snug text-center">Examples</h2>
      <div className="max-w-4xl">
        <div className="grid bg-white border border-gray-200 rounded-lg overflow-hidden shadow-sm">
          <h3 className="text-sm font-semibold bg-gray-100 p-2 text-center">Connect your wallet</h3>
          <div className="flex justify-center items-center p-4">
          <w3m-button />
          </div>
        </div> 
        <br></br>
        {isConnected && (
          <div className="grid bg-white border border-gray-200 rounded-lg overflow-hidden shadow-sm">
            <h3 className="text-sm font-semibold bg-gray-100 p-2 text-center">Network selection button</h3>
            <div className="flex justify-center items-center p-4">
              <w3m-network-button />
            </div>
          </div>
        )}
      </div>
    </main>
  );
}


The code above uses the AppKit configuration to provide two buttons: one for users to connect their wallet to the app, and another to allow users to switch networks.

You can now run the app and test it out. In order to do so, run the command given below.

If you are using alternative package managers, you can try either of these commands - 

And that’s it! You have now learned how to create a simple app using AppKit that allows users to connect their wallet and interact with any EVM network.

You can view the complete code repository below.

If you're wondering how to use Reown for various use cases and build apps with great UX, feel free to check out our other blogs below.

Build the App using AppKit

How to Integrate Reown AppKit on EVM

Reown

Rohit Ramesh

Head of DevRel at Reown

1inch is a network of protocols on Ethereum and EVM blockchains. It is most known for its swap protocols, but this is only the beginning for what 1inch has to offer the community. Beyond swapping, 1inch also has a comprehensive set of APIs that can be used to build out any blockchain application. Token details/prices, gas costs, and transaction analysis are just some of the data that is available through 1inch APIs. Additionally, 1inch has also created public goods like Token Plugins, enabling users to design ERC20 tokens with more security and modularity. Let's take a look at each of these in more detail. 

Introduction 

1inch has four swap protocols (listed in chronological order):

Classic Swap (previously known as Aggregation Protocol)

Each of these swap protocols has the same goal: give users efficient access to onchain liquidity. Let's briefly look at each one:

 (previously known as Aggregation Protocol) is 1inch's original swap protocol and has been a leader in onchain swaps since 2019. It was heavily used during DeFi summer and has never let go of its position as the best DEX aggregator on Ethereum. The router is currently on version 6 and is trusted by protocols across the entire ecosystem. 

 is an onchain limit order system, enabling tokens to be listed at a specific price for a specific token. This allows specific sell points for users with gasless execution (the person who ultimately fills the order will also pay the gas). Our orderbook protocol is also tracked by our aggregation protocol to further reduce price impact for swaps. 

Fusion Mode is our implementation of intent swaps. Users simply tell us what token they want to sell and a dutch auction is triggered. During this dutch auction (lasting a couple minutes), a decentralized set of resolvers compete to fill the order at the best rate possible. This simplifies the user experience further as they do not need to concern themselves with price impact, slippage, or even gas costs. They are able to click a single button and get the best rate available for their tokens. 

Fusion+ is the long-awaited cross-chain solution built natively into 1inch! Built on top of the Fusion rails, this extends the functionality to allow a swap between any two tokens on any of our supported EVM chains.

We will discuss using these swap protocols as they pertain to application development in the 

 section, but before that, let's talk about 1inch's suite of REST APIs.

Swap Protocols

Beyond swap protocols, 1inch has also built and released a comprehensive set of REST APIs that dApp developers can leverage to greatly speed up development. Some examples:

Whether you want to add swaps into your application or utilize one of our many REST APIs to get onchain data, access to either of these tools will be through the 1inch Developer Portal.

Infrastructure APIs

The 1inch Developer Portal is the hub for accessing 1inch APIs. It contains API keys, API documentation, and usage metrics for your project. If you continue to use 1inch APIs outside of a hackathon setting, visit portal.1inch.dev to sign up for an account (you can skip this step for now).

Since this is a hackathon, we are skipping the normal onboarding flow and giving hackers a special process of acquiring an API key. Create your Developer Portal account through this link: 

Note: the API keys created for this hackathon will be disabled after the event

Requests to the 1inch API are documented at 

Additionally, you can use our Typescript and Golang SDKs to make API interactions easier. The SDKs are generally the preferred way to interact with our APIs and are necessary to interact with our Orderbook and Fusion systems:

Developer Portal API Requests from frontends

Due to 1inch API calls requiring an authorization token in the headers, developers must explicitly hide the 1inch API call from browsers using a proxy. If a proxy is not used, the request will fail with a CORS error. 

Here are two ways to get past the CORS restriction:

events {
}

http {
    limit_req_zone $binary_remote_addr zone=mylimit:100m rate=40r/m;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    server {
        listen 80;
        server_name 127.0.0.1;

        location / {
            limit_req zone=mylimit burst=1000;
            proxy_pass https://api.1inch.dev/;
            proxy_set_header X-Forwarded-Proto https;
            proxy_ssl_server_name on;
            proxy_set_header Authorization "Bearer replace_this_with_dev_portal_api_token";
            proxy_pass_header Authorization;
        }

        location /health {
            add_header Content-Type text/plain;
            return 200 'ok';
        }
    }

}

version : "3"
services :
  nginx:
    image: nginx:latest
    container_name: nginx_container
    ports:
      - 8888:80
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf

Onto the final hackathon topic, one of 1inch's public goods, Token Plugins!

1inch Developer Portal

Token plugins are smart contracts that extend the capabilities of ERC20 tokens and wrappers by adding custom accounting features to the original token. The major benefit, and a key difference from existing solutions, is that these do not require token transfers to a special smart contract, as is commonly seen in farming or delegating protocols. Another beneficial point is that once an ERC20 plugin code is deployed, it can be reused by any tokens that support the 1inch plugin standard.

Support for plugins on the side of a token is as straightforward as the usage of any other ERC20 extensions (e.g., OpenZeppelin ERC20 extensions). The deployment and usage are permissionless from the perspective of a token contract owner, since the holder is the actor who decides which plugin to subscribe to.

The token plugins standard is designed to be secure and to prevent asset loss, gas, and DoS attacks on transfers.

Here are some examples of how Token Plugins is being (or could be used) today:

Staked 1INCH tokens earn rewards from Resolvers in the Fusion system. In order to earn rewards, the tokens must be pointed to a specific Resolver. The resolver is incentivized to have st1INCH pointed at them, so they will reward delegators with some amount of funds. The delegation of st1INCH is done with a token plugin, so there is no need to transfer the tokens to another contract. 

VE governance models like veCRV require the user to lock tokens for a certain amount of time to earn voting rights. This signals to the protocol a long-term vested interest and greatly reduces the surface area for governance attacks. With Token Plugins, this model can now be reversed and align long-term token holders with additional voting power.

Some protocols incentivize LP token holders with additional rewards beyond swap fees through an additional yield contract that holds the LP tokens and distributes the rewards proportionally to the participating LPs. With token plugins, this extra rewards for LP holders can continue to be opt-in without the need to deposit those LP tokens into a secondary contract.

If a protocol wanted to simply reward holders of their token, they could reward them similarly to the weighted voting power method, but instead of increasing voting power over time, the APR of holding the token can increase. Long-term holders will receive rewards and short-term holders/traders would not receive the same benefit.

A full writeup of Token Plugins' design, risks, etc. can be found 

Token Plugins

Due to 1inch's use of live protocols and counterparties, 

This can be tested locally using a combination of our live swap API and a local fork of mainnet. A simple repository that can achieve this can be found 

This can also be tested locally using a similar approach to Classic Swap. Use that example to get started

These protocols require live counterparties to function properly. Come see us in person to get assistance on testing this for your project!

Testing 1inch protocols

Building with 1inch

1inch

Tanner Moore

A VRF or Verifiable Random Function is a unique blend of cryptographic techniques that generates pseudorandom numbers in a publicly verifiable manner. Think of VRF as a way to generate random numbers where:

The entity possessing a secret key can compute the random number and also provide a proof of its correctness.

Anyone with the public key can verify that the random number was indeed computed correctly, ensuring the integrity of the result.

In simple terms, VRFs are like cryptographic hash functions but with an added layer of public verification. They're an essential tool in systems where the trustworthiness of random outputs is highly important.

Gelato VRF offers real randomness for blockchain applications by leveraging Drand, a trusted decentralized source for random numbers. With Gelato VRF, developers get random values that are both genuine and can be checked for authenticity.

The potential applications of a reliable and transparent random number generator on the blockchain are vast. Here are just a few use cases:

 Determine fair outcomes for online games or decentralized gambling applications.

 Use in protocols where random selections, like lottery systems, are required.

 Randomly generate traits or characteristics for unique digital assets.

 In protocols where decisions need to be randomized, such as selecting validators or jurors.

This is the heart of the randomness. Drand is a decentralized randomness beacon, ensuring the unpredictability and unbiased nature of the random numbers provided. To learn more about Drand and how it works, please refer to 

Developers deploy their smart contract inheriting the GelatoVRFConsumerBase.sol. This contract serves as an interface to the Gelato VRF system, allowing other smart contracts to request and receive random numbers.

Your contract emits a RequestedRandomness event. Your contract inherits the GelatoVRFConsumerBase.sol contract which serves as an interface to the Gelato VRF system, allowing other smart contracts to request and receive random numbers.

Web3 functions listen for the event and fetch the random number from Drand.

The random number is delivered to your contract through the fulfillRandomness function.

How does Gelato VRF work?

Foundry or Hardhat development environment

Fill in .env with variables in .env.example

: forge install gelatodigital/vrf-contracts --no-commit

The recommended approach to integrate Gelato VRF is by inheriting from the GelatoVRFConsumerBase smart contract. Here's a simple example to help you set it up:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.18;

import {GelatoVRFConsumerBase} from "./GelatoVRFConsumerBase.sol";

contract YourContract is GelatoVRFConsumerBase {
    // Your contract's code goes here
}

To request randomness, call the _requestRandomness() function. You should protect the call since it will deduct balance from your 1Balance. The data argument will be passed back to you by the W3F.

   function requestRandomness(bytes memory data) external {
        require(msg.sender == ...);
        uint64 requestId = _requestRandomness(data);
    }

   function _fulfillRandomness(
        bytes32 randomness,
        uint64 requestId,
        bytes memory data,
    ) internal override {
    }
}

When you're ready to deploy your Gelato VRF-compatible contract, an important step is to include the dedicated msg.sender as a constructor parameter. This ensures that your contract is set up to work with the correct operator for fulfilling the randomness requests.. It's crucial for ensuring that only authorized requests are processed.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.18;

import {GelatoVRFConsumerBase} from "./GelatoVRFConsumerBase.sol";

contract YourContract is GelatoVRFConsumerBase {
    constructor(address operator)
        GelatoVRFConsumerBase(operator) {
        // Additional initializations
    }

    // The rest of your contract code
}

and once you have your contract ready & deployed, grab the address and Deploy your VRF instance!

Quick Start

Before you begin, make sure you have the address of your requester contract at hand. This will be essential for the deployment process.

, sign in and create on click on "Create new" to create a new task.

When prompted to select the VRF type, opt for "Gelato VRF". 

Ensure you choose the same network where both your VRF requester and receiver contracts are deployed.

You'll be asked to provide the address of the Request Contract to which the Gelato nodes should respond. Enter the address you gathered in step 1.

Once all details are correctly entered, go ahead and launch your Gelato VRF instance.

When you call the requestRandomness in your consumer contract, you should see a execution shortly in your task indicating that the randomness was deliver to your contract.

Deploying your VRF instance

Resources

Introduction to VRF with Gelato

Gelato

Anirudh

This developer guide will walk you through setting up a new Relay app, configuring the preferred network details, setup basic wallet connection, test and deploy your contract through a hardhat configuration in order to achieve gasless transaction for your users.

Introduction to Gelato Relay

Using Gelato Relay, we relay your user's transactions on-chain, enabling secure 

transactions for an ultra smooth UX for your app. This allows for a variety of new web3 experiences, as the user can now send transaction by only signing a message where relay costs are covered in either native or ERC-20 tokens and they are paid synchronously during the relay call (

), or their transaction costs can be sponsored by 

Before diving into Gelato Relay works, it’s essential to understand the concept of meta transactions. 

A meta transaction is a regular ethereum transaction which contains the actual message to be delivered on-chain to a 

. The outer transaction helps facilitate the first on-chain call which is sent by a relayer. The call is forwarded to the 

 contract using an intermediate smart contract (Gelato Relay), which in turn forwards the call using the inner transaction to deliver the relayed message.

 contracts into your smart contract, you can enable gasless transactions and securely authenticate user signatures. As requests are submitted to Gelato Relay, a network of decentralised Gelato Executors will execute and get the transactions validated as soon as possible

 enforce the integrity of data)
While transactions are either sponsored by the 1Balance or paid by the target contract through SyncFee. The system ensures that each transaction is processed securely, with proper validation of user signatures and relay contexts.

Please refer to the implementation of these contracts below:

 most sales on Highlight let anyone "sponsor" a number of mints by paying for their price and mint fee. This allows other people to mint without incurring gas fees or transaction costs, simply by clicking a button, and without needing to approve any wallet transaction.

 tokenizes real-world collectibles directly to your digital wallet and lets you trade them

 utilizes Relay to automate the breeding process of digital racehorses, enabling decentralized and seamless on-chain execution without manual intervention

What is Gelato Relay?

At this point you will have to answer a few questions:

Do you require user authentication? ERC2771 or non-ERC2771?

What is the funding strategy? Off chain or on-chain payments?

It relies on the ERC-2771 standard, which ensures secure meta-transactions by verifying the user's signature before relaying the transaction. In practice, the user's address is encoded in the transaction data off-chain and decoded on-chain using the ERC2771Context contract, the relay contract validates the signature and appends the user's 20-byte address to the end of the calldata. This guarantees that the transaction originates from the correct user. This method provides a gasless experience for their users, with Gelato covering the gas fees via the 1Balance payment method and require authenticate the users.

Similar to sponsoredCallERC2771, but in this case, the developer is responsible for verifying the user’s signature and ensuring transaction security (such as replay protection). The nature of  sponsoredCall is permissionless and does not enforce any security. The developer sponsors the users' gas fees without relying on ERC-2771’s signature verification. This method is useful when an application already has in-house security measures and wants to sponsor users' gas without modifying the smart contract to support ERC-2771

It combines the ERC-2771 meta-transaction capabilities with the SyncFee model, where the target contract pays the fee to Gelato during transaction execution. The fees are estimated using Gelato’s Fee Oracle, and the relay context contracts handle the fee transfer in the background. This method is suitable for developers who want users to cover their transaction fees while maintaining secure signature verification.

This method allows users to pay for their own gas fees through the 

 payment model without the added security of ERC-2771. When using callWithSyncFee relay method the target contract assumes responsibility for transferring the fee to Gelato's fee collector during transaction execution. For this, the target contract needs to know:

feeCollector: the destination address for the fee

Gelato provides some useful tools within the

  contract in your target contract, you have the ability to transfer the fee through one of two straightforward methods: 

transferRelayFeeCapped(uint256 maxFee). In either case, the inherited contract takes care of decoding the fee, feeToken, and feeCollector behind the scenes.

Relay Methods

Before beginning, ensure you have the following installed or set up on your computer:

API Key from Gelato: Sign up for an API key at

Install the Gelato Relay SDK in your project using npm or yarn:

npm install @gelatonetwork/relay-sdk ethers

Step 2: Deploy or Use an ERC-2771 Compatible Contract

You need an ERC-2771 compatible smart contract. If you don't have one, you can deploy the example contract 

// SPDX-License-Identifier: MIT
pragma solidity 0.8.17;

import { ERC2771Context } from "@gelatonetwork/relay-context/contracts/vendor/ERC2771Context.sol";

contract CounterERC2771 is ERC2771Context {
    mapping(address => uint256) public contextCounter;

    event IncrementCounter(address _msgSender);

    constructor(address trustedForwarder) ERC2771Context(trustedForwarder) {}

    function increment() external {
        contextCounter[_msgSender()]++;
        emit IncrementCounter(_msgSender());
    }
}

This contract implements ERC-2771 and tracks a counter for each user.

In your TypeScript project, import the Gelato Relay SDK and ethers

import { GelatoRelay } from "@gelatonetwork/relay-sdk";
import { ethers } from "ethers";

// Initialize Gelato Relay
const relay = new GelatoRelay();


Set up the necessary variables for interacting with your smart contract, such as the contract address, ABI, and user information.

// Set up the contract address and ABI
const counterAddress = "0x00172f67db60E5fA346e599cdE675f0ca213b47b";  // replace with your contract address
const abi = ["function increment()"];
const provider = new ethers.JsonRpcProvider(url); // replace with your json-rpc endpoint
const signer = await provider.getSigner();
const userAddress = await signer.getAddress();

// Create the contract instance
const contract = new ethers.Contract(counterAddress, abi, signer);

// Generate the data for the relay request
const { data } = await contract.incrementContext.populateTransaction();

You need to create the relay request containing the chain ID, contract address, user address, and encoded function data.

const request = {
  chainId: (await provider.getNetwork()).chainId,
  target: counterAddress,
  data: data,
  user: userAddress,
};

To sponsor the transaction, you need an API key from Gelato. If you don’t have one, go to

const apiKey = "your_gelato_api_key";  // Replace with your actual API key

Now that you have prepared the relay request, use the sponsoredCallERC2771 method to send the request through Gelato

const relayResponse = await relay.sponsoredCallERC2771(request, provider, apiKey);
console.log("Relay response:", relayResponse);

Once you send the request, the response will include a unique taskId, which can be used to track the status of the transaction.

const taskId = relayResponse.taskId;
console.log(`Task ID for the transaction: ${taskId}`);

When submitting your Gelato Relay requests, you'll receive a taskId in response. This taskId allows you to track the status of your request in two primary ways:

1. WebSocket Subscriptions: This is the recommended and most efficient method. By subscribing via WebSocket, the Gelato backend will automatically push updates for all your tasks to your Relay SDK client. To start receiving these updates, you must register a callback function, which will be triggered every time one of your tasks gets updated.


2. Polling for Updates: Alternatively, you can periodically query the Gelato task status API for updates. If you're using the Gelato Relay SDK, the getTaskStatus method makes this easy. 

For further information on how to track your relay request, please refer 

Tracking your Request

Gelato Relay makes gasless transactions simple by using ERC-2771 and Gelato’s system for managing fees. Throughout this guide, we've explored the setup of the Gelato SDK, contract deployment, and how to configure the relay service using sponsoredCallERC2771


Additionally, other relay methods like sponsoredCall and callWithSyncFee provide alternative options for managing gas fees, allowing developers to choose the most suitable approach for their applications.

Guides

Interested in contributing? Ping us at [email protected]

How to Integrate Reown AppKit on EVM

Building with 1inch

Introduction to VRF with Gelato

Introduction to Relay with Gelato

Introduction to Automation/Web3 functions with Gelato

Simplify Onchain Data with Goldsky

Building dApps for Cars

Intro to The Graph and Querying Subgraphs

Introduction to Hedera

Introduction to Zircuit

Efficient Data Indexing Using SubQuery Network

A Complete Guide to Oracles

All You Need To Know About Our Hackathons!

Intro to Celo

Building a Superfluid Super App

Introduction to Unlock Protocol

Creating ERC20 Token on Polygon

Intro to Sequence Smart Contract Wallet

Introduction to MetaMask Snaps

Introduction to Optimism

Introduction to Livepeer

Verifying Storage on Filecoin

Introduction to libp2p

Smart Contract Development Guidelines

Bridging Tokens & Data

Intro to Push Protocol

Intro to Ethereum Name Service

Money Streaming with Solidity 101

Getting started with Metamask