Gas Costs and Optimization

IntentGuard protection adds gas overhead by wrapping the user transaction in a three-transaction bundle. This page explains the cost structure, how it scales, and the design tradeoffs available to reduce overhead.

Overview

A protected bundle consists of:

1. Pre-enforcement transaction — writes balance snapshots to storage for each constrained (account, token) pair.
2. User transaction — executes the intended operation.
3. Post-enforcement transaction — reads snapshots back and verifies that balance deltas satisfy the declared constraints.

The additional cost comes primarily from storage operations in the enforcement contract. Persisting balance snapshots (SSTORE) dominates the additional gas cost. Reading them back (SLOAD) during verification is significantly cheaper.

Example gas usage

The following benchmark was measured on Sepolia using a 1:1 token swap with two constraints (one maxOutflow, one minInflow):

Unprotected swap gas: 97,185
Protected total gas:  216,130
  preTx gas:          106,709
  userTx gas:          62,985
  postTx gas:          46,436

Additional gas:       118,945
Measured multiplier:  2.22×

Breakdown:

• Pre-check (106,709 gas) — the most expensive component. Each (account, token) pair requires a storage write (SSTORE, ~20,000 gas for a cold write) to persist the balance snapshot, plus contract call overhead and balance reads.
• Post-check (46,436 gas) — cheaper because it performs SLOAD reads (~2,100 gas cold, ~100 gas warm) against the stored snapshots and comparison logic. No new storage writes.
• User transaction (62,985 gas) — lower than the unprotected baseline (97,185) because storage slots were already warm from the preceding pre-check and from prior transactions in the test session.

The protected userTx benefits from storage warming caused by the pre-check, which accesses the same token balances. This effect does not occur in an isolated unprotected transaction, so the baseline swap gas should be used when estimating real-world overhead. A practical estimate for a protected swap with two constraints is approximately 250,000 gas (~2.5× the unprotected cost).

Cost scaling with constraints

Each constrained (account, token) pair adds:

• One SSTORE in the pre-check (~20,000 gas for a cold write)
• One SLOAD in the post-check (~2,100 gas cold, ~100 gas warm)
• Balance fetching via balanceOf or native balance read

Approximate per-constraint overhead: 25,000–30,000 gas.

The following table provides rough estimates assuming a ~100k gas baseline transaction (typical swap). Actual overhead depends on the transaction complexity and number of constrained assets.

Constraints	Estimated total gas	Approximate multiplier
1	~210,000	~2.2×
2	~250,000	~2.5×
5	~330,000	~2.8×
10 (max)	~480,000	~3.2×

Cheaper transactions (simple transfers at ~21,000 gas) will show a higher multiplier. Expensive transactions (complex DeFi operations at ~500,000 gas) will show a lower multiplier because the fixed enforcement overhead is amortized over a larger base cost.

Optimization: removing the pre-check transaction

A lower-cost enforcement profile is possible by removing the pre-check transaction entirely. In this model:

• The wallet declares expected balances at signing time.
• The post-check verifies balance deltas against these declared values rather than onchain snapshots.
• The pre-check SSTORE writes are eliminated.

This reduces the bundle from three transactions to two and removes the largest gas component (~100,000 gas).

Tradeoff:

Without the onchain snapshot, the enforcement baseline is the balance declared at signing time, not the actual balance at execution time. This introduces a gap:

• If another transaction modifies the constrained balances between signing and inclusion, the declared baseline may be stale.
• A concurrent transaction from the same wallet could cause the constraints to pass or fail against an incorrect starting balance.
• Any transaction that modifies the constrained balances before execution — whether from the same wallet or another actor interacting with the account — would not be reflected in the verification baseline.

When this profile is appropriate:

• Transactions are serialized (no concurrent pending transactions from the same account).
• The wallet ensures no conflicting operations target the same assets.
• The time between signing and inclusion is short (small ttlBlocks).

When this profile is not appropriate:

• Wallets that pipeline multiple protected transactions concurrently.
• High-frequency trading bots with overlapping operations.
• Any scenario where the constrained balances may change between signing and block inclusion.

The pre-check exists specifically to close this gap. It reads balances inside the execution block, ensuring the constraint baseline is always accurate regardless of concurrent activity.

Future optimizations

Several improvements can reduce enforcement gas cost:

• EIP-2930 access lists — pre-declaring storage slots can reduce cold access penalties for SLOAD operations and balance reads, saving ~1,900 gas per access in some cases.
• Storage layout optimization — packing multiple snapshots into fewer storage slots reduces the number of SSTORE operations.
• Constraint batching — encoding multiple constraints into a single storage write where possible.
• Alternative verification strategies — enforcement models that avoid per-constraint storage entirely, such as callback-based verification or inline balance checks.

In practice, most protected swaps with two constraints fall in the 2–3× gas range, with higher multipliers for simple transfers and lower multipliers for complex transactions where enforcement overhead is amortized.