> ## 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.

# 공유 인프라

> 모든 Raydium 프로그램이 공유하는 기본 요소 — 권한 PDA, AmmConfig 계정, 프로토콜/펀드/크리에이터 수수료 분할, 관찰 계정, 퍼블릭 REST API 표면 — 이를 한 번 정의하여 각 제품별 장에서 참조할 수 있도록 구성됩니다.

<Info>
  **이 페이지는 AI 자동 번역입니다. 모든 내용은 영문판을 기준으로 합니다.**

  [영문판 보기 →](/protocol-overview/shared-infrastructure)
</Info>

<Info>
  Raydium의 제품 프로그램들은 독립적인 코드베이스이지만, 공유된 규약 집합을 기준으로 설계되었습니다. 이 페이지는 그러한 규약들의 정식 레퍼런스입니다. 각 제품별 장에서는 규약이 계정에서 어떻게 *구현*되는지 설명하고, 이 페이지에서는 규약 자체를 설명합니다.
</Info>

## "공유"의 의미

코드베이스 전체에 걸쳐 세 가지 공유 방식이 있습니다.

* **규약 공유.** 모든 프로그램이 동일한 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`](/ko/products/cpmm/accounts), [`products/clmm/accounts`](/ko/products/clmm/accounts), [`products/amm-v4/accounts`](/ko/products/amm-v4/accounts), [`products/farm-staking/accounts`](/ko/products/farm-staking/accounts), [`products/launchlab/accounts`](/ko/products/launchlab/accounts)를 참조하세요.

## 2. 관리자 및 설정 계정

CPMM과 CLMM은 \*\*`AmmConfig`\*\*라는 설정 계정 패턴을 공유합니다. 이는 `u16`으로 인덱싱된 작은 글로벌 계정으로, 전체 *수수료 티어*에 적용되는 수수료율과 관리자 목적지를 보유합니다. 풀은 생성 시 설정에 바인딩되며 절대 다시 바인딩되지 않습니다.

```rust theme={null}
// 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`](/ko/security/admin-and-multisig)에 있습니다. 현재 사용자 대면 수수료 분할은 [`ray/protocol-fees`](/ko/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`](/ko/reference/fee-comparison)과 [`ray/protocol-fees`](/ko/ray/protocol-fees)에 있습니다.

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

CPMM과 CLMM 모두 풀별로 **관찰 계정**을 유지합니다. 이는 다른 계약이 조작-저항성 TWAP을 파생시키는 데 사용할 수 있는 고정 크기의 링 버퍼로, `(timestamp, cumulative_price)` 샘플들을 포함합니다.

```rust theme={null}
// 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`](/ko/products/cpmm/accounts)와 [`products/clmm/accounts`](/ko/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`](https://github.com/raydium-io/raydium-idl) 저장소에 있습니다 (프로그램당 하나의 JSON: CPMM, CLMM, LaunchLab). TypeScript SDK는 이러한 IDL을 내부적으로 사용합니다. 다운스트림 Rust / Python 클라이언트는 동일한 파일에서 재생성됩니다.

경계는 명확합니다.

| 조각       | 읽기             | 쓰기                | 오래됨 허용                  |
| -------- | -------------- | ----------------- | ----------------------- |
| REST API | 인덱서 (체인 로그 파싱) | — (통합자용 읽기 전용)    | 몇 초                     |
| SDK      | API + RPC      | 거래 빌드; 브로드캐스트 안 함 | 없음 — 서명 전 상태 다시 가져오기 필수 |
| IDL      | 프로그램 소스        | —                 | 프로그램 업그레이드별 버전 관리       |

일반적인 실수는 REST API 출력을 거래에 직접 공급하는 것입니다. 하지 마세요. 서명 중인 슬롯에서 Solana RPC에서 관련 풀/포지션 상태를 다시 가져오세요. SDK는 1차 플로우에 대해 이를 자동으로 수행합니다. SDK를 우회하는 경우 직접 수행해야 합니다.

전체 레퍼런스는 [`sdk-api/`](/ko/sdk-api)에 있으며, IDL 표면은 특별히 [`sdk-api/anchor-idl`](/ko/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은 클리어 전에 오라클을 확인하지 않습니다.

## 포인터

* [`protocol-overview/architecture`](/ko/protocol-overview/architecture) — 이 조각들이 어떻게 구성되는지 보여주는 정식 다이어그램.
* [`protocol-overview/versions-and-migration`](/ko/protocol-overview/versions-and-migration) — 규약이 프로그램 버전 전체에서 어떻게 진화했는지.
* [`security/admin-and-multisig`](/ko/security/admin-and-multisig) — AmmConfig 뒤의 키를 누가 제어하는지.
* [`reference/fee-comparison`](/ko/reference/fee-comparison) — 제품별 수수료율 매트릭스.
* [`reference/program-addresses`](/ko/reference/program-addresses) — 정식 프로그램 ID.

출처:

* [Raydium SDK v2](https://github.com/raydium-io/raydium-sdk-V2) — PDA 시드, 계정 레이아웃, IDL 정의의 사실의 원천.
* [Raydium IDL 레지스트리](https://github.com/raydium-io/raydium-idl) — Anchor IDL.
* 위에서 인라인으로 인용한 제품별 계정 페이지.