메인 콘텐츠로 건너뛰기

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

이 페이지는 AI 자동 번역입니다. 모든 내용은 영문판을 기준으로 합니다.영문판 보기 →
Raydium의 제품 프로그램들은 독립적인 코드베이스이지만, 공유된 규약 집합을 기준으로 설계되었습니다. 이 페이지는 그러한 규약들의 정식 레퍼런스입니다. 각 제품별 장에서는 규약이 계정에서 어떻게 구현되는지 설명하고, 이 페이지에서는 규약 자체를 설명합니다.

​
”공유”의 의미

코드베이스 전체에 걸쳐 세 가지 공유 방식이 있습니다.
  • 규약 공유. 모든 프로그램이 동일한 PDA 파생 패턴, 동일한 수수료 분할 구조, 동일한 관찰 계정 아이디어를 사용합니다. 하지만 각각 자신의 프로그램에서 자신의 시드로 구현합니다.
  • 계정 공유. 소수의 계정이 많은 풀에서 정확히 동일한 레코드입니다 (CPMM의 글로벌 권한 PDA, AmmConfig 계정).
  • 오프체인 공유. 하나의 REST API와 하나의 TypeScript SDK가 네 개의 모든 프로그램을 담당합니다. 통합자는 최종적으로 호출하는 프로그램이 무엇이든 하나의 HTTP 호스트와 하나의 NPM 패키지와 상호작용합니다.
아래의 다섯 가지 기본 요소는 프로그램 경계를 넘는 모든 것을 다룹니다.

​
1. 권한 PDA

모든 Raydium 프로그램은 정확히 하나의 토큰 금고를 소유하는 PDA를 가집니다. 사용자는 금고 권한을 직접 보유하지 않습니다. 권한 PDA는 자금을 이동할 수 있는 유일한 서명자이며, 유효한 프로그램 명령어가 이를 지시할 때만 서명합니다. 패턴은 제품 전체에서 동일하며, 시드만 다릅니다.
프로그램권한 PDA 시드참고
AMM v4[poolId]풀별 권한. v4의 풀별 설계와 동일한 구조.
CPMM[b"vault_and_lp_mint_auth_seed"]모든 CPMM 풀에서 공유되는 단일 PDA. 풀 특정 시드 없음.
CLMM[b"pool_vault_and_lp_mint_auth_seed"]모든 CLMM 풀에서 공유되는 단일 PDA.
Farm v3 / v5 / v6[farmId]팜별. PDA는 해당 팜의 스테이킹 + 보상 금고를 소유합니다.
LaunchLab[b"vault_auth", launchId]론칭별. 졸업 전 베이스 + 쿼트 금고를 소유합니다.
이로부터 몇 가지가 따릅니다.
  • CPMM과 CLMM의 경우, 권한 PDA는 글로벌 계정입니다. 해당 타입의 모든 풀이 이를 사용합니다. CPMM으로 CPI하는 경우 풀별로가 아니라 한 번만 필요합니다.
  • 풀별/팜별 권한의 경우, 풀/팜 ID에서 PDA를 파생시킵니다. SDK는 getPoolKeys / getFarmKeys에서 이를 수행합니다. 직접 통합하는 경우, findProgramAddressSync로 파생시킵니다.
  • 금고 소유권은 변경될 수 없습니다. 권한 PDA를 소유자로 하여 토큰 계정이 생성되면, 오직 그 PDA만 — 프로그램에 의해 호출될 때만 이체할 수 있습니다. 관리자 재정의는 없습니다.
프로그램별 정확한 시드와 ATA 레이아웃은 products/cpmm/accounts, products/clmm/accounts, products/amm-v4/accounts, products/farm-staking/accounts, products/launchlab/accounts를 참조하세요.

​
2. 관리자 및 설정 계정

CPMM과 CLMM은 **AmmConfig**라는 설정 계정 패턴을 공유합니다. 이는 u16으로 인덱싱된 작은 글로벌 계정으로, 전체 수수료 티어에 적용되는 수수료율과 관리자 목적지를 보유합니다. 풀은 생성 시 설정에 바인딩되며 절대 다시 바인딩되지 않습니다. 
// CPMM AmmConfig (축약 — CLMM 버전은 구조적으로 유사함)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // gate new pool creation in this tier
    pub index: u16,                       // tier index
    pub trade_fee_rate: u64,              // fraction of trade going to fees
    pub protocol_fee_rate: u64,           // fraction of trade fee to protocol
    pub fund_fee_rate: u64,               // fraction of trade fee to fund
    pub create_pool_fee: u64,             // one-time per-pool creation fee
    pub protocol_owner: Pubkey,           // signer for CollectProtocolFee
    pub fund_owner: Pubkey,               // signer for CollectFundFee
    pub padding: [u64; 16],
}
규칙:
  • 수수료 티어는 글로벌입니다. 풀이 “이것은 0.25% 풀입니다”라고 말할 때, 생성 시 trade_fee_rate이 0.25%였던 AmmConfig에 바인딩된다는 의미입니다. 풀별 비율 재정의는 없습니다.
  • 설정은 변경될 수 있지만 풀은 따르지 않습니다. AmmConfig 권한이 AmmConfig를 편집하면, 그 설정에 바인딩된 모든 기존 풀이 즉시 새로운 비율을 적용합니다. 이는 버그가 아니라 기능입니다. 풀별 마이그레이션 없이 프로토콜 수준의 경제 변화가 전파되는 방식입니다.
  • disable_create_pool은 폐지 레버입니다. 수수료 티어가 일몰되면, 프로토콜 멀티시그가 이 플래그를 설정합니다. 기존 풀은 계속 작동하지만 새 풀은 이 티어를 선택할 수 없습니다.
  • **protocol_owner / fund_owner**는 수수료 수거 호출의 서명자입니다. 이들을 멀티시그로 설정하는 것이 수수료 인출을 제한하는 방식입니다. 이들은 수수료의 목적지 주소가 아닙니다. 그것은 동일한 계정의 protocol_fee_destination / fund_fee_destination입니다.
AMM v4에는 AmmConfig가 없습니다. 수수료 매개변수는 풀별이며 생성 시 하드코딩됩니다. Farm과 LaunchLab은 각각의 장에서 다루는 자신의 동등물 (FarmConfig, LaunchConfig)을 가집니다. 누가 무엇을 변경할 수 있는지에 대한 완전한 표는 security/admin-and-multisig에 있습니다. 현재 사용자 대면 수수료 분할은 ray/protocol-fees에 있습니다.

​
3. 프로토콜 / 펀드 / 크리에이터 수수료 분할

모든 CPMM 및 CLMM 스왑 수수료는 나가는 길에 최대 네 개의 목적지로 분할됩니다. 
                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)
메커니즘:
  1. 거래 수수료가 풀로 발생합니다. 수수료는 스왑의 입력 측에서 제거되고 수수료 후 금액이 상수곱 수학으로 표시됩니다. 이것이 “LP가 수수료를 얻는다”는 의미입니다. k가 상승하고 따라서 LP당 토큰의 내재 가치도 상승합니다.
  2. 프로토콜/펀드/크리에이터 부분은 그 LP측 발생분에서 풀별 카운터 계정으로 차감됩니다. 이들은 풀 상태 (protocol_fees_token{0,1}, fund_fees_token{0,1} 등)에 앉아 있다가 누군가 CollectProtocolFee / CollectFundFee / CollectCreatorFee를 호출할 때까지 그대로 있습니다. 그 때까지 풀의 금고에서 나가지 않습니다. 스왑의 관점에서 여전히 “풀에 있습니다”.
  3. 수거가 이들을 이동시킵니다. 각 서명자 (AmmConfig의 protocol_owner / fund_owner 키, 또는 LaunchLab 풀의 론칭 크리에이터)가 수거 명령어를 호출하고 프로그램이 풀 금고에서 목적지 ATA로 이체합니다.
몇 가지 중요한 관찰:
  • 분할 비율은 거래 수수료에서이며, 거래에서가 아닙니다. 0.25% 거래 수수료에 12% 프로토콜 공유는 프로토콜이 거래의 0.25% × 12% = 0.03%를 얻는다는 의미입니다. 거래의 12%가 아닙니다.
  • 크리에이터 수수료는 LaunchLab-졸업 풀에만 존재합니다. 표준 CPMM/CLMM 풀은 3방향 분할 (LP / 프로토콜 / 펀드)입니다. LaunchLab은 토큰을 론칭한 사람에게 라우팅되는 네 번째 슬롯을 추가하며, Initialize에서 구성되고 불변입니다.
  • AMM v4는 2방향으로만 분할합니다. 풀별로 하드코딩됩니다. LP와 프로토콜. 펀드 슬롯 없음, 크리에이터 슬롯 없음.
  • 펀드 vs 프로토콜 — 둘 다 프로토콜-재무 목적지이지만, 다른 서명자와 다른 의도된 용도를 가집니다. protocol은 역사적으로 운영 비용을 충당합니다. fund는 장기 재무입니다. 둘 사이의 분할 자체가 조정 가능합니다.
구체적인 비율은 reference/fee-comparison과 ray/protocol-fees에 있습니다.

​
4. 관찰 계정 (TWAP 링 버퍼)

CPMM과 CLMM 모두 풀별로 관찰 계정을 유지합니다. 이는 다른 계약이 조작-저항성 TWAP을 파생시키는 데 사용할 수 있는 고정 크기의 링 버퍼로, (timestamp, cumulative_price) 샘플들을 포함합니다. 
// CPMM ObservationState (축약)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // next slot to overwrite
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // sum of (price × dt) since init
    pub cumulative_token_1_price_x32: u128,
}
작동 방식:
  • 모든 스왑이 update_observation을 호출합니다. 프로그램은 현재 가격을 읽고, 이전 관찰 이후 경과한 초 수를 곱하고, 누적 카운터에 더합니다. 새로운 항목이 가장 오래된 슬롯을 덮어씁니다 (링 버퍼 스타일).
  • 윈도우 이상의 TWAP = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). 소비자는 원하는 윈도우를 괄호로 두는 두 관찰을 선택하고 나눕니다.
  • Raydium 자체는 가격 결정을 위해 TWAP을 사용하지 않습니다. AMM 수학은 현물 준비금을 직접 읽습니다. 관찰은 외부성입니다. Raydium은 다른 계약이 읽을 수 있도록 이들을 쓰는 비용을 지불합니다.
  • AMM v4에는 관찰 계정이 없습니다. ObservationState 설계보다 오래됩니다. v4 TWAP을 원하는 통합자는 로그 히스토리에서 오프체인으로 하나를 계산해야 합니다.
레이아웃 세부 사항과 인덱싱 수학은 products/cpmm/accounts와 products/clmm/accounts에 있습니다.

​
5. REST API + SDK + IDL

오프체인 표면은 모든 제품에서 사용되는 단일 삼중항입니다.
  • REST API — https://api-v3.raydium.io. 모든 온체인 상태의 읽기 중심 인덱싱된 뷰 플러스 견적 엔진. 하나의 호스트, 하나의 스키마.
  • TypeScript SDK — NPM의 @raydium-io/raydium-sdk-v2. 모든 프로그램에 대한 거래를 빌드하고 서명합니다. 견적/메타데이터를 위해 API와 대화하고, 서명 전 상태 새로 고침을 위해 Solana RPC와 대화합니다.
  • IDL 레지스트리 — 모든 공표된 프로그램의 Anchor IDL은 raydium-idl 저장소에 있습니다 (프로그램당 하나의 JSON: CPMM, CLMM, LaunchLab). TypeScript SDK는 이러한 IDL을 내부적으로 사용합니다. 다운스트림 Rust / Python 클라이언트는 동일한 파일에서 재생성됩니다.
경계는 명확합니다.
조각읽기쓰기오래됨 허용
REST API인덱서 (체인 로그 파싱)— (통합자용 읽기 전용)몇 초
SDKAPI + RPC거래 빌드; 브로드캐스트 안 함없음 — 서명 전 상태 다시 가져오기 필수
IDL프로그램 소스—프로그램 업그레이드별 버전 관리
일반적인 실수는 REST API 출력을 거래에 직접 공급하는 것입니다. 하지 마세요. 서명 중인 슬롯에서 Solana RPC에서 관련 풀/포지션 상태를 다시 가져오세요. SDK는 1차 플로우에 대해 이를 자동으로 수행합니다. SDK를 우회하는 경우 직접 수행해야 합니다. 전체 레퍼런스는 sdk-api/에 있으며, IDL 표면은 특별히 sdk-api/anchor-idl에 있습니다.

​
6. 인덱서 및 가격 피드

REST API는 Raydium 자신의 인덱서에 의해 공급되며, 이는 Solana RPC 플릿에서 프로그램 로그를 구독하고 SQL 저장소에 비정규화된 레코드를 씁니다. 통합자를 위한 두 가지 결과:
  • 인덱서는 교차 프로그램 상태를 “알고 있는” 유일한 것입니다. CPMM 풀을 CLMM 대응물로 매핑하기, 프로그램 버전 전체에 걸쳐 24시간 거래량 계산하기, LP 민트와 연관된 팜 선택하기 — 이 모든 것이 인덱서 작업입니다. 프로그램 자체는 하지 않습니다.
  • 인덱서 가동 중단은 API 가동 중단입니다. API가 오래된 또는 빈 데이터를 반환하면 인덱서가 용의자입니다. 온체인 상태는 영향을 받지 않습니다. 자신의 RPC 및 SDK를 가진 통합자는 거래를 계속할 수 있습니다.
가격 피드는 별도의 관심사입니다. API는 대부분의 풀 응답에 priceUsd 필드를 발행합니다. 이는 풀 준비금의 인덱서 뷰 스냅샷과 인용된 참조 가격 (일반 피벗인 USDC 풀)에서 오프체인으로 계산됩니다. UI에는 충분합니다. 온체인 오라클로는 안전하지 않습니다. 그런 용도에는 관찰 TWAP을 사용하세요.

​
공유되지 않는 것

새로운 독자들이 존재하는 것보다 더 많은 공유를 가정하는 경우가 많기 때문에 명시적으로 나열할 가치가 있습니다.
  • 프로그램은 서로를 호출하지 않습니다. CPMM 스왑은 CLMM이나 AMM v4로 CPI하지 않습니다. 여러 AMM을 조합하는 유일한 프로그램은 AMM 라우팅 프로그램입니다. 그리고 그것도 얇은데, 단지 각 AMM으로 CPI를 순서대로 내보낼 뿐입니다.
  • 프로그램 전체에 걸친 공유 업그레이드 권한이 없습니다. 각 온체인 프로그램은 자신의 프로그램 업그레이드 키를 가집니다 (3/4 멀티시그 플러스 24시간 타임락). 이들은 연결되어 있지 않습니다.
  • 팜과 AMM 사이에 공유 상태가 없습니다. 팜은 자신이 스테이킹하는 LP가 CPMM 풀에서 온 것인지, CLMM-포지션-NFT-민트인지, 관련 없는 SPL 토큰인지 알지 못합니다. 팜 프로그램은 스테이킹 민트를 불투명하게 취급합니다.
  • 오라클 의존성이 없습니다. 가격 결정은 온체인 준비금입니다. Pyth/Switchboard 폴백이 없습니다. AMM은 클리어 전에 오라클을 확인하지 않습니다.

​
포인터

출처: