Seraphis와 Jamtis 완벽 해설: 2026년 Monero 프로토콜의 다음 도약

2025년 말 Monero Research Lab(MRL)이 첫 감사를 마친 Seraphis 라이브러리 브랜치를 테스트 포크에 조용히 머지했을 때, 프로토콜을 오랫동안 추적해 온 관찰자들이 4년 가까이 예상해 온 사실이 비로소 확정되었습니다. Monero가 2017년 RingCT 도입 이후 가장 광범위한 트랜잭션 계층의 재설계를 준비하고 있다는 것입니다. Seraphis는 단순한 기능 업그레이드가 아닙니다. 트랜잭션 프로토콜 전체, 송신자 익명성을 보호하는 암호학적 증명, 그리고 사용자가 지갑에서 마주하는 주소 체계까지 통째로 교체합니다. Seraphis 위에서 동작하도록 설계된 주소 계층 Jamtis는 지난 5년간 모든 Monero 지갑의 뼈대 역할을 해 온 서브주소(subaddress) 형식을 역사 속으로 보내게 됩니다.

이 가이드에서는 두 가지 변화를 모두 풀어봅니다. 무엇이 바뀌는지, 핵심 연구자들(koe, jberman, UkoeHB)이 왜 수천 시간을 들여 설계했는지, 일반 사용자에게 무엇이 달라지는지, 그리고 MoneroSwapper와 같은 KYC 없는 스왑 서비스가 사용자에게 새로운 학습 부담을 지우지 않으면서 어떻게 마이그레이션을 처리하는지 살펴봅니다. XMR을 한 번이라도 보내거나 받아 본 적이 있다면, 지금 사용하시는 주소는 결국 더 이상 권장되지 않을 것입니다. 활성화 당일에 허둥대는 것보다, 지금 미리 업그레이드를 이해해 두는 편이 훨씬 비용이 적게 듭니다.

왜 Monero는 Seraphis가 필요한가

현재 Monero의 트랜잭션 프로토콜은 여러 층이 쌓여 만들어진 패치워크에 가깝습니다. 핵심 증명인 CLSAG는 2020년 10월 하드포크에서 MLSAG를 대체하면서 링 서명 크기를 약 25% 줄였지만, 여전히 최근 출력에서 샘플링된 16개의 디코이로 구성된 고정 링 위에서 동작합니다. "16개 중 하나"라는 구조는 표면적으로는 견고해 보이지만, 통계적 휴리스틱, 타이밍 분석, 이른바 "EAE 공격(eve-alice-eve)"은 적대적 모델에서 송신자 익명성을 조금씩 깎아내립니다. 2019년 이후 여러 동료 심사 논문이 멤풀(mempool) 가시성이 넓은 분석가가 출력의 상당 부분을 확률적으로 비익명화할 수 있다는 점을 보여주었습니다.

대체성(fungibility) 논쟁은 이 문제를 더 복잡하게 만듭니다. 모든 CLSAG 링은 실제 지출 하나와 디코이 15개로 구성되는데, 그 디코이 역시 과거 트랜잭션의 출력입니다. 두 트랜잭션이 서로를 디코이로 참조하고 체인 분석이 그중 한 가능성을 배제하면, 다른 쪽에 대한 확률은 더 뚜렷해집니다. 시스템은 전체적으로는 견고하지만 가장자리에서 정보가 새어 나갑니다. Seraphis는 익명성 집합을 극적으로 넓히는 동시에 증명의 구조를 재편하여 "소유"와 "멤버십"을 분리함으로써 이 누수를 막습니다.

• 더 큰 익명성 집합: Seraphis는 16개가 아니라 128개 또는 256개(활성화 시점에 선택되는 곡선과 증명 시스템에 따라 더 클 수도 있음) 출력을 대상으로 한 멤버십 증명을 지원하도록 설계되었습니다. 수학적으로 증명 크기는 로그 함수적으로 증가하므로, "128 중 하나"는 CLSAG의 "16 중 하나"에 비해 바이트 비용이 아주 조금만 더 듭니다.
• 관심사의 분리: 오늘날 단일 CLSAG 증명은 "나는 이 출력들 중 하나의 소유자다"와 "아직 사용하지 않았다"를 한 묶음으로 처리합니다. Seraphis는 이를 멤버십 증명과 컴포지션 증명으로 분리합니다. 각각은 독립적으로 최적화, 감사, 업그레이드할 수 있습니다.
• 뷰 키(view key) 수술: 현재 뷰 키는 보유한 사람 누구에게나 모든 수신 출력을 그대로 노출합니다. 감사인, 거래소, 세무 회계사 모두에게 똑같이 정보의 소방 호스를 들이대는 셈입니다. Seraphis는 뷰 키를 계층화하여 사용자가 잔돈이나 자기 지출을 노출하지 않고도 영수증에 대한 읽기 전용 권한만 부여할 수 있게 합니다.
• 플러그인 형태의 증명: Seraphis 아키텍처는 멤버십 증명을 교체 가능한 모듈로 취급합니다. 현재 목표는 FCMP++(Full-Chain Membership Proofs Plus Plus)로, 체인 위의 모든 출력이 잠재적 디코이가 될 수 있게 만듭니다. 이는 16개에서 단번에 차원이 다른 수준으로 도약하는 것입니다.

이 모든 이야기가 CLSAG가 지금 깨졌다는 뜻은 아닙니다. 다만 설계 공간이 한 단계 더 나아갔고, 학계의 암호학이 성숙했으며, Monero의 연구 문화가 "증명 가능한 더 나은 방법"이 테이블 위에 올라와 있을 때 "쓸 만하다" 정도에 만족하지 않는다는 의미입니다. 비용은 엔지니어링 복잡성과 수년에 걸친 전환 과정이고, 그 대가로 얻는 것은 향후 10년의 분석 도구를 견뎌낼 수 있는 프라이버시 자세입니다.

Seraphis가 트랜잭션을 어떻게 다시 짜는가

Seraphis는 단일 원시 요소(primitive)가 아니라 트랜잭션 프로토콜 전체입니다. 무엇이 바뀌는지 이해하려면, 오늘 XMR을 보낼 때 일어나는 일을 단계별로 따라가며 Seraphis 환경에서의 대응 단계와 비교해 보는 것이 가장 좋습니다. 사용자 경험 측면에서는 차이가 미묘하지만, 내부 구조는 근본적으로 다릅니다.

CLSAG에서 컴포지션 + 멤버십 증명으로

CLSAG에서는 지갑이 체인에서 15개의 디코이를 골라 총 16개로 이루어진 링을 구성하고, "이 16개 중 하나가 내 것이며 이중 지출을 하지 않았다"고 주장하는 증명에 서명합니다. Seraphis에서는 지갑이 서로 다른 두 개의 증명을 따로 만듭니다. 컴포지션 증명은 "나는 이 집합에서 특정한 한 출력을 정당하게 소유하고 있으며, 이 키 이미지가 그것을 사용한 적이 없다는 증거"라고 말합니다. 멤버십 증명은 "내가 참조하는 그 출력이 체인 위의 이 더 큰 익명성 집합에 실제로 존재한다"고 말합니다. 두 증명은 암호학적으로 연결되어 있지만 독립적으로 생성되며, 바로 이 점 덕분에 트랜잭션 형식 전체를 재설계하지 않고도 나중에 익명성 집합을 확장할 수 있습니다.

키 이미지(key image) 자체도 재설계됩니다. 현재의 키 이미지는 일회용 출력 키와 지출 키로부터 결정론적으로 파생됩니다. 똑똑한 구조이지만 수년간 엣지 케이스 연구의 표적이 되어 왔습니다. Seraphis는 FCMP++와 순방향 호환되는 새로운 키 이미지 형식을 도입하는데, 이는 Monero 연구진이 궁극적으로 익명성 집합이 체인 전체 UTXO를 포괄하도록 만들고자 하는 멤버십 증명 시스템입니다.

Carrot: 출력 인코딩 계층

Carrot은 Seraphis와 함께 설계된 출력 인코딩 스킴입니다. 현재의 출력은 수신자의 공개 뷰 키와 트랜잭션 고유의 공유 비밀에서 파생된 스텔스 주소(stealth address)를 사용하지만, Carrot 출력은 뷰-잔액 키, 내부/외부 마커, 순방향 비밀성 힌트 같은 새로운 필드를 추가합니다. 실용적인 결과로, 지갑 스캔이 더 빨라집니다(내부 출력 — 자기 자신에게 보내는 잔돈 — 을 전체 복호화 없이도 식별할 수 있기 때문). 그리고 뷰 키 감사도 더 안전해집니다(감사인은 사용자가 권한을 부여한 정보만 볼 수 있기 때문).

Carrot은 또한 "Janus 보호"를 기본 내장합니다. Janus 공격이란 악의적인 송신자가 두 수신 주소 중 어느 쪽이 자금을 받았는지 나중에 증명할 수 있는 출력을 구성하는 공격입니다. 현재 Monero 프로토콜은 서브주소 체크로 이를 완화하지만, Carrot은 예방 메커니즘을 출력 형식 자체에 새겨 넣음으로써, 지갑 정책 수준이 아니라 암호학 수준에서 한 부류의 버그를 통째로 제거합니다.

트랜잭션 크기와 수수료

비판하는 분들은 Seraphis가 트랜잭션을 더 크게 만들고 수수료를 더 높이는 것 아니냐고 자주 묻습니다. 솔직히 말씀드리면, 단기적으로는 약간 그렇습니다. 그리고 장기적으로는 그렇지 않을 가능성이 높습니다. 초기 Seraphis 증명은 활성화 시 선택되는 구성에 따라 CLSAG보다 1.5배에서 2배 정도 더 큽니다. 그러나 Monero의 동적 블록 크기 덕분에 수수료는 원시 바이트 수가 아니라 혼잡도에 따라 조정됩니다. 그리고 Bulletproofs+는 이미 2022년에 범위 증명을 공격적으로 줄여 놓았습니다. FCMP++가 도입되고 익명성 집합이 체인 전체 규모로 확장되면, 프라이버시 단위당 바이트 비용은 오늘에 비해 급격히 떨어집니다.

Jamtis: 사용자가 실제로 마주할 주소 계층

Seraphis가 엔진이라면 Jamtis는 대시보드입니다. 대부분의 사용자는 컴포지션 증명을 한 줄도 읽을 일이 없겠지만, 모든 사용자는 Monero 주소를 복사하고 붙여 넣습니다. Jamtis는 그 주소를, 그리고 그 뒤에 있는 키 체계를 다시 설계하여 Seraphis가 가져오는 프라이버시 향상이 지갑, 거래소, 가맹점이 네트워크와 상호 작용하는 방식에까지 그대로 반영되도록 만듭니다.

현재 Monero 주소는 base58로 95자이며, 메인넷 기본 주소는 "4"로, 서브주소는 "8"로 시작합니다. 이 주소는 본질적으로 공개 지출 키와 공개 뷰 키만 인코딩합니다. Jamtis 주소는 길이는 비슷하거나 약간 더 깁니다(최종 형식은 아직 프로토콜 수준에서 확정 중). 하지만 그 안에 훨씬 더 풍부한 구조를 담습니다. 주소 인덱스, 주소 유형 플래그(메인, 거래소, 통합, "보조"), 그리고 특정 피싱·치환 공격을 막는 인증 태그가 포함됩니다.

뷰 키 계층화는 특히 주목할 만한 변화인데, 실제 현장의 고민거리를 해결하기 때문입니다. 오늘은 회계사에게 뷰 키를 건네는 순간, 그 사람은 자신이 받은 모든 출력을 보게 됩니다. 자기 지출에서 돌아온 잔돈, 자기 서브주소 사이의 이동, 그리고 모든 보조 수입까지 전부입니다. Jamtis는 감사인에게 필요한 단계만 골라서 권한을 줄 수 있게 합니다. "find-received" 키는 금액 없이 수신 결제만 드러냅니다. "view-incoming" 키는 금액과 함께 수신 결제를 보여주지만 잔돈은 가립니다. "view-balance" 키는 개별 트랜잭션을 노출하지 않고 컴플라이언스 보고용 가용 잔액만 보여줍니다. 사용자가 본인만 보유하는 "view-all" 키만이 전부를 봅니다.

MoneroSwapper처럼 고객의 입금만 확인하면 될 뿐 더 넓은 지갑 내역을 알 필요가 없는 서비스에게, 새 계층 구조는 통합 구현을 더 깔끔하게 만들어 주고 기본값에서부터 더 강한 프라이버시를 보장합니다. 스왑 서비스는 "약속한 주소로 약속한 금액을 보냈다"는 사실만 확인할 수 있고, 고객의 전체 잔액, 잔돈 패턴, 다른 수신 내역에 대한 가시성은 결코 갖지 못합니다. 이것이 중요한 이유는 단순합니다. 프라이버시 보호 서비스가 수집하지 않은 메타데이터의 모든 한 바이트는, 그 서비스가 소환장에 응할 수도, 침해로 유출될 수도, 사회공학 공격으로 탈취당할 수도 없는 한 바이트이기 때문입니다.

프라이버시 업그레이드를 한 문장으로 설명할 수 있다면, 그것은 거의 확실히 지나치게 단순화된 설명입니다. Seraphis와 Jamtis는 함께 하나의 시스템입니다. 증명, 인코딩, 주소, 키 계층, 지갑 UX가 모두 함께 움직입니다. 기능 목록이 아니라 하나의 패키지로 이해해야 합니다.

마이그레이션 경로: 지갑을 어떻게 준비할 것인가

Seraphis 하드포크는 이 글을 쓰는 시점에 아직 일정이 잡혀 있지 않습니다. Monero Research Lab과 코어 팀은 활성화 일정에 대해 의도적으로 보수적이며, 달력에 맞춰 출시하기보다 "준비되면 출시한다" 원칙을 선호합니다. 과거 Monero 하드포크는 사용자에게 2개월에서 6개월의 사전 공지를 주었고, Seraphis는 복잡도를 감안할 때 거의 확실히 이 범위의 긴 쪽에 해당할 것입니다. 정확한 활성화 주(週)와 무관하게 통하는 실용적 준비 체크리스트를 정리해 봅니다.

1. 시드 형식을 점검하십시오. 지갑이 아직 레거시 25단어 시드를 사용한다면, 업그레이드 전에 16단어 Polyseed 기반 지갑으로 전환을 고려해 보십시오. Polyseed는 Jamtis 파생 경로와 순방향 호환되므로, 포크 시점에 레거시 시드는 지갑 측 변환 단계가 필요해질 것입니다.
2. 포크 전에 지갑 소프트웨어를 최소 두 번 업데이트하십시오. Monero GUI, CLI, Feather Wallet, Cake Wallet 팀은 일반적으로 포크 전에 여러 개의 사전 릴리스를 배포합니다. 활성화 한 달 전부터 공식 Monero 릴리스 노트와 사용 중인 지갑의 변경 로그를 추적하십시오. 자동 업데이트만 믿지는 마십시오. 일부 지갑은 주요 업그레이드를 수동 확인 뒤로 미루기 때문입니다.
3. 예비 기기에서 시드 복구를 끝까지 한 번 연습하십시오. 주요 프로토콜 업그레이드 전에 가장 가치 있는 위험 통제는 종이에 적어 둔 시드로 실제 자금이 복구되는지 확인하는 일입니다. 별도 컴퓨터에 깨끗한 Monero CLI나 Feather Wallet을 띄우고, 시드로 복구하고, 잔액이 일치하는지 확인하십시오. 두 번 하십시오. 업그레이드가 없는 시기에도 6개월마다 한 번씩 하십시오.
4. 서브주소 난립을 정리하십시오. 거래 상대방마다, 가맹점마다 서브주소를 따로 발급해 수십 개를 굴려 온 사용자라면 마이그레이션이 조금 더 복잡해집니다. 포크 전에 더 적은 서브주소 집합으로 자금을 통합하고, 각 주소에 명확한 라벨을 붙여 두면 포크 후의 멘탈 모델이 훨씬 단순해집니다.
5. 뷰 키 공유 관계를 문서화하십시오. 회계사, 거래소, 감사 도구에 뷰 키를 공유해 두었다면, 누가 무엇 때문에 보유하고 있는지 적어 두십시오. Jamtis가 활성화된 뒤에는 레거시 풀 뷰 키 대신 새 계층 키로 그 관계들을 갱신하고 싶어질 것입니다.
6. "포크 후 스윕(sweep)" 안내를 주시하십시오. 과거 Monero 업그레이드 중에는 이전 형식의 출력을 새 형식으로 "스윕"한 뒤에야 사용할 수 있게 되는 경우가 가끔 있었습니다. Seraphis에 이것이 필요하다면 Monero 코어 팀이 명시적 지침을 발표할 것입니다. 포럼이나 소셜 미디어의 소문에 따라 움직이지 마십시오.

KYC 없는 스왑 서비스 사용자에게 운영상 영향은 보통 미미합니다. 잘 설계된 서비스는 프로토콜 전환을 추상화합니다. 사용자는 주소를 주고 XMR을 받습니다. 백엔드에서 Seraphis와 이전 포맷의 출력을 모두 처리합니다. 예컨대 MoneroSwapper는 도착지 주소의 프로토콜 버전을 고객이 신경 쓸 사안이 아니라 라우팅 결정으로 처리합니다. 고객은 늘 쓰던 워크플로우를 그대로 유지하면 됩니다.

실전 예시: 새 모델에서 스왑 수신하기

2026년 중반의 전형적인 시나리오를 생각해 봅시다. 그때까지 Seraphis가 활성화되어 있다고 가정합니다. 서울의 한 사용자가 KYC 없이 비트코인을 모네로로 바꾸고 싶어 합니다. MoneroSwapper와 같은 스왑 서비스에 접속해, 업데이트된 지갑(Feather, 공식 Monero GUI 등)에서 생성한 Jamtis 수신 주소를 붙여 넣고, 안내된 입금 주소로 비트코인을 보냅니다.

뒤에서 스왑 서비스는 비트코인을 자체 유동성 풀로 라우팅하고, 모네로를 확보한 뒤, 약속한 금액을 사용자의 Jamtis 주소로 보내는 Seraphis 트랜잭션을 만듭니다. 이 트랜잭션에는 컴포지션 증명, 128개(또는 그 이상) 출력으로 이루어진 익명성 집합에서 뽑은 멤버십 증명, 그리고 사용자의 지갑이 단 한 번의 스캔으로 식별할 수 있는 Carrot 인코딩 출력이 포함됩니다. 사용자는 평소와 같은 10~20분의 컨펌 시간 안에 지갑에서 자금을 확인합니다.

사용자 입장에서 바뀐 것은? 눈에 보이는 변화는 없습니다. 뒤에서 바뀐 것은? 익명성 집합은 자릿수 단위로 커졌고, 출력 인코딩은 프로토콜 수준에서 Janus 공격에 저항하며, 스왑 서비스는 사용자의 더 넓은 모네로 활동을 들여다볼 수 있는 키를 단 한 번도 받지 않았습니다. 시스템은 더 많은 프라이버시 작업을, 그것도 사용자에게 보이지 않는 방식으로 수행했습니다. 이것이 잘 실행된 프로토콜 업그레이드의 목표입니다. 사용자에게는 보이지 않고, 감사인에게는 명백히 더 강한 것입니다.

모네로 생태계 밖에서 새로 들어오는 사용자들 — 프라이버시가 궁금한 비트코이너, 프라이버시 코인을 처음 시도하는 분들 — 에게는 Seraphis 시대가 사실상 첫 경험이 될 가능성이 높습니다. 그들은 16개짜리 링 서명 시절이 어땠는지 영영 모를 것입니다. 오늘의 사용자가 트랜잭션 금액이 체인에서 공개되던 RingCT 이전 시절을 거의 떠올리지 않는 것과 마찬가지입니다. 프로토콜 업그레이드는 그렇게 느껴져야 합니다. 조용히 더 나아져서 새로운 기준선이 되는 것입니다.

자주 묻는 질문(FAQ)

Seraphis와 Jamtis는 메인넷에서 언제 활성화됩니까?

확정된 날짜는 발표되지 않았습니다. Monero Research Lab과 코어 팀은 활성화가 암호학 감사 완료, 라이브러리 강화, 주요 구현체의 지갑 통합, 그리고 최소 한 차례의 전체 테스트넷 사이클 완료에 달려 있다고 반복해서 밝혀 왔습니다. 2025년 말 기여자들의 공개 추정치는 2026년 말부터 2027년 중반까지였지만, 프로젝트의 문화는 보안에 결정적인 업그레이드를 달력 일정에 맞춰 출시하지 않는다는 원칙을 분명히 합니다. 권위 있는 일정 정보는 공식 Monero 릴리스 노트와 Monero Research Lab 미팅 로그에서 확인하시기 바랍니다.

업그레이드 후에도 현재 사용 중인 모네로 주소는 계속 동작합니까?

전환 기간 동안은 그렇습니다. Monero의 하드포크는 역사적으로 레거시 주소로 보낸 자금이 그대로 도착하도록 후방 호환 주소 처리를 포함해 왔습니다. 장기적으로는 지갑 소프트웨어가 사용자에게 Jamtis 주소로의 이전을 권장하게 될 것이고, 결국 새로운 지갑은 레거시 주소를 더 이상 발급하지 않을 수 있습니다. 현재 주소에 보관된 자금에 즉각적인 "마감일" 위험은 없지만, 포크 시점 전후로 지갑 소프트웨어를 업데이트해 두시는 것이 좋습니다.

Seraphis가 Monero의 테일 발행이나 공급 일정을 바꿉니까?

아닙니다. Seraphis는 트랜잭션 계층의 프로토콜 업그레이드입니다. 통화 정책에는 손대지 않습니다. 블록당 0.6 XMR의 테일 발행은 변함없이 유지됩니다. 전체 발행 곡선, 블록 보상 동역학, RandomX 작업 증명 알고리즘은 모두 Seraphis와 별개이며 업그레이드의 영향을 받지 않습니다.

Seraphis는 Trezor, Ledger 같은 하드웨어 지갑과의 호환성을 깨뜨립니까?

하드웨어 지갑 제조사는 새로운 증명 형식과 키 파생 경로를 지원하도록 펌웨어를 업데이트해야 합니다. 역사적으로 Trezor와 Ledger 모두 Monero 펌웨어 업데이트를 하드포크 일정에 맞춰 출시했지만, 때로는 몇 주에서 몇 달의 시차가 있었습니다. 하드웨어 지갑에 의존하시는 분들은 포크 당일에 무턱대고 펌웨어를 업그레이드하지 마시고, 새 펌웨어가 활성화된 Monero 프로토콜 버전을 지원한다는 제조사의 공식 확인이 나올 때까지 기다리십시오. 전환 기간에는 소프트웨어 지갑 백업 수단을 별도로 확보해 두시는 것이 안전합니다.

Seraphis는 다른 프라이버시 프로젝트의 접근법과 어떻게 다릅니까?

Zcash는 완전 차폐 트랜잭션에 zk-SNARK를 사용합니다. 이론적 프라이버시는 더 강하지만 역사적으로 신뢰된 셋업(trusted setup) 의식이 필요했고, 채택률도 훨씬 낮습니다(대부분의 Zcash 거래량은 투명 풀에서 발생합니다). Grin 같은 Mimblewimble 체인은 출력 집계(aggregation)에 기반한 근본적으로 다른 모델을 사용하며, 컴팩트함을 얻는 대신 감사 가능성의 일부를 포기합니다. Seraphis는 Monero 기존 모델 — 링 서명과 스텔스 주소 — 안에 머무르되, 그 설계를 실용적으로 도달 가능한 최대치까지 밀어붙입니다. 그 대가는 엔지니어링 복잡성이지만, 신뢰된 셋업이 필요 없고 오늘의 Monero와 매끄럽게 연결되는 사용자 경험을 얻습니다.

포크 활성화 전에 MoneroSwapper에서 Jamtis 주소로 스왑할 수 있습니까?

아닙니다. 현재의 운영용 지갑은 아직 Jamtis 주소를 생성하지 않기 때문입니다. 프로토콜이 활성화되고 Monero GUI, Feather, Cake Wallet 같은 주요 지갑이 Jamtis 지원을 배포한 뒤에는, 스왑 서비스가 전환 기간 동안 새 주소 형식과 레거시 주소를 함께 받아들이게 됩니다. 그 전까지는 현재 모네로 주소가 모든 스왑 활동에 평소처럼 정상적으로 동작합니다.

결론

Seraphis와 Jamtis는 Monero가 분석 곡선에 끌려가는 것이 아니라 그 앞에 머무르겠다는 약속을 보여줍니다. 이 업그레이드는 화려하지 않고, 가격 급등 내러티브를 만들어 내지도 않으며, 사용자가 매일 하는 일을 극적으로 바꾸지도 않습니다. 그것이 해내는 일은 따로 있습니다. 네트워크의 프라이버시 하한선을 의미 있게 끌어올리고, 사용자가 무엇을 누구에게 공개할지 더 세밀하게 제어할 수 있게 하며, 향후 10년 Monero 개발의 암호학적 토대를 놓는 일입니다. XMR을 보유하시거나 일상적인 프라이버시 결제에 사용하신다면, 앞으로 6~12개월에 걸쳐 시드 형식을 정비하고, 지갑 소프트웨어 업데이트 습관을 다듬고, 복구 절차를 검증해 두십시오. 포크가 도착했을 때, 사용자 입장에서는 아무 일도 일어나지 않은 것처럼 느껴지는 편이 가장 좋습니다. 가장 잘 준비된 업그레이드란, 사용자가 평소처럼 송금 버튼을 누르고 지갑에서 잔액을 확인하는 동안 뒤에서 조용히 완료되는 업그레이드입니다. 지금부터 KYC 없고 계정도 필요 없는 스왑 서비스로 Monero를 사용하기 시작하고 싶으시다면, Seraphis 전환을 사용자에게 보이지 않게 처리해 줄 MoneroSwapper에서 보유 중인 암호자산을 몇 분 만에 XMR로 교환해 보십시오.