Configurar os endpoints RPC

Última atualização: 7 de setembro de 2026

A aplicação não tem backend. Consulta as redes diretamente, pelo que cada rede precisa de uma fonte de dados: ou uma API pública oficial, ou o endereço RPC de um nó que o utilizador forneça. Esta página explica como configurar uma e o que fazer quando não responde.

Indicar um endpoint

1. Definições (⚙ no topo do ecrã inicial) → Redes.
2. Escolha a rede. O subtítulo já indica a fonte em uso — ou que não está configurada.
3. Toque em Configurar o nó RPC / Mudar de endpoint e introduza o URL. Tem de começar por http:// ou https://.
4. Se o nó exigir autenticação, preencha o utilizador e a palavra-passe no mesmo diálogo.
5. Toque em Testar a ligação: a aplicação obtém a altura da cadeia e mostra «OK» ou o erro exato.
6. Repor volta ao valor predefinido: o URL oficial nas redes que o têm, o campo vazio nas restantes.

Onde ficam as credenciais

O utilizador e a palavra-passe RPC são escritos no Keystore do Android / Porta-chaves do iOS, com uma entrada por rede. Nunca aparecem nas definições, no ficheiro de cópia de segurança, nos registos nem no pacote da aplicação.

• A palavra-passe nunca volta a ser mostrada. Reabrir o diálogo e deixar o campo vazio mantém as credenciais guardadas.
• Apagar as credenciais remove-as do armazenamento seguro.
• Uma cópia de segurança exportada contém apenas os URL RPC — nunca uma palavra-passe, nunca um utilizador.

Alojar o seu próprio nó

Estas redes são forks do Bitcoin ou do Dash: o RPC configura-se no ficheiro de configuração do daemon. As chaves úteis são as mesmas em todo o lado.

server=1
rpcuser=<utilizador>
rpcpassword=<palavra-passe longa e aleatória>
rpcbind=0.0.0.0                  # escutar na rede, e não apenas em localhost
rpcallowip=<ip-de-confiança>/32  # restringir quem pode chamar o RPC
# rpcport=...                    # mantenha o valor predefinido da rede salvo necessidade

Daemon, ficheiro de configuração, porta predefinida e método chamado pela aplicação, rede a rede:

As redes ausentes desta tabela — Cosanta, Neoxa e Flux — são lidas através de um explorador ou de uma API pública, e não de um nó RPC. Não há qualquer porta RPC a abrir para elas: muda-se apenas um URL.

HTTPS e proxy inverso

Um daemon expõe HTTP em claro, e a aplicação aceita-o nas catorze redes: nenhum daemon de masternode serve TLS, e o nó que vigia é muitas vezes acessível apenas na sua rede local, onde um certificado publicamente reconhecido não faz sentido. Em HTTP, no entanto, tudo circula em claro — as respostas do daemon e, sobretudo, a palavra-passe RPC, se existir. Assim que a ligação não for de confiança, coloque um proxy inverso TLS à frente do RPC — Caddy, Nginx ou Traefik — e dê à aplicação o URL do proxy. Com o Caddy são duas linhas e o certificado é automático:

rpc.exemplo.com {
    reverse_proxy 127.0.0.1:9998
}

Também pode deixar a autenticação Basic a cargo do proxy em vez do daemon. Em ambos os casos, a aplicação envia as credenciais por TLS, nunca em claro.

Particularidades por rede

As redes que funcionam de imediato

Beldex, Firo, Cosanta e Neoxa vêm com uma fonte pública oficial e não exigem qualquer configuração. Ainda assim, vale a pena saber duas coisas:

• O Beldex é a única rede onde pode empilhar vários endpoints. São tentados por ordem, pelo que um segundo URL é um failover automático.
• O Firo oferece dois modos. O explorador público funciona de imediato, mas não expõe a pontuação PoSe numérica: um nó penalizado parece saudável até ser banido. O seu próprio firod expõe-a — e recorre ao explorador público se o seu nó cair.

As redes que exigem o seu próprio nó

PIVX, Dash, Syscoin, Divi, Raptoreum, SmartCash, SwiftCash, BitCore, Flux e Terracoin começam por configurar. É uma escolha deliberada, não um esquecimento, e há duas razões distintas. Nas oito primeiras não existe qualquer endpoint público oficial que exponha a lista de masternodes, e preferimos deixar o campo vazio a encaminhar o seu tráfego por uma gateway comercial que nunca escolheu. O Flux e o Terracoin são o outro caso: existe uma fonte oficial que responde perfeitamente, mas o seu operador não autoriza que uma aplicação a consulte — ambos foram retirados das predefinições a 2026-08-25.

• A autenticação é obrigatória em todas, exceto no PIVX, onde é opcional: um nó público pode não a exigir, o seu pivxd pessoal exige.
• As gateways com chave de API (NOWNodes, GetBlock e semelhantes) não funcionam: a aplicação não envia qualquer cabeçalho api-key. As gateways públicas sem chave podem servir, desde que permitam os métodos de listagem de masternodes — muitas só servem consultas de blocos.
• Os seus exploradores estão em baixo ou foram fechados de propósito. Se conhecer um endpoint público de confiança, basta colá-lo.
• O Flux não precisa de credenciais — a sua API é pública e apenas de leitura — e cada FluxNode serve essa mesma API na porta 16127, em HTTP sem cifragem: indique http://o-seu-ip:16127. As duas portas vizinhas são becos sem saída — a 16126 é a interface web e a 16128 a mesma API atrás de um certificado autoassinado que o telemóvel recusa.

Uma rede que merece um aviso

Segurança

• Nunca exponha um RPC sem autenticação à Internet pública. Um RPC aberto é um nó — e por vezes uma carteira — à mercê de quem o encontrar. Use rpcallowip, uma firewall, uma VPN ou um proxy inverso autenticado.
• Use uma palavra-passe longa e aleatória. O RPC é uma interface para máquinas: ninguém tem de a escrever duas vezes.
• Nunca introduza uma chave privada no campo de adicionar nó. A monitorização só precisa de dados públicos. Em várias redes a aplicação rejeita uma chave privada apenas pelo formato, antes de qualquer pedido sair do aparelho.
• As credenciais ficam no aparelho, no cofre do sistema — nunca nas definições, nunca numa cópia de segurança, nunca num registo.

Resolução de problemas

Ainda com problemas? Envie-nos a rede, o erro exato apresentado por Testar a ligação e a versão do daemon — ver suporte. Nunca envie credenciais.