호패란
호패는 GIWA 위의 컴플라이언스 어테스테이션 레이어입니다. 한 번 검증받은 지갑은 어느 dApp에서든 다시 검증받지 않고, 자격을 잃으면 트랜잭션 한 건으로 생태계 전체에서 동시에 꺼집니다.
풀려는 문제
원화 스테이블코인과 은행 자금이 체인에 올라오면, 모든 온체인 금융 서비스가 같은 질문을 먼저 하게 됩니다. “이 지갑까지 보내도 되는가.” 지금 GIWA에는 그 답을 돌려줄 공용 레이어가 없습니다.
dApp이 각자 KYC를 붙이면 비용이 네 곳에서 동시에 발생합니다.
- ·사용자는 서비스마다 같은 신분증을 다시 찍습니다.
- ·개인정보가 열 군데에 복제되어 쌓입니다 (PIPA 리스크).
- ·팀마다 KYC 벤더 계약과 구축에 수개월과 수천만 원을 씁니다.
- ·한 곳에서 제재 대상이 걸러져도 나머지는 모릅니다. 검증 결과가 서비스 안에 갇히기 때문입니다.
호패의 답 — 동사 세 개
| 동사 | 무슨 일이 일어나나 | dApp이 할 일 |
|---|---|---|
| 발급 | 심사 결과를 EAS 어테스테이션으로 발급합니다. 온체인에 올라가는 것은 종류·등급·해시뿐이고 개인정보는 0바이트입니다. | 없음 (발급 서비스의 몫) |
| 검증 | 어느 컨트랙트·프론트엔드에서든 isVerified() 한 번으로 판정을 읽습니다. 가스가 들지 않는 view 호출입니다. | view 호출 한 줄 |
| 폐기 | 제재 히트·재심사 탈락이 나오면 폐기 트랜잭션 한 건으로 모든 게이트에서 즉시 false가 됩니다. | 없음 (다음 조회에 자동 반영) |
이 셋을 한 곳에 모은 것이 호패입니다. 검증 결과를 서비스 안에 가두지 않고 지갑에 붙여두면, 발급은 한 번이고 재사용은 무제한이며 철회는 즉시입니다.
무엇으로 이루어져 있나
| 레이어 | 구성요소 | 역할 |
|---|---|---|
| L1 · 온체인 | HopaeRegistry · HopaeZkGate | GIWA 프리디플로이 EAS 위의 발급·폐기·검증. 증적 해시 없는 발급은 revert됩니다. |
| L2 · 발급 서비스 | 심사 → 발급/폐기 · 수명주기 데몬 | 소유권 증명, 벤더 검증, 제재 스크리닝, 증적 생성, 재대사와 자동 폐기. 가스는 서비스가 부담합니다. |
| L3 · SDK | @hopae/sdk | isVerified 래퍼, React 훅, 배지 컴포넌트, 클레임 커밋먼트 모듈. |
| L4 · 서피스 | 데모 웹 · 컴플라이언스 콘솔 · 지갑 통합 | 사용자의 발급 체험, 운영자의 케이스·SLA·KPI 화면, 지갑 안의 인증마크. |
신뢰의 원천은 어테스테이션 하나입니다. EAS 표준을 그대로 쓰기 때문에, 호패 레지스트리를 거치지 않고 EAS를 직접 읽는 검증자와도 호환됩니다.
설계 원칙 — 지켜야 할 선
| 원칙 | 의미 |
|---|---|
| PII 온체인 금지 | 온체인에는 kind·level·증적 해시 등 판정값만. 개인정보는 0바이트. |
| 본인확인기관이 아님 | 검증 “실행”은 공인 벤더(통신사 본인확인·eKYC 등)에 위임. 호패는 심사·온체인화·수명주기·증적을 맡습니다. |
| 자산에 대한 권한 없음 | 호패는 자격 판정만 제공합니다. 폐기돼도 자산 동결·몰수는 없고, 한도·차단 정책은 각 dApp의 것입니다. |
| Fail-closed 판정 | 폐기·만료·어테스테이션 부재 시 isVerified()는 즉시 false. 판단 불가는 곧 불허입니다. |
| 증적 없는 발급·폐기 불가 | 모든 발급·폐기 트랜잭션은 오프체인 증적 레코드의 해시를 동반해야 합니다 (없으면 revert). |
지금 어디까지 되나
호패는 GIWA Sepolia 테스트넷에서 동작하는 MVP입니다. 발급·폐기·검증은 실제 온체인 트랜잭션이고, 신원 검증 벤더 연동은 아직 없습니다.
| 영역 | 상태 | 내용 |
|---|---|---|
| 온체인 레지스트리 | 라이브 | 4개 컨트랙트 GIWA Sepolia 배포·소스 Verified. 테스트 37종. |
| 발급·폐기 서비스 | 라이브 | 가스리스 발급, EIP-191 소유권 서명 검증, 폐기와 SLA 측정. |
| SDK · 게이트 통합 | 라이브 | 코어 + React + 클레임 모듈. 컨트랙트 직접 조회도 가능합니다. |
| ZK 커밋먼트 · 술어 증명 | 라이브 | claimsRoot 온체인 기록, age_over 회로의 온체인 검증까지 동작합니다. |
| 벤더 신원 검증 (L2·L3) | 로드맵 | 휴대폰 본인확인·eKYC 연동 전이라 지금 발급되는 등급은 L1 본인 선언뿐입니다. |
| 일일 재대사 데몬 · 증적 저장소 | 로드맵 | 제품의 핵심 주장이지만 아직 자동화 전입니다. 로드맵의 1순위입니다. |
영역별 전체 목록은 기능 전체, 언제 무엇이 열리는지는 로드맵에 있습니다.
왜 GIWA인가
- ·GIWA는 EAS를 프리디플로이(
0x4200…0021)로 탑재하고, 공식 FAQ에 공인 기관 KYC 결과의 온체인 기록을 명시했습니다. 호패는 그 표준 위의 구현입니다. - ·하나·두나무 원화 스테이블 생태계와 은행 PoC가 GIWA 위에서 진행 중입니다. 자금이 올라오는 시점과 신뢰 레이어가 필요한 시점이 같습니다.
- ·같은 모델이 Base에서 이미 검증됐습니다(Coinbase Verifications, EAS 기반). 한국의 규제 문법 — 특금법 고객확인, 재이행 주기, 트래블룰 — 으로 구현한 것은 아직 없습니다.
다음으로
처음이라면
누가 쓰는가 →
dApp·지갑·발행사·사용자별 통합 시나리오와 게이트 설계.
작동 원리 →4레이어 구조, 발급 플로우, 어테스테이션 수명주기.
기능 전체 →심사부터 증적·ZK까지 영역별 기능 목록과 구현 상태.
로드맵 →Phase별 계획, 등급 실발급 순서, ZK 단계, KPI.