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

FAQ

Frequently asked questions about Exec402.

How is Exec402 different from a typical relayer or facilitator?

Traditional relayer setups:

  • are usually centralized,
  • implement their own custom logic,
  • often have opaque fee structures.

Exec402 instead:

  • defines a standard task format and shared task registry (the Exec canister),
  • moves validation and fee math on-chain into ExecCore contracts,
  • lets any executor participate permissionlessly.

Executors are just gas-paying broadcasters; the chain decides outcomes.

x402 is an HTTP‑native stablecoin payment standard: servers return 402 Payment Required, and wallets use stablecoins to pay for APIs, content, and software over HTTP.

Exec402 extends this idea to on-chain execution:

  • x402 standardizes how agents pay HTTP services;
  • Exec402 standardizes how those same agents pay for and execute on-chain workflows across multiple chains and tokens.

Exec402 can sit behind an x402-enabled API, but it does not require x402 to be useful.

Do users need native gas tokens?

Not for the Exec402 part of the flow.

  • Users (or agents) sign x402-style payment authorizations and token permits.
  • Executors pay gas to submit ExecCore transactions.
  • Payment is made in the token specified by the task (for example, a stablecoin).

However, users may still need native gas for other, unrelated interactions in your product.

Which chains does Exec402 support?

Exec402 is designed to be multi-chain. A task always specifies chainId, and ExecCore is deployed per chain.

See Supported Chains for the current list of mainnet and testnet deployments, and the Exec canister /info endpoint for up-to-date configuration.

Which tokens and permit types are supported?

Exec402 focuses on tokens that support off-chain permissions via:

  • EIP‑3009 (eip3009),
  • EIP‑2612 permit (permit),
  • Permit2 (permit2).

As long as a token satisfies the required permit type, it can be integrated. See Permit Types for details and recommended choices (e.g. USDC via EIP‑3009).

Is Exec402 custodial?

No.

  • Users keep control over their funds.
  • They only sign authorizations and permits that are bounded by:
    • a specific task payload,
    • a maximum amount + fee,
    • an expiration time.
  • Funds move directly from the initiator to the target/recipients and fee recipients via ExecCore.

Executors never custody user funds; they only pay gas and receive their share of the fee when tasks execute.

Who decides the fee, and how is it split?

  • Referrers (agents or dapps) propose a fee for each task in their product UX.
  • Users or agents explicitly confirm this fee when they sign the payment authorization.
  • When the task executes, ExecCore:
    • takes a fixed 10% protocol fee,
    • pays the configured referrer share (currently 60% of the total fee),
    • sends the remainder (currently 30%) to the executor.

All of this math is done on-chain and can be audited in the ExecCore contracts.

What happens if an ExecCore transaction fails?

If an ExecCore transaction reverts:

  • no tokens are moved from the initiator,
  • no fees are paid,
  • the executor only loses the gas spent on that attempt.

If a target contract reports success but some internal step “fails” at the application level, that behavior is defined by the target contract itself; Exec402 does not override its logic.

What happens if an executor disappears?

If one executor stops operating:

  • other executors can still pick up and execute tasks,
  • tasks may be delayed, but not lost (subject to their expiration time).

Network liveness improves as more executors join and compete for fees.

Can I run my own private executor?

Yes.

  • You can run an executor that only executes:
    • tasks from your own products,
    • or tasks that satisfy specific filters (chains, tokens, targets).
  • You can also operate both as:
    • a referrer (your product),
    • and an executor (your infra).

The protocol does not enforce how centralized or decentralized the executor ecosystem must be; it only ensures that anyone else could also join.

Do I need to use Exec402 if I already use x402?

Not necessarily.

  • If you only sell off-chain APIs / content / software, x402 alone may be enough.
  • If you want on-chain workflows (mint, swap, stake, bridge, cross-protocol multicalls) with the same pay‑per‑use semantics, Exec402 gives you a standard way to do that across chains and tokens.

You can adopt Exec402 incrementally for the parts of your product that need on-chain execution.

Where can I learn more?

Last updated on
Executors