Verify MIP-4 reserve-dip behavior when delegated EOA self-submits (sponsor == authority)

[furious-fury]

Summary

We've confirmed on Monad testnet that a sponsor-submitted EIP-7702 authorization-list transaction can cause dippedIntoReserve() to return true for the delegated EOA whose balance actually crosses the reserve threshold. What we haven't tested is whether the same holds when the delegated EOA submits the transaction itself (i.e. it is both the signer of the 7702 authorization and the broadcaster/gas-payer).

This matters for ReserveGuard's guidance to consumers: if behavior differs by submission path, checkpoint()/assertHealthy() usage needs to document that distinction rather than assume it's sponsor-agnostic.

Confirmed behavior (sponsor path)

Live Monad testnet, tx 0xeed48539..., type 4:

• Sponsor/caller: 0x5ee198D6... (signs + broadcasts, pays gas)
• Delegated authority: 0x188F267e... (signs the 7702 authorization; Testnet7702DelegatedDrainRestore code runs in this account's context)
• Balance: 19169866400000000000 → 9169866400000000000 → 19169866400000000000 wei
• Reserve state: beforeDip=false, duringDip=true, afterDip=false

Negative control: an ordinary contract account (TestnetDrainRestore) crossing the same 19→9→19 MON pattern did not trigger a dip (duringDip=false throughout), ruling out a simple "any account below 10 MON" explanation.

See docs/live-testnet.md → "Verified Live Testnet Observations" for full details.

Open question

Does duringDip still return true when the delegated authority is also the transaction sender/gas-payer — i.e. PRIVATE_KEY == DELEGATED_AUTHORITY_PRIVATE_KEY?

Proposed repo steps

No contract changes needed — ReserveObservation already logs account and caller separately.

1. Deploy (or reuse) Testnet7702DelegatedDrainRestore per docs/live-testnet.md.
2. Fund the delegated authority above 10 MON.
3. Sign the EIP-7702 authorization with DELEGATED_AUTHORITY_PRIVATE_KEY as usual.
4. Difference from the existing flow: broadcast with PRIVATE_KEY set to the same key as DELEGATED_AUTHORITY_PRIVATE_KEY, instead of a separate sponsor key.
5. Run scripts/run-7702-drain-restore.sh (or the equivalent cast send ... --auth command) with that config.
6. Record lastBeforeDip/lastDuringDip/lastAfterDip and the emitted ReserveObservation logs (account vs caller should now be equal).
7. Compare against the sponsor-path run above.

Expected outcomes and implications

• If duringDip=true in both cases: reserve tracking is sponsor-agnostic; checkpoint() docs can state this without caveats.
• If self-submission does not trigger the dip: this is a meaningful divergence that needs to be called out explicitly in ReserveGuard's docs/README, since sponsored-tx / account-abstraction flows are a primary target use case for V1.