Trust & Privacy
What you can verify yourself
Nothing here requires trusting the operator:
- Every state change is signed. The circuit checks an Ed25519 signature by the key the operation requires, so a name cannot move without its owner's key.
- Every batch has a ZK proof. The anchor contract will not accept a root without one,
verified against
programVkey— a commitment to the exact compiled circuit you can rebuild yourself. - Every resolution comes with a Merkle proof. You can check the record against a root, and check the root against the contract. See Verifying Proofs.
- Every root is deterministic. Any indexer replaying the same commands must produce the same root, so disagreement is immediately visible.
- Roots form a chain, each anchored to the PIVX block height it covers.
What you have to trust
A short, honest list — everything else on this page you can check for yourself:
- PIVX and BNB Smart Chain work as designed — transactions are final, the chains do not reorganise beyond their confirmation thresholds.
- Standard cryptography is sound — SHA-256, Ed25519, and the SP1 proof system.
- A withdrawal reaches the address you nominated. Amounts, fees and obligations are all publicly auditable; the destination is the one detail confirmed by you rather than by an outside observer. Explained under Balances and withdrawals.
Replication is what makes the registrar accountable
The registrar publishes its protocol address and the viewing key for it. That is deliberate and load-bearing: with both, anyone can
- scan PIVX and decrypt every command and payment from genesis, in canonical order,
- replay them through the open-source indexer,
- compute the state root independently, and
- compare it against the root anchored on BNB Smart Chain.
A registrar that censors a paid command, invents a transfer, mis-credits a balance, or reorders operations produces a root that every independent indexer contradicts. No permission or special access is required to check.
The property this gives is fraud-evident, not fraud-preventing: a bad batch can land on-chain and be disproved afterwards. Recovery is social, not automatic.
Balances and withdrawals
Money does not move directly between buyer and seller. Sale proceeds credit the seller's internal balance net of the service fee, losing bids on a contested name are refunded to balance, and the user withdraws whenever they choose. Keeping funds in a balance is what makes refunds possible at all: a shielded transaction carries no sender address, so there is nowhere to automatically return a mistaken payment to.
Payouts are on-chain and attributed
The registrar publishes a full viewing key, not an incoming-only one, so outgoing payments are as visible as incoming ones. Every payout carries a memo naming the account it settles:
Payout #{id}: {gross} PIVX for pubkey '{pubkey}' (including the {fee}% service fee)
That makes the whole ledger reconstructible by anyone. Scan the protocol address with the published viewing key and you can see, for every public key:
- every credit it earned — sale proceeds and refunds, derived from the public command stream
- every payout it received, attributed by the memo, with the amount taken from the note value
- the service fee applied to each
which gives a running balance anyone can compute independently:
balance(pubkey) = Σ(sale proceeds net of fee) + Σ(refunds) − Σ(payouts sent) stays ≥ 0
A payout with no matching obligation, an incorrect fee, or a balance driven negative would all be visible to any observer. The registrar cannot quietly pay itself, skip an obligation, or apply a fee other than the published one.
Read amounts from the note, not the memo
The memo quotes the gross obligation — the balance before the service fee — while the note carries the net amount actually paid. A note's value is cryptographic; memo text is written by the registrar. When auditing, take every amount from the note value and treat the memo purely as attribution.
What the recipient confirms rather than an auditor
One detail sits outside that picture, and it is worth stating plainly rather than leaving implicit. A withdrawal is authorised on the website with your Ed25519 key, and that request travels over HTTPS rather than through the chain. An outside observer therefore sees that a correctly-sized payout was made for your account, but has no public record of which destination address you nominated.
In practice the person best placed to check that is you, immediately: you know what you requested and whether the funds arrived. And the check is not a matter of opinion — you keep the request you signed, so a mismatch can be demonstrated cryptographically rather than argued about.
| Confirmed by | |
|---|---|
| Domain state | Any observer, automatically — an independent indexer sees a root mismatch unprompted |
| Payout amounts, fees, obligations | Any observer, from the published viewing key and memo attribution |
| Payout destination | The recipient, against the request they signed |
Routing withdrawals through the memo transport would move the last row into the first category, at almost no privacy cost, since the viewing key and pubkey-naming memos already expose the link. It was considered and set aside in favour of keeping withdrawal a simple website action; it remains a reasonable future change rather than a defect.
Keep your signed withdrawal requests
Retain the signed request until you have confirmed the funds arrived. It is what turns a disputed payout into something you can prove.
What a malicious indexer cannot do
Cannot fake a record. Resolutions come with Merkle proofs, and a root that the anchor contract never accepted is rejected by the check in Verifying Proofs.
Cannot hide a registration. Absence is proven, not asserted: a Blocked terminal
carries the full blocking record so you can verify the claim rather than accept it. And
the whole history is re-derivable from the chain with the public viewing key.
Cannot disappear. Every command lives on PIVX and the code is open source. Anyone can rebuild the entire registry from the genesis block.
Private resolution over Tor
Resolving over the clearnet reveals to the server which names you look up, and when. The indexer API is therefore also published as a Tor hidden service:
http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion
In Tor Browser:
http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion/v1.0/resolve/richard.pivx
From the command line, with Tor running locally:
curl --socks5-hostname 127.0.0.1:9050 \
http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion/v1.0/info
It is the same API returning the same data, Merkle proofs included, so you lose nothing by using it. The server never learns your IP, and your ISP sees only that you used Tor.
Verification is what removes the trust, not the transport
Tor protects your privacy from the indexer. It does not make the indexer honest — the Merkle proof and the on-chain root check do that, and you should run them regardless of how you connect.