Skip to main content
Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Esta página funciona em conjunto com products/clmm/accounts (o que são as contas) e products/clmm/math (o que é a matemática). É autoritativa para argumentos e ordenação de contas; layouts de bytes específicos vêm do IDL.A atualização do programa 2026-09 reconstruiu CLMM no Anchor 1.0.2 / Solana 3.1.10, adicionou a instrução de admin CollectExcessLamports e alterou o que CreateAmmConfig escreve em owner / fund_owner. Nenhuma instrução voltada ao usuário alterou suas contas, argumentos ou matemática. Veja a entrada do changelog 2026-09-30.A atualização do programa 2026-10-22 renomeia CreatePermissionedPool para CreateCustomizablePoolV2, a torna chamável por qualquer pessoa e remove a conta Permission com suas duas instruções de admin. Veja a entrada do changelog 2026-10-22.

​
Inventário de instruções

Não há instrução de inicialização de array de tick, e nenhuma é necessária. Um array de tick é criado dentro de OpenPosition* / IncreaseLiquidity* por TickArrayState::get_or_create_tick_array, pago por payer. Passe o PDA do array de tick (possivelmente ainda não inicializado, de propriedade do sistema) como tick_array_lower / tick_array_upper e o programa o aloca se estiver faltando. OpenLimitOrder faz o mesmo para seu único tick_array.
A maioria das instruções apenas de admin (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) é controlada pela chave admin codificada do programa. CreateSupportMintAssociated / CloseSupportMintAssociated aceitam a chave pública admin ou uma chave de proprietário de mint de suporte dedicada; CollectExcessLamports aceita a chave pública admin ou uma carteira dedicada de coleta de lamports. As instruções de admin de fluxo de recompensa (TransferRewardOwner, CollectRemainingRewards) são controladas pelo financiador de recompensa, não pelo admin do programa. Sufixo V2 significa “suporta Token-2022 em cofres / NFT, requer slot de extensão de bitmap”. O SDK escolhe V2 por padrão para novos pools.

​
CreatePool

Argumentos
Contas (abreviado)
Os slots 10 e 11 são por-mint, não “SPL Token depois Token-2022”. Cada um é restringido por mint::token_program no mint correspondente, então para um pool cujo token_mint_0 é Token-2022 e token_mint_1 é SPL clássico você deve passar Token-2022 no slot 10 e SPL Token no slot 11. CreateCustomizablePool e CreateCustomizablePoolV2 usam os mesmos dois slots.
Pré-condições
  • token_mint_0 < token_mint_1 por ordem de byte.
  • amm_config.disable_create_pool == false.
  • Mints não são rejeitados pela lista de permissões de extensão Token-2022.
Pós-condições
  • pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
  • pool_state.liquidity = 0 (sem posições ainda).
  • pool_state.fee_on = FromInput (padrão legado).
  • pool_state.dynamic_fee_info é zerado (taxa dinâmica desabilitada).

​
CreateCustomizablePool

Recomendado para novos pools. Mesmo efeito que CreatePool mais modo de coleta de taxa por pool e um opt-in de taxa dinâmica opcional. Argumentos
Contas — exatamente as 13 contas declaradas de CreatePool. dynamic_fee_config não é uma conta declarada.
Quando enable_dynamic_fee = true, o DynamicFeeConfig a capturar deve ser fornecido como a última remaining_account — o manipulador lê ctx.remaining_accounts.last(). Qualquer PDA de bypass SupportMintAssociated deve portanto vir antes dele, ou o programa captura a conta errada e falha na desserialização. Omiti-lo enquanto o sinalizador está definido falha com AccountLack.
Pré-condições — mesmas que CreatePool. Se enable_dynamic_fee = false, nenhuma remaining_account é necessária e qualquer uma que seja passada é apenas verificada para registros de mint de suporte. Pós-condições
  • pool_state.fee_on definido para a variante CollectFeeOn escolhida.
  • Se taxa dinâmica foi habilitada: pool_state.dynamic_fee_info é inicializado a partir do DynamicFeeConfig fornecido (cinco parâmetros de calibração copiados; campos de estado zerados).
  • Caso contrário: pool_state.dynamic_fee_info é zerado (= taxa dinâmica inativa para sempre para este pool).
fee_on e o bit de habilitação de taxa dinâmica são definidos apenas na criação do pool. Não há atualização in-place — pools criados via CreatePool legado não podem ganhar retroativamente taxa dinâmica ou taxa unilateral. Novas implantações devem usar como padrão esta instrução.

​
CreateCustomizablePoolV2

Tanto CreatePool quanto CreateCustomizablePool derivam o pool PDA a partir de ["pool", amm_config, token_mint_0, token_mint_1], portanto existe exatamente um endereço de pool canônico por tripla (config, mint0, mint1) — uma segunda init com as mesmas seeds falha. CreateCustomizablePoolV2 remove essa restrição ao incorporar um seed_index: u16 fornecido pelo cliente nas seeds do pool PDA, permitindo múltiplos pools para o mesmo par e nível de taxa — cada um em seu próprio endereço. Qualquer pessoa pode chamá-lo. Tudo mais sobre o pool é idêntico a CreateCustomizablePool: ele recebe os mesmos CreateCustomizableParams e suporta taxa de um lado e opt-in de taxa dinâmica.
Até a atualização de 2026-10-22, essa instrução era chamada CreatePermissionedPool e exigia que o pagador tivesse um PDA Permission emitido por um administrador. A atualização a renomeou, removeu a conta permission e deletou a maquinaria de permissões. O discriminador mudou com o nome, portanto clientes construídos contra CreatePermissionedPool devem ser reconstruídos.
Argumentos
Contas remaining_accounts: os PDAs do registro de support-mint quando um mint Token-2022 precisa deles, e o DynamicFeeConfig por último quando enable_dynamic_fee = true — como em CreateCustomizablePool. Pré-condições
  • seed_index != 0. Um seed_index de 0 é reservado para pools legados e é rejeitado aqui; o componente de seed [0, 0] é o que faz um endereço de pool legado colapsar para a forma clássica de quatro seeds.
  • Nenhum pool já existe no endereço derivado.
  • Mesmas regras de mint / allow-list que CreatePool.
Pós-condições
  • Um novo pool_state existe no endereço derivado de seed_index, com pool_state.seed_index = seed_index.
  • Todo o resto do pós-estado corresponde a CreateCustomizablePool (modo de taxa, taxa dinâmica opcional).
Como pool_creator não é verificado, qualquer pagador pode escrever qualquer endereço em pool_state.owner. Esse endereço pode chamar InitializeReward no pool, mas não é prova de quem criou o pool. Integradores não devem rotular ou classificar pools V2 por seu owner.

​
OpenPositionV2 / OpenPositionWithToken22Nft

Crie uma nova posição dentro de um pool existente. Argumentos
Contas — as duas variantes têm listas de contas diferentes. OpenPositionV2 declara 22; OpenPositionWithToken22Nft declara 20. OpenPositionV2, em ordem: OpenPositionWithToken22Nft é a mesma lista com metadata_account (5) e metadata_program (19) removidos — ele escreve os metadados da posição através da extensão de metadados Token-2022 no mint do NFT — resultando em 20 contas. Seu position_nft_mint é um Signer simples e position_nft_account um UncheckedAccount.
tick_array_bitmap_extension não é uma conta declarada em nenhuma variante. Quando o intervalo da posição cai fora do tick_array_bitmap inline do pool (±512 arrays de tick), anexe o PDA TickArrayBitmapExtension com seeds ["pool_tick_array_bitmap_extension", pool_state] como remaining_accounts[0].
Matemática — veja products/clmm/math. Dado base_flag, o programa resolve liquidity ou (amount_0_max, amount_1_max) em L real e os valores de token reais consumidos. Pré-condições
  • tick_lower < tick_upper, ambos múltiplos de pool.tick_spacing, dentro de [MIN_TICK, MAX_TICK].
  • Os dois PDAs de tick-array são passados. Eles não precisam já existir — get_or_create_tick_array aloca um faltante em ["pool_tick_array", pool_state, tick_index] à custa do payer dentro dessa instrução. Não há instrução separada de init-tick-array.
  • O usuário tem pelo menos amount_0_max e amount_1_max nas ATAs de origem.
Pós-condições
  • personal_position existe, liquidity definido, fee_growth_inside_last capturado.
  • Entradas de tick-array em tick_lower e tick_upper atualizadas (liquidity_gross += L, liquidity_net ± L, snapshots de crescimento de taxa mantidos).
  • pool_state.liquidity += L se a posição está no intervalo (tick_lower ≤ tick_current < tick_upper).
  • O mint do NFT da posição registra pool_state como autoridade de congelamento. A autoridade de mint é removida após o único NFT ser cunhado. Registrar a autoridade de congelamento não altera o estado da conta de token do NFT.
  • A conta de token do NFT permanece descongelada a menos que a instrução seja OpenPositionV2 ou OpenPositionWithToken22Nft e a autoridade de congelamento de qualquer mint do vault corresponda à lista de emissores restritos do CLMM. Apenas esse caminho V2 correspondente congela a conta. OpenPosition V1 não congela.
Erros comuns — TickInvalidOrder (tick_lower >= tick_upper), TickAndSpacingNotMatch (um endpoint não é múltiplo de tick_spacing), InvalidTickIndex (fora de [MIN_TICK, MAX_TICK]), MissingTickArrayBitmapExtensionAccount (intervalo fora do bitmap inline e a extensão não foi anexada), NotApproved (pool_state.status bloqueia abertura), ZeroAmountSpecified.
O congelamento de posição não adiciona contas de instrução declaradas ou argumentos. Clientes podem abrir essas posições com os layouts V2 existentes. O comportamento é selecionado on-chain a partir de vault_0_mint e vault_1_mint.

​
IncreaseLiquidityV2

Adicione liquidez a uma posição já aberta. Argumentos
Contas — 15, e não deriváveis de OpenPosition: não há rent, não há system_program, não há associated_token_program e não há conta de metadados. Anexe o PDA TickArrayBitmapExtension como remaining_accounts[0] quando o intervalo da posição está fora do bitmap inline. Efeito
  • Transfere amount_0_actual / amount_1_actual do usuário → vaults.
  • Incrementa personal_position.liquidity e pool_state.liquidity (se no intervalo), e o liquidity_gross / liquidity_net do tick de endpoint correspondentemente.
  • Coleta taxas e recompensas devidas desde o último toque e as credita a token_fees_owed_{0,1} / reward_amount_owed. Essas são pagas apenas em DecreaseLiquidity / DecreaseLiquidityV2, não em aumento — não há instrução de coleta independente.

​
DecreaseLiquidityV2

Remova liquidez de uma posição. Argumentos
Contas — 16, e não a mesma forma ou ordem que IncreaseLiquidityV2: personal_position e pool_state são trocados, os vaults vêm antes dos tick arrays, as contas do lado do usuário são nomeadas recipient_token_account_*, e há um memo_program extra. Contas restantes — três por recompensa ativa sendo coletada, na ordem reward_token_vault(W), recipient_token_account(W), reward_vault_mint. Anexe o PDA TickArrayBitmapExtension quando o intervalo da posição está fora do bitmap inline.
Essa é também a única forma de coletar taxas e recompensas. Para coletar sem alterar a posição, chame-a com liquidity = 0, amount_0_min = 0, amount_1_min = 0.
Efeito
  • Computa (amount_0, amount_1) para o L removido dado o sqrt_price_x64 atual.
  • Liquida taxas/recompensas acumuladas desde o último toque, igual a IncreaseLiquidity.
  • Transfere amount_0 + fees_owed_0 e amount_1 + fees_owed_1 dos vaults para o usuário.
  • Decrementa contadores de liquidez; se o novo personal_position.liquidity == 0, a posição é elegível para ClosePosition.
Slippage — amount_0_min e amount_1_min são os mínimos que o usuário aceita líquido de taxas de transferência Token-2022 no lado da saída.

​
ClosePosition

Queima o NFT da posição e fecha PersonalPositionState. Contas declaradas Contas restantes
  • NFT não congelado: nenhuma necessária; uma conta de pool extra é inofensiva porque o handler não a lê.
  • NFT congelado: anexe personal_position.pool_id como a primeira conta restante. O programa a carrega como PoolState e usa suas sementes PDA para assinar o descongelamento.
Pré-condições
  • personal_position.liquidity == 0.
  • tokens_fees_owed_{0,1} == 0.
  • Todos os contadores de recompensa reward_amount_owed == 0.
(Ou seja, colete tudo e diminua para zero primeiro.) Efeito
  • Se a conta de token NFT estiver congelada, verifica se a primeira conta restante é igual a personal_position.pool_id, depois a descongela com o PDA do pool.
  • Queima o NFT.
  • Fecha a conta de token NFT e personal_position, reembolsando aluguel para nft_owner. Se o NFT da posição usar Token-2022, também fecha o mint do NFT; mints SPL Token clássicos não podem ser fechados e permanecem com fornecimento zero.
O descongelamento, queima e fechamento são atômicos. O NFT não pode se tornar transferível entre essas etapas. Quebra condicional do cliente — o layout IDL declarado não muda, então clientes legados continuam fechando posições existentes e não congeladas. Um construtor legado que omite a conta de pool restante falha com AccountLack ao fechar uma posição congelada. Passar o pool para cada fechamento é a estratégia compatível mais simples.

​
SwapV2

Percorre a curva de liquidez; entrada exata ou saída exata dependendo de is_base_input. Argumentos
Contas (abreviadas) Os chamadores passam uma lista classificada de arrays de tick cobrindo a caminhada de swap esperada; o programa usa quantos precisar. O SDK calcula essa lista via PoolUtils.computeAmountOutFormat ou o endpoint de cotação da API. Pré-condições
  • pool_state.status permite swap.
  • now >= open_time.
  • sqrt_price_limit_x64 está no lado correto de sqrt_price_x64 para a direção.
Erros comuns — TooLittleOutputReceived (slippage de entrada exata), TooMuchInputPaid (slippage de saída exata), SqrtPriceLimitOverflow, NotEnoughTickArrayAccount, InvalidFirstTickArrayAccount, MissingTickArrayBitmapExtensionAccount, LiquidityInsufficient, NotApproved (bit de swap definido em pool_state.status). CLMM não tem variante ExceededSlippage — esse nome é do CPMM — e não tem TickArrayNotFound. O que SwapV2 faz internamente que os chamadores devem saber (lançamento pós-2025):
  1. Sobretaxa de taxa dinâmica — se pool.dynamic_fee_info for diferente de zero, o programa atualiza o acumulador de volatilidade usando a distância de tick percorrida desde o último swap (com as regras de filtro/decaimento de products/clmm/fees) e adiciona um dynamic_fee_component em cima de AmmConfig.trade_fee_rate. A taxa total é limitada a 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000).
  2. Correspondência de ordem limitada — quando a caminhada de preço cruza um tick que contém ordens limitadas abertas, o programa primeiro preenche a liquidez de ordem limitada disponível naquele tick (FIFO por order_phase), depois prossegue ao longo da curva de liquidez do LP. Os valores preenchidos atualizam tick.unfilled_ratio_x64 e tick.part_filled_orders_remaining para liquidação posterior; as ordens em si permanecem não gastas até que seu proprietário chame SettleLimitOrder.
  3. Roteamento de taxa unilateral — quando pool.fee_on = Token0Only ou Token1Only, a etapa de swap ainda calcula o mesmo comércio entrada-saída; a taxa é então roteada para o lado configurado. Para direções onde o lado de taxa configurado é a saída, a taxa é deduzida da saída do swap (o usuário recebe out − fee); para direções onde é a entrada, o comportamento corresponde a FromInput. Veja is_fee_on_input(zero_for_one) e is_fee_on_token0(zero_for_one) em PoolState.
Swap (V1) implementa a mesma taxa dinâmica, roteamento de taxa unilateral e correspondência de ordem limitada que SwapV2; o único recurso que falta é suporte Token-2022 — ambos os vaults devem ser SPL Token clássico. Pools com qualquer mint Token-2022 devem ser trocados via SwapV2. O agregador e SDK já preferem V2 para cada perna CLMM, então os chamadores não precisam ramificar no tipo de mint.

​
OpenLimitOrder

Coloca uma ordem de venda em um tick específico. A ordem fica em uma coorte FIFO por tick e é preenchida conforme o preço passa. Argumentos
Contas (abreviadas) Contas restantes — [0] tick_array_bitmap_extension, obrigatória apenas ao inicializar um array de tick cujo índice inicial fica fora do bitmap inline do pool. Não passe nada caso contrário.
Não há nenhuma conta rent: a struct termina em system_program, 13 contas declaradas. Um rent deslocado na posição 14 cai exatamente onde a extensão de bitmap opcional é lida, então a ordem parece funcionar até a primeira vez que um array de tick fora do bitmap inline precisa ser criado — e então falha.
Mudança na lista de contas (lançamento 2026-07). OpenLimitOrder agora também leva as contas do lado de saída — output_token_account, output_vault e output_vault_mint — além do lado de entrada. Elas são usadas apenas para validação: o programa rejeita a ordem se a conta de token de entrada ou saída do proprietário estiver congelada. Isso garante que um preenchimento possa realmente ser liquidado para a ATA de saída do proprietário, o que importa para mints Token-2022 com lista de permissões / congelados por padrão (por exemplo, tokens permissionados) onde uma conta pode ainda não estar descongelada. Clientes construídos contra a lista de contas unilateral mais antiga devem adicionar as três contas de saída.
Pré-condições
  • Nem input_token_account nem output_token_account estão congeladas (caso contrário NotApproved).
  • pool_state.status permite ambas as operações de swap (bit 4) e ordem limitada (bit 5) (caso contrário NotApproved).
  • tick_index % pool.tick_spacing == 0 e dentro de [MIN_TICK, MAX_TICK].
  • tick_index está no lado direito de pool.tick_current para a direção escolhida (venda de token0 → tick deve estar acima do atual, e vice-versa). Vender em um tick já cruzado seria correspondido imediatamente e é rejeitado.
Pós-condições
  • limit_order existe, capturando tick.order_phase e tick.unfilled_ratio_x64 no momento da abertura.
  • tick.orders_amount += amount (na coorte atual).
  • limit_order_nonce.order_nonce += 1.
  • OpenLimitOrderEvent emitido.
Erros comuns — NotApproved (conta de token de entrada ou saída congelada, ou o pool tem swap / ordem limitada desabilitada), ZeroAmountSpecified (amount == 0 após a taxa de transferência do lado de entrada), InvalidLimitOrderAmount (o valor produziria uma saída abaixo de 1 unidade base naquele tick, ou transbordaria u64), InvalidTickIndex (fora de [MIN_TICK, MAX_TICK], ou no lado errado de tick_current para a direção escolhida), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

​
IncreaseLimitOrder

Adiciona a uma ordem aberta existente. Apenas chamável pelo owner da ordem. Argumentos
Contas — 8, apenas lado de entrada. Remove a conta de nonce, todas as três contas do lado de saída e system_program. Pré-condições
  • limit_order.owner == signer.
  • A ordem ainda está na mesma coorte (tick.order_phase == limit_order.order_phase). Se a coorte já começou a ser preenchida, a ordem está parcialmente liquidada — o chamador deve chamar DecreaseLimitOrder ou SettleLimitOrder primeiro para avançar.
Efeito
  • Transfere amount da ATA do proprietário para input_vault.
  • limit_order.total_amount += amount; tick.orders_amount += amount.

​
DecreaseLimitOrder

Reduz ou cancela completamente uma ordem aberta. Paga o restante não preenchido de volta ao proprietário, mais qualquer saída já liquidada por preenchimentos parciais anteriores. Argumentos
Contas — ambos os lados de token de entrada e saída: Efeito
  • Recalcula o valor preenchido da ordem a partir de unfilled_ratio_x64 da coorte desde a abertura.
  • Envia saída preenchida para output_token_account.
  • Envia amount de entrada não preenchida de volta para input_token_account.
  • Atualiza limit_order de acordo. Se o novo restante não preenchido for zero, o programa fecha a conta e reembolsa aluguel para owner.

​
SettleLimitOrder

Transferir tokens de saída preenchidos para o proprietário sem alterar o restante não preenchido da ordem. Útil quando keepers com auto_withdraw desejam fazer pagamentos graduais de preenchimentos parciais de longa duração. Chamador — o owner da ordem ou o limit_order_admin do programa (uma carteira operacional off-chain que executa um loop de keeper automatizado). O keeper não tem outra autoridade — não pode mover fundos do usuário além de transferir a saída preenchida para a ATA owner da ordem. Contas Efeito
  • Calcula a saída cumulativa devida usando (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
  • Transfere o delta para output_token_account.
  • Atualiza limit_order.settled_output.
  • Não fecha a ordem; ela permanece aberta contra qualquer entrada restante.

​
CloseLimitOrder

Fechar uma conta de ordem totalmente consumida. A taxa de aluguel é sempre devolvida a limit_order.owner independentemente de quem assina. Chamador — owner ou limit_order_admin. Pré-condições
  • A ordem tem zero restante não preenchido (ou amount == total_amount foi preenchido e liquidado, ou o proprietário diminuiu anteriormente a ordem para zero e esqueceu de fechá-la).
Efeito
  • Fecha limit_order; a taxa de aluguel é enviada para limit_order.owner.

​
CreateDynamicFeeConfig (admin)

Criar um conjunto de parâmetros reutilizável sob um índice u16. Argumentos
Contas Erros comuns — InvalidDynamicFeeConfigParams se decay_period <= filter_period ou qualquer campo com valor 0 estiver fora dos limites.

​
UpdateDynamicFeeConfig (admin)

Modificar um DynamicFeeConfig existente. Pools que já capturaram a configuração no momento da criação não são atualizados retroativamente; apenas pools recém-criados que referenciam esta configuração usarão os novos valores. Argumentos — os mesmos cinco campos de calibração de CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator); index é fixo na criação e não é passado novamente aqui.

​
CollectProtocolFee / CollectFundFee

Coletar taxas de protocolo/fundo acumuladas dos vaults do pool para um destinatário, zerando os campos correspondentes PoolState.protocol_fees_* / fund_fees_*. Este não é o layout do CPMM — CLMM não tem conta authority, e os campos de destinatário são nomeados recipient_token_account_{0,1} em vez de recipient_token_{0,1}_account. Argumentos — amount_0_requested: u64, amount_1_requested: u64.
Alterado em 2026-09: novas configurações não obtêm mais seus proprietários de taxa do assinante. create_amm_config agora escreve o protocol_fee_owner::ID codificado do programa em owner e fund_fee_owner::ID em fund_owner. Antes, copiava a chave do assinante admin em ambos. Na mainnet, estas são as mesmas chaves já armazenadas em todas as 21 configurações existentes. Os endereços estão em reference/program-addresses.Os assinantes aceitos acima não foram alterados. O admin ainda pode coletar de qualquer configuração, e contas AmmConfig existentes não são reescritas. Leia owner / fund_owner da conta em vez de assumir qualquer valor. Os parâmetros 3 e 4 de UpdateAmmConfig ainda os rotacionam.

​
CollectExcessLamports

Coleta de admin de lamports acima do mínimo isento de aluguel em contas que CLMM controla. Foi adicionado na atualização 2026-09 para recuperar o excesso de financiamento que a redução de aluguel SIMD-0437 deixa em contas criadas antes de cada etapa. Apenas o excesso se move. Saldos de tokens, dados da conta, proprietários, estado do pool e a curva de preço não são alterados. Uma conta já no seu mínimo é deixada como está, então a instrução pode ser executada novamente com segurança após cada etapa de lançamento. Argumentos: nenhum. Contas Escopo: um pool por chamada. CLMM não tem autoridade de vault em todo o programa. Os vaults de cada pool são de propriedade de seu próprio PoolState. Cada origem do programa de token deve, portanto, ter o pool_state no slot 2 como sua autoridade: token_vault_0, token_vault_1, ou um dos vaults de recompensa desse pool. Se você passar o vault de outro pool ou uma conta de token do usuário, a verificação de proprietário do programa de token falha e toda a instrução é revertida. Não é ignorada. Mints de NFT de posição não podem ser coletados, porque sua autoridade de mint é revogada quando a posição é aberta. Como cada conta de origem é tratada O programa faz duas passagens sobre remaining_accounts: cada CPI do programa de token primeiro, depois os débitos diretos. Intercalar os dois aborta com o erro UnbalancedInstruction do runtime, então a ordem é fixa no programa e você não precisa classificar a lista você mesmo.
A passagem 2 cobre contas cujo aluguel um usuário pagou. Um PersonalPositionState ou LimitOrderState passado aqui abre mão de seu excesso como qualquer outra conta de propriedade do CLMM. Permanece isento de aluguel e mantém seus dados. Quando é posteriormente fechado, o proprietário recebe de volta o que a conta contém naquele ponto, que após uma coleta é o mínimo de aluguel atual.
O tamanho da transação é o limite real de quantas origens cabem em uma chamada. É a mesma restrição que a coleta do lado da carteira descrita em solana-fundamentals/rent-and-reclaimable-rent. Erros comuns:
  • NotApproved (6000): assinante errado.
  • LamportsCalculateError (6052): a viagem de ida e volta do wSOL não resultou em zero.
  • Um erro de incompatibilidade de proprietário do programa de token: uma origem de token não é de propriedade de pool_state.
  • InsufficientFunds: uma conta de propriedade do programa contém menos do que seu próprio mínimo de aluguel.
Sem construtor SDK. @raydium-io/raydium-sdk-v2 não fornece um construtor para este caminho de admin. Codifique-o manualmente a partir do IDL.

​
InitializeReward

Adicionar um novo fluxo de recompensa a um pool. Até 3 fluxos podem estar ativos simultaneamente. Argumentos — uma única struct, param: InitializeRewardParam:
A codificação de transmissão é os três campos um após o outro, então uma instrução construída manualmente não é afetada — mas um cliente orientado por IDL deve passar um objeto param em vez de três argumentos posicionais. Contas Pré-condições
  • Menos de 3 fluxos atualmente ativos no pool.
  • O financiador deposita total_emission = emissions_per_second × (end_time − open_time) de token de recompensa no vault como parte desta instrução.
  • Mint de recompensa na lista de permissões por operation_state.

​
SetRewardParams

Estender, aumentar ou alterar a taxa de emissão em um fluxo de recompensa existente. Normalmente chamado por um criador de pool ou pelo multisig Raydium. As restrições vivem on-chain: você geralmente pode estender end_time ou aumentar emissões, não encolhê-las retroativamente. Verifique a lista de proprietários de operation_state.

​
UpdateRewardInfos

Pura contabilidade — liquida reward_growth_global_x64 para o tempo atual multiplicando emissions_per_second × Δt / liquidity. Chamado internamente por cada instrução que toca liquidez. Exposto como uma instrução independente porque atores externos (UIs, cranks) às vezes desejam acioná-lo.

​
Coletando recompensas

Não há instrução de coleta de recompensa independente. O programa não expõe nenhum ponto de entrada CollectReward, e o IDL publicado também não tem nenhum.
As recompensas devidas a uma posição são pagas por DecreaseLiquidity / DecreaseLiquidityV2. Para coletar sem alterar a posição, chame-a com liquidity = 0, amount_0_min = 0, amount_1_min = 0. Os vaults de recompensa e contas de destinatário vão em remaining_accounts em grupos de três por recompensa ativa, na ordem reward_token_vault(W), recipient_token_account(W), reward_vault_mint. CollectRemainingRewards é uma coisa diferente: permite que o financiador de recompensa, após o end_time de um fluxo, colete tokens que nunca foram alocados para nenhuma posição.

​
Matriz de mudanças de estado

​
Próximos passos

Fontes: