Building a Privacy-First Monero + Tor Infrastructure for MyZubster
Today we reached another important infrastructure milestone for MyZubster: a self-hosted Monero node is now running on our VPS, with a restricted RPC interface exposed through a dedicated Tor Onion Service.
This is not a mockup or an architectural proposal.
The infrastructure is running, Tor connectivity has been tested, and the Onion RPC endpoint has been successfully queried end-to-end.
The blockchain is currently synchronizing, and once synchronization is complete we will move to the next milestone: the first real XMR transaction handled by the MyZubster infrastructure.
Why Monero?
MyZubster is increasingly being designed around a simple principle:
Privacy should be infrastructure, not an optional feature added later.
For payments and economic interactions, that naturally led us to experiment with Monero.
But simply creating a wallet and connecting it to an arbitrary public node would not have been enough.
A public remote node introduces another party into the architecture. Even though Monero protects transaction information at the protocol level, network metadata still matters.
So we decided to build toward something more independent.
Step 1 — A Dedicated MyZubster Monero Wallet
We created a dedicated operational Monero wallet on the VPS.
Instead of using the primary wallet address for every purpose, we also created a dedicated subaddress for the first MyZubster transaction.
Conceptually:
MyZubster Operational Wallet
│
├── Primary address
│
└── myzubster-first-tx
│
└── first experimental XMR transaction
Private wallet material remains private.
Seed phrases, private keys and wallet passwords are not part of the public MyZubster infrastructure and should never be committed to GitHub or exposed through an API.
Step 2 — Running Our Own Monero Node
The VPS is now running:
Monero Fluorine Fermi
v0.18.5.1
The node is configured as a pruned node.
This was an intentional infrastructure choice.
Instead of requiring storage for the complete historical blockchain representation, pruning allows us to participate in the Monero network while reducing storage requirements.
The node is currently synchronizing against Monero mainnet.
During today's work we observed it progressing from the early synchronization stages through hundreds of thousands of blocks.
At the latest check:
height: 479116
target_height: 3747546
busy_syncing: true
synchronized: false
So the infrastructure is operational, but we are deliberately waiting for full synchronization before calling the payment layer production-ready.
Step 3 — Separating P2P and RPC Interfaces
We did not want the administrative RPC interface exposed publicly.
The current network layout separates the services:
0.0.0.0:18080
│
└── Monero P2P
127.0.0.1:18081
│
└── local RPC
127.0.0.1:18089
│
└── restricted RPC
This distinction is important.
The normal RPC interface stays on localhost.
The interface intended for remote access is explicitly configured as:
restricted: true
But we went one step further.
We did not expose port 18089 directly to the public Internet.
Step 4 — Adding Tor
Tor was installed directly on the VPS and configured with a local SOCKS endpoint:
127.0.0.1:9050
We verified the Tor bootstrap sequence all the way to:
Bootstrapped 100% (done): Done
Then we independently tested outbound connectivity through the SOCKS proxy.
The result confirmed:
{
"IsTor": true
}
So we knew the VPS could actually communicate through the Tor network before connecting it to the Monero architecture.
Step 5 — Creating a Dedicated Monero Onion Service
Next came the most interesting part.
We created a dedicated Tor Hidden Service for the MyZubster Monero RPC.
The architecture became:
Tor Network
│
▼
MyZubster .onion
│
▼
127.0.0.1:18089
│
▼
Monero Restricted RPC
│
▼
monerod
│
▼
Monero Mainnet
The Onion Service maps the external Onion endpoint to the restricted RPC running exclusively on localhost.
The unrestricted RPC remains inaccessible through that path.
Step 6 — Testing the Onion RPC End-to-End
Creating an Onion address is easy.
Proving that the complete path actually works is more important.
So we queried the Monero RPC through Tor:
curl --socks5-hostname 127.0.0.1:9050 \
http://.onion:18089/get_info
And received a valid response from monerod.
Most importantly:
restricted: true
The node height also continued changing between requests, demonstrating that we were reaching the live synchronizing daemon rather than some static test endpoint.
For example:
height: 445832
restricted: true
synchronized: false
target_height: 3747545
That gives us a verified path:
Client
↓
Tor
↓
MyZubster Onion Service
↓
Restricted Monero RPC
↓
MyZubster monerod
↓
Monero Network
Step 7 — Making the Node Persistent
The next requirement was operational resilience.
A manually started daemon is useful for experimentation, but infrastructure should survive a reboot.
We therefore moved the Monero daemon toward a systemd-managed configuration while keeping:
P2P → :18080
Local RPC → 127.0.0.1:18081
Restricted RPC → 127.0.0.1:18089
Tor SOCKS → 127.0.0.1:9050
The node continues synchronizing while the Tor Hidden Service remains reachable.
Why We Are Not Sending XMR Yet
Technically, we already have a wallet and a receiving subaddress.
We could send XMR to it.
But that is not the milestone we want.
The local node currently reports:
synchronized: false
So we're waiting.
The first MyZubster transaction should happen when the complete stack can observe and verify it properly through infrastructure under our control.
The next target is therefore:
synchronized: true
Then:
Monero mainnet
↓
first XMR transaction
↓
MyZubster subaddress
↓
monerod
↓
monero-wallet-rpc
↓
MyZubster
↓
verification
From Wallet to MyZubster
The next development phase is especially interesting.
Once synchronization is complete, the operational wallet will be exposed locally through monero-wallet-rpc.
MyZubster will then be able to interact with the wallet programmatically without exposing private wallet credentials publicly.
The intended architecture is:
MONERO NETWORK
│
▼
monerod
│
┌────────┴────────┐
│ │
local RPC restricted RPC
:18081 :18089
│
▼
Tor Onion
monero-wallet-rpc
│
▼
MyZubster
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Payments Verification Rewards
This opens the door to much more than simply accepting donations.
Where This Could Go
A native Monero layer could eventually support MyZubster concepts such as:
bounties, contributor rewards, private payments, marketplace settlement, Proof of Contribution, permaculture projects, decentralized collaborations and community-funded experiments.
And importantly, this economic layer can coexist with the other privacy infrastructure already being developed around MyZubster.
Tor isn't being treated as a branding feature.
It is becoming part of the network architecture.
A Small but Important Principle
During development we deliberately rejected the shortcut of simply telling the wallet to trust an arbitrary clearnet remote node.
The Monero wallet itself warned us about the privacy implications.
That warning was useful.
Instead of disabling the protection, we built the missing infrastructure.
That resulted in:
Self-hosted wallet ✓
Dedicated subaddress ✓
Pruned Monero node ✓
Local RPC ✓
Restricted RPC ✓
Tor SOCKS ✓
Tor Hidden Service ✓
Onion RPC test ✓
Persistent node service ✓
Blockchain synchronization ⏳
First real XMR TX ⏳
MyZubster wallet RPC ⏳
This is the difference between adding a cryptocurrency logo to a project and actually building the infrastructure behind it.
What Comes Next
The next milestone is very concrete:
wait for the MyZubster Monero node to reach full mainnet synchronization and execute the first real XMR transaction.
After that, we'll connect monero-wallet-rpc to the MyZubster backend and start experimenting with automated payment verification.
Longer term, the goal is straightforward:
Build an economic layer where privacy, decentralization and verifiability are architectural properties rather than promises.
The node is running.
The Onion route is working.
The blockchain is syncing.
Now we wait for the chain — and then we send the first transaction.
MyZubster
Open source · Privacy-first · Decentralized infrastructure · Monero · Tor · AI · Real-world experimentation
