Para a mesma solicitação eth_chainId, o endereço da mainnet listado oficialmente não devolveu resposta, enquanto a testnet respondeu normalmente. Não se pode distorcer esse resultado para afirmar que a mainnet já está fora do ar. Ele revela um problema de outra ordem. @Dusk : incluir o endpoint na documentação só prova que o endereço foi declarado; não prova que a minha máquina estabeleceu com ele uma conexão confiável. Entre a existência da documentação e a disponibilidade para o cliente ainda há certificados, rede e identidade da cadeia.
Reduzi bastante o número de variáveis. O cliente, o conteúdo do POST e o tempo limite de 15 segundos são exatamente os mesmos; só substituí o endpoint RPC. Em 24 de agosto de 2026, às 00h08, a testnet retornou 0x2e9 e, em seguida, o bloco 0x11bc06. Na mainnet, com a validação estrita de certificados, a conexão parou no TLS: o status HTTP foi 000, o resultado da validação foi 20 e nem sequer foi possível obter o chain ID na camada de aplicação.
O mais útil nesta comparação não é emitir um veredito sobre a saúde da rede. Uma falha de TLS estrito pode vir da cadeia de certificados ou ocorrer apenas no caminho de rede que estou usando no momento. O que ela pode provar é bem claro: pelo menos neste ambiente de cliente, o endereço da documentação ainda não passou no teste de disponibilidade. Descrever uma falha de conexão como uma avaria de toda a rede seria ainda mais precipitado do que ignorar a própria falha.
Antes, eu via um RPC e começava logo a configurar a carteira. Agora, a ordem precisa mudar. Uma conexão confiável é a porta de entrada, o chain ID é o número da casa, e só o avanço contínuo dos blocos mostra que há alguém lá dentro. Se uma etapa falhar, não se deve arriscar dinheiro de verdade. Desta vez, foi possível continuar verificando os três itens na testnet; na mainnet, a verificação parou logo na primeira etapa. A diferença não é de velocidade, mas de poder avançar para a próxima validação.
Para que o endpoint EVM de $DUSK seja realmente utilizável, é preciso confirmar ao mesmo tempo que o certificado é confiável, que o chain ID corresponde ao esperado e que a altura dos blocos continua mudando. Sem reunir as três evidências, vou marcá-lo apenas como pendente de investigação, não como utilizável, e muito menos dizer que a mainnet está fora do ar. Para um usuário comum, a medida mais econômica também é bem concreta: faça essas três verificações antes de transferir fundos e pare se alguma delas não der resultado.
A documentação fornece o endereço; só o teste prático concede o passe. #dusk
Reduzi bastante o número de variáveis. O cliente, o conteúdo do POST e o tempo limite de 15 segundos são exatamente os mesmos; só substituí o endpoint RPC. Em 24 de agosto de 2026, às 00h08, a testnet retornou 0x2e9 e, em seguida, o bloco 0x11bc06. Na mainnet, com a validação estrita de certificados, a conexão parou no TLS: o status HTTP foi 000, o resultado da validação foi 20 e nem sequer foi possível obter o chain ID na camada de aplicação.
O mais útil nesta comparação não é emitir um veredito sobre a saúde da rede. Uma falha de TLS estrito pode vir da cadeia de certificados ou ocorrer apenas no caminho de rede que estou usando no momento. O que ela pode provar é bem claro: pelo menos neste ambiente de cliente, o endereço da documentação ainda não passou no teste de disponibilidade. Descrever uma falha de conexão como uma avaria de toda a rede seria ainda mais precipitado do que ignorar a própria falha.
Antes, eu via um RPC e começava logo a configurar a carteira. Agora, a ordem precisa mudar. Uma conexão confiável é a porta de entrada, o chain ID é o número da casa, e só o avanço contínuo dos blocos mostra que há alguém lá dentro. Se uma etapa falhar, não se deve arriscar dinheiro de verdade. Desta vez, foi possível continuar verificando os três itens na testnet; na mainnet, a verificação parou logo na primeira etapa. A diferença não é de velocidade, mas de poder avançar para a próxima validação.
Para que o endpoint EVM de $DUSK seja realmente utilizável, é preciso confirmar ao mesmo tempo que o certificado é confiável, que o chain ID corresponde ao esperado e que a altura dos blocos continua mudando. Sem reunir as três evidências, vou marcá-lo apenas como pendente de investigação, não como utilizável, e muito menos dizer que a mainnet está fora do ar. Para um usuário comum, a medida mais econômica também é bem concreta: faça essas três verificações antes de transferir fundos e pare se alguma delas não der resultado.
A documentação fornece o endereço; só o teste prático concede o passe. #dusk