solana-arb-executor

O que solana-arb-executor faz?

Estrutura o caminho quente de execução em Rust para arbitragem em Solana: stream -> detectar -> simular -> bundle -> landing, encapsulado em um gate de risco (limites, disjuntor, kill-switch) e um gate de confirmação. Esta é a camada on-chain que o estado da arte anterior apenas analisa: agiprolabs/claude-trading-skills é análise em Python (sinais, backtests, sem execução), e skills de arbitragem em TypeScript deixam o caminho sensível à latência para trás. Este é o espaço genuíno — a parte que precisa ser rápida, correta e segura.

Economia honesta (fundamental): arbitragem DEX espacial em Solana é dominada por infraestrutura e altamente disputada; lacunas de preço brutas vão para partes com melhor posição de rede do que uma única máquina. A vantagem duradoura de um operador de varejo não é velocidade bruta — é landing correto (simular primeiro, preço de CU certo, dimensionamento de gorjeta, disciplina de retentativa), disciplina de risco (limites/disjuntor/kill-switch) e oportunidades menos disputadas (basis de funding, diferenças de taxa entre venues, jogos de horizonte maior). Isto é estruturação + conhecimento, não um bot hospedado e não uma máquina de lucro garantida.

PRECEDÊNCIA (leia antes de qualquer geração de código)

1. Leia references/safety-rails.md PRIMEIRO. Todo caminho de execução emitido o obedece.
2. Nunca emita código que envie uma transação que mova fundos / assine sem um gate de confirmação humano explícito e tipado; nenhuma flag o desativa. Padrão DRY_RUN=true, REQUIRE_CONFIRM=true. Sempre simule antes de submeter.
3. Use as versões fixadas de crates em references/sdk-versions.md (verificado 2026-06). Sinalize jito-sdk-rust como 0.x inicial.
4. Delegue trabalho de programa / Anchor / IDL / assinatura de transações para ../solana-dev/ via references/delegation.md. Não o duplique aqui.
5. Limites obrigatórios (notional máximo, posição máxima, perda diária) + disjuntor + kill-switch bloqueiam cada ordem antes que ela possa chegar ao gate de confirmação.

Guia de Roteamento de Tarefas

Mapeie a intenção do usuário para exatamente uma folha.

Usuário pergunta sobre...	Abra esta folha
design do caminho quente / orçamento de latência	references/architecture.md
stream de contas/slots / ingestão ShredStream	references/streaming-ingestion.md
bundle Jito / gorjeta / temporização de líder	references/jito-bundles.md
landing de tx / taxa de prioridade / simular / retentativas	references/transaction-landing.md
detectar oportunidade / spread / limite	references/opportunity-detection.md
risco / disjuntor / kill-switch / limites	references/risk-and-killswitch.md
segurança / gate de confirmação	references/safety-rails.md
crate / versão / instalação	references/sdk-versions.md
programa / Anchor / assinatura	references/delegation.md

Divulgação progressiva

• Roteador (este arquivo): apenas ponteiros — sem conteúdo volumoso.
• Folhas (~60-200 linhas cada): densas, corretas, mínimas. O código vive em skill/templates/.
• Lógica pura é testável offline: templates/src/fees.rs e templates/src/risk.rs são apenas std e autocontidos — execute rustc --edition 2021 --test fees.rs (e risk.rs) de forma independente. O crate completo (stream.rs, jito.rs, detector.rs, main.rs) compila com cargo build contra os crates fixados.
• Delegação: ../solana-dev/ para programa / tx / assinatura.

Agentes

Agente	Papel	Modelo
agents/arb-execution-architect.md	Projeta o orçamento de latência, topologia de ingestão/landing e envelope de risco antes do código	opus
agents/rust-perf-engineer.md	Conecta stream -> detector -> RiskGate -> bundle Jito com simulação prévia	sonnet

Comandos

Comando	Faz
commands/scaffold-executor.md	Emite o esqueleto do crate executor (padrões DRY_RUN + REQUIRE_CONFIRM)
commands/wire-yellowstone.md	Gera o módulo de ingestão gRPC Yellowstone com reconexão/backoff
commands/add-killswitch.md	Insere o RiskGate com limites + disjuntor + kill-switch