Por cinco anos, "insuficiente SOL para transação" tem sido a mensagem de erro mais cara da Solana. Cada aplicativo de consumo que tentou atrair um usuário não familiarizado com cripto perdeu uma porcentagem deles ali mesmo — na etapa de checkout, onde um estranho precisa adquirir um segundo token apenas para gastar o primeiro. Em abril de 2026, a Solana Foundation finalmente lançou a resposta: Kora, um relayer de taxas e nó de assinatura que permite que dApps patrocinem transações nativamente, paguem taxas em qualquer token SPL e terceirizem a assinatura para TEEs ou cofres baseados em KMS. Não é um lançamento chamativo. É uma atualização de infraestrutura básica. E atualizações de infraestrutura são como a Base e a Abstract capturaram silenciosamente os últimos doze meses de integração de usuários.
A questão não é mais se a Solana pode igualar a UX sem gás das cadeias de consumo EVM. O Kora torna essa parte trivial. A questão é se fechar essa lacuna de "última milha" é o suficiente para reconquistar os desenvolvedores que já construíram em outro lugar.
O que o Kora Realmente Entrega
Remova o marketing e o Kora é composto por três coisas unidas: um relayer de transação, um assinante remoto e um mecanismo de política. Um dApp constr ói uma transação, define um nó Kora como o pagador da taxa, o usuário assina o payload a partir de uma carteira incorporada e o operador do Kora assina em conjunto e faz o broadcast. Os validadores ainda são pagos em SOL. O usuário nunca detém nenhum.
O que o torna interessante é a camada de validação. Um nó Kora não repassa cegamente qualquer coisa que os usuários lhe entreguem. Ele realiza três verificações antes de assinar:
- Validação de instruções em relação aos programas Solana associados, para que instruções malformadas ou maliciosas sejam rejeitadas antes de atingirem um líder.
- Adequação de taxas apoiada por oráculos, comparando a quantidade de token SPL oferecida com o preço atual do SOL mais a margem do operador, para que o relayer nunca opere com prejuízo.
- Aplicação de listas de permissão e listas de bloqueio no nível do programa e do token, para que um operador que execute um nó Kora para um único dApp nunca patrocine acidentalmente uma transação visando algum contrato aleatório não auditado.
O caminho de assinatura é onde a arquitetura se torna ambiciosa. O Kora suporta assinatura remota através do Turnkey e AWS KMS nativamente, o que significa que a chave privada que paga as taxas nunca reside no disco do relayer. Para uma fintech construindo na Solana, essa é a diferença entre "nós criamos nosso próprio paymaster e cruzamos os dedos" e "nossa história de custódia de chaves passa por uma auditoria SOC 2".
Tudo foi auditado e testado por fuzzing diferencial pela Runtime Verification, que é o tipo de detalhe que você menciona apenas quando espera que instituições leiam os pormenores.
Por que o "Nativo" Vence o "Contrato Inteligente" Aqui
A tentação é comparar o Kora ao ERC-4337 e assumir que a Solana está se recuperando. As arquiteturas estão fazendo coisas diferentes, e a diferença importa.
O ERC-4337 é a abstração de conta implementada como um sistema paralelo no topo do Ethereum. Ele introduz uma mempool separada, um objeto UserOperation, uma função de bundler e um contrato EntryPoint — nada disso o protocolo base entende nativamente. Os bundlers agrupam as operações do usuário, os paymasters patrocinam as taxas e um contrato on-chain impõe a validação. Ele funciona, e foi implantado na rede principal do Ethereum e em grandes L2s, mas é um projeto de construção de seis anos para adaptar um recurso de UX que o protocolo nunca previu.
O design da Solana absorveu essa complexidade na camada de protocolo anos atrás. Cada transação já possui um campo feePayer. Assinaturas parciais são nativas. Programas podem validar instruções arbitrárias. O Kora não é uma construção de bundler e paymaster; é um operador de nó que preenche o slot feePayer e assina com uma das assinaturas parciais que o protocolo já aceita.
A consequência prática é a latência e a área de superfície do desenvolvedor. As transações ERC-4337 passam por uma mempool separada com suas próprias regras de ordenação e atrasos de propagação. As transações Kora passam pelo mesmo caminho que qualquer outra transação Solana, com a mesma finalidade inferior a 400 ms. Não há mercado de arbitragem de bundlers para se preocupar, nenhuma versão de contrato EntryPoint para rastrear, nenhuma estimativa de gás de UserOperation para depurar.
O que isso oferece aos desenvolvedores da Solana é algo próximo a "defina o campo do pagador de taxas, lance o dApp". O que se perde é parte da opcionalidade que as contas inteligentes EVM obtêm gratuitamente — autenticação de múltiplas chaves, chamadas em lote, políticas de sessão on-chain — embora muito disso esteja sendo construído separadamente na Solana através de PDAs e contas controladas por programas.
A Lacuna de "Última Milha" que a Solana Realmente Tinha
Apesar de toda a conversa sobre o ímpeto dos desenvolvedores da Solana em 2025 e 2026, a camada de carteira de consumo foi a parte que ficou para trás. A pilha de infraestrutura amadureceu rápido: o volume DEX da Pump.fun ultrapassou US$ 2 bilhões no primeiro trimestre de 2026, Jito e Marinade dominam o staking líquido, a Tensor transformou a negociação de NFTs em um terminal profissional. Mas cada um desses produtos teve que lançar sua própria resposta para "o usuário não tem SOL".
As soluções improvisadas tornaram-se criativas. A Pump.fun roteou as aquisições iniciais de tokens através de onramps integrados. A Jito pré-financiou contas de usuários com pequenas quantias (dust). A Tensor apoiou-se na Phantom e na Backpack para lidar com a etapa de aquisição de SOL antes que os usuários chegassem ao livro de ofertas. Cada uma delas funcionou individualmente e nenhuma delas era composta. Um usuário que fizesse o onboarding através do fluxo da Pump.fun não chegava à Tensor com um saldo para pagamento de taxas.
Enquanto isso, a Base lançou o fluxo de passkey da Coinbase Smart Wallet, patrocínio de gás gratuito através da Coinbase Developer Platform e um SDK para desenvolvedores que esconde todo o conceito de uma chave privada por trás do login por e-mail. A Abstract levou a mesma ideia adiante com carteiras incorporadas que parecem aplicativos Web2. A proposta combinada para um desenvolvedor de aplicativos de consumo em 2025 era: construa na Base, seus usuários não saberão que estão on-chain e nós pagaremos as taxas enquanto você escala.
O Kora não replica essa proposta linha por linha. O que ele faz é remover a razão arquitetônica pela qual um dApp Solana não poderia fazer a mesma proposta. Com o Kora, uma equipe Solana pode agora oferecer:
- Cadastro por e-mail ou passkey através de Privy, Turnkey ou Coinbase Embedded Wallets.
- Saldo zero de SOL necessário para transacionar.
- Taxas pagas em USDC, BONK ou no token nativo do dApp, se houver.
- Finalidade abaixo de um segundo sem nenhum bundler no caminho.
As peças já existiam antes. O Octane foi o ancestral de código aberto. Circle's Gas Station, Openfort, Portal, Gelato, Biconomy e meia dúzia de outros fornecedores ofereciam o repasse de taxas como um serviço. O que o Kora muda é que a própria Solana Foundation está agora lançando a implementação de referência padrão, auditada e compatível com KMS. Isso remove a pergunta "em qual paymaster de terceiros confiamos" da árvore de decisão de cada equipe que anteriormente estava criando o seu próprio ou pagando a um fornecedor.
A Camada de Fornecedores Acima da Kora
O ponto onde as coisas ficam interessantes é o que acontece com os fornecedores de carteiras incorporadas (embedded wallets) que já construíram soluções em torno da lacuna que a Kora acaba de fechar.
A Privy, adquirida pela Stripe em junho de 2025, tem sido a carteira de escolha para apps de consumo em dApps da Solana que desejam login por e-mail. A Solana é oficialmente uma rede secundária para a Privy — a profundidade está na EVM — mas o fluxo de carteira incorporada se estende à Solana, e a Privy já suporta a configuração de uma carteira pagadora de taxas (fee payer) que o app gerencia. A Kora não substitui a Privy; ela fornece à Privy um backend padronizado para se conectar, em vez de cada cliente rodar seu próprio serviço de paymaster.
A Turnkey é o signatário incorporado focado em segurança que se combina naturalmente com a API de assinatura remota da Kora. A Turnkey explicitamente não inclui infraestrutura de paymaster, portanto, as equipes da Solana que desejam chaves isoladas por hardware combinadas com uma UX gasless (sem taxas) foram forçadas a unir dois fornecedores. A Kora simplifica essa integração.
A Dynamic, adquirida pela Fireblocks em 2025, traz autenticação multi-chain para equipes institucionais. O posicionamento apoiado pela Fireblocks torna a Dynamic a escolha natural para fintechs que precisam de cobertura tanto para Solana quanto para EVM com conformidade empresarial. A Kora oferece à Dynamic uma narrativa limpa de abstração de taxas na Solana que não exige que a Fireblocks lance um paymaster concorrente.
A Coinbase Developer Platform está em uma posição desconfortável. A Coinbase investiu pesadamente em tornar a Base a rede de consumo padrão por meio da Coinbase Smart Wallet, taxas gratuitas na Base e o SDK de carteira incorporada. A Kora reduz a diferenciação que a Base vem vendendo, especialmente para apps que desejam fluxos nativos de USDC, onde a Solana já possui vantagens de escala.
O resultado provável é que a Kora se torne o backend padrão da Solana para todos os fornecedores de carteiras incorporadas que não quiseram operar um serviço de paymaster por conta própria. Os fornecedores competem na UX de autenticação, gerenciamento de chaves e controles de política. A Kora cuida do relay de taxas por baixo. Isso é mais saudável para o ecossistema do que o estado anterior, onde cada dApp de consumo na Solana tomava uma decisão de fornecedor independente e tinha que avaliar a segurança do relayer próprio de cada candidato.
O Que Isso Resolve e O Que Não Resolve
A Kora fecha uma lacuna definitivamente e deixa várias outras abertas. Vale a pena ser preciso sobre o que é o quê.
O que a Kora resolve:
- O abismo de UX de que o "usuário deve possuir SOL" para qualquer dApp disposto a subsidiar taxas em outro token.
- A decisão de "construir vs comprar um paymaster" para equipes que anteriormente tinham que escolher entre carga operacional e dependência de fornecedor (vendor lock-in).
- A lacuna de aceitabilidade institucional, já que a auditoria e o suporte a KMS permitem que entidades regulamentadas operem nós da Kora sem criar os seus próprios.
O que a Kora não resolve:
- A aquisição de carteira em si — os usuários ainda precisam de uma carteira incorporada de algum lugar, seja Phantom, Privy, Turnkey ou Coinbase.
- Primitivas de abstração de conta, como chamadas em lote (batched calls) e chaves de sessão, que ainda estão sendo montadas separadamente na Solana através de PDAs e outros padrões de nível de programa.
- A questão econômica de quem paga pelo SOL que os operadores da Kora adiantam. Para um dApp com receita de token ou uma reserva de stablecoin, isso é aceitável; para um produto gratuito, o patrocínio de taxas é apenas um custo de aquisição de cliente.
- A UX cross-chain, que ainda exige que o usuário interaja com uma ponte ou uma camada de abstração de rede como LayerZero, Wormhole ou Across.
A tese da "infraestrutura gasless como primitiva de protocolo" corta para os dois lados. A Solana agora tem a história de abstração de taxas nativa mais limpa de qualquer grande rede. Isso também significa que a diferenciação sobe na pilha para a UX da carteira, fluxos de recuperação e recursos de abstração de conta, onde a EVM tem uma vantagem de vários anos.
A Leitura Estratégica para Construtores
Para uma equipe escolhendo uma rede em meados de 2026, o cálculo mudou. Doze meses atrás, a resposta para o onboarding de consumidores era Base, Abstract ou uma das novas redes de consumo EVM, ponto final. A Solana tinha a atenção dos desenvolvedores e ímpeto de infraestrutura, mas perdia usuários de varejo para a etapa de aquisição de SOL. Isso não é mais verdade.
Um dApp de consumo lançado hoje na Solana com Privy ou Turnkey no front-end e Kora no back-end tem funcionalmente a mesma superfície de UX que o stack equivalente na Base. Login por e-mail, transações sem taxas, pagamento de taxas em USDC, finalidade abaixo de um segundo. As diferenças restantes são o modelo de runtime, o ecossistema de ferramentas e a liquidez disponível. Para um app que deseja o throughput da Solana e a profundidade das DEXs, o argumento de UX para escolher EVM tornou-se substancialmente mais fraco.
Para equipes que já estão operando na Base, a Kora não muda a decisão imediata. Ela muda a pressão competitiva de longo prazo. Se os dApps de consumo com a UX mais limpa começarem a aparecer na Solana porque a nova infraestrutura é uma integração a menos com que se preocupar, a gravidade em torno do fosso de onboarding de consumidores da Base começa a mudar.
A leitura honesta é que a Kora é necessária, mas não suficiente. Ela remove um motivo específico pelo qual os desenvolvedores não estavam escolhendo a Solana para apps de consumo. Ela não cria, por si só, um novo motivo para escolher a Solana. Os próximos dois trimestres mostrarão se os fornecedores de carteiras incorporadas realmente adotarão a Kora por padrão, se novos dApps de consumo a citarão como um motivo para sua escolha de rede e se as redes de consumo EVM existentes responderão melhorando suas próprias histórias de infraestrutura.
De qualquer forma, "o usuário deve adquirir SOL antes de transacionar" é finalmente um problema do passado, não um problema atual. Só isso já vale o lançamento.
BlockEden.xyz opera infraestrutura RPC da Solana de nível de produção para equipes que constroem dApps de consumo, trilhos de pagamento e sistemas de negociação. Se você está integrando fluxos sem taxas ou escalando um produto na Solana, explore nosso marketplace de APIs para endpoints de baixa latência projetados para a próxima geração de cripto para consumidores.
Fontes
