fix: all account overrides + gas limits by Thunkar · Pull Request #22173 · AztecProtocol/aztec-packages

Thunkar · 2026-03-31T04:50:59Z

The introduction of NO_FROM means that sometimes we might want to override account contracts during simulations that are not the from of the transaction (for example, to do authwit capture when the entrypoint is an FPC). This PR overrides accounts also in the additionalScopes list before simulating.

Gas estimations were poorly defined in the previous implementation. Simulation always estimates gas, and our default gas limits for sending embedded in the protocol. These constants have been removed and moved to GasSettings with proper explanations. Furthermore, the pipeline is simplified:

BaseWallet will use the user-provided gas limits for everything, and then resort to the an arbitrary max (during sending) or the estimation values (during simulation) if they're not provided.
EmbeddedWallet will do the same for simulation, but for sending will simulate first and then apply the estimated gas with a padding to the tx if the user didn't provide limits.

Why respect the user-provided gas limits during simulation/gas estimation? Sometimes the tx itself will enforce certain conditions on the gas/fee consumed (during teardown, for example). Setting the max limit on teardown will cause those transactions to fail simulation, since teardown gas is charged unconditionally.

Closes: https://linear.app/aztec-labs/issue/F-404/decrease-or-remove-default-gas-limits

benesjan · 2026-03-31T07:47:39Z

Merged merge-train/fairies to get a clean CI pass

…of github.com:Aztt push!ecProtocol/aztec-packages into gj/wallet_improvements

sirasistant

Inner gas stuff LGTM but haven't read much of the wallet side.

benesjan

Docs and naming Karen is back!

benesjan · 2026-04-01T07:57:25Z

+  /** User-provided partial gas settings. */
+  gasSettings?: Partial<FieldsOf<GasSettings>>;
+  /** If true, uses high gas limits for estimation/simulation. If false, uses protocol max limits. */
+  forEstimation?: boolean;


Why is it called forEstimation?

Could you also explain the difference between high gas limits and protocol max limits? I don't really understand it.

I understood the naming from below. Maybe something like "canExceedProtocolLimits" would be better?

Then we could explain here why it's fine and desirable to exceed the limits when simulating.

This is only every used for estimation with the combination of skipFeeEnforcement and skipTxValidation. I wouldn't complicate it further

I am fine with keeping it as "forEstimation" but would explain here that the high gas limits are higher than the protocol max and how is it even possible and why do we do it. Setting here higher limits than protocol max is very confusing and I think wallet builders will want to understand this so would not dismiss this as it being just an unimportant setting that noone will see (even if it was just for internal team it would make sense to explain).

Updated comment

I don't see it updated. If you don't want to repeat the explanation here then would point to where it's explained.

benesjan

Looks good 👍

benesjan · 2026-04-07T07:49:14Z

-  /** Default gas settings to use when user has not provided them. Requires explicit max fees per gas. */
-  static default(overrides: {
+  /**
+   * Fills in gas limits high enough for transactions to be included in most cases.


"in most cases"

I would expect everyone to be asking what are the cases this will fail.

Would also explain here why it's called fallback.

Explained cases where this would fail

benesjan · 2026-04-07T07:52:00Z

+   * Fills in gas limits high enough for transactions to be included in most cases.
+   * gasLimits is set to the maximum the protocol allows; since teardown gas is reserved
+   * from gasLimits during private execution (see gas_meter.nr), the effective gas available
+   * for app logic will be gasLimits - teardownGasLimits - privateOverhead.


Unrelated to your PR but the fact that we cannot just use the max protocol limits makes me think the constants were incorrectly defined and now the complexity leaks all the way here and is vomited in the dev's face.

It's not a constants definition problem, but a chicken-and-egg problem. You need to pay for teardown unconditionally, so you need to allocate some gas to it. How much? Well, you don't know until you estimate. Hence, there's no "max" in the protocol, since you could potentially allocate MAX_PROCESSABLE_L2_GAS to teardown...but then you cannot do anything else

benesjan · 2026-04-07T08:00:51Z

        l2Gas: DEFAULT_TEARDOWN_L2_GAS_LIMIT,
        daGas: DEFAULT_TEARDOWN_DA_GAS_LIMIT,


These 2 constants now have stale naming.

mmm, I thought it was fine keeping them the same, since it's an arbitrary value. Maybe FALLBACK_TEARDOWN_L2_GAS_LIMIT?

benesjan · 2026-04-07T08:26:59Z

+  /** User-provided partial gas settings. */
+  gasSettings?: Partial<FieldsOf<GasSettings>>;
+  /** If true, uses high gas limits for estimation/simulation. If false, uses protocol max limits. */
+  forEstimation?: boolean;


I don't see it updated. If you don't want to repeat the explanation here then would point to where it's explained.

The introduction of `NO_FROM` means that sometimes we might want to override account contracts during simulations that are not the `from` of the transaction (for example, to do authwit capture when the entrypoint is an FPC). This PR overrides accounts also in the `additionalScopes` list before simulating. Gas estimations were poorly defined in the previous implementation. Simulation always estimates gas, and our default gas limits for sending embedded in the protocol. These constants have been removed and moved to `GasSettings` with proper explanations. Furthermore, the pipeline is simplified: * `BaseWallet` will use the user-provided gas limits for everything, and then resort to the an arbitrary max (during sending) or the estimation values (during simulation) if they're not provided. * `EmbeddedWallet` will do the same for simulation, but for sending will simulate first and then apply the estimated gas with a padding to the tx *if the user didn't provide limits*. Why respect the user-provided gas limits during simulation/gas estimation? Sometimes the tx itself will enforce certain conditions on the gas/fee consumed (during teardown, for example). Setting the max limit on teardown will cause those transactions to fail simulation, since teardown gas is charged unconditionally. Closes: https://linear.app/aztec-labs/issue/F-404/decrease-or-remove-default-gas-limits --------- Co-authored-by: Jan Beneš <janbenes1234@gmail.com>

AztecBot · 2026-04-07T09:40:02Z

✅ Successfully backported to backport-to-v4-next-staging #22258.

BEGIN_COMMIT_OVERRIDE chore: remove dead to_be_bytes fn (#22243) fix: correct args length in `#[authorize_once]` (#22209) chore: fix inconsistent usage of contract class hash fn (#22248) chore: delete old field comparison fns in favor of lt (#22249) fix: all account overrides + gas limits (#22173) feat: allow for runtime length arrays of sorts and selects (#22250) chore: remove dead pub global vars reexport (#22244) chore: changed default wait behavior (#22325) chore: apply code consistency consolidation (#22251) END_COMMIT_OVERRIDE

BEGIN_COMMIT_OVERRIDE fix: pippenger edge case (#22256) cherry-pick: fix: separate fisherman StatefulSet from rpc-node and stop archiver pollution (#22183) — WITH CONFLICTS fix: separate fisherman StatefulSet from rpc-node and stop archiver pollution (backport #22183) (#22284) fix: preserve DeployAccountMethod type in with() method chaining (#22322) docs: backport docs build/release infrastructure from #22106 and #22144 (#22223) chore(docs): remove v5 nightly and devnet versioned docs (backport #22193) (#22236) chore: improve release-docs skill and add release-network-docs skill (#22328) chore: remove dead to_be_bytes fn (#22243) fix: correct args length in `#[authorize_once]` (#22209) chore: fix inconsistent usage of contract class hash fn (#22248) chore: delete old field comparison fns in favor of lt (#22249) fix: all account overrides + gas limits (#22173) feat: allow for runtime length arrays of sorts and selects (#22250) chore: remove dead pub global vars reexport (#22244) chore: changed default wait behavior (#22325) chore: apply code consistency consolidation (#22251) fix(docs): simplify TypeScript API reference links (backport #22232) (#22369) fix: remove detailed revert codes (#22380) fix: backport #21673 — prevent HA peer proposals from blocking equivocation in duplicate proposal test (#21693) fix: subfield note selectors (#22211) END_COMMIT_OVERRIDE

Thunkar added 2 commits March 31, 2026 04:35

fixes

304968c

better comments

aa60cf7

Thunkar requested review from benesjan and mverzilli March 31, 2026 04:50

Thunkar self-assigned this Mar 31, 2026

Thunkar and others added 2 commits March 31, 2026 05:32

restore

44f7be5

Merge branch 'merge-train/fairies' into gj/wallet_improvements

8299351

Thunkar added ci-no-fail-fast Sets NO_FAIL_FAST in the CI so the run is not aborted on the first failure ci-draft Run CI on draft PRs. labels Mar 31, 2026

Thunkar marked this pull request as draft March 31, 2026 08:47

wip

1f7121f

Thunkar removed request for benesjan and mverzilli March 31, 2026 09:15

Thunkar added 10 commits March 31, 2026 09:47

added gassettings branch

deb14bd

fixe

58bd4be

Merge branch 'merge-train/fairies' into gj/wallet_improvements

c973c7f

fixes

3c38f12

Merge branches 'gj/wallet_improvements' and 'gj/wallet_improvements' …

4336e14

…of github.com:Aztt push!ecProtocol/aztec-packages into gj/wallet_improvements

removed default limits

4a28f42

reworked constants

804c843

fixtures

89260d2

found discrepancy

2174b3c

more fixtures

1860f7f

Thunkar marked this pull request as ready for review March 31, 2026 13:01

Thunkar requested review from LeilaWang, dbanks12, fcarreiro, jeanmon and sirasistant as code owners March 31, 2026 13:01

sirasistant approved these changes Mar 31, 2026

View reviewed changes

benesjan reviewed Apr 1, 2026

View reviewed changes

Thunkar added 2 commits April 1, 2026 12:39

comments from review

04819f0

comments from review

acd1bff

Thunkar requested a review from benesjan April 1, 2026 15:11

mverzilli reviewed Apr 1, 2026

View reviewed changes

Comment thread yarn-project/wallet-sdk/src/base-wallet/base_wallet.ts Outdated

mverzilli approved these changes Apr 1, 2026

View reviewed changes

benesjan reviewed Apr 2, 2026

View reviewed changes

Comment thread yarn-project/stdlib/src/gas/gas_settings.ts Outdated

Thunkar marked this pull request as draft April 6, 2026 04:18

Thunkar added 4 commits April 6, 2026 04:58

renaming and addressing comments

8765e13

fix

ca5eb76

more comment

14ea8d8

migration notes

516ac5e

Thunkar marked this pull request as ready for review April 6, 2026 05:08

Merge branch 'merge-train/fairies' into gj/wallet_improvements

015c740

Thunkar requested review from benesjan and mverzilli April 6, 2026 05:09

Thunkar added the backport-to-v4-next label Apr 6, 2026

benesjan approved these changes Apr 7, 2026

View reviewed changes

more review comments

566d238

Thunkar enabled auto-merge (squash) April 7, 2026 09:31

Thunkar merged commit 41ee481 into merge-train/fairies Apr 7, 2026
12 checks passed

Thunkar deleted the gj/wallet_improvements branch April 7, 2026 09:38

AztecBot mentioned this pull request Apr 7, 2026

feat: merge-train/fairies #22350

Merged

AztecBot mentioned this pull request Apr 7, 2026

chore: Accumulated backports to v4-next #22258

Merged

AztecBot mentioned this pull request Apr 14, 2026

chore(v4): release 4.2.1 #20979

Open

		l2Gas: DEFAULT_TEARDOWN_L2_GAS_LIMIT,
		daGas: DEFAULT_TEARDOWN_DA_GAS_LIMIT,

Conversation

Thunkar commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benesjan commented Mar 31, 2026

Uh oh!

sirasistant left a comment

Choose a reason for hiding this comment

Uh oh!

benesjan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

benesjan left a comment

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

AztecBot commented Apr 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Thunkar commented Mar 31, 2026 •

edited

Loading