Skip to Content
Early draft of the Exec402 docs. Interfaces and APIs may change.
Introduction

Introduction

Exec402 is a decentralized execution layer that extends the x402 model for HTTP‑native payments to any chain and any token, adding a permissionless network of executors for agents and dapps.

The core idea is simple:

Agents or dapps sign lightweight payment authorizations, not raw transactions.
The Exec canister turns those into tasks.
A network of executors settles those tasks on-chain via ExecCore contracts and earns fees,
while the protocol verifies everything and splits fees transparently on-chain.

Why Exec402 exists

Today, many agents and dapps that want to run non‑trivial on-chain workflows run into a different set of problems:

  • They want to mint, swap, stake, bridge, or compose DeFi strategies, but each protocol and chain has its own bespoke interface and authorization model.
  • They want to support multiple chains and tokens, but end up duplicating “facilitator logic” and routing code for every new environment.
  • They need batched and atomic execution (e.g. swap → bridge → stake), yet lack a shared way to express and safely execute multi-step workflows.
  • They would like permissionless executors to handle gas and liveness, but there is no common, on-chain fee model that makes this sustainable.

Exec402 exists to provide a shared execution layer for these workflows:

  • a standard task format for multi-chain, multi-token, multi-step on-chain actions,
  • a common execution pathway via the Exec canister and ExecCore contracts instead of bespoke DeFi facilitators,
  • and a transparent fee model that splits rewards between referrers, executors, and the protocol.

From x402 to Exec402

x402 is an HTTP‑402 based open payment standard for machine‑native, pay‑per‑use stablecoin payments between agents and HTTP services:

  • Clients (apps or AI agents) call an x402‑enabled API.
  • The server responds with a 402 Payment Required payload describing price, token (e.g. USDC), network, and expiry.
  • The client signs an x402 payment authorization (for example, using an EIP‑3009–style permit) and retries the request with an X-PAYMENT header.
  • A facilitator verifies and settles the payment on-chain, and the server returns the resource with an X-PAYMENT-RESPONSE header.

This works extremely well for off-chain services (APIs, software, digital content), but it raises a harder question:

How should agents interact with on-chain protocols—minting, swapping, staking, or bridging across chains—
using similar machine-native, pay-per-use semantics?

Without Exec402, each project that wants “x402-style DeFi workflows” has to:

  • hand‑roll complex, chain-specific logic for each protocol,
  • decide how to encode multi-step, multi-chain actions,
  • and manage how payments, permits, and fee splits should be structured and verified.

Exec402 extends these ideas specifically for on-chain workflows:

  • Supports multiple permit / authorization standards like EIP‑2612 and Uniswap Permit2.
  • Integrates with Across protocol to move value across chains and tokens.
  • Uses an improved multicall handler so DeFi interactions can be batched and executed atomically:
    • e.g. swap → bridge → stake in one logical task, all succeed or all revert.

In short, x402 standardizes HTTP-native, pay-per-use stablecoin payments between agents and services,
while Exec402 standardizes how those same agents pay for and execute complex, multi-chain on-chain workflows.

Exec402 takes the 402-style economic model further:

  • Multi-token – supports multiple permit / authorization standards instead of a single token.
  • Multi-chain – designed to work across chains and DeFi protocols instead of being locked to one.
  • Decentralized executors – anyone can run an executor bot, pick up tasks, and earn fees.
  • Fully on-chain verification – ExecCore contracts and the underlying chains decide outcomes; executors are not trusted.

High-level architecture

At a high level, Exec402 consists of three main pieces that work together:

  1. Agents or dapps (initiators)

    • Use the Exec402 SDKs to call the Exec canister (/call, /transfer, etc.).
    • Sign x402-style payment authorizations with their wallet (no raw transaction building).
    • Treat Exec402 as “charge the user and execute this call later”.

  2. Exec canister (task registry)

    • Receives requests and, if needed, responds with a 402 Payment Required body describing what to pay.
    • Once the wallet signs, records a task with:
      • chain and target contract to call,
      • calldata,
      • payment token, amount, and permit type,
      • referrer address and optional metadata.
    • Exposes /tasks and /tasks/{id}/refresh so frontends, SDKs, and executors can track status.

  3. ExecCore contracts and executors (settlement layer)

    • Executors poll the Exec canister for pending tasks.
    • For each profitable task, an executor:
      • constructs a transaction to the ExecCore contract on the target chain,
      • submits the task payload and user authorization,
      • pays gas on-chain.
    • ExecCore contracts:
      • validate the authorization / permit,
      • charge the user in the chosen token,
      • split fees between referrer, executor, and protocol,
      • emit events with execution results.

Everything is designed so that executors remain permissionless and untrusted. If they submit invalid data, ExecCore contracts simply revert and the executor only loses its own gas.

The diagram below shows the end‑to‑end flow between an agent or dapp, the Exec canister, executors, and the ExecCore contracts:

What Exec402 is not

Exec402 is not:

  • a single hosted SaaS API,
  • a custody service,
  • a traditional relayer that you must trust,
  • or a chain / rollup by itself.

It is an execution layer protocol that any agent or dapp can integrate as a referrer, and that any executor can join permissionlessly.

Continue with the Quick Start to see what integrating Exec402 looks like in practice.

Last updated on
OverviewQuick Start