fix(transaction-pay-controller): use exact input for Relay deposits by pedronfigueiredo · Pull Request #9954 · MetaMask/core

pedronfigueiredo · 2026-08-25T13:51:39Z

Explanation

Relay quote behavior is now determined after transaction processing rather than by transaction-type allowlists.

This change:

uses EXACT_INPUT with sourceTokenAmount when a Relay quote has no embedded txs, so the entered source amount remains the total amount paid;
preserves EXACT_OUTPUT with the target amount for quotes that embed transactions, including Money Account calls;
assigns the final Relay tradeType and amount once after transaction processing;
adds the optional, client-facing TransactionPayQuote.isInputBased and TransactionPayTotals.isInputBased flags;
has Relay, Across, Server, Fiat, and no-op strategies expose normalized input-based semantics without requiring totals code to inspect provider-specific quote internals;
marks totals as input-based only when every selected quote is input-based, preventing source-side fees from being counted twice; and
clamps negative Relay dust to zero when exact-input output is below the prior target minimum.

The Relay trade-type decision no longer depends on Perps or Predict transaction types. HyperCore requests without embedded transactions follow the same exact-input rule.

Consumer integration

The coordinated client PRs remain drafts until the Core package containing this change is published:

MetaMask Mobile #35249 consumes TransactionPayTotals.isInputBased, keeps input-based source amounts stable, and displays the authoritative target amount. It now wires both the v26 resolveSourceAmount callback and v27 getBalance callback through a shared resolver; final integration still requires aligning @metamask/sentinel-api-service and regenerating the lockfile.
MetaMask Extension #45753 consumes the same aggregate flag. After the Core release it must bump the package, remove its compatibility type, regenerate dependency artifacts including LavaMoat policies and attributions, and validate MV3 and MV2 builds.

Both clients treat only an explicit isInputBased: true as input-based. Mixed aggregates and embedded-transaction/output-based quotes retain the existing Total presentation. Input-based withdrawals use the controller's authoritative target amount; legacy or output-based withdrawals retain the existing fee-subtraction fallback.

Local absolute-path file: links in the client worktrees are integration-only and are not part of either client PR.

Validation

yarn workspace @metamask/transaction-pay-controller run test
- 100% statement, line, and function coverage; 99.49% branch coverage
yarn workspace @metamask/transaction-pay-controller run jest --no-coverage src/utils/totals.test.ts src/strategy/relay/relay-quotes.test.ts src/strategy/across/across-quotes.test.ts src/strategy/server/server-quotes.test.ts src/strategy/fiat/fiat-direct-musd.test.ts src/utils/no-op-quote.test.ts
- 6 suites and 288 tests passed
yarn workspace @metamask/transaction-pay-controller run build
yarn workspace @metamask/transaction-pay-controller run changelog:validate
Targeted ESLint and oxfmt --check for changed TypeScript files
git diff --check origin/main...HEAD

References

CONF-1782
Mobile consumer PR: fix(confirmations): show Relay exact-input deposit output metamask-mobile#35249
Extension consumer PR: feat(confirmations): show received amount for Relay deposits metamask-extension#45753

Checklist

I've updated the test suite for new or updated code as appropriate
I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
I've communicated my changes to consumers by updating changelogs for packages I've changed
I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Note

Medium Risk
Changes quote trade types, amounts, and confirmation totals for MetaMask Pay flows (including HyperCore deposits without embedded txs), with coordinated mobile/extension consumer PRs.

Overview
Relay quoting now picks tradeType and amount after transaction embedding instead of from transaction-type rules (including the removed HyperCore EXACT_OUTPUT path). Quotes without embedded txs use EXACT_INPUT and sourceTokenAmount; quotes with embedded calls (delegation, Money Account post-quote, etc.) stay EXACT_OUTPUT with the target or override amount.

The PR adds optional TransactionPayQuote.isInputBased and TransactionPayTotals.isInputBased, set across Relay, Across, Server, Fiat, and no-op normalization. calculateTotals no longer keys off isMaxAmount; it treats totals as input-based only when every selected quote is input-based, uses that for the paid amount in totals, and avoids double-counting fees already baked into the source side. Relay dust is clamped to zero when exact-input output falls below the prior minimum.

Embedded-transaction handlers no longer mutate tradeType / amount on the draft body; processMoneyAccountPostQuote returns the raw amount for the final request instead.

^{Reviewed by Cursor Bugbot for commit ccb7854. Bugbot is set up for automated code reviews on this repo. Configure here.}

matthewwalsh0 · 2026-08-27T08:49:54Z

+    // start as EXPECTED_OUTPUT until transaction processing determines whether
+    // the request embeds transactions.
+    const useExactInput =
+      (isMaxAmount ?? false) || (request.isPostQuote ?? false);


Minor, could also just Boolean(isMaxAmount || request.isPostQuote) if more readable?

Agreed, Boolean(...) is clearer here. I’ll simplify it.

Addressed in 5f0d8b805e (commit).

matthewwalsh0 · 2026-08-27T08:51:09Z

      recipient: effectiveRequest.recipient ?? from,
      slippageTolerance,
-      tradeType: getTradeType(useExactInput, useExactOutput),
+      tradeType: useExactInput ? 'EXACT_INPUT' : 'EXPECTED_OUTPUT',


Minor, was the getTradeType function useful if we pass it the request and isMaxAmount it owns the full decision.

matthewwalsh0 · 2026-08-27T08:52:22Z

    }

+    if (!body.txs?.length) {
+      body.tradeType = 'EXACT_INPUT';


Minor, is it simpler to assign tradeType once after we've set the transactions?

Good point. I’ll derive tradeType once from whether transactions were added after processing, instead of setting and overriding it in multiple places.

Addressed in b32aea78f3 (commit).

matthewwalsh0 · 2026-08-27T08:53:01Z

      recipient: effectiveRequest.recipient ?? from,
      slippageTolerance,
-      tradeType: getTradeType(useExactInput, useExactOutput),
+      tradeType: useExactInput ? 'EXACT_INPUT' : 'EXPECTED_OUTPUT',


This EXPECTED_OUTPUT branch is never hit as we override it regardless if transactions or not?

matthewwalsh0 · 2026-08-27T08:53:50Z


+    if (!body.txs?.length) {
+      body.tradeType = 'EXACT_INPUT';
+      body.amount = sourceTokenAmount;


Also here, is it more readable to just assign amount once after transactions are processed?

Agreed. I’ll defer amount too and set it once after transaction processing, preserving the Money Account transaction amount when present.

Addressed in d0eb8912b4 (commit).

matthewwalsh0 · 2026-08-27T08:56:15Z

  /** Total fees for the target transaction and all quotes. */
  fees: TransactionPayFees;

+  /** Whether all selected quotes are driven by the source input amount. */


Is this a bit ambiguous?

Maybe Whether the quote(s) subtract fees from the destination amount meaning the input amount is static

Agreed—the fee behavior is more concrete. I’ll update the documentation to clarify that fees are subtracted from the destination amount while the input amount stays static.

Addressed in c848146ce2 (commit).

matthewwalsh0 · 2026-08-27T08:57:01Z

+  isMaxAmount: boolean,
+): boolean {
+  if (quote.strategy === TransactionPayStrategy.Relay) {
+    const relayQuote = quote.original as RelayQuote;


This breaks the abstraction provided by the TransactionPayStrategy and couples this code to the internals of each one.

The purpose of the TransactionPayQuote type is to abstract what a quote can return, so it would also need a isInputBased property?

Agreed. I’ll expose isInputBased on TransactionPayQuote, have each strategy populate it, and make totals consume only the normalized property.

Addressed in ccb7854521 (commit).

This was referenced Aug 25, 2026

fix(confirmations): show Relay exact-input deposit output MetaMask/metamask-mobile#35249

Draft

feat(confirmations): show received amount for Relay deposits MetaMask/metamask-extension#45753

Draft

pedronfigueiredo marked this pull request as ready for review August 26, 2026 13:31

pedronfigueiredo requested review from a team as code owners August 26, 2026 13:31

pedronfigueiredo deployed to default-branch August 26, 2026 13:31 — with GitHub Actions Active

pedronfigueiredo added 3 commits August 26, 2026 14:36

fix(transaction-pay-controller): use exact input for Relay deposits

bc17b63

docs(transaction-pay-controller): link Relay deposit changelog

9ce2872

fix(transaction-pay-controller): expose input-based quote semantics

63f9f32

matthewwalsh0 self-requested a review August 26, 2026 13:39

pedronfigueiredo force-pushed the pnf/conf-1782-relay-exact-input-deposits branch from eea585b to 63f9f32 Compare August 26, 2026 13:52

chore(transaction-pay-controller): format totals tests

f610730

matthewwalsh0 requested changes Aug 27, 2026

View reviewed changes

pedronfigueiredo added 5 commits August 27, 2026 10:14

fix: address PR comment about exact input boolean

5f0d8b8

fix: assign Relay trade type after transactions

b32aea7

fix: assign Relay amount after transactions

d0eb891

docs: clarify input-based quote totals

c848146

fix: expose input-based quote semantics

ccb7854

pedronfigueiredo requested a review from matthewwalsh0 August 27, 2026 09:47

Navigation Menu

Uh oh!

Uh oh!

fix(transaction-pay-controller): use exact input for Relay deposits - #9954

fix(transaction-pay-controller): use exact input for Relay deposits#9954
pedronfigueiredo wants to merge 9 commits into
mainfrom
pnf/conf-1782-relay-exact-input-deposits

pedronfigueiredo commented Aug 25, 2026 •

edited

Loading

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

pedronfigueiredo Aug 27, 2026

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

pedronfigueiredo Aug 27, 2026

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

pedronfigueiredo Aug 27, 2026

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

pedronfigueiredo Aug 27, 2026

Uh oh!

matthewwalsh0 Aug 27, 2026

Uh oh!

pedronfigueiredo Aug 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

pedronfigueiredo commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation

Consumer integration

Validation

References

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pedronfigueiredo commented Aug 25, 2026 •

edited

Loading