EIP-8175 has received a significant update introducing revamped CALL/CREATE capabilities, a new fee_auth mechanism, and fresh opcodes that reshape how smart contracts interact with the execution layer.

> impact

EIP-8175, authored by rakita, has landed a substantial update that redefines how CALL and CREATE operations work at the EVM level. The proposal introduces a capabilities-based model for these core opcodes, meaning contracts can now express fine-grained permissions over what child calls and contract deployments are allowed to do. Alongside this, new opcodes have been added to the specification to support these capability checks natively, and a `fee_auth` mechanism has been introduced that allows a caller to authorize fee delegation — essentially enabling patterns where one account can sponsor gas costs for another's execution within a structured, protocol-level framework. The motivation behind these changes is multi-layered. Ethereum's current CALL/CREATE model is relatively coarse: once you hand off execution, you have limited protocol-level control over what the callee can do. The capabilities model addresses this by letting callers restrict downstream behavior (e.g., preventing re-entrancy into specific contracts, limiting value transfer, or constraining CREATE permissions). The `fee_auth` mechanism tackles account abstraction-adjacent use cases by moving gas sponsorship from application-level hacks into the protocol itself, reducing reliance on meta-transaction relayers and ERC-4337 bundler complexity for common sponsorship patterns. For developers, the impact is significant. If EIP-8175 progresses toward inclusion, it will change smart contract design patterns around composability, security, and gas management. Contracts that rely on low-level CALL behavior may need updates for opcode compatibility. DApp developers building on account abstraction or gasless UX flows should evaluate whether `fee_auth` simplifies their stack. Auditors will need to understand the new capability restrictions to properly assess call graph safety. This is an early-stage EIP, but the scope of changes makes it one to track closely.

> Try this now

try this

# EIP-8175 Exploration: Capabilities & fee_auth
# ================================================
# NOTE: EIP-8175 is in draft. These opcodes and mechanisms are NOT live on mainnet.
# This walkthrough is conceptual, based on the current EIP spec, to help you
# reason about the proposed changes.

# --- 1. Understanding the Capabilities Model for CALL ---
# In the current EVM, a CALL is permissionless — the callee can do anything
# its code allows. EIP-8175 introduces a capabilities bitfield that restricts
# what the callee frame is allowed to do.

# Conceptual pseudocode for a capability-restricted CALL:
#
# capabilities = CAP_SEND_VALUE | CAP_CREATE   # allow value transfer + CREATE
# capabilities &= ~CAP_DELEGATECALL            # disallow DELEGATECALL in child frame
#
# CALL_WITH_CAP(gas, target, value, in_offset, in_size, out_offset, out_size, capabilities)
#
# If the callee attempts a DELEGATECALL, the EVM would revert that sub-frame
# automatically. This is enforced at the protocol level, not in Solidity.

# --- 2. New Opcodes ---
# EIP-8175 introduces new opcodes to query and enforce capabilities:
#
# GETCAP          -> pushes the current frame's capability bitfield onto the stack
# REQUIRECAP(cap) -> reverts if the current frame lacks the specified capability
#
# Example: A contract that refuses to execute without CREATE permission:
#
# // Hypothetical Solidity inline assembly (future compiler support needed)
# assembly {
#     let caps := getcap()                     // new opcode
#     let hasCreate := and(caps, 0x04)          // CAP_CREATE = bit 2 (illustrative)
#     if iszero(hasCreate) {
#         revert(0, 0)                          // bail if we can't CREATE
#     }
# }

# --- 3. The fee_auth Mechanism ---
# fee_auth allows an EOA or contract to sign an authorization granting another
# address the right to pay gas fees on its behalf.
#
# Conceptual flow:
#
# Step A: User signs a fee_auth message off-chain:
#   fee_auth_payload = {
#       authorizer: "0xUserAddress",
#       sponsor: "0xSponsorAddress",
#       max_fee: 1000000,                       # max gas units authorized
#       nonce: 42,
#       expiry: 1744070400                       # Unix timestamp
#   }
#   signature = sign(fee_auth_payload, user_private_key)
#
# Step B: Sponsor submits a transaction that includes the fee_auth:
#   tx = {
#       to: target_contract,
#       data: calldata,
#       fee_auth: (fee_auth_payload, signature)  # new transaction field
#   }
#   # The protocol debits gas from sponsor, but msg.sender in the EVM
#   # reflects the authorizer (0xUserAddress), not the sponsor.

# --- 4. What to Watch For ---
# - Compiler support: Solidity/Vyper will need updates for new opcodes
# - Tooling: Hardhat, Foundry, and Revm will need to implement the new opcodes
#   in their EVM interpreters for local testing
# - Security: Capability restrictions change the trust model of composed calls;
#   audit frameworks will need updated threat models
#
# Track the EIP: https://github.com/ethereum/EIPs (search for EIP-8175)
# Track the reference implementation in Revm by rakita