스테이블코인 인프라

Solana에서 스테이블코인 시스템을 구축하세요.

연결 계층과 책임 범위, 그리고 팀이 직접 검토할 수 있는 구현 근거를 처음부터 분명히 정합니다.

명확한 RPC 경계와 검토 가능한 운영 근거를 바탕으로 Solana 스테이블코인 시스템을 설계하세요.

규제 맥락

서비스를 제공할 관할권에 맞춰 설계하세요.

스테이블코인의 발행·유통·보관·이전 의무는 제품과 관할권에 따라 달라지므로, 각 사업 구조에 맞춰 별도로 검토해야 합니다.

검토한 출처 자료:

시장 사례

JPYC

JPYC는 일본의 엔화 연동 스테이블코인 사업을 보여 주는 공개 사례입니다. 발행 주체와 현재 구조, 자사 용도와의 적합성은 독립적으로 확인하세요.

JPYC Inc.JPYC 공식 자료

JPYSC

JPYSC는 일본 시장의 또 다른 공개 사례입니다. 현행 사업 구조와 자사 모델에 맞는지는 별도로 검토하세요.

SBI GroupJPYSC 공식 자료

이 페이지는 기술적 맥락을 제공하며 법률, 세무 또는 규제 자문이 아닙니다.

RPC의 역할

서명 주체가 아닌 연결 경계입니다.

애플리케이션은 ERPC를 통해 Solana 데이터를 조회하고, 고객이 이미 서명한 트랜잭션을 전송하며, 네트워크 결과를 확인할 수 있습니다. 개인 키와 서명 권한은 고객이 관리하고 ERPC는 요청을 Solana RPC 인프라로 전달한 뒤 네트워크 응답을 반환합니다.

01Solana 상태 조회
애플리케이션이 필요한 계정, 블록 및 기타 네트워크 상태를 RPC로 조회합니다.
02서명 완료 트랜잭션 제출
고객 지갑이나 서명자가 먼저 서명한 트랜잭션을 RPC 경로로 전송합니다.
03트랜잭션 결과 조회
고객이 네트워크 결과를 조회하고 자체 확인 정책에 따라 다음 처리를 결정합니다.

ERPC는 RPC 요청과 응답을 운반하지만 고객의 개인 키를 받거나 대신 서명하지 않으며, 고객 업무의 대사 판단도 수행하지 않습니다.

트랜잭션 흐름

다섯 역할의 책임을 단계별로 나눕니다.

거래 의도 작성부터 최종 업무 기록까지 각 단계는 애플리케이션, 고객 서명자, ERPC 연결 계층, Solana 또는 고객 시스템에 속합니다.

  1. 01

    애플리케이션

    애플리케이션이 업무 로직에 따라 거래 의도를 정하고 필요한 명령을 구성합니다.

  2. 02

    고객 서명자

    고객 지갑이나 서명자가 구성된 트랜잭션을 검토하고 고객 통제 아래 서명을 생성합니다.

  3. 03

    ERPC 연결 계층

    ERPC가 서명된 요청을 받아 Solana RPC로 전달하고 수신한 네트워크 응답을 애플리케이션에 돌려줍니다.

  4. 04

    Solana 처리

    Solana는 당시의 네트워크 조건과 프로토콜 규칙에 따라 트랜잭션을 처리합니다.

  5. 05

    고객의 확인 및 대사

    고객 시스템이 확인을 모니터링하고 자체 업무 상태를 대사하는 방식을 결정합니다.

이 구분을 통해 기술 흐름을 보안, 통제, 회계 정책과 단계별로 대응할 수 있습니다.

책임 경계

각 당사자의 법적 역할은 구체적인 구성과 적용 관할권에 따라 달라집니다.

고객 서명자
애플리케이션 로직, 서명자 관리, 서명 생성은 고객이 맡습니다.
ERPC 연결 계층
ERPC의 범위는 RPC 요청을 전달하고 인프라 응답을 반환하는 데 한정됩니다.
Solana 처리
온체인 실행 결과는 Solana 네트워크가 프로토콜 규칙에 따라 만듭니다.
고객의 확인 및 대사
네트워크 결과를 주문, 장부, 내부 절차에 반영하는 일은 고객 시스템이 담당합니다.

운영 사용 사례

서로 다른 결제 흐름에 같은 연결 원칙을 적용합니다.

각 주체의 책임을 유지하면서 RPC 아키텍처를 사용자 결제, 기업 간 정산, 기계 간 API 결제, 내부 회계 시스템에 연결할 수 있습니다.

01

체크아웃

체크아웃에서는 애플리케이션이 결제를 준비하고 고객이 트랜잭션에 서명하며, 판매자 시스템이 네트워크 결과와 주문 상태를 별도로 추적합니다.

02

B2B 결제·지급·자금 관리

기업 간 정산, 지급, 자금 관리 흐름에는 서명 권한과 제출 규칙, 내부 통제 절차를 미리 설정합니다.

03

x402 API 결제

클라이언트와 서버는 x402 결제 요건과 스킴·네트워크별 PaymentPayload를 교환할 수 있습니다. 이 HTTP 결제 흐름은 일반 애플리케이션 흐름과 별개이며, Solana exact 스킴에서는 검증과 결제를 위해 직렬화된 부분 서명 결제 트랜잭션을 페이로드에 포함할 수 있습니다.

04

대사 및 시스템 연동

연동 계층은 고객 시스템의 규칙에 따라 네트워크 응답을 주문, 회계 기록, 운영 로그와 연결합니다.

x402와 API 결제

HTTP 결제 요건에서 확인 가능한 리소스 응답까지.

x402는 API 계층에서 결제 조건과 결제 증빙을 교환하는 흐름을 설명하며, 구체적인 정산 방식과 리소스 제공은 구현에 따라 달라집니다.

x402 PaymentPayload는 선택한 스킴과 네트워크에 따라 달라집니다. Solana exact 스킴에서는 검증과 결제를 위해 직렬화된 부분 서명 Solana 결제 트랜잭션을 포함할 수 있습니다.

  1. 01

    리소스 요청

    클라이언트나 에이전트가 유료 접근이 필요한 리소스에 HTTP 요청을 보냅니다.

  2. 02

    402 결제 요건

    서버가 402 응답으로 지원 방식, 금액 및 기타 결제 조건을 알립니다.

  3. 03

    서명된 API 결제 페이로드

    클라이언트가 전달받은 x402 조건에 맞춰 API 결제 데이터를 구성하고 서명합니다.

  4. 04

    검증 및 결제

    검증 주체가 결제 페이로드를 확인하고 해당 구현에서 정한 정산 절차를 수행하거나 관찰합니다.

  5. 05

    리소스 및 결제 응답

    결제가 수락되면 서버가 HTTP 리소스와 함께 해당 정산을 연결할 수 있는 정보를 반환합니다.

기업 책임 모델

고객 영역, 선택한 ERPC 범위, 네트워크를 구분합니다.

운영 전에 누가 키와 업무 로직을 관리하는지, ERPC에서 어떤 서비스를 선택하는지, Solana가 무엇을 처리하는지 명시하세요.

고객 또는 파트너

고객 시스템이 확인을 모니터링하고 자체 업무 상태를 대사하는 방식을 결정합니다.

  • 체크아웃
  • 대사 및 시스템 연동

ERPC 선택 범위

ERPC는 고객의 개인 키를 보관하지 않으며 고객 애플리케이션의 트랜잭션에 서명하지 않습니다.

  • Solana RPC 연결
  • 전용 VPS 운영
  • 물리 서버 인프라

Solana 네트워크

Solana는 현재 네트워크 조건과 프로토콜 규칙에 따라 온체인 트랜잭션을 받아 처리합니다.

  • Solana 처리

각 당사자의 법적 역할은 구체적인 구성과 적용 관할권에 따라 달라집니다.

구현 근거

각 계층에 해당하는 자료를 따로 확인하세요.

팀은 RPC 서비스, 기술 안내서, 전용 컴퓨팅 인프라 선택지를 각각 검토할 수 있습니다.

01

Solana RPC 연결

RPC 서비스 설명에서 애플리케이션이 Solana에 연결하는 경계와 사용할 수 있는 호출 방식을 확인합니다.

RPC 서비스 보기
02

기술 문서

문서는 연동 전에 확인해야 할 메서드, 요청 매개변수, 운영 전제를 설명합니다.

기술 문서 열기
03

전용 VPS 운영

전용 VPS는 고객 애플리케이션, 모니터링 도구, 연동 작업을 위한 독립 실행 환경을 제공합니다.

VPS 선택지 살펴보기
04

물리 서버 인프라

물리 서버는 자원, 배치 위치, 운영 절차를 직접 계획하려는 팀이 검토할 수 있는 인프라 선택지입니다.

물리 서버 살펴보기

프로덕션 전에 경계를 설계하세요

결제 흐름을 각 계층의 책임과 맞추세요.

아키텍처에 맞는 RPC 연결과 인프라 범위를 ERPC와 논의하세요.