Custody chain

Why the pool operator cannot take, redirect, freeze, or even briefly hold the funds — explained for non-technical readers.

The short version: FleshSimulator generates one Monero wallet on their own computer, writes down the 25-word seed, and gives the pool operator only the public address and a read-only "view key." From that moment on, every coin the pool ever earns is paid by the Monero network itself — directly into FleshSimulator's wallet. The operator's server is a referee that helps coordinate the miners; it is not a bank that holds the money.

1. What FleshSimulator does (the entire list)

Step 1 — Generate a Monero wallet on a computer FleshSimulator controls

Generate a fresh Monero wallet using whichever wallet software FleshSimulator prefers — the choice doesn't matter to the rest of the chain, as long as it produces a primary address and a 25-word seed.

The wallet generator shows a 25-word seed phrase. Mathematically, these 25 words are the only thing in the entire world that can spend any money sent to that address. Write them on paper. Put the paper somewhere safe (fireproof box, safety deposit box, sealed envelope at a trusted relative's house). Do not photograph them. Do not type them into anything online. Do not share them with anyone — including the pool operator, including "Monero support," including anyone who claims they need them. There is no legitimate reason anyone other than the wallet owner ever needs the seed.

Step 2 — Get the address and the secret view key

From the wallet software, copy two strings:

Step 3 — Hand those two strings to the operator

Over any trusted channel (Signal, encrypted email, on paper). The operator plugs them into the pool server.

That's the entire setup process from the creator's side. No logging into the pool, no entering passwords on the operator's machine, no signing anything with the seed. The operator could vanish tomorrow and FleshSimulator would lose nothing.

2. How the money actually moves

  1. A volunteer miner runs xmrig pointed at stratum.fleshball.org:3334. They are donating compute; they receive nothing back.
  2. The pool server bundles their work with everyone else's and asks the Monero network: "construct a candidate block whose reward is paid to address 4... (FleshSimulator's address)." That requested address is hard-coded in the pool's config file, which is published publicly so anyone can verify the pool is requesting the right address.
  3. When the combined hashrate of the pool eventually solves a block, the Monero network itself writes a coinbase transaction. Its only output goes to the address from step 2 — FleshSimulator's address.
  4. FleshSimulator's wallet, on FleshSimulator's own computer, sees the coinbase the next time it syncs. The funds are theirs. The operator's server was not involved in this step at all. The Monero network paid the creator directly.

3. Four independent locks against operator theft

This isn't "trust me." It's four overlapping technical guarantees, each of which would have to be defeated independently for the operator to take a single coin.

1The wallet on the operator's server is view-only

The wallet running on the pool's machine was generated from the view key (read-only). It has no spend key. In Monero, spending requires a digital signature that can only be produced by the spend key. The view key, by mathematical construction, cannot produce that signature. If the operator types transfer into the wallet, it returns the error This wallet is watch-only. Cannot spend. Anyone can verify this — see Proof 3.

2The pool fee is 100% to the creator's address — there are no payouts to construct

The pool's config contains pool-fee = 1.0. 100% of every block reward is allocated to the wallet address (FleshSimulator's). Miners get 0% (they are donating). With no payouts to make, the pool software never even attempts to construct a spending transaction. Even if Lock 1 were defeated, there's no payout machinery to abuse.

3The destination address is published and witnessed on every block

FleshSimulator's address is written into the coinbase output of every single block the pool finds. Anyone — donors, journalists, lawyers, you — can pick any block from the pool's stats page, look it up on a public block explorer like xmrchain.net, and decode the coinbase. If it ever shows an address that isn't FleshSimulator's, that's caught immediately and publicly. Redirected payments cannot be hidden; the blockchain is the world's most public ledger.

4The operator's entire deployment is open source, with pinned versions

Every config file, every systemd unit, every line of nginx config, the exact build commit of monero-pool and the Monero daemon — all of it lives in a public GitHub repo. The operator cannot quietly change a setting; any change requires a public commit visible to everyone. The community is asked to compare the running pool's behavior against the published code, and any divergence is a flashing red flag.

Worst case

So what's the worst that can happen?

What the operator mathematically cannot do — full stop, with or without root — is spend any coin already paid to FleshSimulator's address. Lock 1 is enforced by the Monero protocol itself: no spend key on the server, no signature possible. Funds already in the wallet are untouchable from the operator's side.

What a maliciously rooted operator could attempt is to redirect future block rewards by overwriting the on-server config and regenerating the on-server wallet to watch a different address. They cannot keep that hidden — Lock 3 catches it within one block (~2 minutes): any donor running the proofs in VERIFY sees the coinbase paying the wrong address. Lock 4 makes the config change publicly visible the moment they push it; refusing to push doesn't help, because the running pool is then verifiably out of sync with the public repo, which is itself a red flag.

To shrink that window further, both pool.conf and the on-server wallet keys are locked with the kernel chattr +i (immutable) flag right after configure. Even root can't edit them without consciously unlocking — a deliberate, auditable action. The realistic worst case is "operator briefly redirects future blocks before being caught publicly," and the recovery is straightforward: another operator stands up the same open-source stack pointing at the same address, miners point at the new pool. The operator can also simply shut the pool down, in which case nothing is lost except the fundraising channel.

In every case: FleshSimulator's wallet, seed, and any funds already received are on their own machine and entirely under their control. The operator never had them and cannot reach them.

4. Trust the math, not the operator

5. Glossary

Address — Public Monero "account number," starting with 4.... Sharing it is safe; it's how anyone sends Monero.

View key — Read-only key derived from the wallet. Lets the holder see incoming transactions, cannot send/spend/modify. Sharing it gives visibility, not power.

Spend key / seed — The 25-word phrase. The only thing that can authorize spending. Lives only on FleshSimulator's machine, on paper, never online.

Coinbase — The first transaction in every block, created by the network itself, paying out the block reward. Every coinbase from this pool pays FleshSimulator directly.

View-only wallet — A wallet with the view key but not the spend key. Can see balances and incoming funds. Cannot send. This is what runs on the pool server.

Hashrate — Speed at which a miner does the cryptographic work that contributes to finding blocks. Hashes per second (H/s, KH/s, MH/s, GH/s).

Stratum — Network protocol miners use to talk to a pool. stratum+ssl://stratum.fleshball.org:3334 is what donors put in their xmrig config.

This document is open source. If anything is wrong, misleading, or unclear, file an issue or PR at the deployment repo.