docs(features): add Gasless Execution intro

[scout-relayprotocol]

Implements MAR-1403: Create Gasless Execution feature page

What this changes

• Adds the approved Gasless Execution marketing intro to features/gasless-execution.mdx.
• Explains the stablecoin-without-gas problem, Relay's execution model, supported EVM account types, benefits, and target integrators.
• Preserves the existing technical integration guide below the new intro.

How I verified

• Parsed docs.json successfully.
• Validated the MDX frontmatter, expected sections, and balanced code fences.
• Ran git diff --check successfully.
• This repo does not define a local package-based lint or test command; GitHub/Mintlify review remains the final rendering check.

Open questions

• None.

---

🤖 Opened by Scout (autonomous). Ready for human review.
Linear: https://linear.app/relayprotocol/issue/MAR-1403/create-gasless-execution-feature-page

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	Jul 31, 2026, 11:02 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[github-actions]

Claude finished @pedromcunha's task in 2m 48s —— View job

---

Code review — PR #389 (docs: Gasless Execution intro)

• Gather context (diff vs origin/main)
• Read full features/gasless-execution.mdx
• Check against AGENTS.md style guide (§2 global rules, §3.1 feature guide profile)
• Verify cross-links and cross-page consistency
• Post review

Reviewed the 45 added lines (features/gasless-execution.mdx:6-49). The prose is strong and the technical bullets at lines 20–22 accurately match the existing accordions further down. Findings below, most significant first. Nothing here is blocking-critical, but #1 and #2 are factual gaps worth resolving before merge.

---

1. The stated cost model contradicts the page's own requirements and Caveats

features/gasless-execution.mdx:14

The user never needs to hold or buy a native gas token: costs are deducted from the token in the flow, so a user holding only USDC pays in USDC.

features/gasless-execution.mdx:30

You choose the cost model. Fees come out of the stablecoin in motion, or you sponsor them for a full 1:1.

Both frame "fees out of the user's token" as a mode that needs no integrator funding. The rest of the page says otherwise:

• features/gasless-execution.mdx:61 (existing) — "you'll need an API key with a linked funding address and a funded app balance." Not optional, not conditional on which cost model you pick.
• features/gasless-execution.mdx:853 (Caveats) — "Should the fees amount to more than the app balance, the transaction will not be sponsored."
• features/fee-sponsorship.mdx:22 — "Your app balance must have enough funds to cover the fees you wish to sponsor."

And references/api/api_guides/calling-integration-guide.mdx:16 draws the distinction the intro collapses: Relay "deducts fees from the user's tokens" at the quote level, but "the initial onchain deposit still requires native gas — this is an EVM-level requirement." What /execute adds is that Relay fronts that origin gas from your app balance. So the two options in line 30 aren't "sponsor vs. don't" — the app balance is funded in both, and the difference is only whether quote fees are passed to the user.

As written, a reader who buys the line-14 promise hits an undocumented funding prerequisite. Suggest making the intro say Relay fronts the origin gas and that origin gas is drawn from your app balance, then let ## How to use it? carry the detail.

Fix this →

2. Account-type list overclaims relative to the msg.sender caveat

features/gasless-execution.mdx:31

Support ERC-4337 smart accounts, EIP-7702-delegated EOAs, embedded wallets, and custodial wallets without building paymaster or bundler infrastructure.

features/gasless-execution.mdx:854 (Caveats) — "If the transaction relies on msg.sender, the transaction signer must be a smart wallet (EIP-7702, ERC-4337, etc)."

A plain embedded or custodial EOA is not a smart wallet, so it isn't covered for msg.sender-dependent transactions. features/gasless-swaps.mdx:16-25 makes exactly this distinction — its decision tree routes embedded/custodial wallets through 4337 or 7702 rather than treating them as a separate supported category. Your own bullet at line 22 hedges correctly ("Any raw transaction that doesn't depend on the submitter"); line 31 drops the hedge. Suggest "embedded and custodial wallets (via 7702 or 4337)" or dropping the last two items.

3. Concepts with their own pages are mentioned without links (§2.6)

§2.6: "When introducing a concept that has its own page, link on first mention."

Mention	Page that exists	Status
:45 "just-in-time gas"	/features/gas-top-up	unlinked, and not the canonical name used anywhere in the docs
:45 "pay-with-any-token"	/use-cases/calling ("pay with any token")	unlinked, non-canonical name
:47 "price stabilization"	/features/price-stabilization	unlinked — solutions/payment-service-providers.mdx:30 links it as **[Price stabilization](/features/price-stabilization)**

Also missing: /features/gasless-swaps, which already owns the "which gasless approach do I need?" decision tree (features/gasless-swaps.mdx:10). That's the natural companion link for this intro and the one readers most need.

Fix this →

4. "one of four ways" is a hard-coded count that no other page backs

features/gasless-execution.mdx:45

Gasless Execution is one of four ways to get gas out of your users' way, alongside Fee Sponsorship, just-in-time gas, and pay-with-any-token. They combine.

The arithmetic is fine (1 + 3 = 4), but this taxonomy appears nowhere else in the repo, and features/ also contains gasless-swaps.mdx and gas-top-up.mdx, which a reader will reasonably count. A fixed number goes stale the moment a fifth approach ships. Suggest dropping "four" — "Gasless Execution is one of several ways… and they combine" — or pointing at the gasless-swaps decision tree as the canonical list.

5. Page-type profile: this is §3.2 use-case voice on a §3.1 feature guide

Flagging as a judgment call for the doc owner rather than a defect, but it's the largest structural question in the diff.

• §3.1 requires the intro to be one paragraph with definitional framing (<FeatureName> is a feature that …). Lines 6–22 are a bold tagline, five paragraphs, and a bullet list before the first ##.
• ## Why it matters (:24) and ## Who it's for (:39) aren't in the §3.1 profile, whose optional order is Requirements → How to use it? → Caveats.
• The bolded lead-in benefit blocks at :28-37 are the §3.2 Benefits block pattern, which §3.2 scopes to use-cases/*.mdx. They also don't match §3.2's own spec ("3–5 bolded lead-ins… No surrounding bullets") — these are bulleted, and "For integrators" has 4 while "For your users" has 3 across two subsections.
• §2.4: feature guides are "practical and task-oriented"; positioning-first prose is reserved for use-case guides.
• The single --- at :49 fencing marketing off from technical content is a symptom of two page types sharing one file. §2.5 permits HRs between major sections, so this is legal, just telling.

Worth noting solutions/payment-service-providers.mdx:30-34 already carries this positioning and already links here, so some of this is now duplicated. If the goal is a marketing surface, use-cases/ or solutions/ fits the guide better, with this page keeping a one-paragraph definitional intro.

6. "Pair with Fee Sponsorship" is stated three times

Lines 16, 41, and 47 all say to pair with Fee Sponsorship; 1:1 settlement appears at lines 30, 37, 41, and 47. Line 47 is close to a restatement of line 16 with price stabilization added. Collapsing to one mention (line 16) plus the closing line would tighten this noticeably.

7. Minor

• Unquantified superlatives. :10 "That's the state most payers are in" and :28 "include most new users" are asserted without support. §2.4 asks for concrete numbers when available — features/price-stabilization.mdx:1301 shows the docs do carry real figures (~$0.02 execution fee) — so either cite or soften.
• §2.3 voice. :14 "Decouple signing from submitting." is imperative but describes product behavior, not a reader action. §2.3 wants a named subject for definitions: "Relay decouples signing from submitting."
• Frontmatter drift. description: "Submit arbitrary transactions for gasless execution" (:3, unchanged) is about arbitrary EVM execution, while the new lead is about stablecoin payments. The body supports the broader framing; consider whether the lead should too, since :18 already walks it back ("covers any EVM transaction, not just payments").
• Feature-name casing. This page uses "Gasless Execution"; solutions/payment-service-providers.mdx:32 uses "Gasless execution". §5 doesn't rule on this, but it's worth settling.

---

Verified clean

• [Fee Sponsorship](/features/fee-sponsorship) resolves; root-relative form per §2.6 ✓
• Nav wiring intact — docs.json:47 lists features/gasless-execution, redirect at docs.json:545 ✓
• No # H1 in body; ##/### only, no deeper nesting (§2.2) ✓
• Terminology: "onchain" one word (:43), no italics added (§2.9), no callouts added so the 15-line cap is moot ✓
• Technical bullets at :20-22 match the existing accordions — ERC-4337 user operations (:582), gasless 7702 upgrade including "the upgrade itself" (:759-760), and the tx.origin constraint (:855) ✓
• EVM-only scope in the intro is consistent with Caveats :852 ✓
• No changes to code blocks; existing fences balanced ✓

I reviewed only content and style-guide conformance — this repo has no lint or test command, so I ran none. The Mintlify preview remains the rendering check.

I made no code changes, since this was a review request.
· scout/MAR-1403-gasless-execution-feature-page

[greptile-apps]

Greptile Summary

This change adds an introductory overview of Gasless Execution, including stablecoin-funded transactions, supported account types, and Fee Sponsorship. The new copy incorrectly promises that sponsorship alone produces an exact 1:1 payment outcome; the documented examples show that exchange-rate variation remains unless price stabilization is also enabled.

Confidence Score: 4/5

Do not merge as written because the page can cause integrators to promise recipients an exact settlement amount that sponsorship alone cannot guarantee.

A focused executable check confirmed that sponsored payments can still vary with the stablecoin exchange rate and that price stabilization is required for an exact 1:1 outcome.

Files Needing Attention: features/gasless-execution.mdx, especially line 37; ensure any 1:1 settlement claim explicitly includes price stabilization.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for the first posted P1 finding, including a focused validation script source and candidate claim with sponsorship-only pricing evidence.
• T-Rex produced a proof for a second posted P1 finding.
• T-Rex performed a general-contract validation and documented sponsorship-only outcomes of 100, 100.05, and 99.95 USDT for 100 USDC input, noting that exact 1:1 requires the documented fixed-rate mechanism.
• T-Rex surfaced and organized artifacts tied to the proofs, including the focused validation script, pricing evidence, and validation result logs, to enable review.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Fee Sponsorship is presented as an unconditional 1:1 settlement guarantee

   • Bug
     • features/gasless-execution.mdx:37 says “Get 1:1 payments when sponsored. Send a dollar, and a dollar arrives.” However, the checked-in price-stabilization documentation explicitly states that sponsorship covers fees but still permits price-driven outputs of 100.05 or 99.95 USDT for a 100 USDC input. The same candidate page correctly requires both Fee Sponsorship and price stabilization at line 47.
   • Cause
     • The line conflates removal of transaction fees with stabilization of the stablecoin exchange rate.
   • Fix
     • Revise line 37 to say sponsorship removes/absorbs fees without implying exact settlement, or explicitly require Price Stabilization (fixed rates) for the “send a dollar, a dollar arrives” claim. Align line 41 as well if retaining its separate “1:1 settlement” wording.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into scout/MAR-1403-..." | Re-trigger Greptile}

[greptile-apps]

Fee Sponsorship does not guarantee 1:1 settlement

This says sponsorship alone ensures that “a dollar arrives,” but sponsorship removes the user’s fee rather than fixing the stablecoin exchange rate. The documented price-stabilization examples show that a sponsored 100 USDC payment can settle as 100.05 or 99.95 USDT, and this page itself correctly states at line 47 that exact 1:1 settlement also requires price stabilization. Revise this to describe sponsored fees without promising an exact received amount, or explicitly require price stabilization for the 1:1 claim.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Artifacts

Focused validation script source

• The captured Python source reads the relevant checked-in pages and asserts the claim, required conjunction, variable sponsorship-only outcomes, and fixed-rate requirement; it makes the validation reproducible.

Candidate claim and sponsorship-only pricing evidence

• The captured command output shows line 37, line 47, and the price-stabilization documentation’s 100, 100.05, and 99.95 USDT sponsorship-only outcomes; it demonstrates the contradiction.

Successful focused validation result

• The executed Python check exited successfully and reports that Fee Sponsorship covers fees but does not guarantee exact 1:1 settlement; it verifies the misleading claim.

_{Ran code and verified through T-Rex}