Toda fintech eventualmente chega à mesma encruzilhada: você constrói em cima da infraestrutura bancária existente ou constrói algo novo no lugar dela?

Nós escolhemos a segunda opção. E escolhemos Cardano.

Este post é a história técnica sem filtro do porquê — não o pitch de marketing, não o discurso maximalista de blockchain, mas o raciocínio real de engenharia que levou um time de construtores de sistemas a apostar em uma blockchain baseada em UTXO como fundação para uma instituição financeira.

O problema com a infraestrutura bancária que você conhece

Se você já trabalhou dentro do core system de um banco — seja FIS, Temenos, Mambu ou qualquer um dos dezenas de provedores "modernos" de core-as-a-service — você conhece o modelo de dados fundamental: livros-razão de partida dobrada armazenados em bancos de dados relacionais, enredados em processos de reconciliação em lote, envoltos por camadas de middleware de compliance.

Funciona. Vem funcionando desde os anos 1970. Mas foi projetado para responder bem a uma única pergunta: o que aconteceu?

Toda a arquitetura é otimizada para registrar fatos históricos. Um débito aqui, um crédito ali, timestamps, referências, reconciliação periódica para garantir que os livros batem. Todo core bancário moderno é, na sua essência, um diário — um log append-only de coisas que já aconteceram.

O problema aparece no momento em que você tenta responder a uma pergunta diferente: o que deveria acontecer a seguir?

Quando um cliente faz um Pix, o core registra o débito imediatamente. Mas o fluxo real é um processo com múltiplas etapas e múltiplas partes envolvendo o banco do remetente, o SPI do Banco Central e a instituição do destinatário — com janelas de liquidação, possibilidade de devolução e momentos em que o dinheiro está em trânsito entre instituições. Durante esse tempo, o saldo do cliente mostra uma dedução por uma transação que, do ponto de vista do core, não possui conceito nativo de "este valor está comprometido mas não resolvido". Ele simplesmente finge que o dinheiro já foi.

Essa lacuna — entre registrar uma intenção e garantir sua resolução — é onde vive toda a complexidade do sistema bancário moderno. Lançamentos provisórios. Transações pendentes. Bloqueios de autorização. Créditos provisórios. Isso não são funcionalidades. São remendos sobre uma arquitetura que não consegue expressar o conceito de valor em trânsito.

E piora no momento em que você tenta construir qualquer coisa que envolva coordenação entre múltiplas partes. Pagamentos em grupo onde cinco pessoas juntam dinheiro antes de um único comerciante ser pago. Assinaturas compartilhadas com ciclos automáticos de cobrança. Trocas entre pares com garantias similares a escrow. Nada disso se encaixa de forma limpa em um livro-razão de partida dobrada tradicional. Você acaba empilhando camadas de orquestração — filas, cron jobs, lógica de retry, scripts de reconciliação que rodam às 2h da manhã e acordam alguém quando os números não batem. O core se torna uma caixa-preta que sua camada de aplicação precisa driblar constantemente.

Sabíamos desde o primeiro dia que a Sona precisaria de coordenação financeira multipartidária como uma primitiva de primeira classe. Não como uma funcionalidade que adicionaríamos depois, mas como a operação fundamental sobre a qual todo o sistema seria construído.

O que realmente precisávamos

Precisávamos de um ledger que pudesse fazer três coisas que o modelo tradicional não consegue:

Representar valor sob restrições, não apenas valor em repouso. Quando um cliente envia dinheiro, não queremos "deduzir o valor e esperar que dê certo". Queremos bloquear o valor sob uma restrição que diz: este valor está comprometido com um resultado específico, e não pode ser gasto, contado duas vezes ou perdido enquanto esse resultado está pendente. Seja esse resultado uma transferência bilateral simples, um pagamento em grupo de cinco partes ou uma liberação condicional de escrow, a restrição deve ser expressa na camada de dados — não imposta por verificações na camada de aplicação que poderiam ser contornadas por um bug na nossa API.

Impor transições de estado, não apenas registrá-las. Quando uma obrigação se move de OPEN para PENDING para SETTLED, essas transições não deveriam ser violações de política que você detecta depois do fato em uma rodada de reconciliação. Deveriam ser invariantes impostas na camada de infraestrutura. Uma obrigação SETTLED não pode reverter para PENDING. Uma posição consumida não pode ser gasta novamente. Essas não são regras de negócio coladas por cima — são propriedades do modelo de dados em si.

Fornecer auditabilidade criptográfica sem um sistema de auditoria separado. Cores tradicionais geram logs de auditoria como efeito colateral. Esses logs podem ser adulterados, podem divergir da realidade, podem ser incompletos. Queríamos uma arquitetura onde o ledger é a trilha de auditoria — onde cada transição de estado carrega sua própria prova.

Por que não construir um ledger customizado?

Consideramos isso. Passamos semanas desenhando como seria um ledger baseado em intenções se o construíssemos do zero em cima de um banco de dados relacional. A máquina de estados era elegante. Intenção flui para Cumprimento ou Exceção. Cada transição de estado é auditável. Cada movimentação de dinheiro é explícita.

Mas então tivemos que responder às perguntas difíceis. Como garantimos que uma liquidação é atômica — que ou todos os cinco participantes de um pagamento em grupo recebem seu troco de volta, ou nenhum deles recebe? Como provamos para um regulador que os fundos em um pool nunca foram gastos duas vezes? Como damos aos usuários prova criptográfica de que sua contribuição foi tratada corretamente?

Construir tudo isso em cima do PostgreSQL é possível. Pessoas fazem isso. Mas você está essencialmente reconstruindo consenso, garantias de atomicidade e auditabilidade do zero. Você está escrevendo suas próprias primitivas de sistemas distribuídos e torcendo para que sua bateria de testes capture os edge cases que importam às 3h da manhã de um sábado.

Escolhemos o problema difícil com uma solução provavelmente correta, em vez daquele com uma solução apenas aproximadamente correta. Para uma empresa cuja proposta de valor inteira é "seu dinheiro é tratado corretamente, sempre", essa pareceu a única escolha honesta.

Por que UTXO, especificamente

Se você só trabalhou com modelos de contas estilo Ethereum, o modelo UTXO pode parecer alienígena. Mas para infraestrutura financeira, é um encaixe natural — indiscutivelmente mais natural que contas.

Em um modelo baseado em contas, você tem estado global mutável. A Conta A tem saldo X. Você atualiza. Agora tem saldo Y. Se duas transações tentam atualizar a mesma conta simultaneamente, você precisa de locking, ordenação, resolução de conflitos — todas as dores de cabeça familiares de sistemas distribuídos.

Em um modelo UTXO, o valor não vive em um saldo de conta. Ele vive em outputs discretos e imutáveis. Cada output tem um valor específico, um proprietário específico e condições de gasto específicas. Para "transferir dinheiro", você consome um ou mais outputs e produz novos. Os outputs antigos deixam de existir. Os novos outputs passam a existir com suas próprias restrições.

Isso reflete diretamente como o valor se move no sistema financeiro — e se encaixa quase perfeitamente no nosso modelo financeiro baseado em intenções:

O sistema bancário tradicional simula tudo isso com lançamentos contábeis, verificações de saldo e reconciliação. UTXO te dá isso de graça na camada do modelo de dados.

Insight técnico

Isso não é "blockchain por blockchain". É usar um modelo computacional específico porque ele codifica diretamente as garantias que nosso produto exige.

Por que Cardano, e não {outra chain}

Avaliamos múltiplas chains. A decisão se resumiu a três fatores.

Extended UTXO com inline datums

O modelo Extended UTXO (eUTXO) da Cardano permite anexar dados estruturados arbitrários — chamados datums — diretamente aos outputs. Isso é crítico para infraestrutura financeira. Significa que podemos codificar semânticas de propriedade, estados de obrigação e parâmetros de restrição como dados estruturados anexados ao próprio output, em vez de depender de endereços de conta ou estado externo.

Isso nos dá a separação de mecanismo e política que você quer em infraestrutura financeira: lógica de execução uniforme com semânticas de propriedade e restrição expressivas e orientadas por dados.

Validators como predicados de gasto

Cardano nos permite escrever validators que impõem condições de gasto — funções puras que, dado o estado atual (os UTXOs sendo consumidos) e o novo estado proposto (os UTXOs sendo produzidos), retornam verdadeiro ou falso.

A distinção em relação aos smart contracts estilo Ethereum importa. Não queremos lógica autônoma on-chain tomando decisões financeiras. Queremos restrições on-chain que garantam que decisões off-chain sejam executadas corretamente. O validator diz "este valor só pode se mover se as condições corretas forem atendidas e os outputs rotearem corretamente." A decisão sobre para onde mover o valor é tomada off-chain, nos nossos serviços, com contexto completo de negócio.

Para um pagamento em grupo, isso significa que a chain em si se recusa a processar uma transação onde a soma das contribuições não corresponde ao valor do pagamento, onde fundos vazam ou onde participantes não autorizaram a operação. Essas não são verificações na camada de aplicação. São regras no nível de consenso. Não registramos que um pagamento em grupo foi liquidado corretamente e torcemos para que nossa reconciliação concorde. Tornamos estruturalmente impossível que um pagamento em grupo seja liquidado incorretamente.

É isso que queremos dizer com "infraestrutura que garante o futuro".

Hydra para throughput

Aqui as coisas ficam práticas. A L1 da Cardano tem tempos de bloco e características de throughput projetadas para consenso global, não para operar um ledger institucional em tempo real. Precisávamos de algo mais rápido.

Hydra é um protocolo de state channel isomórfico — o formato de transação dentro do canal é idêntico à L1. Mesmo modelo UTXO, mesmos validators, mesmas regras de gasto. Mas ao invés de esperar por consenso global, transações confirmam quando todos os participantes do canal concordam com um snapshot.

Para o nosso caso de uso — uma única instituição operando seu próprio ledger — isso é ideal. Executamos um Hydra head com nossos serviços como participantes. Transações confirmam em tempo sub-segundo. Todo o stack de validação roda dentro do head. E quando precisamos de finalidade de liquidação na L1, o estado do head pode ser commitado na mainchain.

Não estamos usando Hydra como uma "solução de escalabilidade" genérica. Estamos usando como um ambiente de execução de alto throughput que herda as semânticas UTXO e as garantias dos validators da Cardano. O fato de também fornecer privacidade off-chain e confirmação quase instantânea é um bônus.

A arquitetura na prática

Nosso app móvel não fala com a blockchain diretamente. Isso seria impraticável tanto do ponto de vista de UX quanto de segurança. A arquitetura separa responsabilidades de forma clara:

O app gerencia a experiência do usuário e o estado local. Nossa camada de API cuida de autenticação, autorização e coordenação off-chain — coletando contribuições, negociando divisões, mostrando status em tempo real. Um motor de intenções traduz intenções financeiras de alto nível em transações de liquidação. E a camada blockchain fornece execução atômica, determinística e verificável.

A maior parte da complexidade voltada ao usuário acontece off-chain. A camada de liquidação só entra em cena no momento da execução, quando precisamos das garantias que importam: atomicidade, determinismo e verificabilidade.

O resultado é um sistema onde uma transferência produz outputs UTXO bloqueados sob as credenciais do destinatário; onde obrigações transitam por estados explícitos com cada transição imposta na camada de infraestrutura; onde a liquidação acontece quando evidência externa é casada com uma obrigação pendente, disparando uma transação subsequente que movimenta o valor corretamente; e onde o estado inteiro do ledger pode ser reconstruído a partir do seu histórico de transações. Não existe uma "fonte da verdade" separada — o conjunto UTXO é a verdade.

E quanto a custo e velocidade?

Uma pergunta comum quando as pessoas ouvem "blockchain" no contexto de bancos: e as taxas e a latência?

A resposta é simples: todas as nossas transações são liquidadas dentro do nosso Hydra head, não na mainchain L1 da Cardano. Usamos o modelo eUTXO e as semânticas de validação da Cardano como nosso framework de contabilidade e execução — mas não estamos pagando por consenso global em cada transferência. A liquidação é interna, sub-segundo, e com custo zero de transação para o usuário final.

Essa é uma distinção importante. Não estamos roteando pagamentos de clientes por uma blockchain pública e absorvendo taxas de gas. Operamos o Hydra head como nosso próprio ambiente de execução, herdando o modelo computacional da Cardano e suas garantias sem herdar as restrições de throughput ou a estrutura de taxas da L1. O usuário nunca interage com uma blockchain. Ele interage com um produto bancário que é construído sobre infraestrutura criptograficamente sólida.

O ângulo regulatório

Operamos como Instituição de Pagamento parceiras no Brasil e em breve teremos a nossa própria licença de operação. Nossos recursos são mantidos em contas de salvaguarda segregadas. Cada Real que transita pela Sona deve ser contabilizado com total auditabilidade.

Nossa arquitetura nos dá uma trilha de auditoria imutável e verificável por terceiros para cada operação financeira coordenada. Quando um regulador pergunta "prove que este pagamento em grupo foi liquidado corretamente", não entregamos um export de banco de dados e pedimos que confiem na nossa lógica de aplicação. Entregamos um hash de transação e um script de validação. A prova é matemática, não processual.

Esse não é um benefício teórico. A regulação financeira brasileira está evoluindo rapidamente, e as instituições que conseguirem demonstrar corretude comprovável — não apenas checklists de compliance — terão uma vantagem estrutural.

O que abrimos mão

Seríamos desonestos se não reconhecêssemos os tradeoffs.

Abrimos mão do ecossistema de middleware bancário tradicional. Não existe módulo de PLD/FT pronto que se conecte à nossa camada de liquidação. Não existe integração pronta que fale eUTXO. Cada ponto de integração com o mundo bancário tradicional é uma ponte que temos que construir nós mesmos.

Abrimos mão da familiaridade do desenvolvedor. O ecossistema de smart contracts usa paradigmas de programação funcional. A lacuna de modelo mental entre um endpoint de API típico e a construção de uma transação com inline datums e redeemers criptográficos é real. Investimos pesadamente em camadas de abstração que permitem que a maior parte do nosso time trabalhe em território familiar enquanto um grupo menor gerencia o código específico da chain. Dito isso, a lacuna está diminuindo mais rápido do que a maioria imagina — assistentes de código baseados em IA tornaram linguagens funcionais como Haskell dramaticamente mais acessíveis do que eram há dois anos, e a barreira de entrada para novos membros do time está mais baixa do que nunca.

Assumimos o risco de infraestrutura nascente. Hydra é production-grade, mas jovem. Quando nos deparamos com edge cases, frequentemente somos o primeiro time a enfrentá-los. Esse é o preço de construir na fronteira.

Aceitamos o gerenciamento de chaves criptográficas como uma preocupação de primeira classe. Em um core tradicional, identidade é uma linha no banco de dados. No nosso sistema, cada conta é respaldada por material criptográfico de chaves, e a segurança de todo o sistema depende de geração adequada de chaves, criptografia em repouso e controle de acesso. É um problema mais difícil que hashing de senhas. Mas também é o mais correto.

Tamanho do ecossistema de desenvolvedores. A comunidade de desenvolvedores da Cardano é menor que a do Ethereum. O ferramental de smart contracts tem uma curva de aprendizado mais íngreme que Solidity. Encontrar engenheiros que entendam tanto sistemas financeiros quanto desenvolvimento de smart contracts funcionais é difícil.

Mas a alternativa — construir garantias de liquidação atômica multipartidária em cima de um banco de dados tradicional — é mais difícil. É apenas um tipo diferente de difícil. É o tipo onde você acha que terminou, e então um edge case na sua lógica de reconciliação custa dinheiro para alguém, e você passa uma semana escrevendo um post-mortem sobre como sua liquidação "atômica" acabou não sendo atômica afinal.

A aposta

A aposta que estamos fazendo é que a infraestrutura financeira será reconstruída sobre primitivas criptográficas — não porque "blockchain" é um buzzword, mas porque as propriedades de sistemas baseados em UTXO (execução determinística, prevenção estrutural de gasto duplo, propriedade criptográfica, auditabilidade nativa) são exatamente o que você projetaria se estivesse construindo um ledger financeiro do zero hoje.

Não escolhemos Cardano porque somos entusiastas de cripto. Escolhemos porque somos engenheiros que passaram anos lutando com as limitações dos cores financeiros tradicionais, e quando avaliamos o espaço de design, o modelo eUTXO com validators e state channels isomórficos era a coisa mais próxima que encontramos do ledger que realmente queríamos construir.

Cores tradicionais registram o que aconteceu. Nós estamos construindo infraestrutura que garante o que deveria acontecer. Essa é a diferença, e é por isso que estamos aqui.