docs(fee-sponsorship): add product value overview

[scout-relayprotocol]

Implements MAR-1396: Marketing strategy for fee sponsorship

What this changes

• Adds a product-value overview to features/fee-sponsorship.mdx focused on stablecoin payment outcomes.
• Explains the sponsorship flow, integrator and user benefits, target use cases, controls, and cost considerations.
• Links fee sponsorship to fixed rates, deposit addresses, gasless execution, and just-in-time gas while preserving the existing technical integration guide.

How I verified

• git diff --check
• npx -y mintlify@latest broken-links --files features/fee-sponsorship.mdx --check-anchors
• Confirmed the enterprise requirement was removed in relay-docs PR Update docs for developer dashboard  #369 before retaining the generally available positioning.
• Reviewed the final one-file diff against the Relay Docs style guide.

Open questions

• None.

---

🤖 Opened by Scout (autonomous). Ready for human review.
Linear: https://linear.app/relayprotocol/issue/MAR-1396/marketing-strategy-for-fee-sponsorship

[mintlify]

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

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

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

[github-actions]

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

---

Code Review: docs(fee-sponsorship): add product value overview

• Read PR diff
• Read full features/fee-sponsorship.mdx
• Verify internal links + anchors resolve
• Check against AGENTS.md style guide (§2, §3.1)
• Verify factual claims against sibling docs
• Post review

All four new links resolve (gasless-swaps.mdx, gas-top-up.mdx, deposit-addresses.mdx, price-stabilization.mdx), and #fixed-rates matches the ### Fixed Rates heading at features/price-stabilization.mdx:654. The writing is clean and the technical half of the page is untouched. Findings below, most significant first.

---

1. The opening hook contradicts price-stabilization.mdx (accuracy)

features/fee-sponsorship.mdx:10 frames the shortfall as pure fees:

your user sends 100 USDC and 99.80 USDT arrives. Bridge fees, gas, and execution costs came out of the payment

But features/price-stabilization.mdx:27-32 says the opposite for exactly this pair:

With sponsorship, you cover the fees. Importantly, this doesn't mean the user gets 1:1 in our USDC:USDT example: … If 1 USDT = 1.0005 USDC, that's 99.95 USDT out

Combined with "Payments arrive whole" (line 32) and the H1 description ("so stablecoin payments arrive whole"), a reader concludes subsidizeFees: true turns 100 USDC into 100 USDT. It doesn't — the rate still moves the output, which is why fixed rates exist. Line 50 does point at fixed rates, but it arrives 40 lines after the promise.

The magnitude is off too: price-stabilization.mdx:27 puts fees at $0.03 on the identical $100 USDC scenario, and line 1299 calls swap impact "sub 1bps." Line 10's $0.20 is ~20bps with no basis.

Cheapest fix: make the example same-token (100 USDC in → 99.80 USDC out) so the gap is unambiguously fees, and reconcile the number with the sibling page. Fix this →

2. Line 54 overstates deposit-address cap support (accuracy)

Choose full or partial coverage… Deposit-address flows support full sponsorship and a maximum cap, but not selective fee components.

Two places later in the same file say the cap behaves inversely on deposit addresses:

• :107 — "maxSubsidizationAmount is supported by deposit addresses but if the amount exceeds the maximum the user pays all fees and nothing is subsidized"
• :150 — "Partial fee sponsorship is not supported for deposit addresses"

So on deposit addresses the cap is a kill switch, not a partial-coverage knob. Listing it as "supported" one clause after "Choose full or partial coverage" reads as an endorsement of the behavior the page explicitly warns against. Suggest: "Deposit-address flows support full sponsorship only — no selective fee components, and no partial coverage when the cap is exceeded." Fix this →

3. gasless execution links to the wrong page (§2.6)

:48 — [gasless execution](/features/gasless-swaps). There is a dedicated features/gasless-execution.mdx, titled "Gasless Execution". Either the label should read "gasless swaps" (if the decision-tree hub is the intent) or the target should be /features/gasless-execution. Line 60 then uses "gasless execution" again to mean the specific mechanism, so the label is doing double duty. Fix this →

4. Unsourced "four ways" count (:48)

Fee sponsorship is one of four ways to get gas out of your users' way.

No other page enumerates four, and the sentence names only three companions (the fourth being fee sponsorship itself, which the reader has to infer). This is the kind of hardcoded count that silently goes stale when a fifth mechanism ships. Recommend dropping "four" and just listing the companions.

5. :56 documents a requirement that no longer exists

Fee sponsorship is generally available and does not require an enterprise partnership.

enterprise partnership appears nowhere else in the docs — so this sentence raises a gate purely to deny it, which invites the question it's trying to close. It's also orphaned in ## What you can control, a section otherwise about coverage knobs. Suggest deleting; the absence of a requirement is the default reading.

6. Profile fit: this is §3.2 shape on a §3.1 page (structural — human call)

Per AGENTS.md §3.1, a feature guide is "practical, task-oriented" with one intro paragraph, then Requirements → How to use it? → Caveats. This PR adds three intro paragraphs and six ## sections ahead of ## Requirements, in the §3.2 use-case idiom — bolded-lead benefit blocks, "Why it matters", "Who it's for", "positioning-first, marketing-adjacent". §3 does say to validate present sections rather than flag missing ones, so this isn't a hard violation, but a reader hitting features/fee-sponsorship.mdx for integration mechanics now scrolls past ~55 lines of positioning first.

Worth deciding explicitly: does this belong in use-cases/ (with the feature guide linking to it), or is a marketing preamble on feature guides the new house pattern? Either is defensible — but if it's the latter, AGENTS.md §3.1 should be updated in the same PR so the next agent doesn't get flagged for copying it.

7. Consistency nits within the page

• Heading case — new sections are sentence case ("How it works", "Why it matters"); every pre-existing ## on the page is Title Case ("Sponsoring Transactions", "Best Practices", "What Fee Sponsorship Does Not Cover").
• Horizontal rules (§2.5) — the existing lower half separates every ## with ---. The six new sections have none, then one --- appears at :66. Reads as two documents stapled together.
• gas top-up vs topup — :63 normalizes to "gas top-up" but :100 ("gas topup amounts") and :301 ("Auto-Topup") are left alone. Terminology §5 doesn't cover this one; pick a spelling and apply it page-wide.

8. Redundancy

Several points land three times:

• :12 ("Cover some or all of your users' fees… You decide what they pay, what you absorb, and the maximum amount") restates :8 and pre-states :54.
• :44 ("Deploy sponsorship deliberately for onboarding, promotions, premium tiers…") restates the bullet at :26.
• ## What to consider (:60) and the <Note> (:62-64) make the same origin-gas point back to back, immediately adjacent.

Tightening these would cut the preamble meaningfully, which also softens finding 6.

9. :38 — "Sponsoring spreads on volatile pairs rarely makes sense"

Fee sponsorship covers fees; there's no parameter that sponsors spread (subsidizeFees / sponsoredFeeComponents are both fee-scoped). The sentence implies a capability that doesn't exist, and it's the only use of "spread" on the page. Also, "stablecoin orchestration" (same line) isn't a term used anywhere else in these docs — either define it or use language from the existing pages.

---

Summary

No blocking correctness bugs in the technical reference half of the page — it's unmodified. Findings 1 and 2 are the ones I'd fix before merge: both put marketing copy in direct conflict with statements elsewhere in the docs (including one contradiction inside this same file), and both are the kind of thing an integrator discovers at runtime. 3–5 are quick corrections. 6 is a genuine judgment call for a human reviewer, not something I'd want automation to decide.

I reviewed content only — I did not run the Mintlify link checker (the PR body reports it passing, and my manual check of the four new links and one anchor agrees).
· Branch scout/MAR-1396-fee-sponsorship-marketing

[greptile-apps]

Greptile Summary

This update expands the Fee Sponsorship guide with stablecoin-payment positioning, sponsorship controls, use cases, and guidance for combining sponsorship with related gas features. Browser validation confirmed that the “gasless execution” link opens the distinct Gasless Swaps guide instead of the general Gasless Execution guide, so it should be corrected before merge.

Confidence Score: 4/5

Not merge-safe until the gasless-execution link points to the guide matching its label.

One independent, verified P1 non-security finding remains. The rendered documentation flow confirmed that the current destination and the intended guide are separate pages with different prerequisites.

Files Needing Attention: features/fee-sponsorship.mdx line 48 needs its gasless-execution route corrected.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for the posted P1 finding and attached it to the review comment.
• A set of validation artifacts was prepared to illustrate the proof steps, including two videos and two poster-frame images.
• A route validation log and a Python route validation script were included to let reviewers inspect the validation results.
• Browser navigation was captured with a log and a JavaScript capture script to enable replay of the navigation flow.

_{Ran code and verified through T-Rex}

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

[greptile-apps]

Gasless execution link opens the wrong guide

The link labeled “gasless execution” navigates to /features/gasless-swaps, which renders the separate Gasless Swaps guide. The general Gasless Execution guide exists at /features/gasless-execution and has different setup requirements, including an API key, linked funding address, and funded app balance. Point this link at /features/gasless-execution so integrators receive the instructions implied by the link text.

Artifacts

▶ Recording of the check

• Playwright clicked the authored Fee Sponsorship link and recorded its landing page, showing it opens Gasless Swaps; the takeaway is that the current destination is the swap-specific guide.

Poster frame of the authored link landing on Gasless Swaps

• Poster frame from the existing-link recording shows the Gasless Swaps heading after navigation; the takeaway is that the visible destination does not match the general gasless-execution label.

▶ Recording of the check

• Playwright rendered the existing intended `/features/gasless-execution` route at the same scope, showing the Gasless Execution guide; the takeaway is that the proper general guide exists and is reachable.

Poster frame of the intended Gasless Execution guide

• Poster frame from the intended-route recording shows the Gasless Execution heading; the takeaway is that this is a distinct guide from Gasless Swaps.

Route validation output

• Output from the executed Python validator records both authored routes, titles, descriptions, navigation presence, and distinct prerequisites; the takeaway is that the finding is verified.

Route validation script

• Python source executed to inspect the authored link and validate both documentation routes and prerequisites; the takeaway is that the route comparison is reproducible.

Browser navigation output

• Output from the executed Playwright navigation capture records the actual URL and heading after clicking the authored link and the expected route render; the takeaway is that browser navigation confirms the mismatch.

Browser navigation capture script

• Playwright/Chromium source executed against the local Mintlify server to record the current and intended documentation routes; the takeaway is that rendered navigation confirms the target difference.

_{Ran code and verified through T-Rex}