A board that publishes what it earns usually asks you to believe a number. It prints a total, and behind the total is a database it controls and could edit before breakfast.
Monero makes that worse at first glance. Amounts are hidden, senders are hidden, receivers are hidden. So how does a board paid entirely in Monero prove it was paid anything at all?
With a transaction proof. Specifically an InProof, which is the one proof a receiver can produce, and it is what sits behind every row on the receipts page.
The three proofs, and why only one of them works here
Monero can produce three kinds of proof, and they answer different questions.
- SpendProof answers "I sent this transaction." Only the sender can make it.
- OutProof answers "I sent this transaction to that address." Also the
sender's to make.
- InProof answers "this transaction paid this amount to this address, and I
am the one who received it." The receiver makes it, using the view key.
A board is a receiver. It never has the sender's keys and cannot ask a bidder for a proof they may not want to make. So the InProof is not the convenient choice, it is the only one available, and it happens to be exactly the right one: it proves income without proving anything about who sent it.
What is actually published
For each settled payment, the board publishes the transaction hash, the subaddress the payment arrived at, the amount, and the signature.
Anybody can check it. Take those four things to any Monero node, including one you run yourself, and call check_tx_proof. The node reads the chain, verifies the signature against it, and returns the amount. The number comes back from the Monero blockchain, not from this server.
check_tx_proof txid the transaction address the subaddress it paid signature the InProof
If our published total did not match the sum of those payments, the arithmetic would fail in public, on a chain we do not control.
Why the wallet on this server cannot spend
The board runs a view-only wallet. It has the view key, which is enough to see incoming payments and to sign an InProof, and it does not have the spend key, which means it cannot move a single piconero.
That is the arrangement that makes the rest of it safe to publish. A server holding a spend key is a server worth attacking, and a board that asked you to send money to a hot wallet on a webserver would be asking you to share a risk that is entirely its own. The spend key was generated on a machine that is not this one and has never been on this one.
The console shows the wallet's own answer to whether it can spend, asked of the wallet rather than read off a config file, because that is the one claim this board cannot afford to be wrong about.
What a receipt does not prove
Two limits, said plainly.
It does not prove who paid. That is the point. Monero carries no sender, and an InProof does not add one.
A published receipt does make the transaction hash publicly known as a payment to this board. Nobody can be named by it, but if the payment was funded straight out of an exchange withdrawal, the exchange already knows what it sent and to where. That is a thread somebody might follow, so the bid form lets a payer decline a public receipt with one checkbox. The signature is then never made, rather than made and stored somewhere.
Payments with no published receipt are still counted in the totals and are marked as unproven rather than quietly dropped. A total that only counts the payments that made us look good would be the other way of lying about the same number.
Why this matters for a directory
Because the price of a rank is only meaningful if the numbers around it are real. If a board can invent its income, it can invent its traffic, and then every figure you would use to decide what a position is worth is decoration.
Anchoring the income to the chain is the cheapest way to make a whole page of claims checkable at once. The stats page shows the rest of the arithmetic, and the chain of daily seals makes it hard to quietly rewrite yesterday.