Ordenar as transações é poder

Todo rollup precisa de alguém — ou algo — que defina a ordem em que as transações são processadas. É exatamente isso que faz o sequencer.

A ordem não é neutra. Quem controla o sequencer pode: extrair MEV (Maximal Extractable Value), inserindo ou reordenando transações em benefício próprio; censurar transações, omitindo aquelas que não quiser processar; e praticar front-running, colocando-se à frente das transações de outros usuários.

Em um sistema descentralizado, nenhuma entidade concentra sozinha esse poder. Em um sistema com sequencer centralizado, ele cabe à equipe que o opera. Os riscos associados a essa concentração são: a censura de transações, os atrasos, a baixa disponibilidade do serviço, o controle sobre a ordem, a extração de MEV e a existência de um ponto único de falha.

Por que muitos rollups começam com um sequencer centralizado

A resposta mais simples: uma arquitetura assim é mais fácil de operar. Na fase inicial, um operador único simplificaria a coordenação, as atualizações e a depuração. Ao mesmo tempo, o modelo concentra o poder e as dependências em uma única entidade.

Um sequencer descentralizado pressupõe um protocolo de consenso entre vários sequencers, mecanismos contra conluio, sistemas de eleição ou rotação de líder e incentivos econômicos sólidos, resistentes a ataques.

Construir todos esses mecanismos antes do lançamento pode exigir um tempo de desenvolvimento consideravelmente maior. Arbitrum, Optimism e Base — três rollups importantes no Ethereum — começaram com um sequencer centralizado e, muitos anos depois, seguem com o seu processo de descentralização. A comparação é puramente contextual: não pressupõe equivalência de arquitetura ou de segurança com a arquitetura descrita para o Bitcoin Hyper.

Segundo a documentação do projeto, analisada no capítulo 34.2 do volume, no lançamento da mainnet o sequencer seria centralizado e operado pela equipe. Na data de referência da análise, o Bitcoin Hyper ainda se encontrava na fase anterior ao lançamento da mainnet: o sequencer único faz parte do modelo de partida previsto, e não de um componente operacional já verificado na prática. O roadmap prevê uma descentralização gradual, ao longo de dois a quatro anos, por meio de mecanismos de rotação, leilão e eleição de líder. É uma intenção declarada, não uma funcionalidade concluída.

Como o risco de censura seria limitado?

O principal mecanismo arquitetural previsto é a inclusão forçada das transações (forced inclusion): uma transação poderia ser “imposta” ao rollup pela camada base do Bitcoin, contornando o sequencer. Se o sequencer censurasse uma transação, o usuário poderia obter o seu processamento pagando as taxas diretamente no Bitcoin. O sequencer único cria um ponto central de controle operacional; o forced inclusion é o mecanismo de segurança previsto para que esse controle não se torne absoluto. Ele deve ser visto como uma função documentada, mas ainda a verificar, e não como uma garantia já disponível.

A ressalva essencial: no Bitcoin Hyper, o forced inclusion ainda está em desenvolvimento (situação em 28 de abril de 2026). A função não estava disponível na devnet. Enquanto não for entregue e testada, a proteção que ela oferece permanece não verificada. Essas informações se referem à documentação disponível naquele momento.

Sinais a acompanhar

Antes de considerar uma posição em Bitcoin Hyper, eis os sinais que indicariam um progresso real na descentralização do sequencer. Na data de referência não existia nenhuma especificação pública suficientemente detalhada do mecanismo final:

Especificações técnicas publicadas para o mecanismo de descentralização escolhido
Forced inclusion funcional na testnet ou na mainnet
Um roadmap com marcos verificáveis (não apenas “nos próximos anos”)
Auditoria do código do sequencer, realizada por empresas independentes reconhecidas
Um cronograma crível, com dependências claramente definidas

Conclusões

Um sequencer centralizado no lançamento pode ser uma escolha pragmática e explicável, e não necessariamente um sinal de alarme. Em si, ele não significa a perda dos fundos, mas pode enfraquecer a disponibilidade do serviço, a ordenação das transações e a resistência à censura. Torna-se um problema quando falta um roadmap concreto para a descentralização, quando o forced inclusion nunca chega a ser implementado ou quando o operador do sequencer usa a sua posição para extrair MEV de forma não transparente.

O projeto afirma que a ordenação das transações será descentralizada em uma etapa posterior. No momento da redação, essa transição continua sendo um objetivo do roadmap, e uma promessa genérica de descentralização não equivale a um roadmap verificável. O sequencer, o bridge, a disponibilidade dos dados e o sistema de provas são camadas distintas: a descentralização do sequencer não eliminaria automaticamente os riscos ligados ao bridge nem os ligados à disponibilidade dos dados. Forced inclusion, forced exit e Escape Hatch devem ser tratados como funções documentadas ou como funções ainda a verificar. Um sequencer único pode ser um ponto de partida pragmático, mas não deveria ser apresentado como ponto de chegada: a avaliação depende das limitações publicadas, dos mecanismos de controle implementados e dos procedimentos alternativos. A credibilidade da descentralização se apoia em marcos verificáveis, não em declarações de intenção.

Um único sequencer no lançamento: risco ou pragmatismo?