EIP-6963은 지갑이 window.ethereum 하나를 서로 덮어쓰는 대신 두 개의 창 이벤트로 자신을 알리게 하는 탐지 방식입니다. 앱이 요청 이벤트를 보내면 지갑이 정보와 provider를 담아 알립니다. 이 글은 2026-10-27에 연 EIP-6963 원문(상태 Final)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
무엇이 문제였을까?
원문 Motivation은 여러 지갑 확장 프로그램이 window.ethereum에 주입되면 마지막에 로드된 지갑이 보통 이기고 사용자는 선택권이 없다고 설명합니다.
| 필드 | 원문 요건 |
|---|---|
| uuid | UUIDv4 형식의 고유 식별자 |
| name | 사용자에게 보여 줄 지갑의 이름 |
| icon | 데이터 URI여야 하며 96×96 이상의 정사각형 이미지를 권장 |
| rdns | 필수, 유효한 역방향 도메인 이름 |
두 이벤트는 어떻게 오갈까?
지갑은 eip6963:announceProvider 이벤트를 보내고, detail에 정보와 provider를 담은 객체를 싣습니다. 앱은 eip6963:requestProvider 이벤트로 지갑에게 다시 알리라고 요청합니다. 연결 해제와 권한 정리는 지갑 연결 해제와 토큰 승인 취소가 다른 이유 글에, 가짜 확장 프로그램 대응은 지갑 확장 프로그램 침해 공지, 설치 버전과 서명 노출 범위 확인하기 글에 있습니다.
rdns 값은 믿어도 될까?
rdns는 지갑이 스스로 적는 역방향 도메인 식별자입니다. 원문은 자기 신고이므로 기능 판단에 쓰지 말라고 안내합니다. 지갑 이름과 아이콘도 설치한 확장 프로그램이 진짜인지를 보증하지 않습니다.
아이콘과 이름은 어디까지 믿을까?
원문은 icon을 데이터 URI로 하고 96×96 이상의 정사각형 이미지를 권장하며, name은 사용자가 알아볼 수 있는 지갑의 별칭이라고 설명합니다. 이 값들은 모두 지갑 쪽이 채우므로, 앱이 지갑 목록을 보여 줄 때 이름이 같거나 아이콘이 같은 항목이 둘 있어도 이 표준만으로 어느 쪽이 진짜인지 가려낼 수 없습니다. 알림 객체는 Object.freeze로 얼리는 것을 권장하여, 앱이 받은 뒤 값을 바꾸지 못하게 합니다. 사용자가 지갑을 고를 때는 설치 출처와 확장 프로그램 관리 화면에서 직접 확인하는 습관이 더 믿을 만합니다.
이 글에서 확인하지 못한 것은?
원문 뒷부분의 참조 구현 코드, 개별 지갑이 이 표준을 지원하는 시점, 모바일 앱 연결 방식은 이번에 열지 않았습니다. 특정 지갑이 지원한다거나 지원하지 않는다는 서술은 하지 않습니다. 원문은 EIP-1193 provider를 그대로 담는다고 설명하므로 요청 방식은 EIP-1193 문서를 따로 읽어야 합니다. 정리하면 앱은 지갑을 찾기 위해 요청 이벤트를 보내고 지갑은 알림 이벤트로 답하며, 목록의 모든 필드는 지갑이 적은 값입니다. 원문 작성일은 2023-05-01이고 상태는 Final입니다. 연결 전에 주소와 서명 요청 내용을 직접 읽는 습관이 필요합니다.
자주 묻는 질문
앱이 지갑 목록을 어떻게 얻나요?
요청 이벤트를 보내고 알림 이벤트를 받습니다. 지갑이 늦게 로드돼도 요청에 다시 알립니다.
EIP-6963이 있으면 window.ethereum은 없어지나요?
원문은 window.ethereum의 대체 탐지 방식이라고만 설명합니다. 제거한다는 내용은 없습니다.
이 표준이 가짜 지갑을 걸러 주나요?
아닙니다. 필드는 모두 지갑이 제공하는 값이라 진위는 별도로 확인해야 합니다.
