Skip to main content

Security Guarantees

This page states precisely what PiNS guarantees, and what it does not. Being exact is more useful than being reassuring: the parts that are strong are genuinely strong, and knowing where the edges are is what lets you rely on them.

The property: fraud-evident​

PiNS is fraud-evident. Every rule violation is either impossible to prove in the first place, or publicly visible to anyone who looks — and the data needed to look is published, so looking requires no permission and no cooperation from the operator.

The distinction worth understanding is between the two halves. Ownership and state transitions are enforced by cryptography and simply cannot be violated. Everything else is established by independent replication, where a deviation is contradicted by every replica at once. Both are strong; they are strong in different ways, and this page is explicit about which applies where.

What cannot happen at all​

These are enforced by mathematics. No operator action can bypass them.

  • A domain cannot be taken from its owner. Every state change requires an Ed25519 signature by the key the operation demands, checked inside the circuit with strict verification. The registrar does not hold your key and cannot forge one.
  • A name cannot be registered twice. REG requires a non-inclusion proof; a name that already exists cannot produce one.
  • A sale cannot happen at a price the seller did not sign. BUY asserts the paid price equals the listed price, which is pinned into the tree by the seller's signed LST.
  • A state root cannot be anchored without a valid proof. The anchor contract on BNB Smart Chain verifies every proof against programVkey before accepting a root. An invalid transition simply cannot be proven.
  • The circuit cannot be swapped silently. programVkey commits to the exact compiled program. Changing one line changes the key, and changing the key on-chain is a two-party action requiring both the sequencer and the owner.

What is verified by observation rather than by the circuit​

Some properties are not enforced inside the proof, and are instead established by anyone replaying the public data. That is a different mechanism, not a weaker outcome: these are checkable by any observer, without permission, and a deviation is visible to everyone at once rather than to a privileged few.

  • Command inclusion and ordering. The registrar assembles batches, so it is the registrar that puts commands in order. Because the protocol address and its viewing key are published, every independent indexer derives the same ordering from the chain itself and computes the same root. An omitted or reordered command produces a root that every replica contradicts, immediately and without anyone needing to look for it.
  • The end_block_height a batch reports. It is carried through to the public outputs rather than constrained inside the circuit, because replication already establishes it: an indexer replaying the chain knows which block the batch covered, so a wrong height is caught the same way any other deviation is.
  • Withdrawal destinations. Payout amounts, fees and obligations are fully auditable from the published viewing key — every payout carries a memo naming the account it settles, so anyone can reconstruct the balance ledger. What is not in the public record is which destination address the user nominated, since that request is made on the website. The recipient confirms that part directly, holding the request they signed. See Trust & Privacy.

Why replication is the real guarantee​

The ZK proof answers: given these inputs, were the rules followed?

Replication answers: were these the real inputs?

The second question is the one that matters most in practice, and it is not answered by cryptography — it is answered by the registrar publishing its protocol address and its viewing key, so anyone can decrypt the entire command history from genesis, replay it through the open-source indexer, and compare roots. A registrar that deviates produces a root that every independent replica contradicts.

This is why the viewing key being public is not a detail. It is the mechanism.

A sovereign rollup, precisely​

PiNS is structurally a ZK-rollup:

  • Data availability — every command lives in a PIVX transaction memo, with the payment in the same shielded note, so intent and payment are atomically bound.
  • Execution — off-chain, in the SP1 zkVM.
  • Settlement — BNB Smart Chain stores the anchored root and verifies proofs in seconds.

What differs from a typical rollup is that the data-availability layer is a privacy chain, so "anyone can read the inputs" requires the viewing key to be published — which it is.

Verifying this yourself​

Nothing above needs to be taken on trust:

  • Reproduce programVkey by compiling the prover and comparing against the contract.
  • Replay the chain with the published viewing key through your own indexer and compare roots.
  • Verify any individual resolution with a Merkle proof plus an on-chain root check — see Verifying Proofs.