Infraestructura compartida

​

Qué significa “compartido” aquí

• Compartición de convenciones. Cada programa usa el mismo patrón de derivación de PDA, la misma forma de división de comisiones y la misma idea de cuenta de observación — pero cada uno los implementa en su propio programa con sus propias semillas.
• Compartición de cuentas. Un puñado de cuentas son literalmente el mismo registro en muchos pools (el PDA de autoridad global en CPMM, las cuentas AmmConfig).
• Compartición fuera de cadena. Una API REST y un SDK de TypeScript frontal para los cuatro programas. Los integradores interactúan con un host HTTP y un paquete NPM sin importar qué programa terminen llamando.

​

1. PDAs de autoridad

• Para CPMM y CLMM, el PDA de autoridad es una cuenta global — cada pool de ese tipo la usa. Si estás haciendo CPI en CPMM la necesitas una vez, no por pool.
• Para autoridades por pool / por granja, derivas el PDA del ID del pool/granja. El SDK lo hace en getPoolKeys / getFarmKeys; si estás integrando directamente, derivas con findProgramAddressSync.
• La propiedad de la bóveda no puede cambiar. Una vez que se crea una cuenta de token con el PDA de autoridad como propietario, solo ese PDA — invocado por el programa — puede transferir. No hay anulación de administrador.

​

2. Cuentas de administrador y configuración

// CPMM AmmConfig (abreviado — la versión de CLMM es estructuralmente similar)
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],
}

• Los niveles de comisión son globales. Cuando un pool dice “este es un pool del 0,25%”, significa que se vincula al AmmConfig cuya trade_fee_rate era del 0,25% en el momento de la creación. No hay anulación de tasa por pool.
• Una configuración puede cambiar pero los pools no la siguen. Si la autoridad de configuración edita un AmmConfig, cada pool existente vinculado a esa configuración recoge la nueva tasa inmediatamente. Esta es una característica, no un error; es cómo los cambios económicos a nivel de protocolo se propagan sin migraciones por pool.
• disable_create_pool es la palanca de deprecación. Cuando se pone fin a un nivel de comisión, el multisig del protocolo establece esta bandera — los pools existentes siguen funcionando pero no se pueden elegir nuevos pools en el nivel.
• protocol_owner / fund_owner son los firmantes para las llamadas de recopilación de comisiones. Establecerlos en un multisig es lo que controla el retiro de comisiones. NO son las direcciones de destino de las comisiones en sí; eso es protocol_fee_destination / fund_fee_destination en la misma cuenta.

​

3. La división de comisiones de protocolo / fondo / creador

                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)

1. La comisión comercial se acumula en el pool. La comisión se elimina del lado de entrada del swap y la cantidad post-comisión es lo que ve la matemática de producto constante. Esto es lo que significa “el LP gana la comisión” — k sube y también lo hace el valor implícito de token por LP.
2. Las porciones de protocolo/fondo/creador se deducen de esa acumulación del lado LP en cuentas de contador por pool. Se sientan en el estado del pool (protocol_fees_token{0,1}, fund_fees_token{0,1}, etc.) hasta que alguien llama a la instrucción de recopilación correspondiente. No salen de las bóvedas del pool hasta entonces; desde la perspectiva de un swap todavía están “en el pool”.
3. La recopilación las saca. Las rutas de protocolo y fondo requieren el firmante respectivo protocol_owner / fund_owner de AmmConfig. Las comisiones de creador de CPMM usan la ruta CollectCreatorFee firmada por el creador o CollectCreatorFeePermissionless, que cualquier pagador puede activar pero que fija los destinos a los ATAs canónicos del creador.

• Los porcentajes de división son de la comisión comercial, no del comercio. Una comisión comercial del 0,25% con una participación de protocolo del 12% significa que el protocolo obtiene 0,25% × 12% = 0,03% del comercio — no el 12% del comercio.
• Las comisiones de creador solo existen en pools graduados de LaunchLab. Los pools estándar de CPMM/CLMM tienen una división de 3 vías (LP / protocolo / fondo). LaunchLab agrega una cuarta ranura enrutada a quien lanzó el token, configurada en Initialize e inmutable.
• AMM v4 se divide solo de dos formas, codificadas por pool: LP y protocolo. Sin ranura de fondo, sin ranura de creador.
• Fondo vs protocolo — ambos son destinos de tesorería de protocolo, pero tienen diferentes firmantes y diferentes usos previstos. protocol históricamente financia operaciones; fund es la tesorería a más largo plazo. La división entre los dos es en sí misma ajustable.

​

4. Cuentas de observación (búfer de anillo TWAP)

// CPMM ObservationState (abreviado)
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,
}

• Cada swap llama a update_observation. El programa lee el precio actual, lo multiplica por los segundos transcurridos desde la observación anterior y lo suma al contador acumulativo. La nueva entrada sobrescribe la ranura más antigua (estilo búfer de anillo).
• TWAP sobre una ventana = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). Los consumidores eligen dos observaciones que delimitan la ventana deseada y dividen.
• Raydium en sí no usa el TWAP para precios. La matemática del AMM lee las reservas de spot directamente. Las observaciones son una externalidad — Raydium paga el costo de escribirlas para que otros contratos puedan leer.
• AMM v4 no tiene cuenta de observación. Es más antiguo que el diseño de ObservationState; los integradores que quieren un TWAP de v4 tienen que calcular uno fuera de cadena desde el historial de registros.

​

5. API REST + SDK + IDL

• API REST — https://api-v3.raydium.io. Una vista indexada de solo lectura de todo el estado en cadena más un motor de cotización. Un host, un esquema.
• SDK de TypeScript — @raydium-io/raydium-sdk-v2 en NPM. Construye y firma transacciones para cada programa. Habla con la API para cotizaciones/metadatos, habla con un RPC de Solana para actualizaciones de estado pre-firma.
• Registro de IDL — Los IDLs de Anchor para cada programa publicado viven en el repositorio raydium-idl (un JSON por programa: CPMM, CLMM, LaunchLab). El SDK de TypeScript consume estos IDLs internamente; los clientes de Rust / Python posteriores regeneran desde los mismos archivos.

​

6. Indexadores y fuentes de precios

• El indexador es la única cosa que “sabe sobre” el estado entre programas. Mapear un pool de CPMM a su contraparte de CLMM, calcular un número de volumen de 24h en versiones de programa, recoger una granja asociada con un mint de LP — todo eso es trabajo del indexador. Los programas en sí no lo hacen.
• El tiempo de inactividad del indexador es el tiempo de inactividad de la API. Si la API devuelve datos obsoletos o vacíos, el indexador es el sospechoso. El estado en cadena no se ve afectado; los integradores con su propio RPC y SDK pueden seguir transaccionando.

​

Qué no se comparte

• Los programas no se llaman entre sí. Un swap de CPMM nunca hace CPI en CLMM o AMM v4. El único programa que compone múltiples AMMs es el programa de Enrutamiento de AMM — y ese es en sí mismo delgado, solo emitiendo CPIs en cada AMM en secuencia.
• Sin autoridad de actualización compartida entre programas. Cada programa en cadena tiene su propia clave de actualización de programa (un multisig de 3/4 más un bloqueo de tiempo de 24h). No están vinculadas.
• Sin estado compartido entre granjas y AMMs. Una granja no sabe si el LP que apuesta es de un pool de CPMM, un mint de NFT de posición de CLMM o un token SPL no relacionado. El programa de granja trata el mint de apuesta como opaco.
• Sin dependencia de oráculo. El precio es en reservas en cadena. No hay respaldo de Pyth/Switchboard; el AMM no verifica un oráculo antes de liquidar.

​

Punteros

• protocol-overview/architecture — el diagrama canónico que muestra cómo se componen estas piezas.
• protocol-overview/versions-and-migration — cómo evolucionaron las convenciones en versiones de programa.
• security/admin-and-multisig — quién controla las claves detrás de los AmmConfigs.
• reference/fee-comparison — matriz de tasas de comisión por producto.
• reference/program-addresses — IDs de programa canónicos.

• Raydium SDK v2 — la fuente de verdad para semillas de PDA, diseños de cuentas y definiciones de IDL.
• Registro de IDL de Raydium — IDLs de Anchor.
• Páginas de cuentas por producto citadas en línea arriba.