Seis etapas desde um VPS nórdico nu até o seu próprio monerod — binários verificados, uma configuração hardenizada, completo ou podado, alcançável via SSH, WireGuard ou um onion v3. Um nó remoto não consegue ler o seu saldo, mas pode ver o seu IP transmitir a sua transação — este guia fecha essa única brecha. Testado no Debian 12 com a linha v0.18.
Provisionar
Disco primeiro, hardenização depois
Verificar
Assinatura, depois instalação
Configurar
monerod.conf + systemd
Sincronizar
Um dia ou dois, acompanhado
Conectar
SSH, WireGuard ou onion
Anonimizar
Transmitir via Tor
Quase toda carteira Monero já vem apontada para o daemon de outra pessoa, porque a alternativa é um quarto de terabyte e dois dias de espera. Esse padrão é defensável, e a perda de privacidade resultante costuma ser descrita de forma errada nas duas direções — por quem acha que um nó remoto lê o saldo, e por quem acha que ele não aprende nada. Entender corretamente o formato desse vazamento é o que diz se este guia vale uma tarde do seu tempo.
O que ele não consegue fazer. Ele não consegue ver o seu saldo, seus endereços ou suas chaves. Uma carteira Monero não diz a um nó o que procurar; ela baixa blocos inteiros em um intervalo de blocos e tenta decriptar cada saída localmente com a chave de visualização privada, que nunca sai do dispositivo. O nó entrega os mesmos bytes que entregaria a qualquer pessoa. Ele não consegue saber quais saídas, se é que alguma, eram suas — e essa é uma diferença arquitetural genuína em relação ao modelo de carteira leve usado em outros lugares, onde um servidor recebe os endereços a observar e, portanto, sabe exatamente o que está observando.
O que ele consegue fazer. Ele vê o endereço IP que se conectou. Ele vê o intervalo de blocos que aquele IP pediu, o que delimita quando a carteira por trás dele foi criada. Ele vê o ritmo das suas atualizações, que é um padrão de uso. E quando você gasta, ele recebe a transação assinada de você primeiro, antes que o resto da rede a tenha — então está em posição de registrar que esta transação entrou na rede a partir deste endereço, neste segundo. Tudo o mais em Monero é projetado para quebrar exatamente esse tipo de vínculo. Entregar isso de graça a um desconhecido, junto com um IP estável, é a parte que vale a pena corrigir.
E o que ele consegue fazer que ninguém menciona. Ele pode mentir. Um nó hostil, ou simplesmente com defeito, pode servir um topo de cadeia desatualizado, fazendo sua carteira reportar um pagamento recebido que nunca aconteceu, ou pode falhar em retransmitir uma transação que você acredita ter enviado. Nada disso rouba fundos — a carteira verifica o que decripta — mas isso faz você agir com base em uma visão falsa do mundo, o que, para um comerciante esperando uma confirmação, é uma perda por si só. Um nó que você mesmo roda é um nó cujas respostas você não precisa pesar.
| O que é exposto | Nó remoto público | Seu nó, clearnet | Seu nó, via Tor |
|---|---|---|---|
| Seu saldo e endereços | Nunca | Nunca | Nunca |
| Seu IP, para o operador do nó | Sim — um desconhecido | Sim — você | Não |
| Janela de criação da carteira | Sim — um desconhecido | Sim — você | Sim — você |
| IP ↔ sua transação de saída | Sim — um desconhecido | O IP do seu servidor, para os peers dele | Quebrado pelo tx proxy |
| Pode te servir um topo de cadeia falso | Sim | Não | Não |
"Janela de criação da carteira" continua visível para você no seu próprio nó, porque a solicitação ainda acontece — ela simplesmente deixa de ser visível para qualquer outra pessoa. Esse é todo o sentido do exercício: não fazer os metadados desaparecerem, mas fazer de você a única parte que os detém.
Um nó Monero podado mantém um oitavo dos dados de assinatura em anel dos blocos antigos e descarta o resto. Ainda assim, ele baixa e verifica cada bloco por conta própria — podar não é confiar, é esquecer depois de conferir — e mantém por completo tudo o que uma carteira pede e tudo o que outro peer podado precisa. A economia é de cerca de dois terços do disco. Para um nó cuja função é dar suporte às suas próprias carteiras, não há diferença funcional perceptível.
O argumento a favor de um nó completo é estreito, mas real: só um nó completo pode entregar a um nó novinho em folha todos os dados históricos de que ele precisa para verificar a cadeia do zero, então uma rede feita inteiramente de nós podados não funcionaria. Se você tem o disco, rodar completo é uma contribuição. Se não tem, rodar podado não é uma forma inferior de participação — é a configuração que a maioria de quem auto-hospeda deveria escolher.
Decida antes de iniciar o daemon. Passar --prune-blockchain na primeira execução poda o nó enquanto ele sincroniza, o que é rápido e gratuito. Converter um banco de dados completo depois significa parar o daemon e rodar sobre ele a ferramenta separada monero-blockchain-prune, que leva horas e precisa de espaço livre para trabalhar. Acertar isso no início custa uma linha em um arquivo de configuração; errar custa uma noite inteira.
| Formato | Disco, meados de 2026 | O plano que encaixa | Escolha-o quando |
|---|---|---|---|
| Podado · apertado | ~90 GB | Sentinel · 2 vCPU / 4 GB / 120 GB · $3.90 | Você quer o nó funcional mais barato e aceita ter que revisitar o disco |
| Podado · confortável | ~90 GB | Garrison · 4 vCPU / 8 GB / 240 GB · $7.90 | A recomendação padrão — anos de margem, cache do banco de dados quente |
| Completo | 240 GB+ | Ravelin · 8 vCPU / 16 GB / 480 GB · $16.90 | Você quer uma cópia arquivística, ou servir a sincronização inicial de novos nós |
| Completo + serviço público | 240 GB+ | Bulwark · 16 vCPU / 32 GB / 960 GB · $32.90 | Você pretende carregar tráfego real de peers — banda ilimitada importa aqui |
Os tamanhos de cadeia são uma estimativa para meados de 2026 e só se movem em uma direção. Verifique o número atual antes de se comprometer com um plano — todo plano da NordBastion vem com banda ilimitada, que é o que um nó com slots de peer abertos realmente consome.
Uma coisa que não está nesta tabela: RAM. O daemon em si é modesto, e 4 GB de fato rodam um nó. O que a memória extra compra é cache de páginas na frente do banco de dados, o que se sente durante a sincronização inicial e durante a primeira varredura completa de uma carteira, e não na operação do dia a dia. Se você está escolhendo entre mais RAM e mais NVMe com o mesmo orçamento, escolha o NVMe — e dê uma olhada na lista de planos antes de decidir.
No painel: Order → VPS → Garrison para um nó podado, Ravelin se você quiser a cadeia completa, imagem Debian 12. Nenhum endereço de e-mail é exigido para abrir a conta, nenhum documento de identidade é pedido em momento algum, e a fatura é quitada em Monero — o que é uma simetria agradável, e também o caminho mais curto de uma carteira até um servidor ligado que conhecemos. Escolha o bastião pela latência até você mesmo, não até a rede: as conexões entre peers são assíncronas e não se importam, mas as atualizações da sua carteira vão se importar.
Depois, dedique a primeira hora ao firewall. Um nó Monero é, por natureza, um serviço público — ele escuta em uma porta P2P e conversa com estranhos — então o básico não é opcional: SSH somente por chave em uma porta não padrão, um firewall que nega por padrão, atualizações de segurança automáticas, fail2ban. A checklist de hardenização da primeira hora é a peça complementar, e vale a pena executá-la do início ao fim antes que o daemon exista.
O formato do firewall para este nó é incomumente simples. Exatamente duas coisas devem ser alcançáveis a partir de fora: a sua porta SSH e a porta P2P do Monero. Nada mais — em especial não a porta RPC, que o passo 05 alcança por meio de um túnel.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp # or your relocated SSH port
ufw allow 18080/tcp # Monero P2P — the only service port
ufw enable
ufw status numbered
Confirme o disco que você realmente recebeu antes de sincronizar um quarto de terabyte nele, porque descobrir a falta de espaço quarenta horas depois de iniciar uma sincronização é um tipo bem específico de desagradável:
df -h /
# → the "Avail" column is your real budget, not the tier name
Você está prestes a instalar um programa que vai sustentar a visão de rede em que suas carteiras confiam. Um monerod adulterado é a posição ideal a partir da qual mentir para uma carteira, então a etapa de verificação aqui não é um ritual — é o motivo pelo qual o projeto Monero sequer publica um arquivo de hashes assinado. Faça isso, uma vez, direito.
Baixe o arquivo CLI para Linux x86-64 e o arquivo de hashes assinado a partir da página oficial de downloads, junto com a chave pública do mantenedor conforme publicada ali. Não pegue a chave em um espelho de keyserver de terceiros que você encontrou em um post de fórum — pegue-a do próprio projeto, via TLS, na mesma página que a nomeia.
apt update && apt install -y gnupg curl bzip2
cd /tmp
curl -LO https://downloads.getmonero.org/cli/linux64 # the release archive
curl -LO https://www.getmonero.org/downloads/hashes.txt # the signed hash list
# Import the signing key named on getmonero.org, then:
gpg --verify hashes.txt
# → "Good signature from ..." — anything else, stop here.
O checksum só significa alguma coisa depois que a assinatura é verificada. Calcule o hash do arquivo que você baixou e encontre essa string exata dentro do arquivo que acabou de verificar:
sha256sum linux64
grep -F "$(sha256sum linux64 | cut -d' ' -f1)" hashes.txt
# → one matching line. No output means no match: do not install it.
Depois, descompacte e coloque no lugar os dois binários de que você precisa. O arquivo traz um diretório versionado; monerod é o daemon, e monero-blockchain-prune é a ferramenta offline que você vai ficar feliz de ter caso mude de ideia sobre a poda.
tar -xjf linux64
cd monero-x86_64-linux-gnu-*/
install -m 0755 monerod monero-blockchain-prune /usr/local/bin/
monerod --version
Anote a string de versão que esse comando imprime em algum lugar onde você vá encontrá-la de novo. Quando uma atualização de rede for anunciada, você vai querer saber exatamente de qual versão está partindo, e "a mais recente" não é uma resposta.
Dê ao daemon seu próprio usuário sem privilégios e seu próprio diretório. Nada em um nó Monero precisa de root depois que ele está rodando, e um serviço que conversa com a internet aberta o dia todo é exatamente o tipo de serviço que você não quer rodando como root.
useradd --system --home /var/lib/monero --shell /usr/sbin/nologin monero
mkdir -p /var/lib/monero /var/log/monero
chown -R monero:monero /var/lib/monero /var/log/monero
/etc/monerod.conf — as mesmas opções que o monerod aceita na linha de comando, escritas sem os hífens iniciais. Remova a linha prune-blockchain se você decidiu por um nó completo; essa é a única linha que é irreversível.
# ── storage ────────────────────────────────────────────────
data-dir=/var/lib/monero
log-file=/var/log/monero/monerod.log
log-level=0
max-log-file-size=104857600
prune-blockchain=1
sync-pruned-blocks=1
# ── P2P: the only port the firewall opens ─────────────────
p2p-bind-ip=0.0.0.0
p2p-bind-port=18080
out-peers=32
in-peers=48
no-igd=1
# ── RPC A: unrestricted, loopback only, for you ───────────
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
# ── RPC B: restricted, what a wallet is allowed to ask ────
rpc-restricted-bind-ip=127.0.0.1
rpc-restricted-bind-port=18089
# ── misc ──────────────────────────────────────────────────
zmq-pub=tcp://127.0.0.1:18083
db-sync-mode=safe
Os dois listeners RPC são a parte que vale a pena entender. A porta 18081 responde a tudo, incluindo chamadas administrativas, e está vinculada ao loopback, onde deve estar. A porta 18089 é a interface restrita: chamadas somente de leitura, sem detalhes internos sensíveis à privacidade, e é o que todo nó público da rede expõe. Aqui, as duas ficam em 127.0.0.1 de propósito — o passo 05 alcança a 18089 por meio de um túnel, em vez de abri-la.
/etc/systemd/system/monerod.service
[Unit]
Description=Monero full node
After=network-online.target
Wants=network-online.target
[Service]
User=monero
Group=monero
Type=simple
ExecStart=/usr/local/bin/monerod --config-file /etc/monerod.conf \
--non-interactive
Restart=on-failure
RestartSec=30
TimeoutStopSec=300
KillSignal=SIGINT
StandardOutput=journal
StandardError=journal
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
[Install]
WantedBy=multi-user.target
KillSignal e TimeoutStopSec não são decoração. O banco de dados quer fechar de forma limpa, e um daemon morto à força no meio de uma escrita pode voltar precisando de um reparo — ou de uma nova sincronização. O SIGINT pede que ele encerre de forma correta, e cinco minutos é o período de tolerância para deixá-lo terminar. Todo guia que omite essas duas linhas está a um reboot infeliz de distância de um fim de semana perdido.
systemctl daemon-reload
systemctl enable --now monerod
systemctl status monerod --no-pager
O daemon agora está percorrendo a cadeia desde o bloco gênesis, checando cada assinatura em anel e cada prova de alcance que encontra. Em NVMe com alguns núcleos, isso é um dia ou dois; é limitado por CPU e disco, não por banda, então um uplink mais rápido não vai encurtar o processo. Esse trabalho é o produto inteiro. Um nó que pulasse essa etapa seria apenas uma forma mais lenta de confiar em outra pessoa.
Acompanhe por um segundo shell. A linha de status informa a altura, a contagem de peers e o tempo restante estimado, e é todo o monitoramento de que a maioria dos nós jamais vai precisar:
monerod --rpc-bind-port 18081 status
journalctl -u monerod -f --no-pager
df -h /var/lib/monero # check this one more often than you think you need to
Não importe uma blockchain baixada. Existem arquivos na internet que prometem pular a espera, e importar um deles transforma um nó que você verificou em um nó que acredita em um arquivo que um desconhecido lhe deu. Isso anula a única coisa pela qual você veio até aqui. Se o tempo de sincronização é realmente inaceitável, a correção honesta é uma máquina com mais núcleos, não um atalho ao redor da verificação.
A armadilha do daemon de bootstrap. O monerod pode responder às consultas da carteira usando um nó público enquanto sua própria sincronização se atualiza, o que é uma conveniência com um lado perigoso: enquanto estiver ativa, o tráfego da sua carteira está sendo atendido exatamente pelo tipo de terceiro que este guia existe para eliminar. Se você a ativar para já começar a funcionar na primeira hora, coloque um lembrete no calendário e a desligue no momento em que a sua própria altura alcançar o topo. Um compromisso temporário que ninguém se lembra de encerrar é apenas a configuração antiga usando um nome novo.
Quando a altura para de se mover e passa a corresponder a um explorador de blocos em que você confia, o nó está no ar. A partir desse ponto, o daemon custa a você alguns gigabytes de tráfego por dia, um pouco de CPU, e nenhuma atenção adicional além das atualizações.
A interface RPC restrita está vinculada ao loopback, o que significa que atualmente não é alcançável por nada. Esse é o padrão correto, e o restante desta etapa trata de escolher como cruzar essa lacuna. Escolha uma — elas combinam mal entre si, e você só precisa de uma.
Opção A · túnel SSH — uma máquina, configuração zero. A resposta certa se você usa um único notebook. Nada de novo é instalado, nada de novo passa a escutar, e o túnel morre com a sessão. Sua carteira então aponta para 127.0.0.1:18089 como se o nó fosse local.
ssh -N -L 18089:127.0.0.1:18089 monero-vps
# leave it running; point the wallet at 127.0.0.1:18089
Opção B · WireGuard — vários dispositivos, sempre ativo. A resposta certa para um celular, mais um desktop, mais um notebook. O nó entra na sua rede privada e as carteiras o endereçam pelo seu IP de túnel, sem nenhuma porta exposta à internet. O guia do WireGuard constrói o túnel; o único passo extra aqui é deixar o daemon responder nele.
# in /etc/monerod.conf
rpc-restricted-bind-ip=10.8.0.1 # the node's WireGuard address
confirm-external-bind=1
# and in the firewall, only on the tunnel interface
ufw allow in on wg0 to any port 18089 proto tcp
Opção C · onion v3 — de qualquer lugar, sem porta, sem IP fixo. A resposta certa se você viaja, ou se quer o nó alcançável sem nenhuma porta de entrada em lugar nenhum. O Tor publica o serviço; não há nada para encaminhar e nada para varrer. O guia do serviço oculto cobre o torrc completo; a parte específica do nó são três linhas.
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-rpc/
HiddenServiceVersion 3
HiddenServicePort 18089 127.0.0.1:18089
# then read the address Tor generated for you
cat /var/lib/tor/monero-rpc/hostname
Seja qual for o caminho que você montou, o lado da carteira é sempre os mesmos três campos. No Feather: Settings → Node → adicione um nó personalizado, host e porta, e ative o proxy Tor se você escolheu o onion. No Monero GUI oficial: Settings → Node → Remote node, com "connect to a remote node" selecionado. No Cake Wallet: Settings → Nodes → add node, que aceita um endereço onion diretamente. Se você definiu um nome de usuário e senha na interface RPC, os três têm campos para isso.
Depois, confira se funcionou. A carteira deve mostrar a mesma altura do seu nó, e o nó deve mostrar mais um cliente RPC. Se a carteira ainda atualiza em um segundo redondo, provavelmente ainda está falando com o nó público padrão — a maioria das carteiras mantém o antigo na lista e volta para ele silenciosamente.
Sua carteira não entrega mais as transações a um desconhecido — ela as entrega ao seu próprio daemon. Mas esse daemon então as anuncia aos seus peers a partir do endereço IP do seu servidor, e peers guardam registros. O Monero já espalha uma nova transação por uma fase de retransmissão randomizada antes de ela se propagar, o que dificulta identificar o primeiro salto; enviá-la via Tor em vez disso elimina a questão por completo.
Uma linha resolve. O daemon continua sincronizando blocos pela clearnet — o que mantém a sincronização rápida — e roteia apenas as transmissões das suas transações de saída pela porta SOCKS local do Tor:
# in /etc/monerod.conf, with tor running locally
tx-proxy=tor,127.0.0.1:9050,16
Se você quiser ir além e também aceitar peers via Tor, publique um segundo serviço oculto para o lado P2P e diga ao daemon qual endereço onion anunciar. O número da porta é escolha sua, desde que os dois lados concordem e nada mais na máquina já o esteja usando:
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-p2p/
HiddenServiceVersion 3
HiddenServicePort 18084 127.0.0.1:18084
# /etc/monerod.conf
anonymous-inbound=YOUR_ONION_ADDRESS.onion:18084,127.0.0.1:18084
Esse passo ajuda mais a rede do que ajuda você, o que é um motivo perfeitamente bom para tomá-lo. Custa um pouco de latência e alguns slots de peer, e significa que nós somente Tor têm onde se conectar.
Opcionalmente: doe um nó público. Se você tem a banda e o disco, pode anunciar seu endpoint RPC restrito para que as carteiras de outras pessoas possam usá-lo. É uma contribuição genuína para uma rede cujo ponto mais fraco é o pouco número de pessoas que rodam seu próprio daemon — e isso vem com as obrigações de qualquer serviço público: você vai carregar o tráfego de outras pessoas e vai ficar visível como operador de nó. Todo plano aqui vem com banda ilimitada, então a primeira dessas obrigações é uma decisão, não uma conta.
# only if you mean it: expose the RESTRICTED port, never 18081
rpc-restricted-bind-ip=0.0.0.0
confirm-external-bind=1
public-node=1
# and open it: ufw allow 18089/tcp
Um nó também é algo interessante para colocar ao lado de outra infraestrutura auto-hospedada — um nó Lightning no mesmo rack, por exemplo. Mantenha-os em máquinas separadas se o orçamento permitir: eles têm requisitos de uptime diferentes e histórias de recuperação bem diferentes.
O daemon para, e o banco de dados pode precisar de uma passagem de reparo antes de abrir novamente. Verifique o espaço livre diariamente durante a sincronização, e dimensione o plano para a cadeia de daqui a três anos, não a de hoje.
A porta 18081 responde a chamadas administrativas. Ela pertence a 127.0.0.1 para sempre. Se algo externo precisar alcançar o nó, ele alcança o listener restrito na 18089, através de um túnel.
Adicionar seu nó à lista não o seleciona, e a maioria das carteiras volta silenciosamente para outro nó quando ele está inacessível. Compare as alturas e confirme que o nó reporta um cliente RPC conectado.
Adicionar isso depois não reduz um banco de dados já existente. Converter significa parar o daemon e rodar o monero-blockchain-prune, que precisa de horas e de espaço de trabalho. Decida antes do primeiro início.
Uma atualização de rede aconteceu e o daemon nunca foi atualizado. Ele não dá alarde — a altura simplesmente para de corresponder à realidade. Acompanhe os anúncios de lançamento e atualize antes da altura do fork.
SIGKILL no meio de uma escrita, geralmente vindo de uma unit systemd sem KillSignal e com um timeout de parada curto. Use SIGINT e dê cinco minutos, deixando o daemon fechar o próprio banco de dados.
Dez perguntas que surgem antes, durante e após mover uma carteira para um daemon que você mesmo roda.
Não. As carteiras Monero escaneiam no lado do cliente: a carteira pede ao nó um intervalo de blocos, baixa-os por completo e tenta decriptar cada saída localmente com a sua chave de visualização privada. O nó nunca recebe sua chave de visualização, sua chave de gasto ou seu endereço, e não consegue saber quais das saídas que acabou de entregar são suas. Essa é uma diferença arquitetural real em relação às carteiras leves do Bitcoin, nas quais o servidor normalmente é informado de quais endereços ou scripts observar. O que um nó remoto realmente aprende é a camada de rede: seu endereço IP, o fato de que uma carteira naquele IP está sincronizando, o intervalo de blocos que ela pediu — que delimita a altura de restauração da sua carteira — e, o mais importante, qualquer transação que você entregue a ele para transmitir. Esse último é o vazamento que vale a pena fechar.
Rode podado, a menos que você tenha um motivo para não fazer isso. Um nó podado descarta sete oitavos dos dados de assinatura em anel dos blocos antigos, mantém tudo o que uma carteira ou um novo peer realmente precisa de você, ainda assim valida a cadeia inteira por conta própria, e fica em torno de um terço do disco de um nó completo. Para um backend de carteira pessoal, o comportamento é indistinguível. Rode um nó completo se você quiser conseguir servir um nó novo fazendo sua própria sincronização inicial do zero, se você roda ferramentas no estilo explorador de blocos que leem dados históricos de transação arbitrários, ou se você simplesmente quer uma cópia arquivística completa. Decida antes da primeira sincronização: --prune-blockchain poda enquanto sincroniza, enquanto converter um banco de dados completo já sincronizado significa parar o daemon e rodar sobre ele a ferramenta separada monero-blockchain-prune.
Um nó completo passa de 240 GB em meados de 2026 e cresce na casa de dezenas de gigabytes por ano, então dimensione para a cadeia que você terá daqui a três anos, não para a de hoje. Um nó podado é aproximadamente um terço disso — hoje, algo entre 85 e 95 GB. Na prática, isso significa que uma Garrison (240 GB NVMe) é o lar confortável para um nó podado com anos de margem, e uma Ravelin (480 GB) é a máquina certa para um completo. Uma Sentinel com 120 GB comporta um nó podado hoje, mas vai fazer você repensar isso mais cedo do que gostaria. Confira o tamanho atual da cadeia antes de comprar o disco — este é o único número deste guia com desatualização garantida.
Um dia ou dois em NVMe para uma primeira sincronização, e ela é limitada por CPU e disco, não pela sua conexão. O daemon está verificando cada assinatura em anel e cada prova de alcance desde o bloco gênesis em diante; esse é o trabalho, e é o motivo pelo qual vale a pena rodar o nó. Duas coisas pioram muito isso: HD mecânico em vez de NVMe, o que pode transformar dois dias em uma semana, e ficar sem espaço em disco no meio do caminho. Duas coisas que ajudam menos do que se espera: mais banda e mais RAM além do que mantém as páginas do banco de dados aquecidas. Não importe um arquivo de blockchain baixado de terceiros para pular a espera — você estaria confiando exatamente na parte em quem se propôs a parar de confiar.
A irrestrita, nunca. A interface RPC irrestrita expõe chamadas administrativas, e deve permanecer vinculada a 127.0.0.1 durante toda a vida do nó. A interface restrita é outro objeto: responde apenas às chamadas somente de leitura de que uma carteira precisa, e é o que todo nó público da rede expõe. Mesmo assim, publicá-la em uma porta na clearnet anuncia "há um usuário de Monero aqui" para qualquer um que esteja varrendo o espaço de endereços. A ordem de preferência deste guia é: primeiro um serviço onion v3, depois um túnel WireGuard, em terceiro um túnel SSH para uma única máquina, e uma porta pública nua apenas se você decidiu deliberadamente doar um nó público à rede.
Um nó não guarda chaves, não custodia fundos e não pode movimentar o dinheiro de ninguém. Ele valida blocos e retransmite transações que outras pessoas já assinaram — a mesma postura de um relay de e-mail que carrega mensagens que não consegue ler. Essa é a realidade técnica; a realidade legal é jurisdicional, e este guia não é aconselhamento jurídico. O que muda conforme a jurisdição é quem pode obrigar o quê: o guia sobre as quatro jurisdições nórdicas percorre os estatutos que se aplicam a um servidor em Estocolmo, Helsinque, Oslo ou Reykjavík.
Só se você o atualizar. O Monero realiza atualizações de rede programadas, e um daemon rodando um conjunto de regras de consenso mais antigo para de seguir a cadeia principal na altura do fork — ele não avisa em voz alta, simplesmente trava ou se bifurca, e a sua carteira silenciosamente passa a reportar uma altura que já não corresponde à realidade. Assine os anúncios de lançamento, fixe a versão que você instalou em vez de seguir uma tag móvel, e coloque um lembrete no calendário para a altura de atualização anunciada. Esta é a forma mais comum de um nó auto-hospedado parar de ser útil: não é uma pane, é apenas um dono que parou de ler.
Roteie as transmissões das suas transações de saída via Tor — essa é a única configuração com um retorno de privacidade claro e barato, porque separa "esta transação entrou na rede" de "este endereço IP existe". Aceitar também peers Tor de entrada é um passo adicional que ajuda mais a rede do que ajuda você, e custa um pouco de latência. Rotear todo o tráfego de peers via Tor é a opção agressiva: funciona, e vai tornar sua sincronização inicial consideravelmente mais lenta, então a maioria sincroniza pela clearnet e depois muda o caminho das transações para o Tor. O guia do serviço oculto do Tor cobre o lado do torrc com mais profundidade.
Quase sempre é a altura de restauração. Uma carteira sem altura de restauração definida, ou com o valor zero, refaz a varredura da cadeia inteira desde o bloco gênesis toda vez que é restaurada, o que representa horas de trabalho local para nada. Defina a altura de restauração para o bloco que existia quando a carteira foi criada. A segunda causa é o caminho de rede: uma carteira em outro país conversando com o seu nó por um circuito onion saturado será mais lenta do que a mesma carteira em um nó público vizinho — esse é o preço da privacidade, e um túnel WireGuard costuma recuperar a maior parte da velocidade. A terceira causa, e a que passa despercebida, é que o seu nó ainda não terminou sua própria sincronização inicial e continua respondendo a partir de um daemon de bootstrap.
Porque um nó é um objeto de vida longa e publicamente alcançável, com suas transações passando por ele. Um nó completo fecha o vazamento entre a sua carteira e o nó de um desconhecido — e então abre um menor, entre o seu nó e quem quer que tenha alugado a máquina para você. Se o cadastro dessa máquina exigiu a digitalização de um passaporte e um cartão em seu nome legal, você apenas moveu a correlação, não a eliminou. Pagar em Monero pelo servidor que roda o seu nó Monero não é um slogan; é a única versão da configuração em que as duas camadas concordam entre si. O guia principal sobre hospedagem de VPS anônima percorre as três camadas de ponta a ponta.
A Garrison (4 vCPU, 8 GB, 240 GB NVMe, $7.90/mês) comporta um nó podado com anos de margem; a Ravelin (480 GB) recebe a cadeia completa. Banda ilimitada em todos os planos, sem e-mail no cadastro, sem documento de identidade, nunca.
Última revisão · 2026-10-12 · Fontes · Guias de usuário do getmonero.org (rodar um nó, poda, Tor e I2P), monerod --help na linha v0.18, documentação do Debian 12 e do Tor Project · Cadência · anualmente
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own LN node — bitcoind + LND or Core Lightning, on a VPS.
Accept Bitcoin and Lightning with no processor — non-custodial, no fees.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Hospedagem privada, construída no Norte.