v0.2

Layer 2 토큰 발행 주체 세그먼트 델타 (Token Issuer Segment Delta)¶

1. Executive Summary¶

본 문서는 D'CENT Enterprise의 Layer 2 토큰 발행 주체(TI) 세그먼트 델타이다. e2e-core-flow.md(Layer 1)에서 정의한 5단계 E2E 플로우를 변경하지 않고, 토큰 발행 주체(S7~S8)에 고유한 차별화 요소를 [TI Delta] {단계명} Step N: 형식으로 기술한다.

적용 시나리오:

시나리오	조합	특성	예상 비중
S7	TI + Hybrid + 비콜드룸	대형 재단/프로토콜. 일부 인프라 직접 운영. 비동기 분산 서명 기본	3-5%
S8	TI + SaaS + 비콜드룸	중소 프로젝트/DAO. SaaS로 인프라 부담 최소화. 배치 배포 템플릿 활용	5-8%

TI 세그먼트의 핵심 특성: - 프로젝트 트레저리 관리: 프로젝트 토큰, 스테이블코인, ETH/BTC 리저브 등 다양한 자산 유형 - 분산 거버넌스: 코어팀/DAO 투표/커뮤니티 멀티시그 -- SC/CSP와 근본적으로 다른 의사결정 구조 - 베스팅 스케줄: 팀/투자자/어드바이저/커뮤니티별 시간 기반 토큰 릴리스 - 배치 배포: 에어드롭, 유동성 제공, 파트너 할당 등 다수 수신자 일괄 처리 - 커뮤니티 투명성: 규제보다 커뮤니티 신뢰가 핵심. 온체인 증명 필요

SC/CSP와의 근본적 차이:

차원	SC (셀프 커스터디)	CSP (수탁 사업자)	TI (토큰 발행)
의사결정 구조	이사회/CISO 중앙	이중 승인(내부+고객)	DAO 투표/코어팀 합의
서명자 위치	같은 사무실/국가	CSP 시설	전 세계 분산
TX 패턴	건별 고액	건별/배치	배치 중심
리포팅 대상	이사회	규제기관+고객	커뮤니티
정책 변경 권한	CISO/경영진	CSP+고객 합의	DAO 투표 결과

2. 도입 델타 (Adoption Delta)¶

[TI Delta] Adoption Step 1: 보안 요건 평가 -- 분산 거버넌스 매핑¶

Layer 1의 A-Step 1에서 TI는 다음이 다르다:

TI 고유 특성: 거버넌스가 분산되어 있으며, 의사결정 주체가 단일 조직이 아님

거버넌스 구조 분석:
코어팀 주도형: 재단/회사가 실질 의사결정 (초기 프로젝트)
DAO 주도형: 온체인 투표로 의사결정 (성숙한 프로토콜)
혼합형: 코어팀 제안 + DAO 승인 (가장 일반적)
서명자 후보 선정: 코어팀 멤버, DAO 위원회 멤버, 커뮤니티 멀티시그 참여자 -- 지리적으로 분산되어 있는 경우가 대부분
투명성 요건 정의:
온체인 트레저리 잔고 공개 (실시간)
TX 이력 커뮤니티 리포팅 (정기)
베스팅 스케줄 공개 및 이행 증명

[TI Delta] Adoption Step 2: 배포 모델 선택 -- IT 역량 대비 현실적 선택¶

TI의 배포 모델 선택은 프로젝트 규모와 IT 역량에 강하게 의존:

프로젝트 규모	권장 배포 모델	대응 시나리오	근거
대형 재단 (AUC $100M+)	Hybrid	S7	일부 인프라 직접 운영 가능, 대시보드 클라우드로 운영 부담 완화
중소 프로젝트/DAO	SaaS	S8	IT 전담 인력 없음, 인프라 관리 부담 최소화

Zero Cloud 배제 사유: TI의 코어팀은 통상 소규모(5-20명)이며 IT 전담 인력이 부족. Zero Cloud 자체 운영은 비현실적. scenario-matrix.md에서 TI-ZC-CR(#13)과 TI-ZC-NCR(#14) 모두 비유효 판정
콜드룸 배제 사유: TI의 비동기 분산 서명 패턴과 콜드룸 동기 집결이 구조적으로 충돌. scenario-matrix.md에서 TI-*-CR 조합 전부 비유효

[TI Delta] Adoption Step 4: 계약 -- 법인 구조 복잡성¶

계약 주체 불명확: DAO의 경우 법적 주체가 불명확할 수 있음. 재단 설립 여부, 관할권 확인 필요
서명자 합의: 분산된 서명자 간의 솔루션 도입 합의 과정이 SC/CSP보다 복잡 (DAO 투표 또는 코어팀 합의 필요)
규제 불확실성: 토큰 발행 관련 규제가 관할권별로 크게 상이하고 불확실. 규제 리스크 평가 필수

3. 온보딩 델타 (Onboarding Delta)¶

[TI Delta] Onboarding Step 3: 키 세레모니 -- 지리적 분산 서명자¶

Layer 1의 O-Step 3에서 TI의 핵심 차이는 서명자가 전 세계에 분산되어 있다는 것:

비대면 키 세레모니: 서명자가 각자의 위치에서 D'CENT X에 키를 생성. 공개키만 대시보드를 통해 교환
타임존 조율: 키 세레모니 시 최소한의 동기화가 필요한 단계(공개키 교환, aggregated 주소 확인)는 겹치는 업무 시간에 스케줄링
시드 백업 분산 보관: 각 서명자가 자신의 시드를 자신의 관할권 내에서 독립 보관 (중앙 집중 보관 불가)
Safe 선호: MuSig2의 nonce 동기화 요건(4시간 시한)이 극단적 시차(예: 서울-뉴욕)에서 부담. EVM 자산이 주력인 TI는 Safe가 기본 권장 (완전 비동기 지원)

[TI Delta] Onboarding Step 4: 월렛 구성 -- 트레저리 구조¶

TI 전용 월렛 구조:

월렛 유형	용도	비율	예시
Main Treasury	프로젝트 핵심 자산 장기 보관	40-60%	재단 기금, 리저브
Vesting Vault	베스팅 대상 토큰 보관	20-30%	팀/투자자/어드바이저 물량
Distribution Pool	배포 대기 토큰	10-20%	에어드롭, 유동성 공급, 파트너 할당
Operations	일상 운영비 (Warm)	5-10%	가스비, 서비스 비용, 보상

Cold/Warm 분류: Main Treasury + Vesting Vault = Cold (MuSig2/Safe), Distribution Pool + Operations = Warm (MPC-TSS)

[TI Delta] Onboarding Step 5: 정책 초기 설정 -- 베스팅 + 배치¶

TI 전용 정책:

베스팅 스케줄 설정:
대상자 그룹 정의 (팀, 시드 투자자, 시리즈A, 어드바이저, 커뮤니티)
그룹별 클리프(cliff) 기간 설정 (예: 팀 12개월, 투자자 6개월)
릴리스 방식: 선형(linear) 또는 단계별(step)
릴리스 주기: 월간 / 분기간
대시보드에 스케줄 등록 -> 릴리스 일자 도래 시 자동 알림
배치 배포 템플릿 설정:
에어드롭 템플릿: 다수 수신자(수백~수천) 주소 + 금액 CSV 업로드
유동성 풀 배포 템플릿: DEX 유동성 추가 TX 패턴
파트너 할당 템플릿: 정기적 파트너 보상 지급 패턴
DAO 거버넌스 연계 설정:
온체인 투표 결과 모니터링 채널 설정
투표 결과 -> 대시보드 TX 생성 연계 방식 결정:
- 자동 트리거: 투표 통과 시 대시보드에 TX 자동 생성 (서명은 수동)
- 수동 트리거: 투표 결과 확인 후 Admin이 수동 TX 생성
거버넌스 결의 증적 첨부 (TX에 거버넌스 투표 ID 메타데이터 연결)

4. 일상 운영 델타 (Daily Operations Delta)¶

[TI Delta] Daily Step 1: TX 생성 -- 배치 패턴¶

Layer 1의 D-Step 1에서 TI의 TX 패턴:

TX 유형	빈도	특성	예시
베스팅 릴리스	월/분기	스케줄 기반, 대시보드 자동 알림	팀 물량 월 1회 릴리스
배치 배포	주 1-2회	다수 수신자 일괄, 템플릿 사용	에어드롭, 파트너 보상
유동성 관리	주 1-5회	DEX 풀 관리, 리밸런싱	Uniswap/SushiSwap
운영비	일 1-3건	가스비 충전, 서비스 비용	Operations 월렛
거버넌스 실행	비정기	DAO 투표 결과 실행	파라미터 변경, 기금 배분

베스팅 릴리스 플로우: 1. 대시보드가 릴리스 일자를 감지하고 알림 발송 2. Admin이 릴리스 TX를 확인하고 생성 (자동 생성된 초안 기반) 3. 서명자 M명이 비동기로 승인 + 서명 (signing-core-flow.md Step 1~9) 4. 릴리스 완료 후 온체인 증명 기록 + 커뮤니티 공개

배치 배포 플로우: 1. Admin이 배포 템플릿 + 수신자 CSV를 대시보드에 업로드 2. 대시보드가 개별 TX 또는 다수 수신자 TX 생성 (체인 특성에 따라) 3. 서명자 M명이 배치 전체를 한 세션에서 서명 (세션 효율화) 4. 배포 완료 확인 + 커뮤니티 리포팅

[TI Delta] Daily Step 2: 에어갭 서명 -- 비동기 분산 기본¶

비동기 서명이 기본: TI 서명자는 전 세계에 분산되어 있으므로 동기 집결이 불가능. signing-noncoldroom-annotation.md의 비동기 분산 서명 모델이 기본 적용
Safe 프로토콜 권장: 완전 비동기 지원으로 시간대 분산 서명에 최적. MuSig2 nonce 4시간 시한이 극단적 분산 시 제약
서명 시한: Safe 기준 48시간, MuSig2 기준 4시간 (nonce 유효 시간)

[TI Delta] Daily Step 4: 정기 리포팅 -- 커뮤니티 투명성¶

TI 리포팅의 핵심: 규제 기관이 아닌 커뮤니티가 주요 수신자

수신자	리포트 내용	주기	공개 방식
커뮤니티	트레저리 잔고, 베스팅 진행률, 배포 이력	월간	블로그/포럼/온체인
코어팀	운영 현황, 가스비 분석, 리스크 평가	주간	내부 대시보드
투자자	투자 관련 물량 현황, 베스팅 진행률	분기	투자자 리포트
DAO 거버넌스	거버넌스 결의 실행 현황, 기금 사용 보고	분기	거버넌스 포럼

온체인 투명성: 트레저리 잔고와 TX 이력을 온체인에서 직접 검증 가능하도록 공개. 블록 익스플로러 링크 + 대시보드 공개 뷰 제공
온체인/오프체인 모델 선택:
순수 온체인: 거버넌스 투표도 온체인, TX 실행도 온체인 투표 결과에 자동 바인딩 (성숙한 DAO)
오프체인 의사결정 + 온체인 실행: Snapshot 등 오프체인 투표 후 수동 TX 생성 (대부분의 프로젝트)

5. 관리 델타 (Administration Delta)¶

[TI Delta] Admin Step 2: 서명자 교체 -- DAO 결의 기반¶

Layer 1의 M-Step 2에서 TI의 서명자 교체는 DAO 투표 또는 코어팀 합의가 전제:

교체 트리거: DAO 결의, 코어팀 멤버 이탈, 커뮤니티 불신임, 보안 사고
투표 절차:
서명자 교체 제안(Proposal) 등록 (DAO 거버넌스 채널)
투표 기간 (통상 3-7일)
투표 통과 -> 교체 실행
SC/CSP와의 차이: SC는 내부 인사 결정으로 즉시 교체, CSP는 고객 합의로 교체. TI는 커뮤니티 합의 과정 필요 -> 교체에 1-2주 소요

[TI Delta] Admin Step 3: 정책 변경 -- DAO 거버넌스 연계¶

정책 변경의 거버넌스 프로세스:

변경 유형	의사결정 방식	소요 기간	예시
운영 정책 (화이트리스트, 한도)	코어팀 합의	1-3일	DEX 주소 추가
구조 정책 (M-of-N, 서명자)	DAO 투표	7-14일	정족수 변경
토큰이코노미 변경	DAO + 코어팀 합의	14-30일	번/민트, 배분 비율
HW 정책 엔진 변경	DAO 슈퍼 투표	14-30일	SE 불변 규칙 변경

토큰 이코노미 변경 반영: 번(burn)/민트(mint) 이벤트, 유통량 변경 시 트레저리 정책 조정 필요. Vesting Vault와 Distribution Pool 비율 재설정

6. 긴급 대응 델타 (Emergency Response Delta)¶

[TI Delta] Emergency Step 1: 키 손상 대응 -- 커뮤니티 공개 대응¶

Layer 1의 E-Step 1에서 TI의 핵심 차이:

은폐 불가: SC는 내부만 알면 되고, CSP는 영향 고객만 통보하면 되지만, TI는 온체인에서 비정상 TX가 커뮤니티에 즉시 노출. 은폐가 구조적으로 불가능
즉시 공개 대응:
보안 사고 인지 즉시 (1시간 이내) 커뮤니티 공식 채널에 초기 공지
영향 범위 파악 후 (4-8시간) 상세 공지
사후 분석 완료 후 (24-72시간) 최종 사고 보고서 공개
토큰 가격 영향: 트레저리 보안 사고는 토큰 가격에 직접 영향. 신속하고 투명한 대응이 가격 하락을 최소화

[TI Delta] Emergency Step 3: 서명자 불능 -- 분산 서명자 긴급 소집¶

분산 서명자 긴급 소집 문제: 전 세계 분산된 서명자를 긴급 소집하기 어려움 (시차, 연락 두절 가능)
대응:
24/7 비상 연락 채널 유지 (Signal, Telegram 그룹 등 암호화 메신저)
릴레이 서명 방식: 시간대별로 가용한 서명자가 순차적으로 서명
N > M + 3 권장: 분산 환경에서 동시 불능 리스크가 SC보다 높음

[TI Delta] Emergency Step 추가: 스마트 컨트랙트 취약점 대응¶

SC/CSP에는 없는 TI 전용 긴급 대응 시나리오:

트리거: 베스팅 컨트랙트, 배포 컨트랙트, 거버넌스 컨트랙트의 취약점 발견
액션:
취약 컨트랙트와 상호작용하는 모든 TX 즉시 중단
취약점 영향 범위 파악 (트레저리 자산 노출 가능성)
컨트랙트 일시 정지 (pause 기능 있는 경우)
패치 또는 마이그레이션 계획 수립 (DAO 긴급 투표)
커뮤니티 투명 공개
예방: 베스팅/배포 컨트랙트는 D'CENT Enterprise 범위 밖이나, 해당 컨트랙트와 상호작용하는 TX의 안전성은 WYSIWYS 검증으로 확인

7. 시나리오별 차이 매트릭스 (S7~S8)¶

차원	S7 (HY+NCR)	S8 (SA+NCR)
도입 복잡도	중간	낮음
온보딩 기간	2-4주	1-2주
인프라	서명환경 자체 + 대시보드 클라우드	관리 불필요
IT 인력	1-2명 (겸임 가능)	불필요
보안 등급	Grade B	Grade C
서명 방식	비동기 분산 (Safe 기본)	비동기 분산 (Safe 기본)
M-of-N 구성	3-of-5 / 4-of-7	2-of-3 / 3-of-5
배치 규모	대규모 (수백~수천 수신자)	중소규모 (수십~수백 수신자)
DAO 거버넌스	정교한 온체인/오프체인 혼합	Snapshot 오프체인 기본
트레저리 규모	$10M-500M	$1M-50M
대상	대형 L1/L2 프로토콜, DeFi 재단	중소 프로젝트, DAO 트레저리

S7 (Hybrid + 비콜드룸) 특이사항¶

대형 재단/프로토콜이 일부 인프라를 직접 운영
서명 환경(보안 캐비닛)은 코어팀 사무실에 설치
대시보드는 D'CENT 클라우드로 운영 부담 완화
Grade B 보완 조치 적용 (비콜드룸)
배치 배포 시 수백~수천 수신자 처리 능력 필요

S8 (SaaS + 비콜드룸) 특이사항¶

중소 프로젝트/DAO의 진입 장벽 최소화
D'CENT X 콜드월렛만 보유, 나머지 D'CENT SaaS
배치 배포 템플릿 활용 극대화 (에어드롭/유동성/보상 미리 구성된 패턴 사용)
온보딩 1-2주 내 첫 배치 배포 가능
자산 규모 성장 시 S7으로 전환 (배포 모델 전환 축)

작성일: 2026-03-28 Phase 14 Plan 03 산출물 -- Layer 2 Token Issuer Segment Delta 적용 범위: S7~S8 (토큰 발행 주체) 참조: e2e-core-flow.md (Layer 1 E2E Core Flow), signing-core-flow.md (Layer 1 Signing Core Flow)