v0.0

멀티체인 지원 범위 및 우선순위 정의서¶

1. Executive Summary¶

본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 멀티체인 지원 전략을 정의한다. 엔터프라이즈 고객의 자산 포트폴리오 구성과 시장 진입 전략(Phase 1 GTM)을 기반으로 체인 확장 로드맵을 수립하고, 각 체인 유형별 서명 아키텍처와 에어갭 페이로드 포맷을 정리한다.

핵심 원칙: - 엔터프라이즈 고객의 실제 보유 자산 분포에 따른 우선순위 결정 - 체인 추가 시 에어갭 서명 플로우(airgap-signing-flow.md)의 4단계 파이프라인과 호환 필수 - Phase 5 체인 추상화 레이어(SYS-03) 설계를 위한 기능 요구사항 도출 - CLAUDE.md 기술 스택의 BIP/EIP 표준 준수

지원 체인 요약: | 단계 | 시기 | 체인 | 커버리지 | |------|------|------|----------| | Phase 1 (출시) | 0-6개월 | BTC, ETH, USDT, USDC | 기관 자산의 ~80% | | Phase 2 (확장) | 6-12개월 | Polygon, BSC, Arbitrum, Optimism | EVM 생태계 확장 | | Phase 3 (다각화) | 12-24개월 | Solana, Cosmos, Tron | 비EVM 체인 진입 |

2. 멀티체인 지원 전략 개요¶

2.1. 우선순위 결정 기준¶

기준	가중치	설명
기관 보유 비중	40%	기관 투자자의 포트폴리오 내 해당 자산 비중
시가총액	20%	시장 안정성 및 유동성 지표
규제 수용도	15%	주요 시장(한국, EU, 미국)에서의 규제 인정 수준
기술 성숙도	15%	서명 표준, 에어갭 호환 프로토콜의 성숙도
D'CENT 기존 지원	10%	D'CENT 기존 펌웨어의 체인 지원 여부

2.2. Phase별 체인 확장 로드맵¶

Phase 1: 출시 (0-6개월) — 핵심 자산¶

체인	자산	기관 보유 비중	우선순위 점수	비고
Bitcoin	BTC	~45%	4.8/5.0	기관 포트폴리오 최대 비중. ETF 승인 후 기관 수요 급증
Ethereum	ETH	~25%	4.5/5.0	두 번째 기관 자산. DeFi/스테이킹 기반
Ethereum	USDT (ERC-20)	~15%	4.3/5.0	기관 스테이블코인 보유 1위
Ethereum	USDC (ERC-20)	~10%	4.2/5.0	규제 친화적 스테이블코인. MiCA Circle 준수

Phase 1 커버리지: 기관 자산의 약 80-90%

Phase 2: EVM 확장 (6-12개월) — L2 및 대체 EVM¶

체인	자산	우선순위 점수	비고
Polygon	MATIC/POL, USDT, USDC	3.8/5.0	한국 시장 높은 채택률, 낮은 수수료
BNB Smart Chain	BNB, BUSD	3.5/5.0	아시아 시장 점유율 높음
Arbitrum	ARB, USDT, USDC	3.4/5.0	Ethereum L2 선두, 기관 DeFi 접근 채널
Optimism	OP, USDT, USDC	3.3/5.0	Ethereum L2, Superchain 생태계

Phase 2 장점: EVM 호환 — Ethereum 서명 인프라 재사용 가능. 추가 개발 비용 최소화.

Phase 3: 비EVM 확장 (12-24개월) — 다각화¶

체인	자산	우선순위 점수	비고
Solana	SOL	3.0/5.0	Ed25519 서명, 높은 TPS. 기관 관심 증가
Cosmos	ATOM	2.7/5.0	IBC 생태계, Cosmos SDK 체인 다수
Tron	TRX, USDT (TRC-20)	2.5/5.0	USDT 최대 전송 네트워크, 아시아 수요

Phase 3 도전: 각 체인별 독립적 서명 알고리즘 + 트랜잭션 포맷 구현 필요.

3. 체인 유형별 서명 아키텍처¶

3.1. UTXO 모델 (Bitcoin)¶

핵심 표준: | 표준 | BIP | 용도 | 상태 | |------|-----|------|------| | PSBT | BIP-174 (v0), BIP-370 (v2) | 에어갭 트랜잭션 서명 워크플로우 | 필수 구현 | | Schnorr 서명 | BIP-340 | 단일 키 및 집계 서명 기반 | 필수 구현 | | MuSig2 | BIP-327 | N-of-N 집계 Schnorr 서명 | 핵심 다중 서명 방식 | | MuSig2 PSBT 필드 | BIP-373 | PSBT 내 MuSig2 데이터 확장 | MuSig2 연계 필수 | | MuSig2 키 파생 | BIP-328 | 집계 키 결정적 파생 | 월렛 복구에 필요 | | Taproot | BIP-86 | Taproot 주소 파생 경로 | MuSig2 전제 | | HD 월렛 | BIP-44, BIP-84, BIP-86 | 키 파생 경로 | 필수 구현 |

서명 흐름 (MuSig2):

Round 1: Nonce 교환
  서명자 1 → nonce_1 공개
  서명자 2 → nonce_2 공개
  ...
  서명자 N → nonce_N 공개

Round 2: 부분 서명 생성
  각 서명자: partial_sig_i = sign(message, secret_key_i, aggregated_nonce)

서명 집계:
  final_sig = aggregate(partial_sig_1, ..., partial_sig_N)
  → 단일 Schnorr 서명 (64 bytes)
  → 온체인에서는 단일 서명으로 보임 (프라이버시 보장)

에어갭 페이로드: - PSBT v2 (BIP-370): 역할 기반 워크플로우 지원 (Creator, Updater, Signer, Combiner, Finalizer) - UR Type: crypto-psbt (Blockchain Commons UR 표준) - MuSig2 데이터: BIP-373 PSBT 필드로 participant keys, public nonces, partial signatures 포함

PSBT 역할 매핑:

PSBT 역할	D'CENT 컴포넌트	수행 단계
Creator	온라인 대시보드	Request
Updater	온라인 대시보드	Request (UTXO, 경로 정보 추가)
Signer	D'CENT X 콜드월렛 (SE)	Sign
Combiner	오프라인 앱 / 대시보드	Sign/Broadcast
Finalizer	온라인 대시보드	Broadcast
Extractor	온라인 대시보드	Broadcast (최종 TX 추출)

3.2. EVM 모델 (Ethereum 및 호환 체인)¶

핵심 표준: | 표준 | 식별자 | 용도 | 상태 | |------|--------|------|------| | EIP-712 | Ethereum | 구조화 데이터 해싱 및 서명 | 필수 구현 | | ERC-4337 | Ethereum | Account Abstraction (스마트 컨트랙트 월렛) | Phase 2 고려 | | RLP | Ethereum | 트랜잭션 직렬화 | 필수 구현 | | EIP-1559 | Ethereum | Type 2 트랜잭션 (maxFeePerGas) | 필수 구현 |

서명 흐름 (EOA 기반):

1. 트랜잭션 구성 (대시보드)
   - to, value, data, gasLimit, maxFeePerGas, maxPriorityFeePerGas, nonce, chainId

2. EIP-712 TypedData 해싱
   - domainSeparator + structHash → signable hash

3. ECDSA 서명 (콜드월렛 SE)
   - secp256k1 커브
   - 서명값: (v, r, s) — 65 bytes

4. RLP 인코딩 (대시보드)
   - Type 2 트랜잭션 직렬화

EVM 다중 서명 — Smart Contract Multisig (Safe 기반):

1. Safe 트랜잭션 구성 (대시보드)
   - Safe TX Hash 계산: EIP-712 기반 구조화 해시

2. 각 서명자 개별 서명 (콜드월렛)
   - safeTxHash에 대한 ECDSA 서명
   - 각 서명은 독립적 (에어갭 호환)

3. 서명 수집 및 실행 (대시보드)
   - M개 서명 수집 후 execTransaction() 호출
   - 가스비 지불 계정 설정

에어갭 페이로드: - EIP-712 TypedData JSON 구조 - UR Type: crypto-sign-request (범용) 또는 커스텀 UR Type 정의 (Phase 5) - 페이로드 크기: 일반 전송 ~200-500 bytes, 컨트랙트 호출 ~1-10 KB

EVM L2 체인 확장 시 차이점:

항목	Ethereum L1	Polygon	Arbitrum	Optimism
Chain ID	1	137	42161	10
서명 알고리즘	ECDSA (동일)	ECDSA (동일)	ECDSA (동일)	ECDSA (동일)
Gas 모델	EIP-1559	EIP-1559	L2 Gas + L1 Data Fee	L2 Gas + L1 Data Fee
추가 구현	-	-	L1 Data Fee 추정	L1 Data Fee 추정

핵심: 서명 알고리즘과 트랜잭션 포맷은 동일 — Chain ID와 Gas 추정만 차별화. Phase 2 확장 비용 최소화.

3.3. EdDSA 모델 (Solana 등 — Phase 3)¶

핵심 사항: | 항목 | 내용 | |------|------| | 서명 알고리즘 | Ed25519 (Edwards-curve DSA) | | 키 파생 | BIP-44 m/44'/501'/0'/0' (SLIP-0044 Coin Type 501) | | 트랜잭션 포맷 | Solana Transaction v0 (Message + Signatures) | | 다중 서명 | 온체인 Multisig 프로그램 (Squads Protocol 등) |

구현 고려사항: - Ed25519는 secp256k1과 다른 커브 — SE 펌웨어에 별도 구현 필요 - Solana 트랜잭션의 Account 모델이 UTXO/EVM과 상이 - Blockhash 유효 기간 (~60초) — 에어갭 서명 시 시간 제약 존재 - 해결 방안: Durable Nonce 사용 (Blockhash 대신 Nonce Account 참조)

4. 체인별 트랜잭션 포맷 요약 테이블¶

항목	Bitcoin	Ethereum (EVM)	Solana
서명 알고리즘	Schnorr (BIP-340) / ECDSA	ECDSA secp256k1	Ed25519
주소 체계	bc1p... (Taproot), bc1q... (SegWit)	0x... (20 bytes, EIP-55 checksum)	Base58 (32 bytes public key)
트랜잭션 모델	UTXO	Account	Account
수수료 모델	sat/vByte (RBF 지원)	Gas (EIP-1559 base + tip)	Lamports (고정 기반)
다중 서명 방식	MuSig2 (BIP-327)	Smart Contract (Safe)	온체인 프로그램 (Squads)
에어갭 페이로드	PSBT (BIP-174/370)	EIP-712 TypedData	Custom Serialization
UR 인코딩	crypto-psbt	crypto-sign-request	커스텀 정의 필요
키 파생 경로	m/86'/0'/0' (Taproot)	m/44'/60'/0'/0	m/44'/501'/0'/0'
확인 블록 수	1-6	12-64	즉시 (Finality ~400ms)
에어갭 구현 난이도	낮음 (PSBT + UR 표준화)	중간 (EIP-712 표준화)	높음 (커스텀 필요)

5. 체인 추상화 원칙¶

Phase 5 System Architecture Design에서 체인 추상화 레이어(SYS-03)를 설계할 때 적용할 기능 요구사항을 정의한다.

5.1. 추상화 레이어 인터페이스 요구사항¶

ChainAdapter Interface:
  ├── getChainInfo()         → ChainMetadata (chainId, name, nativeCurrency)
  ├── createUnsignedTx()     → UnsignedTransaction (체인별 직렬화)
  ├── parseSignedTx()        → ParsedTransaction (서명 검증 후 파싱)
  ├── broadcastTx()          → TxHash (체인 전파)
  ├── estimateFee()          → FeeEstimate (수수료 추정)
  ├── getBalance()           → Balance (잔액 조회)
  ├── getTransactionStatus() → TxStatus (확인 상태)
  ├── validateAddress()      → boolean (주소 유효성 검증)
  ├── getDerivationPath()    → string (BIP-44 경로)
  └── encodeForAirgap()      → AirgapPayload (UR 인코딩 또는 커스텀)

5.2. 체인 유형별 어댑터¶

어댑터	대상 체인	공유 로직	체인별 구현
UTXOAdapter	Bitcoin	PSBT 생성/파싱, UR 인코딩	UTXO 선택, 수수료 산정, Taproot 스크립트
EVMAdapter	Ethereum, Polygon, BSC, Arbitrum, OP	RLP 인코딩, EIP-712, ABI	Chain ID, Gas 모델, L2 Data Fee
EdDSAAdapter	Solana, Cosmos	-	트랜잭션 직렬화, Account 모델, Nonce 관리

5.3. 설계 원칙¶

단일 인터페이스: 모든 체인이 동일한 ChainAdapter 인터페이스를 구현하여, 상위 레이어(정책 엔진, 대시보드 UI)가 체인에 무관하게 동작
플러그인 아키텍처: 새 체인 추가 시 어댑터 구현만으로 확장 가능 — 코어 로직 수정 불필요
에어갭 호환: 모든 어댑터의 encodeForAirgap() 출력이 QR(UR) 또는 USB-C로 전달 가능해야 함
SE 서명 추상화: 콜드월렛 SE가 체인별 서명 알고리즘(ECDSA, Schnorr, Ed25519)을 지원하되, 상위 레이어는 서명 알고리즘을 알 필요 없음

6. 스테이블코인 특별 고려사항¶

6.1. ERC-20 토큰 서명 패턴¶

스테이블코인(USDT, USDC)은 ERC-20 토큰으로, ETH 네이티브 전송과 다른 서명 패턴을 가진다.

전송 패턴:

Token Contract.transfer(to, amount)
  - to: 수신 주소
  - amount: 전송 금액 (토큰 단위, decimals 적용)
  - msg.sender: 송신자 (= 서명자 주소)
  - Gas: ETH로 지불 (토큰이 아닌 네이티브 코인)

approve/transferFrom 패턴 (위임 전송):

1. Token Contract.approve(spender, amount)
   - 특정 주소에 토큰 인출 권한 부여
   - 엔터프라이즈에서 주의: 무제한 approve 금지

2. Token Contract.transferFrom(from, to, amount)
   - 승인된 금액 내에서 위임 전송

6.2. 스테이블코인 관리 정책¶

항목	정책
approve 금액	필요 금액만 정확히 승인 (unlimited approve 금지)
Gas 관리	ETH 잔액 자동 확인 — Gas 부족 시 사전 경고
Decimals	USDT: 6 decimals, USDC: 6 decimals — 금액 표시 시 정확한 변환 필수
컨트랙트 검증	공식 토큰 컨트랙트 주소 하드코딩 — 위조 토큰 방지
WYSIWYS 표시	콜드월렛에서 토큰명, 수신 주소, 금액 모두 인간이 읽을 수 있게 표시

6.3. 멀티체인 스테이블코인¶

스테이블코인	지원 체인	Phase
USDT	Ethereum (ERC-20), Tron (TRC-20), Polygon, BSC	Phase 1 (ERC-20), Phase 2 (Polygon, BSC), Phase 3 (Tron)
USDC	Ethereum (ERC-20), Polygon, Arbitrum, Optimism	Phase 1 (ERC-20), Phase 2 (L2)
DAI	Ethereum (ERC-20)	Phase 2

7. 컴플라이언스 매핑¶

제약조건 ID	설명	충족 방식
AC-TX-06	콜드/핫 월렛 자산 분리 관리 및 비율 모니터링	체인별 콜드/핫(웜) 월렛 잔액 모니터링 대시보드. 법적 요구 비율(한국: 고객 자산 80% 이상 콜드 보관) 자동 확인
PRD-06	멀티체인 지원 범위 및 우선순위 정의	본 문서 전체 — Phase별 로드맵 및 체인별 서명 아키텍처 정의

8. 리스크 및 고려사항¶

8.1. 기술 리스크¶

리스크	영향	완화 방안
SE 칩의 Ed25519 미지원	Solana 등 Phase 3 체인 지연	Phase 6 펌웨어 요구사항에서 SE 역량 확인 필수
MuSig2 구현 복잡성	BTC 다중 서명 출시 지연	Ledger Bitcoin App v2.4.0 구현 참조, 단계적 구현
L2 Gas 추정 불확실성	트랜잭션 실패 또는 과다 수수료	L1 Data Fee 오라클 연동, 여유분 포함 추정
Solana Blockhash 만료	에어갭 서명 시간 초과	Durable Nonce 필수 적용

8.2. 사업 리스크¶

리스크	영향	완화 방안
체인 지원 경쟁 (Fireblocks 150+)	기관 고객 이탈	핵심 자산(BTC/ETH/스테이블코인) 완성도 우선, 체인 수 경쟁 회피
규제 변화로 특정 체인 제한	지원 체인 조정 필요	모듈화 아키텍처로 체인 비활성화 용이
스테이블코인 규제 강화 (MiCA)	USDT 사용 제한 가능	USDC(MiCA 준수) 우선 지원, USDT는 시장별 선택적

본 문서는 Phase 3 Core Product Design의 일부로, 에어갭 서명 플로우(airgap-signing-flow.md) 및 다중 서명 워크플로우(multisig-workflow.md)와 긴밀히 연계된다. 체인별 서명 알고리즘이 에어갭 페이로드 포맷(PSBT, EIP-712)을 결정하므로, 본 문서의 체인 아키텍처는 서명 플로우 설계의 필수 입력이다.