rayls

@Rayls 의 스테이킹 APY를 볼 때 단순히 표시된 수익률만 확인하면 충분할까?
실제 수익률을 이해하려면 한 가지를 더 살펴봐야 한다.
수익이 어떻게 기록되고, APY로 계산되며, 실제 보상 지급까지 연결되는가?
이번에는 Rayls 공식 저장소의 "RewardCurve"와 "RewardDistributor" 코드를 직접 비교해 봤다.
1. 스테이킹 APY에 네트워크 수익이 자동으로 반영될까?
"RewardCurve"는 기본 월간 배출량과 변동 배출량을 합산해 연간 APY를 계산하도록 설계돼 있다.
여기서 중요한 부분은 "recordRevenue()"다.
이 함수는 네트워크 수익을 자동으로 가져오는 기능이 아니다. "REVENUE_REPORTER_ROLE" 권한을 가진 계정이 직접 호출해야 변동 배출량에 반영된다.
즉, 수수료를 처리하는 "FeeAggregator"가 존재한다고 해서 그 수익이 자동으로 "RewardCurve"에 기록되는 것은 아니다.
수익 처리와 APY 계산에 반영하는 과정은 별개다.
2. 계산된 APY가 실제 보상 지급액을 보장할까?
그렇지는 않다.
"RewardCurve"는 APY를 계산하지만 RLS를 직접 보관하거나 지급하지 않는다.
실제 보상 분배는 "RewardDistributor"가 담당한다.
코드를 보면 보상 목표액을 계산한 뒤, 부족한 경우 "RLSAccumulator"에 있는 사용 가능한 잔액으로 보충을 시도한다.
따라서 APY가 계산된다는 사실만으로 해당 수익률이 그대로 지급된다고 볼 수는 없다.
실제 지급은 보상 재원과 분배 조건에도 영향을 받는다.
3. 그렇다면 RewardCurve는 실제 메인넷에 적용됐을까?
이번 분석에서 가장 중요했던 부분이다.
Rayls 공식 저장소의 RewardCurve 배포 안내서를 확인해 보니, 해당 문서에는 RewardCurve가 고정된 배포 주소와 "deployments.json" 등록 항목을 갖고 있지 않으며, 아직 어디에도 배포되지 않았다고 명시돼 있다.
또한 배포 스크립트는 Rayls 메인넷에서 실행을 거부하도록 작성돼 있다.
물론 "RewardDistributor"에는 RewardCurve 주소를 연결하는 설정 기능이 존재한다.
하지만 코드에 연결 기능이 있다는 것과 실제 메인넷에서 연결돼 작동한다는 것은 다른 이야기다.
따라서 공개 저장소만으로 현재 메인넷에서 수익 연동 APY가 활성화됐다고 판단할 수는 없다.
4. 이번 코드 분석으로 확인한 내용
- 코드에서 확인: RewardCurve는 기본 배출량과 변동 배출량을 바탕으로 APY를 계산한다.
- 코드에서 확인: 수익 기록과 월간 초기화에는 별도 권한을 가진 계정의 호출이 필요하다.
- 코드에서 확인: 실제 보상 분배는 RewardDistributor가 담당한다.
- 공식 문서에서 확인: RewardCurve의 배포 상태에 관한 안내와 메인넷 배포 제한이 기록돼 있다.
- 아직 확인하지 못한 것: 현재 메인넷에서 RewardCurve가 실제로 배포되고 RewardDistributor에 연결돼 있는지 여부다.
이번에 코드를 살펴보면서 느낀 점은 명확하다.
스테이킹 APY를 평가할 때는 숫자만 보는 것이 아니라, 그 숫자가 어떤 데이터로 계산되는지, 실제 보상 재원은 어디서 나오는지, 그리고 해당 기능이 실제 네트워크에 적용됐는지까지 확인해야 한다.
코드가 존재한다는 것과 실제로 작동한다는 것은 다르다.
이 차이를 구분하는 것이 스테이킹 수익률을 제대로 이해하는 첫걸음이라고 생각한다.
참고 자료
RewardCurve 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardCurve.sol
RewardDistributor 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardDistributor.sol
RewardCurve 공식 배포 안내서
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/script/interactions/reward-curve/README.md
RewardCurve 배포 도구 관련 PR
https://github.com/raylsnetwork/axyl/pull/174
#Rayls $RLS

Nos últimos artigos, tenho medido quanto tempo leva para calcular as provas da Rayls, mas, para os bancos, há uma questão ainda mais básica: quando é que o dinheiro é realmente creditado e já não pode ser retirado? Esta semana, mudei de perspetiva: durante duas horas, pedi aos servidores do GitHub que monitorizassem ao mesmo tempo a Ethereum e a blockchain pública da Rayls, para ver como respondiam por si mesmas a essa pergunta.
Comecemos pela resposta curta. Quando os bancos dizem que o dinheiro foi «creditado», isso pode significar duas coisas: que é juridicamente irrevogável e que, do ponto de vista técnico, não pode ser revertido. No plano técnico, os blocos que os próprios nós da Ethereum marcam como «finalizados» ficam entre 12,6 e 19,2 minutos atrás do bloco mais recente — 16 minutos, em mediana. Já a blockchain pública da Rayls marca cada bloco como finalizado assim que é produzido, e os blocos são criados a cada 1,35 segundos, aproximadamente. Esta «finalidade determinística» (deterministic finality) também tem um custo: quando o consenso não consegue avançar, a cadeia para em vez de se dividir. Desde o seu lançamento, a blockchain pública da Rayls parou pelo menos duas vezes: uma durante 11,72 horas e outra durante 9,15 horas. Após ambas as retomas, continuou diretamente a partir do bloco em que tinha parado.

As blockchains públicas oferecem transparência, mas os bancos não podem tratar cada transação financeira como uma publicação pública em uma rede social. Saldos de clientes, valores de pagamentos e contrapartes podem conter informações comercial ou pessoalmente sensíveis.
Portanto, a verdadeira questão não é se os bancos devem usar blockchain. É como podem obter os benefícios da liquidação on-chain sem expor informações financeiras confidenciais.
1. Por que as blockchains públicas comuns representam um desafio
Em uma blockchain pública típica, as transações podem revelar endereços de carteiras, quantias em tokens e padrões de atividade financeira. Mesmo quando os nomes reais não estão diretamente associados aos endereços, transações repetidas às vezes podem ajudar observadores a vincular a atividade a entidades específicas.

Se uma transferência falhar na Rayls, os meus tokens serão devolvidos?
Numa transferência entre cadeias, o que acontece aos tokens processados na origem se a transação no destino falhar? $RLS
Quando os tokens são transferidos para outra cadeia, os ativos podem ser bloqueados ou queimados na cadeia de origem. No entanto, se o processamento falhar no destino, é necessário um procedimento para recuperar o estado dos ativos.
A documentação oficial da Rayls descreve um mecanismo de recuperação para lidar com esta situação. No entanto, a análise do código disponibilizado publicamente revela outros aspetos que importa verificar.

O que descobri ao investigar o consenso, a arquitetura de liquidação e os recibos de transação da Rayls.
Comecei com uma pergunta simples:
Se uma blockchain promete finalização em menos de um segundo, isso significa que toda a transação é concluída em menos de um segundo?
À primeira vista, a resposta pode parecer óbvia. Uma transação é confirmada, a rede chega a um consenso e a operação é concluída.
Mas a infraestrutura financeira é mais complexa do que isso.
Uma transação pode ser confirmada em um livro-razão enquanto uma operação maior ainda depende de outro livro-razão, de um retransmissor, da verificação de provas ou da execução no lado de destino.

$RLS
Ao revisar o código do Relayer do Rayls, notei algo estranho.
Se o Relayer é quem entrega a mensagem, então "executeMessage()" também não deveria exigir a permissão RELAYER?
Mas, ao acompanhar o código real, vi que não era assim.
Pelo contrário, Rayls separou a permissão para entregar mensagens da execução propriamente dita.
Na Public Chain, o primeiro ponto de entrada do Relayer é "PublicRNEndpoint.receivePayload()".
sem executar a mensagem diretamente aqui,

A blockchain oferece às instituições financeiras algo de que elas precisam muito: liquidação verificável sem depender inteiramente de um banco de dados fechado.
Mas há um problema evidente.
Os bancos não podem simplesmente registrar todos os detalhes das transações em uma blockchain pública.
Saldos, contrapartes, valores das transações e outras informações confidenciais talvez precisem permanecer privados — enquanto reguladores, contrapartes e a rede ainda precisam de evidências suficientes para verificar que algo realmente aconteceu.
Então, como é possível ter privacidade e verificabilidade ao mesmo tempo?

Na postagem anterior, eu executei o código de prova que a Rayls publicou e medi que, em um grupo anônimo com 6 pessoas, cada transação leva 1,96 segundos. Mas naquela publicação havia três frases que são inferências, não medições; eu sei disso por conta própria. Esta semana eu troquei a máquina por uma com 2 núcleos e coletei mais alguns dados, então agora vou voltar e completar aquelas três frases com números.
Primeiro, deixe claro qual é a relação entre esta e a anterior, para que os leitores não pensem que é uma republicação do mesmo texto. Na postagem anterior, foi medido o tempo de prova em um ambiente de um único núcleo para os modos com 2 pessoas e com 6 pessoas. Esses dois números foram medidos novamente desta vez, e quase não mudaram. Todo o conteúdo novo desta postagem são aquelas três coisas que na anterior não dava para medir, e só era possível inferir.

Em geral, eu vejo que um anúncio de lock-up se preocupa com uma coisa: se essa promessa pode ou não ser verificada. A maioria dos projetos, no fim, acaba se resumindo a uma frase sobre “lock-up do time”, e você só pode escolher acreditar ou não. Desta vez é um pouco diferente, então eu fui verificar na cadeia.
Primeiro, vamos deixar os fatos claros. A Parfin é a principal fornecedora de tecnologia por trás da Rayls: responsável pelo desenvolvimento dos nós de privacidade, da rede privada, do framework de privacidade Enygma e da blockchain da Rayls. Como remuneração pelo trabalho realizado antes do TGE, ela recebeu 1.070.493.535 unidades de RLS, cerca de 11% do fornecimento total inicial de 1 bilhão de tokens.
Esses tokens foram anteriormente armazenados em um custodiante institucional na rede Ethereum. O motivo é bem prático: na época do TGE, a blockchain pública da Rayls ainda não estava em funcionamento, então foi necessário mantê-los sob custódia. Agora, com a blockchain já ativa, esses tokens foram migrados para a blockchain da Rayls, sendo bloqueados em um contrato inteligente com verificação pública. Ao mesmo tempo, o prazo de desbloqueio foi adiado de dezembro de 2026 para dezembro de 2027.

Para ser honesto, quando vi pela primeira vez essas três siglas juntas, pensei que eram três respostas para a mesma pergunta: quem é mais rápido, quem é mais seguro — escolha uma e pronto. Só depois entendi que colocá-las em um ranking, uma do lado da outra, é como perguntar "qual é a melhor — martelo, chave de fenda ou chave inglesa"; a resposta depende se, nas suas mãos, você tem um prego, um parafuso ou um parafuso-balcão.
Na verdade, cada uma resolve um de três problemas que são misturados.
O primeiro problema é: quero provar que algo é verdadeiro, mas os dados necessários para a prova são sensíveis, então não quero mostrá-los. O banco quer explicar ao órgão regulador que "essa transação é legal, a autorização está correta e não há duplicidade", mas não quer colocar os valores e os pagadores/recebedores no livro-razão. Essa necessidade de uma prova que seja verdadeira, mas sem divulgar os dados, é o campo de atuação do ZK. O encanto está em garantir que a verificação venha da matemática, e não de "eu prometo que não vou olhar"; o regulador ou auditor que obtém a chave de verificação pode checar a conclusão, mas não consegue tocar nos dados subjacentes. O custo também é bem real: ele é ótimo para provar propriedades dos dados, mas não é tão bom para fazer várias partes calcularem juntas quando nenhuma delas tem dados completos — e além disso consome mais capacidade computacional do que o texto em claro.

Irmãos, eu tenho ficado em emboscada por muito tempo no fórum da Rayls. Eu sei que todo mundo está muito insatisfeito com a equipe; eu também. Mas a equipe está realmente trabalhando, sempre se esforçando. Só que o time da Rayls segue uma rota em conformidade. Irmãos, não desistam de jeito nenhum. Deixem tudo com o tempo. Eu acredito que, no fim, a equipe da Rayls vai entregar uma prova que nos satisfaça. Vou compartilhar algumas boas notícias com vocês, sobre o que aconteceu: recentemente, o time da Rayls conectou o RPC. Isso é uma coisa muito importante!!
Visão rápida
O que é RPC
Você pode entender o RPC como uma linha direta dedicada entre o aplicativo e a blockchain.

A tabela comparativa de fornecedores do site Rayls tem nove linhas; eu escolhi a linha «Privacidade». A razão é bem simples: a privacidade é importante e Besu é open source; tanto a documentação quanto o código eu consigo verificar.
Na tabela comparativa, a Rayls marca «privacidade isolada» e «privacidade criptográfica»; a Besu só marca a primeira linha. Eu decidi verificar na própria documentação do outro lado, então procurei a documentação do Besu e, em seguida, baixei o código para contar quantas vezes aparece.
A conclusão não é «Besu não serve». A diferença real é que: as duas empresas colocam a privacidade em camadas diferentes, e o Besu moveu isso para outra parte bem mais cedo do que muita gente imagina.

Todo semana, o círculo das criptos consegue ver “algum grande tradicional do mercado financeiro entrando em blockchain”. Agora, quando vejo esse tipo de manchete, eu já passo para o lado, porque na maioria das vezes termina em um laboratório de inovação: solta um comunicado à imprensa e não há mais desdobramentos. Para avaliar a veracidade, existe um critério bem simples: um cliente comum, no próprio app, consegue abrir e usar diretamente?
A XP Inc. passou neste padrão desta vez.
Primeiro, esclareça o que é essa empresa, porque o tamanho determina o peso dessa questão. A XP é uma plataforma de investimentos do Brasil listada na Nasdaq, com o código de ações XP. Eu conferi os dados do primeiro trimestre de 2026 na página de Relações com Investidores: ativos dos clientes na ordem de R$ 152,9 bilhões, ou seja, R$ 1,529 trilhão com precisão; consultores de investimentos com mais de 18.000 pessoas; nos últimos doze meses, receita total de R$ 19,8 bilhões; e lucro antes de impostos de R$ 5,8 bilhões.

Em 19 de setembro, Rayls publicou um texto (Privacy has a price). No título, dizia honest math, mas o artigo inteiro só forneceu um intervalo de números: uma prova vai de centenas de milissegundos até alguns segundos. Tenho passado semanas escrevendo a arquitetura de privacidade da Rayls; desta vez, vou compartilhar uma novidade. Eu puxei o código da prova que ele disponibilizou publicamente, rodei na prática dezenas de vezes e vou compartilhar esse resultado interessante com vocês!
Primeiro, vamos dizer do que o blog fala. O argumento central dele pode ser resumido em duas frases. A primeira é onde está o custo: transações confidenciais são mais caras do que transações transparentes — o caro está em gerar provas de conhecimento zero; já a verificação é até barata. Uma prova de uma transferência confidencial básica, em hardware comercial comum, leva de centenas de milissegundos a alguns segundos. A segunda frase é o que vale a pena perguntar: em vez de instituições perguntarem apenas sobre TPS, elas deveriam perguntar qual é a vazão quando a sua necessidade de privacidade e de nível de auditoria é considerada, e quando se encara uma carga de trabalho real. O blog afirma que o volume de liquidação entre instituições não é grande, e que está totalmente dentro da capacidade de sistemas de liquidação confidenciais.

Eu comecei a fazer o staking a partir do lote de junho de pré-compromissos, então eu já passei por todo esse processo uma vez. Desta vez, foi aberto para todo mundo, e muita gente ao meu redor perguntou como operar e o que prestar atenção. Então resolvi escrever tudo de uma vez, bem claro.
Primeiro, vamos falar sobre a própria mudança.
O Rayls usa prova de participação delegada: os validadores executam nós, produzem blocos e garantem a segurança da blockchain, enquanto os detentores comuns não precisam rodar um nó. Eles podem delegar o RLS que têm para algum validador e compartilhar parte dos prêmios de staking.
Esse mecanismo foi lançado em junho, mas na época só estava disponível para carteiras que participaram do plano de pré-compromissos e das atividades de semente de liquidez. Aquelas pessoas travaram os tokens antes da rede principal e receberam, por três meses, uma bonificação anual de 55% por parte da equipe oficial; além disso, eles enviaram 1 USDr para cada carteira que atendia aos requisitos, para que eles nem precisassem de ter gas.

Na última vez, ao escrever aquele texto sobre XP, eu estava sempre curioso sobre uma questão: depois que um stablecoin institucional como USDXP é emitido, como exatamente ele participa de uma liquidação transfronteiriça real? Este artigo foi, em parte, uma forma de responder à minha dúvida — e, de quebra, também me fez entender pela primeira vez uma expressão: “sandwich de stablecoin”.
Primeiro, explique essa palavra: ela é bem ilustrativa. Um pagamento transfronteiriço em que as duas pontas são moedas fiduciárias locais e, no meio, existe uma camada de stablecoin pública. O pagador troca sua moeda local por uma stablecoin atrelada ao dólar; a stablecoin faz a liquidação transfronteiriça na blockchain; e o recebedor, então, troca de volta para sua própria moeda local. Parece duas fatias de pão com essa camada de recheio no meio, não parece? É assim que o setor começou a descrever a liquidação transfronteiriça com stablecoins.

Eu comecei a fazer staking de RLS ainda na fase de pré-compromisso; normalmente leio o blog oficial mais para saber se minha posição vai ser afetada. O artigo de 30 de agosto sobre quântica é diferente: ele inteiro ensina instituições a fazer compras, e não tem muita relação direta com um pequeno investidor como eu. Mesmo assim, eu li até o fim, porque logo no começo ele estabelecia uma regra bem rígida, e essa regra acabou me trazendo de volta para o próprio artigo.
Aquela regra é assim: quando se fala em “segurança quântica”, se não ficar claro qual algoritmo padronizado foi usado e em qual nível de parâmetro, isso não é uma afirmação, é só um rótulo.

No artigo anterior, eu falei sobre a própria abertura do staking. Mas nos bastidores, muitos dos irmãos me perguntaram a mesma coisa: como operar exatamente. Então, desta vez, eu percorri todo o processo novamente do começo ao fim, anotando cada etapa e todos os pontos onde é fácil travar; é só seguir.
O link do artigo anterior está aqui: 质押开放给所有人了,但有几件事最好先知道
Primeiro, deixe claro para quem este artigo é. Se você nunca teve contato com Rayls e nem sabe muito bem o que significam termos como carteira e ponte, então este artigo foi escrito para você. Para cada termo técnico, eu também vou explicar rapidinho uma frase.