Skip to main content

Workflow

The PIVX Naming Service (PiNS) allows users to register, update, list, and transfer human-readable domain names (such as myname.pivx) and map them securely to PIVX shielded (Sapling) 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 Arbitrum.

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 market (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. Arbitrum Smart Contract: The Anchor​

The generated ZK proof and its public inputs are sent to the PiNSAnchor smart contract on Arbitrum. 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.

5. Distributed Indexers: The Resolvers​

Anyone can run an independent Indexer Node. Indexers scan the PIVX blockchain for domain transactions and scan the Arbitrum contract for verified root checkpoints. They apply the transactions locally, compute their own Merkle Tree, and verify that their local root matches the Arbitrum 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).