fix: update slippage tolerance equation

[ericneil-sanc]

PR Scope

Please title your PR according to the following types and scopes following conventional commits:

• fix(SDK name): will trigger a patch version
• chore(<type>): will not trigger any release and should be used for internal repo changes
• <type>(public): will trigger a patch version for non-code changes (e.g. README changes)
• feat(SDK name): will trigger a minor version
• feat(breaking): will trigger a major version for a breaking change

Description

[Summary of the change, motivation, and context]

How Has This Been Tested?

[e.g. Manually, E2E tests, unit tests, Storybook]

Are there any breaking changes?

[e.g. Type definitions, API definitions]

If there are breaking changes, please ensure you bump the major version Bump the major version (by using the title feat(breaking): ...), post a notice in #eng-sdks, and explicitly notify all Uniswap Labs consumers of the SDK.

(Optional) Feedback Focus

[Specific parts of this PR you'd like feedback on, or that reviewers should pay closer attention to]

(Optional) Follow Ups

[Things that weren't addressed in this PR, ways you plan to build on this work, or other ways this work could be extended]

[github-actions]

🤖 Claude Code Review

✅ Review complete

Summary

This PR changes the slippage calculation formula in minimumAmountOut across all SDK versions (v2, v3, v4, router-sdk, and mixed routes).

Formula Change

Formula	5% slippage on 69	200% slippage on 69
Old: output / (1 + slippage)	69 / 1.05 ≈ 65.7	69 / 3 = 23
New: output * (1 - slippage)	69 * 0.95 = 65.55	69 * -1 → clamped to 0

The change also adds clamping to zero when slippage >= 100%, which is a reasonable safety measure to prevent negative amounts.

Behavioral Impact

This is a breaking change in terms of the calculated values:

• For small slippage values (e.g., 5%), the difference is minor (~0.2%)
• For large slippage values, the difference is significant and now clamps to 0

Test Updates

All tests have been updated to reflect the new expected values. The previous review comments about worstExecutionPrice tests expecting non-zero values have been addressed - they now correctly expect 0 for 200% slippage.

Questions

1. Is this intentional behavior change documented somewhere? The formula change affects how minimum amounts are calculated, which could impact integrators.

2. Is the 5% slippage calculation change intentional? The tests show 6670 → 6653 for minimumAmountOut with 5% slippage on 7004. This is a small but real difference that integrators may need to be aware of.

---

_{💡 Want a fresh review? Add a comment containing @request-claude-review to trigger a new review at any time.}

[github-actions]

📋 Review verdict: REQUEST_CHANGES

👆 The main review comment above is the source of truth for this PR review. It is automatically updated on each review cycle, so always refer to it for the most current feedback.

This formal review submission is for the verdict only. 2 inline comment(s) are attached below.

Superseded by new review after PR update

[github-actions]

📋 Review verdict: APPROVE

👆 The main review comment above is the source of truth for this PR review. It is automatically updated on each review cycle, so always refer to it for the most current feedback.

This formal review submission is for the verdict only.

[graphite-app]

Graphite Automations

"Request reviewers once CI passes on sdks monorepo" took an action on this PR • (03/20/26)

3 reviewers were added and 1 assignee was added to this PR based on Siyu Jiang (See-You John)'s automation.