Skip to main content
Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.Ver versión en inglés →
Esta página se complementa con products/clmm/accounts (qué son las cuentas) y products/clmm/math (qué es la matemática). Es autoritativa para argumentos y orden de cuentas; los diseños de bytes específicos provienen del IDL.La actualización del programa 2026-09 reconstruyó CLMM en Anchor 1.0.2 / Solana 3.1.10, agregó la instrucción de administrador CollectExcessLamports y cambió lo que CreateAmmConfig escribe en owner / fund_owner. Ninguna instrucción orientada al usuario cambió sus cuentas, argumentos o matemática. Consulta la entrada del registro de cambios 2026-09-30.

​
Inventario de instrucciones

No hay instrucción de inicialización de matriz de tick, y ninguna es necesaria. Una matriz de tick se crea dentro de OpenPosition* / IncreaseLiquidity* por TickArrayState::get_or_create_tick_array, pagada por payer. Pasa el PDA de matriz de tick (posiblemente aún no inicializado, propiedad del sistema) como tick_array_lower / tick_array_upper y el programa lo asigna si falta. OpenLimitOrder hace lo mismo para su único tick_array.
La mayoría de instrucciones solo de administrador (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) están controladas por la clave admin codificada del programa. CreatePermissionPda / ClosePermissionPda aceptan la clave admin o una clave permission_pda_admin dedicada; CreateSupportMintAssociated / CloseSupportMintAssociated aceptan la clave admin o una clave de propietario de mint de soporte dedicada; CollectExcessLamports acepta la clave admin o una billetera de recopilación de lamports dedicada. Las instrucciones de administrador de flujo de recompensas (TransferRewardOwner, CollectRemainingRewards) están controladas por el financiador de recompensas, no por el administrador del programa. El sufijo V2 significa “soporta Token-2022 en bóvedas / NFT, requiere ranura de extensión de mapa de bits”. El SDK elige V2 por defecto para nuevos pools.

​
CreatePool

Argumentos
Cuentas (abreviadas)
Las ranuras 10 y 11 son por mint, no “SPL Token luego Token-2022”. Cada una está restringida por mint::token_program en el mint coincidente, así que para un pool cuyo token_mint_0 es Token-2022 y token_mint_1 es SPL clásico debes pasar Token-2022 en la ranura 10 y SPL Token en la ranura 11. CreateCustomizablePool y CreatePermissionedPool usan las mismas dos ranuras.
Precondiciones
  • token_mint_0 < token_mint_1 por orden de bytes.
  • amm_config.disable_create_pool == false.
  • Los mints no son rechazados por la lista de permisos de extensión Token-2022.
Postcondiciones
  • pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
  • pool_state.liquidity = 0 (sin posiciones aún).
  • pool_state.fee_on = FromInput (predeterminado heredado).
  • pool_state.dynamic_fee_info está en cero (comisión dinámica deshabilitada).

​
CreateCustomizablePool

Recomendado para nuevos pools. Mismo efecto que CreatePool más modo de recopilación de comisiones por pool y una opción de comisión dinámica opcional. Argumentos
Cuentas — exactamente las 13 cuentas declaradas de CreatePool. dynamic_fee_config no es una cuenta declarada.
Cuando enable_dynamic_fee = true, el DynamicFeeConfig a capturar debe suministrarse como la última remaining_account — el manejador lee ctx.remaining_accounts.last(). Cualquier PDA de derivación SupportMintAssociated debe por lo tanto venir antes que ella, o el programa captura la cuenta incorrecta y falla la deserialización. Omitirla mientras la bandera está establecida falla con AccountLack.
Precondiciones — igual que CreatePool. Si enable_dynamic_fee = false, no se requiere remaining_account y cualquiera que se pase solo se escanea para registros de mint de soporte. Postcondiciones
  • pool_state.fee_on establecido en la variante CollectFeeOn elegida.
  • Si la comisión dinámica fue habilitada: pool_state.dynamic_fee_info se inicializa desde el DynamicFeeConfig suministrado (cinco parámetros de calibración copiados; campos de estado en cero).
  • De lo contrario: pool_state.dynamic_fee_info está en cero (= comisión dinámica inactiva para siempre en este pool).
fee_on y la bandera de habilitación de comisión dinámica se establecen solo en la creación del pool. No hay actualización in situ — los pools creados a través del CreatePool heredado no pueden obtener retroactivamente comisión dinámica o comisión de un solo lado. Las nuevas implementaciones deben usar esta instrucción por defecto.

​
CreatePermissionedPool

Tanto CreatePool como CreateCustomizablePool derivan el PDA del pool de ["pool", amm_config, token_mint_0, token_mint_1], así que hay exactamente un dirección de pool canónica por triple (config, mint0, mint1) — un segundo init en las mismas semillas falla. CreatePermissionedPool levanta esa restricción plegando un seed_index: u16 suministrado por el cliente en las semillas del PDA del pool, permitiendo múltiples pools para el mismo par y nivel de comisión — cada uno en su propia dirección. Porque una dirección de pool arbitraria es una capacidad privilegiada, el pagador debe tener un PDA Permission que lo autorice. Todo lo demás sobre el pool es idéntico a CreateCustomizablePool: toma los mismos CreateCustomizableParams y soporta comisión de un lado y la opción de comisión dinámica. Argumentos
Cuentas (abreviadas) — igual que CreateCustomizablePool más, al frente: El PDA pool_state se deriva de ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]. Precondiciones
  • seed_index != 0. Un seed_index de 0 está reservado para pools heredados y se rechaza aquí; el componente de semilla [0, 0] es lo que hace que una dirección de pool heredada se colapse a la forma de cuatro semillas clásica.
  • El PDA permission para payer existe (creado por un administrador a través de CreatePermissionPda).
  • Mismas reglas de mint / lista de permisos que CreatePool.
Postcondiciones
  • Un nuevo pool_state existe en la dirección derivada de seed_index, con pool_state.seed_index = seed_index.
  • Todo otro post-estado coincide con CreateCustomizablePool (modo de comisión, comisión dinámica opcional).
Esta instrucción no amplía el acceso general de creación de pools — la creación sin permisos continúa a través de CreatePool / CreateCustomizablePool, que permanecen como un pool por par. CreatePermissionedPool existe para el caso específico donde un operador en la lista blanca necesita varios pools para el mismo par (p. ej. precios iniciales o cohortes de lanzamiento diferentes) y tiene un PDA Permission otorgado por el administrador.

​
OpenPositionV2 / OpenPositionWithToken22Nft

Crea una nueva posición dentro de un pool existente. Argumentos
Cuentas — las dos variantes tienen listas de cuentas diferentes. OpenPositionV2 declara 22; OpenPositionWithToken22Nft declara 20. OpenPositionV2, en orden: OpenPositionWithToken22Nft es la misma lista con metadata_account (5) y metadata_program (19) removidos — escribe los metadatos de la posición a través de la extensión de metadatos Token-2022 en el mint del NFT en su lugar — dando 20 cuentas. Su position_nft_mint es un Signer desnudo y position_nft_account un UncheckedAccount.
tick_array_bitmap_extension no es una cuenta declarada en ninguna variante. Cuando el rango de la posición cae fuera del tick_array_bitmap en línea del pool (±512 matrices de tick), agrega el PDA TickArrayBitmapExtension en semillas ["pool_tick_array_bitmap_extension", pool_state] como remaining_accounts[0].
Matemática — consulta products/clmm/math. Dado base_flag, el programa resuelve liquidity o (amount_0_max, amount_1_max) en la L real y los montos de token reales consumidos. Precondiciones
  • tick_lower < tick_upper, ambos múltiplos de pool.tick_spacing, dentro de [MIN_TICK, MAX_TICK].
  • Los dos PDAs de matriz de tick se pasan. No necesitan existir ya — get_or_create_tick_array asigna uno faltante a expensas de payer dentro de esta instrucción. No hay instrucción separada de inicialización de matriz de tick.
  • El usuario tiene al menos amount_0_max y amount_1_max en los ATAs de fuente.
Postcondiciones
  • personal_position existe, liquidity establecida, fee_growth_inside_last capturada.
  • Entradas de matriz de tick en tick_lower y tick_upper actualizadas (liquidity_gross += L, liquidity_net ± L, instantáneas de crecimiento de comisión mantenidas).
  • pool_state.liquidity += L si la posición está en rango (tick_lower ≤ tick_current < tick_upper).
  • El mint del NFT de la posición registra pool_state como autoridad de congelación. La autoridad de acuñación se elimina después de que se acuña el único NFT. Registrar la autoridad de congelación no cambia el estado de la cuenta de token del NFT.
  • La cuenta de token del NFT permanece descongelada a menos que la instrucción sea OpenPositionV2 u OpenPositionWithToken22Nft y la autoridad de congelación de cualquier mint de bóveda coincida con la lista de emisores restringidos de CLMM. Solo esa ruta V2 coincidente congela la cuenta. OpenPosition V1 no congela.
Errores comunes — TickInvalidOrder (tick_lower >= tick_upper), TickAndSpacingNotMatch (un extremo no es múltiplo de tick_spacing), InvalidTickIndex (fuera de [MIN_TICK, MAX_TICK]), MissingTickArrayBitmapExtensionAccount (rango fuera del mapa de bits en línea y la extensión no fue agregada), NotApproved (pool_state.status bloquea la apertura), ZeroAmountSpecified.
La congelación de posición no agrega cuentas de instrucción declaradas o argumentos. Los clientes pueden abrir estas posiciones con los diseños V2 existentes. El comportamiento se selecciona en cadena desde vault_0_mint y vault_1_mint.

​
IncreaseLiquidityV2

Agrega liquidez a una posición ya abierta. Argumentos
Cuentas — 15, y no derivables de OpenPosition: no hay rent, no hay system_program, no hay associated_token_program y no hay cuenta de metadatos. Antepone el PDA TickArrayBitmapExtension como remaining_accounts[0] cuando el rango de la posición está fuera del mapa de bits en línea. Efecto
  • Transfiere amount_0_actual / amount_1_actual de usuario → bóvedas.
  • Incrementa personal_position.liquidity y pool_state.liquidity (si está en rango), y el liquidity_gross / liquidity_net del tick de extremo en consecuencia.
  • Cobra comisiones y recompensas adeudadas desde el último toque y las acredita a token_fees_owed_{0,1} / reward_amount_owed. Esas se pagan solo en DecreaseLiquidity / DecreaseLiquidityV2, no en aumento — no hay instrucción de recopilación independiente.

​
DecreaseLiquidityV2

Elimina liquidez de una posición. Argumentos
Cuentas — 16, y no la misma forma u orden que IncreaseLiquidityV2: personal_position y pool_state se intercambian, las bóvedas vienen antes de las matrices de tick, las cuentas del lado del usuario se nombran recipient_token_account_*, y hay un memo_program extra. Cuentas restantes — tres por recompensa activa siendo recopilada, en el orden reward_token_vault(W), recipient_token_account(W), reward_vault_mint. Antepone el PDA TickArrayBitmapExtension cuando el rango de la posición está fuera del mapa de bits en línea.
Esta es también la única forma de recopilar comisiones y recompensas. Para recopilar sin cambiar la posición, llámala con liquidity = 0, amount_0_min = 0, amount_1_min = 0.
Efecto
  • Calcula (amount_0, amount_1) para la L removida dado el sqrt_price_x64 actual.
  • Liquida comisiones/recompensas acumuladas desde el último toque, igual que IncreaseLiquidity.
  • Transfiere amount_0 + fees_owed_0 y amount_1 + fees_owed_1 fuera de las bóvedas al usuario.
  • Disminuye los contadores de liquidez; si el nuevo personal_position.liquidity == 0, la posición es elegible para ClosePosition.
Deslizamiento — amount_0_min y amount_1_min son los mínimos que el usuario acepta netos de comisiones de transferencia Token-2022 en el lado de salida.

​
ClosePosition

Quema el NFT de posición y cierra PersonalPositionState. Cuentas declaradas Cuentas restantes
  • NFT descongelado: ninguno requerido; una cuenta de pool extra es inofensiva porque el manejador no la lee.
  • NFT congelado: agrega personal_position.pool_id como la primera cuenta restante. El programa lo carga como PoolState y usa sus semillas de PDA para firmar el descongelamiento.
Precondiciones
  • personal_position.liquidity == 0.
  • tokens_fees_owed_{0,1} == 0.
  • Todos los contadores de recompensas reward_amount_owed == 0.
(Es decir, recopila todo y disminuye a cero primero.) Efecto
  • Si la cuenta de token del NFT está congelada, verifica que la primera cuenta restante sea igual a personal_position.pool_id, luego la descongela con el PDA del pool.
  • Quema el NFT.
  • Cierra la cuenta de token del NFT y personal_position, reembolsando renta a nft_owner. Si el NFT de posición usa Token-2022, también cierra el mint del NFT; los mints de SPL Token clásico no pueden cerrarse y permanecen con suministro cero.
El descongelamiento, quema y cierre son atómicos. El NFT no puede volverse transferible entre esos pasos. Ruptura condicional del cliente — el diseño IDL declarado no cambia, así que los clientes heredados continúan cerrando posiciones existentes y descongeladas. Un constructor heredado que omite la cuenta de pool restante falla con AccountLack al cerrar una posición congelada. Pasar el pool para cada cierre es la estrategia compatible más simple.

​
SwapV2

Camina la curva de liquidez; entrada exacta o salida exacta dependiendo de is_base_input. Argumentos
Cuentas (abreviadas) Los llamadores pasan una lista clasificada de matrices de tick que cubren el recorrido de swap esperado; el programa usa tantas como necesita. El SDK calcula esta lista a través de PoolUtils.computeAmountOutFormat o el punto final de cotización de la API. Precondiciones
  • pool_state.status permite swap.
  • now >= open_time.
  • sqrt_price_limit_x64 está en el lado correcto de sqrt_price_x64 para la dirección.
Errores comunes — TooLittleOutputReceived (deslizamiento exacto en), TooMuchInputPaid (deslizamiento exacto fuera), SqrtPriceLimitOverflow, NotEnoughTickArrayAccount, InvalidFirstTickArrayAccount, MissingTickArrayBitmapExtensionAccount, LiquidityInsufficient, NotApproved (bit de swap establecido en pool_state.status). CLMM no tiene variante ExceededSlippage — ese nombre es de CPMM — y no tiene TickArrayNotFound. Lo que SwapV2 hace internamente que los llamadores deben saber (lanzamiento posterior a 2025):
  1. Recargo de comisión dinámica — si pool.dynamic_fee_info es distinto de cero, el programa actualiza el acumulador de volatilidad usando la distancia de tick recorrida desde el último swap (con las reglas de filtro/decaimiento de products/clmm/fees) y agrega un dynamic_fee_component encima de AmmConfig.trade_fee_rate. La comisión total está limitada al 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000).
  2. Coincidencia de órdenes limitadas — cuando el recorrido de precio cruza un tick que contiene órdenes limitadas abiertas, el programa primero completa la liquidez de orden limitada disponible en ese tick (FIFO por order_phase), luego procede a lo largo de la curva de liquidez de LP. Los montos completados actualizan tick.unfilled_ratio_x64 y tick.part_filled_orders_remaining para liquidación posterior; las órdenes en sí permanecen no gastadas hasta que su propietario llama a SettleLimitOrder.
  3. Enrutamiento de comisión de un lado — cuando pool.fee_on = Token0Only o Token1Only, el paso de swap aún calcula el mismo comercio entrada-salida; la comisión se enruta entonces al lado configurado. Para direcciones donde el lado de comisión configurado es la salida, la comisión se deduce de la salida del swap (el usuario recibe out − fee); para direcciones donde es la entrada, el comportamiento coincide con FromInput. Consulta is_fee_on_input(zero_for_one) e is_fee_on_token0(zero_for_one) en PoolState.
Swap (V1) implementa la misma comisión dinámica, enrutamiento de comisión de un lado y coincidencia de órdenes limitadas que SwapV2; la única característica que le falta es soporte Token-2022 — ambas bóvedas deben ser SPL Token clásico. Los pools con cualquier mint Token-2022 deben ser intercambiados a través de SwapV2. El agregador y SDK ya prefieren V2 para cada rama CLMM así que los llamadores no tienen que ramificarse en tipo de mint.

​
OpenLimitOrder

Coloca una orden de venta en un tick específico. La orden se sienta en una cohorte FIFO por tick y se completa cuando el precio camina pasado. Argumentos
Cuentas (abreviadas) Cuentas restantes — [0] tick_array_bitmap_extension, requerido solo cuando se inicializa una matriz de tick cuyo índice de inicio cae fuera del mapa de bits en línea del pool. No pases nada de lo contrario.
No hay cuenta rent: la estructura termina en system_program, 13 cuentas declaradas. Un rent extraviado en la posición 14 cae exactamente donde se lee la extensión de mapa de bits opcional, así que la orden parece funcionar hasta la primera vez que una matriz de tick fuera del mapa de bits en línea tiene que ser creada — y luego falla.
Cambio de lista de cuentas (lanzamiento 2026-07). OpenLimitOrder ahora también toma las cuentas del lado de salida — output_token_account, output_vault y output_vault_mint — además del lado de entrada. Se usan solo para validación: el programa rechaza la orden si la cuenta de token de entrada o salida del propietario está congelada. Esto garantiza que un relleno pueda ser liquidado a la ATA de salida del propietario, lo que importa para mints Token-2022 de lista de permisos / congelados por defecto (p. ej. tokens permisionados) donde una cuenta puede no estar aún descongelada. Los clientes construidos contra la lista de cuentas de un solo lado anterior deben agregar las tres cuentas de salida.
Precondiciones
  • Ni input_token_account ni output_token_account están congelados (de lo contrario NotApproved).
  • pool_state.status permite tanto swap (bit 4) como operaciones de orden limitada (bit 5) (de lo contrario NotApproved).
  • tick_index % pool.tick_spacing == 0 y dentro de [MIN_TICK, MAX_TICK].
  • tick_index está en el lado correcto de pool.tick_current para la dirección elegida (vender token0 → tick debe estar arriba del actual, y viceversa). Vender en un tick ya cruzado sería coincidido inmediatamente y se rechaza.
Postcondiciones
  • limit_order existe, capturando tick.order_phase y tick.unfilled_ratio_x64 en tiempo de apertura.
  • tick.orders_amount += amount (en la cohorte actual).
  • limit_order_nonce.order_nonce += 1.
  • OpenLimitOrderEvent emitido.
Errores comunes — NotApproved (cuenta de token de entrada o salida congelada, o el pool tiene swap / orden limitada deshabilitada), ZeroAmountSpecified (amount == 0 después de la comisión de transferencia del lado de entrada), InvalidLimitOrderAmount (el monto produciría una salida por debajo de 1 unidad base en ese tick, u overflow u64), InvalidTickIndex (fuera de [MIN_TICK, MAX_TICK], o en el lado incorrecto de tick_current para la dirección elegida), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

​
IncreaseLimitOrder

Agrega a una orden abierta existente. Solo puede ser llamado por el owner de la orden. Argumentos
Cuentas — 8, solo lado de entrada. Elimina la cuenta nonce, las tres cuentas del lado de salida y system_program. Precondiciones
  • limit_order.owner == signer.
  • La orden aún está en la misma cohorte (tick.order_phase == limit_order.order_phase). Si la cohorte ya ha comenzado a completarse, la orden está parcialmente liquidada — el llamador debe llamar a DecreaseLimitOrder o SettleLimitOrder primero para avanzar.
Efecto
  • Transfiere amount de ATA del propietario a input_vault.
  • limit_order.total_amount += amount; tick.orders_amount += amount.

​
DecreaseLimitOrder

Reduce o cancela completamente una orden abierta. Paga el resto no completado de vuelta al propietario, más cualquier salida ya liquidada por rellenos parciales anteriores. Argumentos
Cuentas — ambos lados de token de entrada y salida: Efecto
  • Recalcula el monto completado de la orden desde el unfilled_ratio_x64 de la cohorte desde la apertura.
  • Envía salida completada a output_token_account.
  • Envía amount de entrada no completada de vuelta a input_token_account.
  • Actualiza limit_order en consecuencia. Si el nuevo resto no completado es cero, el programa cierra la cuenta y reembolsa renta a owner.

​
SettleLimitOrder

Empuja tokens de salida completados al propietario sin cambiar el resto no completado de la orden. Útil cuando los guardianes auto_withdraw quieren pagar en goteo rellenos de larga duración. Llamador — ya sea el owner de la orden, o el limit_order_admin del programa (una billetera caliente operacional fuera de cadena que ejecuta un bucle de guardián automatizado). El guardián no tiene otra autoridad — no puede mover fondos de usuario fuera de empujar salida completada a la ATA owner. Cuentas Efecto
  • Calcula la salida acumulada adeudada usando (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
  • Transfiere el delta a output_token_account.
  • Actualiza limit_order.settled_output.
  • No cierra la orden; aún está abierta contra cualquier entrada restante.

​
CloseLimitOrder

Cierra una cuenta de orden completamente consumida. La renta siempre se devuelve a limit_order.owner independientemente de quién firme. Llamador — ya sea owner o limit_order_admin. Precondiciones
  • La orden tiene cero resto no completado (ya sea amount == total_amount fue completado y liquidado, o el propietario disminuyó previamente la orden a cero y olvidó cerrar).
Efecto
  • Cierra limit_order; la renta se envía a limit_order.owner.

​
CreateDynamicFeeConfig (admin)

Crea un conjunto de parámetros reutilizable bajo un índice u16. Argumentos
Cuentas Errores comunes — InvalidDynamicFeeConfigParams si decay_period <= filter_period o cualquier campo con valor 0 está fuera de límites.

​
UpdateDynamicFeeConfig (admin)

Modifica un DynamicFeeConfig existente. Los pools que ya capturaron la configuración en tiempo de creación no se actualizan retroactivamente; solo los pools recién creados que hagan referencia a esta configuración recogerán los nuevos valores. Argumentos — los mismos cinco campos de calibración que CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator); index se fija en la creación y no se repasa aquí.

​
CollectProtocolFee / CollectFundFee

Barre comisiones de protocolo/fondo acumuladas de las bóvedas del pool a un destinatario, poniendo en cero los campos correspondientes PoolState.protocol_fees_* / fund_fees_*. Este no es el diseño de CPMM — CLMM no tiene cuenta authority, y los campos de destinatario se nombran recipient_token_account_{0,1} en lugar de recipient_token_{0,1}_account. Argumentos — amount_0_requested: u64, amount_1_requested: u64.
Cambiado en 2026-09: las nuevas configuraciones ya no toman sus propietarios de comisión del firmante. create_amm_config ahora escribe el protocol_fee_owner::ID codificado del programa en owner y fund_fee_owner::ID en fund_owner. Antes, copiaba la clave del firmante administrador en ambos. En mainnet estos son las mismas claves ya almacenadas en las 21 configuraciones existentes. Las direcciones están en reference/program-addresses.Los firmantes aceptados arriba no cambian. El administrador aún puede recopilar de cualquier configuración, y las cuentas AmmConfig existentes no se reescriben. Lee owner / fund_owner de la cuenta en lugar de asumir ninguno de los valores. Los parámetros UpdateAmmConfig 3 y 4 aún los rotan.

​
CollectExcessLamports

Barrido de administrador de lamports por encima del mínimo exento de renta en cuentas que CLMM controla. Se agregó en la actualización 2026-09 para reclamar el exceso de financiamiento que la reducción de renta SIMD-0437 deja en cuentas creadas antes de cada paso. Solo el exceso se mueve. Los saldos de token, datos de cuenta, propietarios, estado del pool y la curva de precio no se tocan. Una cuenta ya en su mínimo se deja como está, así que la instrucción puede ser re-ejecutada de forma segura después de cada paso de lanzamiento. Argumentos: ninguno. Cuentas Alcance: un pool por llamada. CLMM no tiene autoridad de bóveda a nivel de programa. Las bóvedas de cada pool son propiedad de su propio PoolState. Cada fuente del programa de token debe por lo tanto tener el pool_state en la ranura 2 como su autoridad: token_vault_0, token_vault_1, o una de las bóvedas de recompensas de ese pool. Si pasas la bóveda de otro pool o una cuenta de token de usuario, la verificación de propietario del programa de token falla y toda la instrucción se revierte. No se salta. Los mints de NFT de posición no pueden ser barridos, porque su autoridad de acuñación se revoca cuando se abre la posición. Cómo se maneja cada cuenta de fuente El programa hace dos pasadas sobre remaining_accounts: cada CPI del programa de token primero, luego los débitos directos. Intercalar los dos aborta con el error UnbalancedInstruction del tiempo de ejecución, así que el orden se fija en el programa y no tienes que ordenar la lista tú mismo.
La pasada 2 cubre cuentas cuya renta pagó un usuario. Un PersonalPositionState o LimitOrderState pasado aquí renuncia a su exceso como cualquier otra cuenta propiedad de CLMM. Permanece exento de renta y mantiene sus datos. Cuando se cierra más tarde, el propietario recupera lo que la cuenta contiene en ese punto, que después de un barrido es el mínimo de renta actual.
El tamaño de la transacción es el límite real de cuántas fuentes caben en una llamada. Es la misma restricción que el barrido del lado de la billetera descrito en solana-fundamentals/rent-and-reclaimable-rent. Errores comunes:
  • NotApproved (6000): firmante incorrecto.
  • LamportsCalculateError (6052): el viaje redondo de wSOL no neteó a cero.
  • Un error de falta de coincidencia de propietario del programa de token: una fuente de token no es propiedad de pool_state.
  • InsufficientFunds: una cuenta propiedad del programa contiene menos que su propio mínimo de renta.
Sin constructor SDK. @raydium-io/raydium-sdk-v2 no envía un constructor para esta ruta de administrador. Codifícalo a mano desde el IDL.

​
InitializeReward

Agrega un nuevo flujo de recompensas a un pool. Hasta 3 flujos pueden estar activos a la vez