😍

Nos últimos anos, o modelo de Rollup-as-a-Service (RaaS) ganhou espaço como resposta pragmática a um problema real do ecossistema blockchain: lançar e operar uma rede própria é caro, complexo e exige um nível de especialização que a maioria das equipes de produto não tem. O RaaS surge, então, como uma abstração conveniente. Ele promete reduzir barreiras técnicas, acelerar o time-to-market e permitir que times foquem no produto, não na infraestrutura.
Esse modelo cumpre bem seu papel inicial. Mas, à medida que aplicações deixam de ser experimentais e passam a sustentar fluxos econômicos reais, surgem limites estruturais que não podem mais ser tratados como detalhes técnicos. É nesse ponto que a discussão deixa de ser “qual stack é mais fácil” e passa a ser sobre soberania, previsibilidade e conectividade de longo prazo.
Este artigo propõe uma análise comparativa sóbria entre o RaaS tradicional e a abordagem da @Tanssi , com foco específico nesses dois eixos. A intenção não é declarar vencedores universais, mas entender por que arquiteturas diferentes produzem resultados diferentes quando confrontadas com casos de uso reais.
O que o RaaS tradicional resolve, e onde começam os atritos
RaaS, em sua forma mais comum, oferece um pacote gerenciado para deploy de rollups. A equipe escolhe um stack conhecido, define alguns parâmetros e herda uma infraestrutura pronta: sequencer, RPC, explorer, bridge padrão, indexação e monitoramento. Para MVPs e aplicações em estágio inicial, isso funciona bem. O custo cognitivo é baixo e a previsibilidade operacional inicial é alta.
O problema surge quando a aplicação cresce e começa a depender de garantias mais fortes. Três atritos aparecem com frequência.
O primeiro é a soberania limitada. Embora o discurso seja de “rede própria”, a realidade é que boa parte das decisões críticas permanece condicionada ao stack subjacente e ao ecossistema de liquidação. Mudanças profundas na lógica de execução, no modelo econômico ou no comportamento da rede tendem a ser difíceis ou inviáveis sem romper compatibilidade.
O segundo atrito é o sequenciamento. Muitos modelos de RaaS dependem, ao menos inicialmente, de um sequencer operado de forma centralizada para garantir desempenho. Isso resolve UX no curto prazo, mas cria dependência operacional e um ponto único de falha que se torna sensível conforme o volume cresce.
O terceiro é a conectividade. Em geral, interoperabilidade e bridges são tratadas como integrações externas. Funciona, mas adiciona camadas de dependência, superfícies de risco e custos operacionais que não desaparecem com o tempo. Apenas se acumulam.
Esses limites não tornam o RaaS “ruim”. Eles apenas delimitam claramente o tipo de aplicação para o qual ele é adequado.
Soberania como variável econômica, não como slogan
Quando falamos em soberania no contexto deste artigo, não estamos falando de independência abstrata, mas de controle efetivo sobre quatro dimensões concretas: execução, economia, previsibilidade e governança.
Controle de execução significa poder definir como a lógica da rede funciona, sem estar restrito a um conjunto fechado de opções. Controle econômico envolve política de taxas, subsídios, incentivos e como o custo é percebido pelo usuário final. Previsibilidade diz respeito a throughput e latência estáveis, independentemente do comportamento de aplicações externas. Governança trata de quem decide mudanças estruturais e em que ritmo.
A abordagem da Tanssi parte da premissa de que, para muitos casos de uso maduros, essas quatro dimensões não podem ser terceirizadas indefinidamente. Por isso, em vez de oferecer apenas rollups configuráveis, a Tanssi foca na viabilização de L1s soberanas, com runtimes modulares que permitem customização profunda da lógica da rede sem exigir que cada equipe construa e opere toda a infraestrutura do zero.
Na prática, isso desloca a soberania do nível do “stack escolhido” para o nível da própria chain. A equipe controla a execução e a economia, enquanto a Tanssi atua como camada de provisionamento, coordenação e confiabilidade operacional.
Infraestrutura gerenciada sem dependência excessiva
Um ponto sensível em qualquer comparação é o trade-off entre descentralização e operacionalidade. A proposta da Tanssi não é exigir que cada projeto monte seu próprio conjunto de operadores, mas também não concentrar funções críticas em um único agente.
Isso aparece, por exemplo, no modelo de sequenciamento. Em vez de depender exclusivamente de um sequencer fixo, a arquitetura prevê conjuntos de sequenciadores atribuídos e rotacionados. O objetivo não é atingir um ideal teórico imediato, mas reduzir riscos operacionais reais sem sacrificar desempenho.
Além disso, a existência de nós dedicados à preservação de dados e leitura histórica reforça a ideia de infraestrutura persistente. Para aplicações que lidam com auditoria, histórico financeiro ou dados regulatórios, isso não é um detalhe técnico, mas um requisito funcional.
Conectividade como parte da arquitetura, não como acessório
Outro ponto de distinção importante está na forma como a conectividade é tratada. No modelo da Tanssi, interoperabilidade não é apenas um conjunto de integrações opcionais, mas um componente estrutural.
Dentro do ecossistema, a comunicação entre redes ocorre de forma nativa, permitindo troca de mensagens e ativos sem depender de soluções externas para cada caso. Para o acesso à liquidez e ativos do Ethereum, a ponte é desenhada com um modelo de confiança minimizada, evitando dependência de custodiantes ou multisigs opacos.
Essa combinação reduz o custo cognitivo e operacional de manter conectividade ao longo do tempo, algo que se torna especialmente relevante quando a aplicação deixa de ser experimental.
Gotas: quando escala de consumidor expõe limites arquiteturais
O caso do Gotas ajuda a ilustrar essas diferenças de forma concreta. A plataforma opera no contexto brasileiro, com forte foco em engajamento de usuários finais e marcas. Seus números são relevantes: centenas de milhares de carteiras, milhões de interações e campanhas em tempo real.

Esse tipo de workload torna inviável depender de blockspace compartilhado imprevisível. Campanhas promocionais, resgates e interações precisam funcionar independentemente de congestionamentos externos. Além disso, a lógica de recompensas exige ajustes frequentes na economia da rede, algo difícil de sustentar em stacks rígidos.
A escolha por uma L1 soberana permitiu o Gotas isolar seu ambiente de execução, controlar custos e reduzir dependência de um sequencer único, mantendo ao mesmo tempo conectividade com outros ecossistemas. Aqui, soberania não aparece como ideologia, mas como consequência direta de exigências operacionais.
Rivool: previsibilidade como requisito, não como bônus
Enquanto o Gotas expõe desafios de escala de consumidor, a Rivool evidencia outro tipo de pressão: previsibilidade em contextos financeiros e produtivos.
A Rivool atua, no seu caso de uso inicial, com crédito agrícola on-chain, conectando produtores a instrumentos financeiros digitais. Nesse cenário, variabilidade de taxas, latência imprevisível ou dependência de decisões externas à rede não são aceitáveis. A lógica de crédito, garantias e prazos exige um ambiente controlado, auditável e estável.

Mais uma vez, a escolha por uma arquitetura soberana não é estética. Ela responde diretamente à necessidade de alinhar infraestrutura blockchain a responsabilidades do mundo real.
Conectando as dores aos desenhos arquiteturais
Ao observar esses casos, fica mais fácil entender onde cada modelo se encaixa.
RaaS tradicional continua sendo uma solução eficiente para aplicações que priorizam velocidade de lançamento e aceitam limitações estruturais em troca de simplicidade. Já a abordagem da Tanssi faz mais sentido quando a aplicação exige controle profundo sobre execução, economia e conectividade, sem abrir mão de uma camada de suporte operacional.
Não se trata de uma evolução linear, mas de escolhas arquiteturais diferentes para estágios e necessidades diferentes.
Considerações finais
O mercado de infraestrutura blockchain está saturado de promessas genéricas. Comparações honestas exigem ir além de slogans e observar como sistemas se comportam quando submetidos a carga real, usuários reais e responsabilidades reais.
Ao posicionar a Tanssi frente ao RaaS tradicional, o ponto central não é afirmar que um modelo substitui o outro, mas mostrar que soberania e conectividade deixam de ser “features avançadas” quando aplicações amadurecem. Elas se tornam condições básicas para que a blockchain deixe de ser apenas uma camada experimental e passe a sustentar economia de verdade.