개발자 문서

보안 모델

이 페이지는 Tidal을 통합해도 안전하게 만드는 수탁과 강제 보장 — 시스템에 서명 키를 맡기기 전에 당신이 알고 싶을 근거 — 을 진술합니다. Tidal의 수탁 설계와 아키텍처 방향에 근거합니다. 이 설계는 적대적으로 도출되었습니다. 각 선택에 대해 매력적인 대안이 구체적인 이유로 기각되었고, 그 이유들이 곧 이 모델입니다.

핵심 입장: 위임된 키가 아니라 예산 계좌

기각된 대안은 뻔한 것입니다. 에이전트에게 사용자 자기 계좌의 제한된 키를 주는 것. 이것이 실패하는 이유는 XRP 원장에 키별 지출 한도가 원생적으로 없기 때문입니다. Payment를 서명할 수 있는 키는 잔액 전부를 서명해 넘길 수 있습니다. 위임 아래에서는 어떤 정책 실패, 침해, 담합의 피해 반경이 사용자의 계좌 전체입니다.

그래서 모든 에이전트는 자금이 든 자기 예산 계좌를 가지며, 그 잔액이 최악의 손실에 대한 확고한, 온체인의, 아무도 믿지 않는 상한선입니다. 선충전, 예비금, 수동 충전이 그 보장의 대가이며, 그것은 치를 만한 값입니다. 약속을 성질로 바꾸어 주니까요. (자동 충전은 무한한 노출을 슬그머니 다시 쌓아 올립니다. 언젠가 추가된다면 자체 상한선과 자체 철회가 필요합니다.)

세 개의 키, 세 개의 권위

권위는 세 당사자가 쥔 세 개의 키에 나뉩니다. 이 분리가 모델의 척추입니다.

키	보유자	서명하는 것	할 수 없는 것
마스터	사용자, 자신의 Tidal 지갑에(저장 시 암호화)	구조적 거래: 자금, `TrustSet`, `SignerListSet`, 비상 쓸어 담기	에이전트의 일상 결제는 결코 서명하지 않음
에이전트	개발자인 당신, 당신의 KMS에 — 개인 절반은 결코 나가지 않음	결제의 첫 번째 서명	혼자 정족수를 채울 수 없음, 자기 한도를 바꿀 수 없음
공동서명자	Tidal 공동서명 서비스, HSM/KMS에	두 번째 서명, 오직 정책 승인 뒤에	혼자 정족수를 채울 수 없음, 마스터에 결코 손대지 못함

예산 계좌는 {에이전트 키, 공동서명자 키}의 정족수 2 SignerList를 지니며, 마스터 키는 활성 상태로 사용자와 함께 남습니다. 사용자가 자기 계좌에서 공동서명자를 우회할 수 있다는 것은 구멍이 아니라 자기수탁입니다. 이 관문은 돈의 주인을 제약하기 위해서가 아니라, 에이전트의 자율 지출을 제약하기 위해 존재합니다.

flowchart TB
    subgraph acct["예산 계좌 — SignerList 정족수 2, 마스터 활성"]
        direction LR
        q["결제하려면 서명 둘 다 필요"]
    end

    master["마스터 키<br/>(사용자)"] -->|"구조 + 비상 쓸어 담기"| acct
    master -.->|"Tidal이 오프라인이어도 쓸어 담기 가능"| exit(["직접 XRPL 탈출"])

    agent["에이전트 키<br/>(개발자 KMS)"] -->|"서명 1"| acct
    cosigner["공동서명자 키<br/>(Tidal HSM/KMS)"] -->|"서명 2, 승인 후"| acct
    policy["정책·위험"] -->|"승인 → 공동서명자 서명 가능"| cosigner

    agent -- "혼자서는: tefBAD_QUORUM" --x acct
    cosigner -- "혼자서는: tefBAD_QUORUM" --x acct

    classDef u fill:#fff4e6,stroke:#d98a3a;
    classDef d fill:#e8f4ff,stroke:#4a90d9;
    classDef t fill:#e8fff0,stroke:#3aa76d;
    class master u;
    class agent d;
    class cosigner,policy t;

공격 표

적대자가 시험할 법한 방식으로 보장을 진술합니다.

에이전트 혼자 — 유효한 거래를 만들 수 없습니다. 한 개의 서명은 정족수를 채우지 못하며, 원장은 tefBAD_QUORUM을 반환합니다. 원장이 강제.
공동서명자 혼자, 또는 침해됨 — 마찬가지입니다. 두 서명 중 하나만 쥐고 있어 결코 정족수에 이르지 못합니다. 원장이 강제.
에이전트와 공동서명자가 담합하거나 둘 다 침해됨 — 최악의 손실은 예산 계좌의 잔액뿐이며 그 이상은 없습니다. 계좌가 사용자의 메인 자금과 벽으로 막혀 있기 때문입니다. 원장이 강제.
정책 한도 — 그 확고한 벽 안쪽의 더 세밀한 제약. 서비스가 강제하며 감사 가능.
Tidal에 연결 불가 또는 소멸 — 사용자의 마스터 키가 공개 XRPL 엔드포인트를 통해 계좌를 직접 쓸어 담습니다. 원장이 강제하는 비상 탈출구.

기각된 단독 수탁 설계 대비 보안 개선은 정확합니다. 정책 권위체를 침해해도 서명 키를 얻지 못합니다. 정족수의 어느 절반도 쥐고 있지 않기 때문입니다.

SDK에서의 키와 권위 분리

이 분리는 설명에 그치지 않고 코드로 강제됩니다. 에이전트 키는 오직 당신의 키 저장소에서만 생성되고 쥐어지며, SDK는 정확히 준비된 프리이미지를 서명해 달라고 요청하고 반환된 기여를 검증할 뿐, 개인키를 결코 보지 않습니다. Tidal은 에이전트 개인키를 생성·가져오기·에스크로·백업·운영하지 않습니다. 그리고 키는 단일 역할입니다. 에이전트 키는 API 요청 서명 키, 웹훅 키, 정책 키로 결코 재사용되지 않습니다. SDK의 패키징도 런타임 경계를 강제합니다. 브라우저, 확장, React Native 번들에는 요청 서명 키 파서도, apiSecret 처리도, KMS SDK도, 서버 구현도 들어 있지 않으며, 서버 임포트가 공개 그래프로 새어 들면 패키징 테스트가 실패합니다.

한도는 실제로 어떻게 강제되는가

이것이 정직한 경계이며, 지갑들이 흔히 과장하는 지점이기에 거듭 말할 가치가 있습니다. 정책 한도 — 결제당, 하루, 누적, 허용 자산과 수신처 — 는 정책 권위체가 승인하지 않음으로써 지켜지고, 그로 인해 공동서명자가 서명을 보류합니다. 이 한도는 실제이고 감사 가능하지만, 서비스가 강제합니다.

원장이 그 어떤 서비스도 믿지 않고 스스로 강제하는 것은 딱 두 가지 — 2-of-2 정족수와 계좌 잔액 — 뿐입니다. 하루 한도를 온체인 보장이라고 말하는 문구는 틀렸으며, Tidal의 문서는 그렇게 말하지 않습니다. 공동서명자는 자신이 서명할 것의 형태도 추가로 강제합니다. 승인을 조회하기도 전에 Payment 이외의 모든 거래 유형을 거부하고, 최종 거래의 모든 필드 — 수신처, 태그, 금액, 자산과 발행자, 수수료, 단일 시퀀스 또는 티켓, 원장 윈도, 빈 서명 공개키, 그리고 경로·교차통화 필드의 부재 — 를 정확한 승인 의도에 묶습니다. 하나의 승인은 최대 하나의 서명을 낳으며, 바뀐 수수료·원장 윈도·티켓, 또는 어떤 필드든 그것은 다른 요청이고 fail-closed로 실패합니다.

철회와 비상 탈출

철회는 종국적이며 즉각적입니다. 정책 권위체가 승인을 멈추므로 공동서명자가 서명을 멈추고, 에이전트에게는 더 이상 정족수를 채울 수 없는 키만 남습니다. 그 예산 계좌에서 더는 결제할 수 없습니다. 철회는 이미 원장에서 검증된 결제를 되돌리지 못하며, 되돌릴 수도 없습니다. 정산된 XRP와 RLUSD는 최종이고, Tidal은 XRP에 대해 결코 클로백이라는 표현을 쓰지 않습니다.

사용자의 탈출구는 Tidal에 전적으로 독립적입니다. 마스터 키는 그들의 것이고 활성 상태로 남으므로, 모든 Tidal 서비스가 오프라인이어도 서명자 목록을 제거하고 잔액을 메인 지갑으로 쓸어 담을 수 있으며, 공개 XRPL 노드에 직접 제출합니다. 그래서 자금은 사용자가 오프라인 복구 백업을 완료하고 확인하기 전까지 막혀 있습니다. 진정한 자기수탁이란 Tidal이 잃어버린 마스터 키를 복구해 줄 수 없다는 뜻이기에, 무엇이 걸리기 전에 사용자가 스스로 복구할 수 있음을 모델이 요구하는 것입니다. 브라우저나 앱의 볼트는 편의용 사본일 뿐, 결코 유일한 사본으로 취급되지 않습니다.

밝혀 둘 잔여 위험

정직한 두 가지 단서가 있습니다. 첫째, RLUSD는 발행 자산이고 발행자 권한은 이 모델 바깥에 있습니다. 발행자는 RLUSD에 대해 온체인 클로백과 동결 통제를 유지하며, 이는 별도로 밝히고 수용해야 할 제3자 잔여 위험이지 Tidal의 수탁 설계가 없애 주는 것이 아닙니다. 둘째, 이 모델은 승인된 아키텍처 방향이며 구현·경화 중입니다. 특정 보장이 아직 배포되지 않은 구성 요소에 의존하는 경우, 그것은 완성된 것으로 제시하지 않고 초안으로 표시했습니다.

초안 — 확정 예정. 사용자가 마스터를 쥐고, 정책 권위체가 순수 위험 서비스로 있는 2-of-2 {에이전트, 공동서명자} 토폴로지가 비준된 방향이며, 라이브 위험 서비스에 맞서 테스트넷에서 종단 간 증명되었습니다. 프로덕션 경화 — 클라우드 KMS의 공동서명자 키, 완전한 복구 절차, 스테이징 배포 — 는 진행 중입니다. 보장은 확정된 설계로, 배포 상태는 변화하는 것으로 봐 주세요.

다음으로 읽을거리

이 보장들이 객체와 결제 수명주기에서 어떻게 드러나는지는 **개념**과 **통합 가이드**에서.
사용자용의 쉬운 설명은 **작동 원리**에 있습니다.