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.
Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Uma transação Solana é uma lista de instruções executadas atomicamente. Compreender a estrutura de transações — instruções, contas, signatários, orçamento de computação — é pré-requisito para construir, depurar ou otimizar qualquer coisa com Raydium. Esta página cobre essa estrutura, os limites que a restringem, e como as duas categorias de taxas (taxas de rede do Solana, taxas de protocolo do Raydium) se acumulam em um swap real.
Anatomia da transação
Uma transação Solana tem três componentes centrais:- Message: a lista ordenada de instruções, as contas que referenciam, e o blockhash recente.
- Signatures: uma por signatário, atestando que a transação foi autorizada.
- Recent blockhash: prova que a transação é recente; transações com blockhashes desatualizados (>150 slots antigos) são rejeitadas.
Instruções
Uma instrução especifica:program_id— o programa a invocar.accounts— as contas (e suas flags de escrita/signatário) que o programa pode acessar.data— bytes opacos que o programa interpreta.
ComputeBudget::SetComputeUnitLimit— aumenta o limite padrão de CU.ComputeBudget::SetComputeUnitPrice— define uma taxa de prioridade.CreateAssociatedTokenAccountopcional — cria o ATA de saída se o usuário não tiver um.Raydium::SwapBaseInput— executa o swap.CloseAccountopcional — fecha um ATA de wrapped-SOL.
raydium.trade.swap().
Contas em transações
Toda conta tocada por qualquer instrução na transação deve estar listada nas chaves de conta da transação. Cada conta é marcada com flags:- Signatário / não-signatário: o proprietário da conta deve assinar a transação?
- Escrita / leitura apenas: a transação pode modificar a conta?
solana-fundamentals/account-model). Swaps CLMM com múltiplos cruzamentos de tick podem ter 20+.
Limite de tamanho de transação
Solana limita transações a 1232 bytes incluindo assinaturas, mensagem e cabeçalhos. Esta é a obstrução mais comum para transações complexas — o CLMM do Raydium com roteamento multi-hop regularmente pressiona esse limite. Detalhamento de um swap Raydium típico de ~1000 bytes:| Componente | Tamanho |
|---|---|
| Assinatura | 64 B |
| Contagem de assinaturas | 1 B |
| Cabeçalho de mensagem | 3 B |
| Blockhash | 32 B |
| Chaves de conta (13 × 32 B) | 416 B |
| Instruções (4 × ~100-150 B) | 400–600 B |
| Total | ~900–1100 B |
Address Lookup Tables (ALTs)
ALTs permitem que uma transação referencie contas por um índice de 1 byte em uma tabela publicada, em vez de uma pubkey completa de 32 bytes. Isso comprime drasticamente uma transação:- Uma transação referenciando 20 contas diretamente: ~640 B de pubkeys.
- A mesma transação usando ALTs: ~20 B de índices + referências ALT.
Orçamento de computação
Toda transação tem um orçamento de unidade de computação (CU). Excedê-lo encerra a execução e falha a transação.- Padrão: 200.000 CU por transação.
- Máximo: 1.400.000 CU por transação (aumentado via
ComputeBudget::SetComputeUnitLimit). - Teto por bloco: 48M CU por bloco (nível de protocolo).
integration-guides/priority-fee-tuning para a tabela completa):
| Instrução | CU |
|---|---|
| Swap CPMM | ~140.000 |
| Swap CLMM (sem cruzamento de tick) | ~170.000 |
| Swap CLMM (4 cruzamentos de tick) | ~320.000 |
| Farm v6 stake | ~130.000 |
| Criação de pool CPMM | ~250.000 |
ComputeBudget; caso contrário você fica com o padrão de 200k, que é muito baixo para a maioria das instruções Raydium.
Taxas de prioridade
Além da taxa de transação base (5000 lamports por assinatura), validadores cada vez mais priorizam transações pagando taxas de prioridade: uma dica por-CU em microlamports.integration-guides/priority-fee-tuning para como dimensionar isso dinamicamente.
Limites de contagem de instruções e contagem de contas
Além do limite total de 1232 bytes:- Máx contas por transação: 128.
- Máx contas por instrução (CPI): 64.
- Máx instruções por transação: sem limite rígido, limitado apenas pelo limite de tamanho.
- Máx profundidade CPI: 4 (um programa pode chamar outro, que pode chamar outro, 4 níveis de profundidade).
Categorias de taxas em um swap Raydium
Uma transação de swap do usuário paga taxas em duas categorias:Taxas de rede Solana
Pagas aos validadores em SOL.- Taxa de assinatura base: 5000 lamports por assinatura. Quase sempre 1 assinatura = 0.000005 SOL.
- Taxa de prioridade: CU-price × CU-limit em microlamports. Varia com congestionamento; veja
integration-guides/priority-fee-tuning.
Taxas de protocolo Raydium
Deduzidas do valor do swap.- Taxa de swap: percentual da entrada (CPMM 0.25% típico, CLMM 0.01%–1% por tier). Dividida entre LPs e destinos de protocolo. Veja
ray/protocol-fees.
Exemplo: $1000 USDC → SOL via CPMM tier 0.25%
| Categoria de taxa | Valor | Vai para |
|---|---|---|
| Taxa de assinatura base | 0.000005 SOL (~$0.0007) | Validador |
| Taxa de prioridade (10k µL × 300k CU) | 0.003 SOL (~$0.45) | Validador |
| Taxa de swap CPMM (0.25%) | $2.50 | LPs + protocolo |
| Custo total do usuário | ~$2.95 |
Transações versionadas
Solana tem dois formatos de transação:- Legacy: o formato original, sem suporte ALT.
- v0 (Versioned): suporta ALTs, extensível para versões futuras.
Atualidade do blockhash
Uma transação deve incluir um blockhash de dentro da última ~150 slots (~60 segundos). Além dessa janela, validadores a rejeitam. Para loops de retry, busque um novo blockhash em cada retry:integration-guides/priority-fee-tuning para o padrão completo de retry-com-taxas-crescentes.
Execução paralela
Solana executa transações não-conflitantes em paralelo em validadores multi-core. Duas transações conflitam se ambas escrevem a mesma conta. Implicações para Raydium:- Dois swaps na mesma pool não podem executar em paralelo — ambos escrevem o estado da pool.
- Um swap na Pool A e um swap na Pool B executam em paralelo se listas de contas não se sobrepõem.
- Uma transação somente-leitura nunca bloqueia um escritor na mesma conta (somente-leitura é concorrente consigo mesmo mas não com escritas).
Níveis de confirmação de transação
Ao submeter uma transação você escolhe um nível de confirmação:| Nível | Espera | Finalidade |
|---|---|---|
processed | ~400 ms | Não finalizado; pode reverter |
confirmed | ~1 s | Supermaioria votou |
finalized | ~13 s | Supermaioria enraizada |
confirmed é padrão. Para operações manipulando grande valor (criação de pool, top-ups de recompensa), finalized é mais seguro.
Simulação
Solana suporta simular uma transação antes de submeter:getBestSwapInfo para verificar que a rota escolhida realmente sucede. Simulação não é gratuita — consome capacidade RPC — mas detecta erros antes de pagar por eles.
Referências
solana-fundamentals/account-model— contas em transações.solana-fundamentals/pdas-and-cpis— como programas invocam um ao outro.integration-guides/priority-fee-tuning— dimensionando limites de CU e taxas de prioridade.ray/protocol-fees— estrutura de taxas de protocolo Raydium.


