Eu comecei a fazer staking de RLS desde a fase de compromisso prévio; ler o blog oficial já virou um hábito. No dia 12 de setembro, o artigo sobre auditabilidade trouxe, na segunda metade, seis padrões: a ideia é que a matemática satisfaz tudo por construção. Eu concordo com isso, mas “satisfazer por construção” é uma afirmação verificável — não algo que se deve apenas acreditar. Então eu levei uma semana para procurar, item por item, as evidências correspondentes nos códigos-fonte públicos, na documentação técnica e nas interfaces on-chain. Agora estou compartilhando com vocês.
Primeiro, vamos falar de sua classificação; eu acho que isso é mais útil do que a maioria das discussões do tipo “privacidade ainda é transparência”. Para auditabilidade, existem três caminhos: coerção matemática, em que as garantias ficam embutidas na construção criptográfica; confiança em hardware, baseada na integridade de ambientes de execução confiáveis; e controle de acesso por política, em que quem consegue ver o quê é determinado pela configuração do operador de rede.
Com base nisso, ela propõe seis critérios de auditabilidade em nível institucional e, em seguida, afirma que a matemática força a satisfação de todos os seis por construção.
Para não ficar só em teoria, eu fixo um cenário: um banco participa de um piloto de moeda digital do banco central; o auditor do banco central quer ver as transações desse banco na rede. O Drex do Brasil é esse cenário, e a Rayls está fazendo piloto nele. Há apenas uma pergunta: com que base o que o auditor vê é confiável?
Esta primeira com a segunda: divulgação seletiva e delimitação de escopo.
O ponto de chegada dessas duas regras é a mesma coisa: a chave de observação.
O GitHub da Rayls é público. No repositório do relayer, dentro do diretório cryptography, há um arquivo mlkem.go. Nele, GenerateSalt usa o encapsulamento da chave pública de observação ML-KEM-768 do destinatário para compartilhar a chave; RecoverSalt usa a chave privada de observação local ML-KEM-768 para desfazer o encapsulamento. Ele chama NewEncapsulationKey768 e NewDecapsulationKey768 da biblioteca padrão do Go. Os nomes das variáveis já são “view public key” e “view secret key”.
Portanto, a base criptográfica da chave de observação é ML-KEM-768 — e esta parte tem lastro/documentação.
Só mais uma coisa sobre o significado disso. Em 30 de agosto, aquele artigo da Rayls sobre preparação quântica destacou especificamente: uma afirmação de segurança quântica, se não escrever parâmetros em nível de detalhe, não é um argumento, é apenas um rótulo; e os exemplos citados exatamente não são a mesma coisa: ML-KEM-512 e ML-KEM-1024. No trecho sobre a própria atualização, só escreveram “substituído por ML-KEM”. No código está escrito: 768. Isso não é uma falha; 768 é o parâmetro formal do NIST e também é o valor padrão recomendado na indústria para deploys corporativos. Ele é apenas um fato que antes exigia ler o código para descobrir, mas agora pode ser citado diretamente.
Já que os níveis estão definidos, o custo de trocar de nível pode ser calculado. A FIPS 203 fixa o tamanho: a chave pública de encapsulamento de 768 tem 1184 bytes, o ciphertext de 1088 tem 1088 bytes; e 1024 em ambos tem 1568 bytes.
O ponto-chave é a frequência. E a documentação de gerenciamento de chaves também diz isso: o encapsulamento é feito uma vez para cada par de participantes quando a rede é construída; o ciphertext fica no hub de rede privada; depois, cada mensagem traz apenas uma etiqueta pequena. Por isso não cresce com o volume de transações. Uma rede com 30 instituições tem 435 pares; a diferença entre duas camadas é cerca de 215 KB. Mesmo que sejam 60 instituições e 1770 pares, a diferença fica abaixo de 1 MB — e ainda é uma vez só.
Este valor é tão pequeno que não significa nada — e é justamente aí que está a conclusão: se algum deployment precisa de um nível mais alto, a resistência não vem de largura de banda ou armazenamento, e sim de ser uma mudança de código. Na discussão genérica de migração pós-quântica, a seleção de parâmetros costuma ser trade-off de performance — mas nessa camada não é.
A restrição desta vez é exclusiva: a documentação técnica adiciona a outra metade. A capacidade de observação pode ser delimitada por janela de tempo e por conta.
Terceira regra: separação entre visibilidade e permissões.
A formulação do documento técnico é mais dura do que a do blog: a chave de despesa e a chave de observação são independentes matematicamente e não se consegue derivar uma a partir da outra. Na síntese de auditoria de segurança, aquela frase é ainda mais direta: as permissões de observação e as de despesa são separadas pela criptografia, não por configuração; então um erro de configuração não transforma permissão de leitura em permissão de escrita.
A documentação de gerenciamento de chaves também corrigiu uma suposição que eu fiz. Todo o material de chaves do lado da instituição é processado de forma unificada por um componente chamado Cryptographic Trust Suite, rodando dentro do próprio perímetro da instituição. O Relayer nunca detém nenhuma chave; apenas executa as operações de criptografia e descriptografia por solicitação. A permissão de leitura do auditor vem de: cada instituição criptografa sua própria chave de observação com a chave pública do operador e armazena, junto com um código de autenticação, no hub de rede privada como parte do registro da parte envolvida; o serviço de auditoria recupera isso na inicialização.
Aqui há um subproduto/documento que ele mesmo deixa explícito: as instituições conseguem ver no hub quais participantes existem registrados — portanto, também sabem quais coisas foram configuradas para serem legíveis. A própria concessão de visibilidade é visível.
A propósito, essas três tabelas de chaves desta página também confirmam o que eu vi no código: chaves de assinatura em ECDSA sobre secp256k1; chaves de observação em ML-KEM; chaves de pagamento com Baby JubJub sobre BN254. Documentação e código-fonte batem perfeitamente.
A quarta regra: verificabilidade de correção.
Este post de blog se baseia em provas de conhecimento zero; a Rayls tem um serviço dedicado gnark-api para gerar e verificar provas Groth16.
A documentação da transação Enygma trouxe alguns parâmetros específicos que normalmente ninguém cita. O tamanho do conjunto anônimo é 2 ou 6; ou seja, cada transferência é agrupada com outra (ou cinco) transferências, e um observador não consegue distinguir quem iniciou. Um crossTransfer aponta no máximo para 5 cadeias de destino e carrega até 5 ações invocáveis. A atomicidade do lote é garantida pelo contrato Enygma no hub de rede privada: ele primeiro valida a prova de todo o lote; só então qualquer destino emite/“cunha” tokens.
Há ainda um custo operacional. A documentação é bem direta: somando processamento em lote, geração de provas e validação no hub, dá algo na ordem de dezenas de segundos. Então tem que planejar por isso, e não por aquele tipo de finalização no nível de microssegundos dentro da organização. Verificabilidade de correção não é gratuita; seu preço é exatamente essas dezenas de segundos.
Mas há um ponto de redação que vale destacar separadamente, porque ele envolve quatro fontes.
O documento técnico diz que o compromisso Pedersen “esconde um valor e, ao mesmo tempo, liga o comprometedor a esse valor, de modo que ele não possa ser alterado posteriormente”. Tratar a vinculatividade como uma propriedade de validação é uma formulação. O artigo quântico de agosto marca essa parte como “não precisa de tratamento”, ou seja, já é resistente a quânticos. O enygma_math.go no código mostra que ele usa dois geradores independentes na curva BabyJubJub, calculando v·G + r·H — que é a construção padrão e correta do Pedersen. E os dois artigos acadêmicos da Rayls, IACR 2025/1639 e 2025/1638, descrevem a palavra usada para o design inteiro como “quantum-private”, isto é, privacidade quântica. A explicação é que um adversário quântico não consegue inferir o pagador, o recebedor e o valor das transações. Isso é uma afirmação puramente sobre confidencialidade.
Minha leitura é que, entre as quatro fontes, apenas o artigo usa termos com precisão. BabyJubJub é construído sobre o domínio escalar do BN254, então a ocultação vale para adversários quânticos — exatamente a parte que o artigo defende. A vinculatividade depende de logaritmo discreto — e essa é justamente a parte que o artigo não está defendendo.
Para uma instituição que precisa provar um cenário de conformidade que resista a auditoria adversarial, “um adversário quântico não consegue ver meu saldo” e “um adversário quântico não consegue falsificar um saldo falso” são coisas diferentes — mas isso foi escrito como se fosse uma só na documentação e no blog. O artigo não comete essa fusão.
Quinta regra: revogabilidade.
Eu procurei por isso por muito tempo. A documentação da Rayls tem uma página chamada “Opções de design de rede privada”, e foi nela que eu encontrei a resposta. Mas não é exatamente o mesmo assunto que o blog diz, e ainda acho que é mais interessante.
O auditor é um papel designado pelo operador; paralelo a ele existem as partes envolvidas e o emissor. O ponto-chave é que a visibilidade do auditor não é um interruptor, mas sim um nível; este documento usa três exemplos para desenhar esses níveis.
Na camada de CBDC (rede de moeda digital do banco central), o auditor pode descriptografar transações entre nós. Na camada de plataforma de negociação de ativos tokenizados, o auditor monitora validando os compromissos de Pedersen publicados de cada nó para o hub; a documentação diz explicitamente que o auditor não tem permissão de acesso direto aos dados do payload criptografado de transações — ele só vê as provas, não o conteúdo. No nível mais extremo, a camada do mercado de NFTs operado por DAO: o papel de auditor é desempenhado por um verificador de provas da blockchain pública; por padrão, sem acesso, e só quando a validação de provas indica fraude é que a descriptografia daquela transação é habilitada.
As três camadas ficam lado a lado; aquela frase sobre o navegador do auditor — “o nível de descriptografia pode ser configurado na fase de implantação” — se concretiza.
Voltando àquela linha do blog. O blog diz que a visibilidade pode ser recolhida/retirada, e que a retirada é forçada pela criptografia. Mas a documentação apresenta um design diferente: a visibilidade é configurada por nível quando a rede é construída, não é algo retirado depois. Ambos limitam o auditor: um é uma restrição prévia; o outro é a revogação posterior.
De fato, existem meios de revogar na camada de governança: papéis podem ser atualizados; o estado dos membros pode ser ativo, congelado ou desativado; o congelamento é executado pelo operador via o contrato de governança ParticipantStorage. Mas quanto a retirar a visibilidade que um auditor já obteve, não encontrei uma descrição de como implementar isso. Há um detalhe que torna esse problema bem específico: a documentação diz que o auditor recebe uma troca de chaves Diffie-Hellman sempre que um novo nó entra, e a capacidade de acesso é entregue na forma de material de chave. Revogar o papel pode impedir futuras concessões; mas fazer com que o material de chaves já entregue se torne inválido — ainda estou estudando se isso é possível.
A sexta regra: persistência.
Esta aqui é o contrário da quinta: o blog se colocou em menor evidência — dizendo que estava menos do que de fato está.
Ele diz que persistência pertence ao gerenciamento de chaves e que isso pode ser resolvido — lendo parece um espaço em branco. Mas a documentação de gerenciamento de chaves já transformou esse “pode ser resolvido” em um esquema concreto. O armazenamento de chaves é plugável no que a instituição já tem: AWS KMS, Google Cloud KMS, Azure Key Vault, HSM local; ambientes de desenvolvimento usam arquivos locais. A criptografia segue o modelo de envelope criptográfico estático; o que fica persistido é o ciphertext, não o material da chave.
O mais crucial é essa frase. Como cada operação de criptografia/descriptografia passa pelos serviços de gerenciamento de chaves próprios da instituição, as trilhas de auditoria que esses serviços já geram naturalmente já existem. Cobrir as operações de chave da Rayls é como cobrir qualquer outra coisa que a instituição faça por conta própria. A conclusão para o departamento de conformidade dada na documentação é: não precisa criar um novo plano/área de auditoria para isso. Isso é exatamente o que a persistência quer: a trilha de auditoria fica no próprio sistema da instituição, não em logs proprietários de algum fornecedor.
A rotação também está escrita bem em detalhes: cada cadeia pode ter várias chaves de assinatura; elas são rotacionadas conforme o uso; cada chave controla um nonce individual. A chave assinada para transações pendentes permanece válida até que essas transações sejam liquidadas. Isso resolve exatamente a lacuna mais fácil de dar errado durante a rotação.
Mas há uma fronteira: a seção que descreve rotação fala de chaves de assinatura; eu não vi rotação de chaves de observação nessas páginas. E persistência é justamente o que importa quando, muitos anos depois, a trilha de auditoria ainda consegue ser lida — o que depende ainda mais do lado das chaves de observação.
A ferramenta que o auditor realmente usa.
Antes eu estava lendo criptografia, mas o auditor de fato senta e usa uma ferramenta. A documentação deixa claro que o navegador do auditor da rede privada pode ser acessado apenas pelo auditor; operador e outros participantes não têm acesso. Ele fornece uma visualização retrospectiva (after-the-fact) descriptografada de transações cross-chain.
Delimitação limitada: cobre apenas transações cross-chain registradas no hub de rede privada; transações que ocorram dentro do próprio ledger Sovereign de alguma instituição não podem ser acessadas pelo auditor. Portanto, a visibilidade auditável é entre instituições, não dentro da instituição.
Então existe um exemplo que dá para verificar completamente?
Sim — e só existe um caso, porque a própria arquitetura determina que a maior parte das coisas não pode ser vista.
A documentação oficial explica o motivo: transações Enygma saem dos próprios ledgers Sovereign de cada instituição. Cada instituição implanta um navegador para monitorar aquela sua própria blockchain; a parte cross-chain é deixada no hub de rede privada e é visualizada pelo navegador do auditor. As atividades das instituições, por design, não ficam na blockchain pública, então não há como encontrar transações Enygma no navegador público: não é uma omissão; é o resultado inevitável de uma arquitetura em três camadas.
Mas o contrato de lock da Parfin está na chain pública, e ele é exatamente um exemplo completo do que chamam de “matemática forçando”.
Aquele que começa com o endereço 0x1463889D; o nome do contrato é RlsTokenLock. O código-fonte foi verificado e não é um contrato proxy. Isso significa que é um dos poucos objetos que dá para ler o código e também checar o estado atual. Eu fiz o confronto dos dois lados.
O construtor declara que totalAmount é 1.070.493.535 RLS. O RLS que o contrato efetivamente mantém agora é 1.070.493.535. Um wei a menos, completamente em dia.
A programação de desbloqueio vale ainda mais ser destacada. No construtor há 48 timestamps; eu decodifiquei todos: o primeiro nível é 1º de dezembro de 2027; depois, um por mês no dia 1º; o último nível é 1º de novembro de 2031. O intervalo é de cerca de 3,92 anos; cada nível é por volta de 22,3 milhões de RLS. Materiais divulgados antes destacavam o lock até dezembro de 2027 — esse é o primeiro nível, correto; o quadro completo dado pelo construtor mostra que, após o primeiro nível, ainda há quase quatro anos de liberação mensal.
As anotações próprias do contrato deixam a intenção do design bem clara: não é atualizável; as condições no deployment são condições para sempre; sem desbloqueio antecipado, nenhuma chave consegue mover um nível antes da data de vencimento. Eu conferi essas duas no código, uma por uma. O cronograma está no constructor sem setter; e o contrato de fato não é um proxy.
É assim que a “matemática forçando” se parece em um exemplo que eu consigo verificar totalmente: as afirmações batem com o código, e o código é mais específico do que o texto. Das seis regras, aquilo que eu só consigo encontrar indícios em código-fonte e documentação, aqui dá para ver ponta a ponta.
Além disso, duas outras referências externas.
Quando o blog fala sobre TEE, ele diz que houve vulnerabilidades registradas no Intel SGX que quebraram garantias de isolamento. Esta parte está certa, mas ele atenua o argumento dele. As falhas de classe de isolamento incluem Foreshadow, Plundervolt, EPIC Leak e SmashEx, com números respectivamente CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186 e CVE-2021-33767. O mais devastador de verdade é a SGAxe de 2020: usando CVE-2020-0549, ela extraiu as chaves de atestado do ambiente enclave de produção do Intel; depois disso, passou a emitir declarações arbitrárias que o serviço de atestado da própria Intel julgava como legítimas.
A argumentação do blog é que a garantia de TEE é fornecida por provas emitidas pelo hardware; e a SGAxe justamente quebra o elo que emite essas provas. O caso mais sério de falha não é que os dados foram roubados; é que a própria garantia foi falsificada. Falando com justiça, essas falhas já foram corrigidas por update de microcódigo e recuperação do TCB. Hoje, o SGX não é o SGX de 2018; a descrição correta é que a raiz de confiança do hardware tem uma superfície de vulnerabilidade “rolante”.
Outra parte em que ele diz que o BIS Project Agora está convergindo para a mesma arquitetura. Eu revisitei o relatório de protótipo do BIS de 27 de maio: topologicamente, realmente parece — uma estrutura em camadas, com ledger compartilhado e, em cada jurisdição, um ledger independente. Mas a fronteira do Agora é traçada por jurisdição; o relatório não explica como o controle de acesso dentro do ledger de cada jurisdição é implementado. Então, se essa convergência se estende até a camada do modelo de confiança, os dados públicos existentes não deixam claro.
O que é confirmado e o que é apenas minha inferência.
Confirmado: ML-KEM-768 é usado para chaves de observação, ver relayer/cryptography/mlkem.go; Pedersen constrói geradores duplos no BabyJubJub, ver enygma_math.go. Chave privada de auditor é distribuída por criptografia com a relayer, ver governance service/cryptography/service.go. A matemática entre chave de despesa e chave de observação é independente; o escopo de observação pode ser delimitado por tempo e por conta; o navegador do auditor cobre apenas transações cross-chain e o nível de descriptografia pode ser configurado na fase de setup — tudo isso aparece na documentação técnica oficial. Cryptographic Trust Suite mantém as chaves de forma unificada e o Relayer nunca detém chaves; o armazenamento de chaves pode ser plugado em KMS ou HSM; criptografia de envelope estática; logs de auditoria do serviço de gerenciamento de chaves próprio da instituição (é a trilha de auditoria das operações de chaves); chaves de assinatura são rotacionadas conforme o uso e as chaves assinadas para transações pendentes permanecem válidas até a liquidação; encapsulamento é feito uma vez no momento da construção da rede de acordo com as partes participantes; o conjunto anônimo tem tamanho 2 ou 6; um crossTransfer aponta no máximo para 5 cadeias de destino; a finalização é na ordem de dezenas de segundos; o congelamento de participantes é executado pelo operador via contrato de governança ParticipantStorage — tudo isso consta na documentação técnica oficial. O status de verificação do RlsTokenLock, a propriedade de não-ser-proxy, o cronograma em 48 níveis, e o valor declarado versus saldo real, foram todos lidos via a interface do explorador público em 12 de setembro de 2026. Os números de vulnerabilidades do SGX vêm dos registros CVE e do artigo SGAxe. A estrutura e os dados do Agorá vêm de materiais públicos do BIS.
Minha inferência: entre as quatro fontes, apenas o artigo usa termos com precisão em relação a Pedersen. A descrição “o limite é forçado pela matemática” fala de execução, não de distribuição. A SGAxe sustenta melhor o argumento do blog do que falhas de classe de isolamento. Nessas três fontes, não está escrito dessa forma.
O que não consegui verificar: o mecanismo de retirada posterior da quinta regra. Eu procurei nos seis documentos: gerenciamento de chaves, navegador do auditor, fundamentos criptográficos do Enygma, congelamento de participantes, opções de design de rede privada e hub de rede privada. Além disso, com os dois repositórios de código do relayer e do serviço de governança. Encontrei apenas três níveis de configuração de visibilidade, o mecanismo de concessão e o congelamento/desativação de participantes — mas não encontrei implementação de revogar uma visibilidade já concedida e ainda forçada pela criptografia. A rotação de longo prazo das chaves de observação também não apareceu: a seção que descreve rotação no documento fala de chaves de assinatura.
Por fim, uma coisa que não tem relação com tecnologia.
Na mesma semana em que esse texto foi publicado, a autoridade anunciou que 55% dos níveis de staking seriam estendidos até 15 de setembro e disse que, durante o ajuste do mecanismo de staking, os primeiros apoiadores continuariam a receber parte desses rendimentos. As atualizações futuras sobre staking e sobre a economia de tokens mais ampla, incluindo queima, seriam anunciadas separadamente.
Eu já estava fazendo staking desde a fase de pré-compromisso e participei integralmente por três meses. O nível original terminava em 9 de setembro; nesses dias, no painel, eu vi o limite se esgotar e não consegui adicionar mais, cheguei a achar que era um problema de frontend. Agora parece que o mecanismo está sendo ajustado.
Este trecho é minha opinião pessoal, não uma afirmação de fatos. Na janela de mudança do mecanismo, em vez de cortar diretamente, escolheram estender — e escreveram as datas de forma explícita. Eu acho que foi uma atitude bem intencional. O que mais tende a aparecer no período de ajuste de mecanismo é a ambiguidade; dar uma data certa significa que, ao vencer, ou se cumpre, ou se explica de novo.
Isso é apenas um caso concreto; não constitui um juízo sobre quaisquer arranjos de longo prazo. Eu não prevejo retornos, nem recomendo que qualquer pessoa tome decisões com base nisso.
Fontes de referência: Rayls oficial blog “Auditability without surveillance: why mathematical enforcement beats trusting the code”, 12 de setembro de 2026; duas páginas do documento técnico oficial da Rayls: “Enygma cryptography fundamentals” e “private network auditor browser”; repositórios rayls-sovereign-relayer e rayls-sovereign-pnh-governance do GitHub org raylsnetwork; interface explorer.rayls.com (addresses e smart-contracts) do blockchain público da Rayls, com coleta em 12 de setembro de 2026; NIST FIPS 203; registros CVE 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 e artigo SGAxe; protótipo do BIS Project Agorá, relatório othp110; arquivo eletrônico de criptografia IACR 2025/1638 e 2025/1639; anúncio da conta oficial da Rayls no X em 12 de setembro de 2026.
