A mesma requisição de eth_chainId: a lista oficial de endereços de mainnet não devolveu a resposta, enquanto a testnet funcionou normalmente. Esse resultado não pode ser “trocado” por uma justificativa de que a mainnet já teria parado. Ele revela outra camada de problema. O @Dusk documenta o endpoint de entrada; isso só comprova que o endereço foi declarado, não que a minha máquina já estabeleceu uma conexão confiável com ele. A existência do documento e a disponibilidade para o cliente são duas coisas diferentes — ainda há certificados, rede e identidade da chain no meio.
Eu deixei as variáveis bem restritas. No cliente, no conteúdo do POST e no timeout de 15 segundos está tudo igual; só troquei o endpoint RPC. Em 24 de agosto de 2026, às 00:08, a testnet respondeu com 0x2e9 e, em seguida, retornou o bloco 0x11bc06. A mainnet, sob validação rigorosa de certificado, parou no TLS; o status HTTP foi 000 e o resultado da validação foi 20. O chain ID da camada de aplicação nem chegou a ser obtido.
O mais útil desta comparação não é um veredito de saúde em rede de teste. A falha estrita no TLS pode ocorrer por causa da cadeia de certificados, ou pode aparecer apenas no meu caminho de rede atual. O que ela comprova é bem claro: pelo menos neste ambiente de cliente, o endereço do documento ainda não passou pela validação de disponibilidade. Escrever uma falha de conexão como se fosse um problema na rede inteira seria mais irresponsável do que ignorar a falha em si.
Antes, eu via o RPC e já começava a configurar a wallet. Agora a ordem precisa mudar. Conexão confiável é a porta; chain ID é o número da casa; somente com o avanço contínuo dos blocos dá para dizer que “tem gente dentro”. Com menos uma etapa, não se deveria tentar com dinheiro real. Desta vez, na testnet, as três verificações continuaram funcionando; na mainnet, parou na primeira etapa e não foi uma questão de “mais rápido ou mais lento”, e sim de conseguir entrar na próxima validação.
Para que o endpoint EVM do $DUSK esteja realmente utilizável, é preciso ver simultaneamente: o certificado confiável, o chain ID batendo com o esperado e a altura do bloco continuando a mudar. Enquanto as três evidências não estiverem completas, eu só vou marcar como “a investigar”, não como “disponível” — e muito menos como “mainnet indisponível”. A ação mais econômica possível para usuários comuns é bem concreta: antes de transferir, faça estas três checagens; se qualquer uma delas não der resultado, pare.
O documento fornece o endereço; só a validação em teste dá o passe. #dusk
Eu deixei as variáveis bem restritas. No cliente, no conteúdo do POST e no timeout de 15 segundos está tudo igual; só troquei o endpoint RPC. Em 24 de agosto de 2026, às 00:08, a testnet respondeu com 0x2e9 e, em seguida, retornou o bloco 0x11bc06. A mainnet, sob validação rigorosa de certificado, parou no TLS; o status HTTP foi 000 e o resultado da validação foi 20. O chain ID da camada de aplicação nem chegou a ser obtido.
O mais útil desta comparação não é um veredito de saúde em rede de teste. A falha estrita no TLS pode ocorrer por causa da cadeia de certificados, ou pode aparecer apenas no meu caminho de rede atual. O que ela comprova é bem claro: pelo menos neste ambiente de cliente, o endereço do documento ainda não passou pela validação de disponibilidade. Escrever uma falha de conexão como se fosse um problema na rede inteira seria mais irresponsável do que ignorar a falha em si.
Antes, eu via o RPC e já começava a configurar a wallet. Agora a ordem precisa mudar. Conexão confiável é a porta; chain ID é o número da casa; somente com o avanço contínuo dos blocos dá para dizer que “tem gente dentro”. Com menos uma etapa, não se deveria tentar com dinheiro real. Desta vez, na testnet, as três verificações continuaram funcionando; na mainnet, parou na primeira etapa e não foi uma questão de “mais rápido ou mais lento”, e sim de conseguir entrar na próxima validação.
Para que o endpoint EVM do $DUSK esteja realmente utilizável, é preciso ver simultaneamente: o certificado confiável, o chain ID batendo com o esperado e a altura do bloco continuando a mudar. Enquanto as três evidências não estiverem completas, eu só vou marcar como “a investigar”, não como “disponível” — e muito menos como “mainnet indisponível”. A ação mais econômica possível para usuários comuns é bem concreta: antes de transferir, faça estas três checagens; se qualquer uma delas não der resultado, pare.
O documento fornece o endereço; só a validação em teste dá o passe. #dusk