Skip to main content

Workflow

The PIVX Naming Service (PiNS) allows users to register, update the resolving address, transfer to another owners and list on marketplace human-readable domain names (such as myname.pivx) and map them securely to PIVX addresses.

Because PIVX is a UTXO-based blockchain without general-purpose smart contracts, it cannot natively run a complex database system like a domain registry. To solve this, PiNS uses a Rollup-style Architecture that executes operations off-chain, stores data on PIVX, and anchors security on BNB Smart Chain.

The system is powered by five interconnected components:

1. PIVX Blockchain: The Data Availability Layer​

Every action a user takes - registering a name (REG), updating an address (UPD), transferring ownership (CHG), listing on the marketplace (LST), unlisting (ULT), or buying (BUY) - starts as a native PIVX transaction. The transaction contains a structured text command in the transaction memo field (e.g. PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • The PIVX chain is the source of truth. It permanently stores every domain command. No state changes can happen without a recorded PIVX transaction.

2. The Registrar Node: The Sequencer​

An automated registrar node scans the PIVX blockchain. It reads the domain commands, verifies that the user paid the correct transaction fee, and queues the operations. Every 10 minutes the registrar bundles these operations into a single Batch.

3. SP1 zkVM: The Zero-Knowledge Engine (by Succinct)​

The batch of transactions is sent to the SP1 Zero-Knowledge Virtual Machine (zkVM). The zkVM runs a specialized Rust guest program that acts as a strict protocol referee. The prover checks every transaction in the batch:

  • Are the signatures valid and signed by the actual domain owners?
  • Are the nonces strictly increasing to prevent replay attacks?
  • Are the domain prefixes formatted correctly?
  • Does a BUY transaction pay the exact price specified in the LST transaction?
  • Does the old_root transition correctly to the new_root using mathematical Merkle proofs?

If all rules are met, the zkVM generates a ZK-SNARK cryptographic proof (using Groth16). This proof is a tiny certificate that mathematically declares: "Starting with state root A, after applying this valid batch of transactions, the new state root is B."

Every compiled version of this guest program yields a unique cryptographic identifier called the Verification Key (vkey). The vkey is a 32-byte hash of the compiled guest program's structure itself. If even a single line of the verification code is modified, the program compiles to a completely different vkey.

4. BNB Smart Chain Contract: The Anchor​

The generated ZK proof and its public inputs are sent to the PiNSAnchor smart contract on BNB Smart Chain. The contract acts as the settlement gateway.

  • The Cryptographic Bind: Inside the smart contract, the programVkey (the expected 32-byte hash of the guest program) is stored on-chain. When a proof is submitted, the contract forwards the proof and the programVkey to the Succinct SP1 Verifier Gateway.
  • Key-Lock Validation: The verification gateway will only approve the proof if it was generated by the exact guest program matching the registered programVkey.
  • If the proof is valid and verified against the registered programVkey, the contract updates the official, globally accepted state root to B and saves it in its history.
  • If a single rule was violated, or if the proof was generated using a modified guest program (which would produce a different vkey), the contract rejects the transaction, preventing unauthorized state transitions.

Why BNB Smart Chain​

The anchor chain's only job is to store a root and verify a proof, so what matters is how quickly a checkpoint becomes final and how confident you can be that it stays final.

  • ~2 second block times, so a batch is anchored almost as soon as it is proven, and indexers converge on a new checkpoint quickly.
  • No deep reorganisations in practice, so a checkpoint an indexer has synced to does not get pulled out from under it. An anchor chain that reorganises deeply would force indexers to unwind state they had already treated as settled.
  • Proof verification is a fixed, inexpensive on-chain cost regardless of batch size — one Groth16 verification covers every operation in the batch.

5. Distributed Indexers: The Resolvers​

Anyone can run an independent Indexer Node. Indexers scan the PIVX blockchain for domain transactions and scan the BNB Smart Chain contract for verified root checkpoints. They apply the transactions locally, compute their own Merkle Tree, and verify that their local root matches the on-chain checkpoint.

  • This ensures that all indexers, no matter where they are run, always resolve domains to the exact same target address (maintaining a single unified state on distributed ends).