문서/시작하기/아키텍처
ARCHITECTURE
아키텍처
체인 무관 척추(게이트웨이) + 얇은 체인 어댑터 + 플러그형 모듈. 모듈은 체크 → 통과?만, 어댑터는 ok·사유·해시만 주고받습니다. 체인·정책 세부는 경계 안에 갇혀 코어로 새지 않습니다.
레이어
클라이언트 → 백엔드(게이트웨이) → 데이터 → 온체인 네 층입니다. 대시보드는 설정을 DB에 쓰고, 게이트웨이는 읽어서 처리·브로드캐스트합니다. signer·quorum의 진짜 소스는 온체인이고 DB는 미러입니다.
클라이언트 레이어
SDK 프론트 (유저 앱 · 빌드·서명)
대시보드 UI (기관 운영자)
↓
백엔드 레이어 · ANAM145
대시보드 백엔드 (설정 관리)
게이트웨이 (오케스트레이션 · 브로드캐스트)
↓
데이터 레이어
DB — 설정 + 히스토리
↓
온체인 레이어 · 외부
체인 — 정족수 최종 강제
느슨한 결합 (내부 인터페이스)
게이트웨이의 역할은 선택 · 호출 · 플래그 분기뿐이고, 모듈 내부의 HOW는 모릅니다. 모듈은 블랙박스로 계약(in → out)만 지킵니다.
| 모듈 | 성격 | 입력 | 출력 |
|---|---|---|---|
| KYT | 옵션 · 게이트 | tx · ctx | { allow, reason } |
| Paymaster | 옵션 · 증강 | tx · decision · ctx | { sponsored, paymasterData?, reason } |
| anam-signer | 필수 · 코어 | tx · ctx | { anamSignature } |
체인 어댑터
게이트웨이는 플래그/결과만 봅니다. 모든 체인은 어댑터 인터페이스 1종(buildUnsigned · setup · verify · submit)을 구현하고, 출력은 체인 무관하게 정규화됩니다 — ok · reason · hash (체인 고유값은 nativeCode에 보존).
| 체인 | Tier | 강제 방식 |
|---|---|---|
| XRPL | Tier B | 네이티브 SignerList · 프로토콜 강제 (Signers 배열 · submit_multisigned) |
| EVM | Tier A | 스마트 계정 · 컨트랙트 강제 (N서명 concat · 4337 번들러) |
| SOL | Tier A | 멀티시그 프로그램 · 컨트랙트 강제 (partialSign · sendTransaction) |
새 체인(Solana…)은 어댑터를 구현해 레지스트리에 등록만 하면 코어를 안 건드리고 추가됩니다. v0는 XRPL(Tier B)이 라이브이고 EVM·SOL은 확장 예정입니다.
옵션 모듈 (KYT · Paymaster)
켜고 끄는 플러그형 기능들. 전부 "메커니즘은 우리, 정책 판단은 기관" 경계를 지키고, 대시보드엔 토글만 둡니다.
- KYT (옵션) — 트랜사이트 스크리닝 → 통과 시에만 안암 signer가 서명(게이트). 켜지면 안암 signer가 정족수 필수 서명자가 됩니다.
- Paymaster (옵션 · EVM·SOL) — 우리 fee-payer가 가스를 대납하고 기관 잔고에서 차감. "누가·언제 무료냐"는 기관이 per-tx로 결정. XRPL은 XLS-68 활성화 전이라 미지원.