# EIP-7702

> EIP-7702는 외부 소유 계정(EOA)이 기존 스마트 컨트랙트에 코드 실행을 위임할 수 있도록 하여, 트랜잭션 일괄 처리 및 수수료 대납과 같은 스마트 계정 기능을 추가할 수 있게 하는 이더리움 개선 제안입니다.

- Canonical URL: https://iq.wiki/kr/wiki/eip-7702
- Categories: Projects & Protocols
- Tags: Ethereum, Infrastructure
- Created: 2026-10-30T13:04:34.908Z
- Last updated: 2026-10-30T13:04:34.908Z
- Source: IQ.wiki — the world's largest blockchain and crypto encyclopedia (https://iq.wiki)

---

**EIP-7702**는 외부 소유 계정(EOA)이 자신의 주소와 개인 키를 유지하면서 기존 [smart contract](https://iq.wiki/wiki/smart-contract)에 코드 실행을 위임할 수 있도록 하는 [Ethereum](https://iq.wiki/wiki/ethereum) 개선 제안입니다. [Vitalik Buterin](https://iq.wiki/wiki/vitalik-buterin), Sam Wilson, [Ansgar Dietrichs](https://iq.wiki/wiki/ansgar-dietrichs), 그리고 lightclient에 의해 제안되었으며, 이더리움의 Pectra 업그레이드의 일환으로 2025년 5월 7일에 활성화되었습니다.[\[1\]](#cite-id-onl799izdk)​[\[2\]](#cite-id-3unuqb31zy)​

이 위임은 교체되거나 삭제될 때까지 지속됩니다. 이를 통해 EOA는 자산을 이동하거나 주소를 변경하지 않고도 일괄 처리(batching) 및 수수료 대납 트랜잭션(sponsored transactions)과 같이 위임된 코드에 의해 구현된 기능들을 사용할 수 있습니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​



## History and Design

2024년 5월 7일 "EOA를 위한 코드 설정(Set Code for EOAs)"이라는 명칭으로 발표된 EIP-7702는 EOA에 계정 수준의 사용자 경험 기능을 제공하기 위해 설계되었습니다. 이 제안의 주요 우선순위에는 작업 일괄 처리(batching operations), 트랜잭션 대납(transaction sponsorship), 그리고 서브 키의 권한 제한 등이 포함되었습니다.[\[1\]](#cite-id-onl799izdk)​

EIP-7702는 EIP-3074의 후속 제안으로 설명되며, 이전 제안에서 제기된 한계와 보안 우려를 해결하기 위해 개발되었습니다.[\[2\]](#cite-id-3unuqb31zy) 이 제안의 저자들은 각 트랜잭션이 끝날 때마다 코드를 삭제하는 이전 설계 대신 지속적인 위임(persistent delegation) 방식을 선호했습니다. 그들은 반복적이고 쉬운 권한 부여가 스마트 컨트랙트 지갑과의 통합을 촉진하기보다는 EOA 스크립트를 별도의 사용자 경험 모델로 고착화할 수 있다고 주장했습니다.[\[1\]](#cite-id-onl799izdk)​

EIP-7702는 권한 부여 시 임의의 바이트코드를 배치하는 대신, EOA가 이미 다른 주소에 배포된 코드를 가리키도록 합니다. 저자들은 위임 메커니즘에 유용한 기능을 추가하지 않고도, 최소한의 프록시에는 약 50바이트가 필요한 반면 주소 포인터에는 20바이트가 필요할 것으로 추정했습니다.[\[1\]](#cite-id-onl799izdk) 이 제안은 위임의 일부로 초기화 코드를 실행하지 않습니다. 설정은 후속 호출에서 이루어져야 하며, 이는 새로운 실행 모드를 피할 수 있게 해주지만 설정을 비원자적(non-atomic)으로 만듭니다.[\[1\]](#cite-id-onl799izdk)​

이 설계는 미래의 [account abstraction](https://iq.wiki/wiki/account-abstraction)과 함께 작동하도록 의도되었습니다. 위임된 코드는 기존 [ERC-4337](https://iq.wiki/wiki/erc-4337) 지갑 코드를 가리킬 수 있으며, 이를 통해 EOA가 기존 EntryPoint를 통해 ERC-4337 번들에 참여할 수 있게 합니다. EIP-7702는 프로토콜 자체에 새로운 옵코드(opcode)를 추가하거나 상세한 [ERC-4337](https://iq.wiki/wiki/erc-4337) 또는 RIP-7560 메커니즘을 통합하지 않습니다.[\[1\]](#cite-id-onl799izdk)​

## Transaction and Delegation Mechanism

EIP-7702는 set-code 트랜잭션이라 불리는 트랜잭션 유형 `0x04`를 도입합니다. 여기에는 일반적인 트랜잭션 필드, 액세스 리스트, 그리고 비어 있지 않은 권한 부여 리스트(authorization list)가 포함됩니다. 이 트랜잭션 유형은 컨트랙트 생성 및 블록 트랜잭션을 제외하며, 대상(destination)이 null인 경우는 유효하지 않습니다.[\[1\]](#cite-id-onl799izdk) 각 권한 부여는 체인 ID, 위임 주소, 계정 논스(nonce), 그리고 서명 값으로 구성된 튜플입니다: `[chain_id, address, nonce, y_parity, r, s]`.[\[1\]](#cite-id-onl799izdk)​

권한 부여자는 권한 부여 파라미터의 해시인 `keccak(0x05 || rlp([chain_id, address, nonce]))`에 서명합니다. 체인 ID가 0이면 권한 부여가 여러 체인에 걸쳐 적용될 수 있으며, 특정 체인 ID는 해당 체인으로만 제한합니다. 논스는 권한 부여를 계정의 현재 상태에 결합하여 재전송 공격(replay)을 방지하는 데 도움이 됩니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

처리 과정에서 체인은 권한 부여의 체인 ID가 0이거나 현재 체인과 일치하는지, 서명이 유효한지, 그리고 권한 부여자의 논스가 서명된 논스와 일치하는지 확인합니다. 권한 부여자는 코드가 없거나 이미 위임된 상태여야 합니다. 유효한 권한 부여는 권한 부여자의 코드를 접두사 `0xef0100`과 대상 주소로 구성된 23바이트 위임 지표(delegation indicator)로 설정한 다음, 논스를 증가시킵니다.[\[1\]](#cite-id-onl799izdk) 주소 0으로의 권한 부여는 지표를 삭제합니다. 유효하지 않은 권한 부여는 처리를 계속하는 동안 건너뛰며, 동일한 권한 부여자에 대해 여러 개의 유효한 권한 부여가 있는 경우 마지막 것이 코드를 결정합니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

지표는 EIP-3541에서 일반 코드에서 금지한 `0xef` 바이트를 사용하여 위임된 계정을 표시합니다. 코드 실행 작업이 위임된 계정에 도달하면, [Ethereum](https://iq.wiki/wiki/ethereum)은 대상에서 코드를 로드하지만 권한 부여자의 계정 컨텍스트에서 이를 실행합니다. 확인(Resolution)은 단 하나의 위임 포인터만 따르므로 위임 체인이 형성되는 것을 방지합니다. 대상이 다른 위임된 계정인 경우 확인이 중단되며, 대상이 프리컴파일(precompile)인 경우 빈 코드로 확인됩니다.[\[1\]](#cite-id-onl799izdk)​

위임으로 인해 코드 검사 작업이 권한 부여자를 대상의 코드를 가진 것처럼 취급하지는 않습니다. 

예를 들어, 권한 부여자에 대한 `EXTCODESIZE` 및 `EXTCODECOPY`는 23바이트 지표를 관찰하는 반면, `CODESIZE` 및 `CODECOPY`는 현재 실행 중인 코드를 참조합니다.[\[1\]](#cite-id-onl799izdk) 위임 지표는 외부 트랜잭션 실행이 나중에 실패하더라도 그대로 유지됩니다.[\[1\]](#cite-id-onl799izdk)​

기본 권한 부여 비용은 권한 부여당 12,500 [gas](https://iq.wiki/wiki/gas)이며, 빈 계정과 관련된 권한 부여의 경우 최대 25,000 가스가 추가로 부과됩니다. 권한 부여자가 이미 비어 있지 않은 경우 처리 시 12,500 가스를 환불합니다. 콜드 계정(cold account)에서 위임된 코드를 확인하면 2,600 가스의 콜드 계정 읽기 비용이 추가되고, 웜 읽기(warm read)의 경우 100 가스가 추가됩니다.[\[1\]](#cite-id-onl799izdk)​

## Account Capabilities and Integrations

Delegated code can enable several wallet features. EIP-7702 supports batching multiple operations atomically in one transaction, such as combining an approval and a token swap. It can also support third-party payment of transaction fees, alternative authentication such as passkeys, spending limits, and account recovery without moving to a new address.[\[2\]](#cite-id-3unuqb31zy)​[\[1\]](#cite-id-onl799izdk)​

The authorization itself does not impose fine-grained permissions: the EIP warns that delegated code has unrestricted access to the account. Restrictions such as session keys or spending limits must be implemented by the delegated wallet code or its modules.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik) The EOA’s private key retains full control after delegation, so delegating to a multisignature wallet contract does not by itself turn the EOA into a multisignature account; the key can still bypass that contract’s signing policies.[\[3\]](#cite-id-z2pee5blik)​

Ethereum.org recommends that delegation contracts align with account-abstraction standards and ideally support [ERC-4337](https://iq.wiki/wiki/erc-4337). It also recommends avoiding dependence on a single relayer, whose failure could prevent the account from using relayer-dependent features. EOAs can perform batching themselves, while features such as [gas](https://iq.wiki/wiki/gas) abstraction and privacy-preserving withdrawals require a relayer.[\[3\]](#cite-id-z2pee5blik) The guidance recommends ERC-4337 bundlers using EntryPoint 0.8 or later, citing standardized relaying interfaces, built-in paymasters, and compatibility with future development.[\[3\]](#cite-id-z2pee5blik)​

For [dApp](https://iq.wiki/wiki/decentralized-application) requests, Ethereum.org points to ERC-5792’s `wallet_sendCalls` interface for batched calls, including batching with gas abstraction, and ERC-6900 for modular wallet features such as session keys and recovery. It recommends standardized wallet interfaces because wallets are expected to allowlist delegation contracts and there is no standardized direct method for dApps to request EIP-7702 authorization signatures.[\[3\]](#cite-id-z2pee5blik)​

Alchemy’s Wallet APIs support EIP-7702 delegation by default. Its Transaction APIs can prepare an authorization, request the required signatures, and submit delegation together with the intended calls; initial delegation requires both an authorization signature and a transaction signature, while subsequent transactions require a transaction signature.[\[4\]](#cite-id-2bvhlanl1h) Alchemy’s default delegate for new accounts created through those APIs is Modular Account v2 v1.1.0; existing accounts keep their recorded delegate unless a different supported version is requested, and delegation remains until replaced or cleared.[\[4\]](#cite-id-2bvhlanl1h) Alchemy also supports separate smart-contract-account options that do not use EIP-7702.[\[4\]](#cite-id-2bvhlanl1h)​



## 보안 고려 사항

EIP-7702는 EOA(외부 소유 계정)에 대한 기존의 가정들을 변화시킵니다. 

위임된 EOA는 트랜잭션을 시작하고, 호출을 수신하며, 하나의 트랜잭션 내에서 여러 호출을 실행할 수 있습니다. 또한 다른 계정에서 시작된 트랜잭션에 의해 잔액이 변경될 수도 있습니다. 따라서 이 제안은 코드가 있는 EOA가 트랜잭션을 시작하는 것을 제한했던 EIP-3607을 수정합니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

위임된 실행은 트랜잭션의 최상위 프레임 이외의 호출 컨텍스트에서도 `msg.sender`와 `tx.origin`이 같아지게 만들 수 있으므로, 컨트랙트는 재진입(reentrancy) 방지책으로 이러한 동일성에 안전하게 의존할 수 없습니다. Ethereum.org는 감사를 받은 `nonReentrant` 제어자나 일시적 저장소(transient-storage) 변수와 같은 명시적인 보호 장치를 권장합니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik) EIP 저자들은 이러한 보호를 위해 `tx.origin`에 의존하는 것을 나쁜 관행으로 규정합니다.[\[1\]](#cite-id-onl799izdk)​

위임된 코드는 계정 자산에 대해 광범위한 통제권을 행사할 수 있으므로, 제안서와 Ethereum.org 모두 서명하기 전에 대상을 신중하게 검토할 것을 권고합니다. 취약한 초기화 흐름은 프런트러닝(front-run)을 당할 수도 있습니다. 만약 초기화가 위임과 결합되어 있다면, 권한을 획득한 누군가가 변경된 매개변수로 초기화를 먼저 호출할 수 있습니다. 제안된 완화 방법으로는 초기화 매개변수에 대한 서명을 요구하거나 초기화를 [ERC-4337](https://iq.wiki/wiki/erc-4337) EntryPoint로 제한하는 방법 등이 있습니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

위임은 기존 EOA 저장소를 삭제하지 않습니다. 만약 새로운 코드가 이전 코드에서 사용하던 슬롯에 다른 의미를 부여하면, 남아있는 데이터가 의도하지 않은 동작을 유발할 수 있습니다. EIP는 업그레이드 중 저장소 충돌을 줄이는 방법 중 하나로 ERC-7201과 같은 네임스페이스 저장소(namespaced storage)를 논의합니다.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik) Ethereum.org는 또한 보호되지 않은 프록시 초기화 도구가 계정 탈취를 허용할 수 있다고 경고하며, 최소한의 감사 가능한 위임 로직과 보안이 확보된 생성자 및 초기화 도구를 사용할 것을 권장합니다.[\[3\]](#cite-id-z2pee5blik)​

체인 ID를 0으로 사용하는 유니버설 권한 부여는 여러 이더리움 가상 머신(EVM) 체인에 걸쳐 적용될 수 있습니다. 따라서 Ethereum.org는 이러한 위임에 프록시 대신 불변(immutable) 대상을 사용할 것을 권장하며, 체인마다 동일한 주소에서 코드가 다를 수 있는 컨트랙트에 대해 주의를 당부합니다.[\[3\]](#cite-id-z2pee5blik) 또한 지갑이 서명 중에 위임 대상을 명확하게 표시할 것을 권장하며, [하드웨어 지갑](https://iq.wiki/wiki/hardware-wallet)은 대신 신뢰할 수 있는 컨트랙트 허용 목록(allowlist)으로 위임을 제한할 수 있습니다.[\[3\]](#cite-id-z2pee5blik)​

스폰서 트랜잭션은 추가적인 위험을 초래합니다. 계정이 논스(nonce)를 높여 권한 부여를 무효화하거나 상환용 자금을 이체해 버리면, 릴레이어(relayer)는 보상을 받지 못한 채 [가스](https://iq.wiki/wiki/gas)를 소비하게 될 수 있습니다. EIP는 릴레이어가 보증금이나 평판 시스템을 고려할 것을 제안합니다.[\[1\]](#cite-id-onl799izdk) 위임된 코드는 또한 다른 대기 중인 트랜잭션을 무효화하는 방식으로 잔액이나 논스를 변경할 수 있습니다. 이 제안은 클라이언트가 위임 표시기가 0이 아닌 EOA에 대해 대기 중인 트랜잭션을 하나만 수락할 것을 권장합니다.[\[1\]](#cite-id-onl799izdk)​

## 피싱 및 지갑 위험

활성화된 지 몇 주 만에, [Ethereum](https://iq.wiki/wiki/ethereum) [mainnet](https://iq.wiki/wiki/mainnet)에서 상당수의 EIP-7702 위임이 지갑 자금을 탈취하도록 설계된 악성 컨트랙트를 가리키는 특수한 피싱 수법이 등장했습니다.[\[2\]](#cite-id-3unuqb31zy) 

​[Binance Academy](https://iq.wiki/wiki/binance-academy)는 [MetaMask](https://iq.wiki/wiki/metamask)와 같은 지갑 제공업체가 의심스러운 권한 부여를 표시하고 있으며, 사용자들에게 위임 대상을 [seed phrase](https://iq.wiki/wiki/seed-phrase)를 공유하는 것과 동일한 수준으로 주의해서 다룰 것을 권고했다고 보고했습니다.[\[2\]](#cite-id-3unuqb31zy)​

Ethereum.org는 릴레이어(relayer) 사용이 사용자의 IP 주소를 노출시킬 수 있으며, 공개 [mempools](https://iq.wiki/wiki/mempool)로 인해 트랜잭션이나 UserOperation이 이를 전파한 IP 주소에서 발생한 것인지 아니면 피어 투 피어(P2P) 네트워크를 통해 전달된 것인지 판단하기 어렵게 만들 수 있다고 경고합니다.[\[3\]](#cite-id-z2pee5blik) 또한 [ERC-20](https://iq.wiki/wiki/erc-20) 토큰을 통한 [gas](https://iq.wiki/wiki/gas) 결제, 일회용 세션 키, 온체인에서 서명이 검증되는 오프체인 승인 위임과 같은 프라이버시 중심의 설계를 권장합니다.[\[3\]](#cite-id-z2pee5blik)​

지갑 지원 여부는 다양합니다. [Alchemy](https://iq.wiki/wiki/alchemy)에 따르면 MetaMask는 인터페이스를 통해 자체 컨트랙트로의 위임은 허용하지만, 임의의 EIP-7702 권한 부여 페이로드에 대한 서명은 지원하지 않습니다. MetaMask를 사용하는 애플리케이션은 대신 ERC-5792 일괄 처리와 같은 지갑 네이티브 기능을 사용해야 할 수도 있습니다.[\[4\]](#cite-id-2bvhlanl1h) [Monad](https://iq.wiki/wiki/monad)에서 Alchemy의 EIP-7702 지원은 화이트리스트(allowlisted)로 관리되며, 위임된 계정은 문서화된 조건에 따라 최소 10 MON의 잔액을 유지해야 합니다.[\[4\]](#cite-id-2bvhlanl1h)​