v0.8.0 execution-policy clarification: gas-limit fallback, native controls, delegated calls and EIP-7702 lifecycle

[DetectiveDdev]

We are preparing independent offline conformance expectations for Arc execution at v0.8.0 / 66ad2d5, Reth 2.2.0 / revm 38, for chain 5042 and the applicable Zero7/Zero8 rules.

We are trying to establish the intended protocol behavior for this specific release, including places where that intent may differ from the implementation. A versioned normative specification or table is preferable where one exists. We are not requesting a patch, node access or historical RPC data.

1. Gas-limit selection and fallback
For v0.8.0, what are the intended validity rules at the configured minimum and maximum gas-limit boundaries?
In particular, are min and max themselves valid, and what is intended for min-1, max+1 and values outside the representable/configured range?
If ProtocolConfig lookup reverts, returns empty data or returns malformed data:

• should execution fall back or reject;
• if it falls back, which default/bounds apply;
• and is unavailable state/database access treated differently from a proved contract-level failure?
  The draft ADR appears to describe inclusive proposer bounds, strict receiver bounds and fallback pseudocode without a terminating branch. Please identify which behavior is normative for this release.

2. Native-transfer controls and fee effects
Is there a versioned normative decision table for v0.8.0 covering native-value restrictions?
We specifically need the intended outcome for:

• blocked caller;
• blocked recipient with zero versus non-zero value;
• top-level versus nested/native-precompile transfer;
• sender/recipient/beneficiary aliasing;
• recipient or beneficiary deletion/selfdestruct within the same transaction or earlier in the block.
  For a rejection at each relevant checkpoint, which state/log/refund effects are retained or reverted?
  Separately, on success, revert and OOG, which base-fee and priority-fee effects accrue to the beneficiary, and which, if any, survive a native-policy guard failure?

3. Delegated/native subcall semantics
Is there a normative v0.8.0 specification for CallFrom/native subcalls covering:

• permitted callers/schemes;
• effective sender, storage and value context;
• delegation resolution;
• cold/warm and fixed overhead;
• gas forwarding;
• rollback/error propagation?
  We specifically need clarification for static-context rejection, target revert, and insufficient overhead/access gas, including whether access warmth, refunds, state or logs survive each failure point.
  If an existing versioned formula/table defines this, a link is sufficient.

4. EIP-7702 authorization-refund lifecycle
For the applicable fork in v0.8.0, what is the intended account-state predicate for the EIP-7702 authorization refund?
Current EIP-7702 prose uses “not empty”, while the independently maintained Osaka execution specification checks account membership.
Please clarify the intended Arc behavior for:

• absent account;
• present but empty account;
• touched-empty account pending clearing;
• deleted and recreated account;
  and the state boundary at which that predicate is evaluated.
  Please also clarify when account clearing occurs relative to authorization processing and transaction/block-prefix commits, and whether any of those states are unreachable under Arc's actual lifecycle rules.

For all four sections, please identify the release/fork scope and normative basis of the answer. If something is intentionally undefined, implementation-specific, or known to differ in v0.8.0, stating that explicitly is useful to us.
We will preserve discrepancies rather than infer intended protocol rules from the implementation being tested.

An answer from an Arc execution/protocol maintainer would be especially helpful because we need to distinguish intended policy from observed implementation behavior. Thank you very much!

[DetectiveDdev]

Hello Circle Arc team,

I'm following up on [Discussion #485](#485) with a narrower technical question concerning native-USDC transfers and transaction rollback.

For Arc v0.8.0 (commit 66ad2d5aa6d9b41e8f689812004be4c7233a9e16) under Zero8/Osaka on mainnet 5042, could you confirm the expected behaviour when:

• A valid type-2 transaction with zero native value invokes an allowed NativeFiatToken caller.
• NativeCoinAuthority.transfer(from, to, amount) completes successfully.
• The outer router subsequently executes REVERT.

All accounts are distinct, funded, unblocked and nonzero. No delegation or other special execution features are involved.

Our source-code investigation and offline tests suggest that:

1. Native principal transfers, descendant state modifications, emitted logs and execution-generated refunds roll back.
2. The sender's nonce advancement and gas charges survive.
3. The beneficiary receives both base and priority fees without additional Transfer logs.
4. The first NativeCoinAuthority CALL is cold unless explicitly warmed.

Our synthetic fixture produced 50,650 gas on outer REVERT, 41,050 on success after refunds, and 50,755 on REVERT with explicit warming.

These are implementation-derived results, not independently established protocol expectations.

Could an Arc engineer confirm or correct these rules for this specific release and fork, ideally with a version-bound specification, independent reference calculation or authoritative test vector?

We can provide the complete unsigned, reproducible fixture if helpful.

We're trying to establish independently defensible financial accounting for protected transactions. We're not requesting approval to trade, and we don't need clarification on unrelated protocol features.

Thank you for your help!