# The Verus Identity System

Understanding VerusID — self-sovereign, on-chain, human-readable identity

A VerusID is a blockchain-native identity. Unlike a wallet address (a string of random characters), a VerusID has a human-readable name like alice@ that maps permanently to a cryptographic identity address (an "i-address" like i...).

Think of it as a domain name + a bank account + a passport, all in one:

• Domain name: A friendly name anyone can look up
• Bank account: Can hold and send funds
• Passport: Cryptographically proves who you are

The critical difference from traditional accounts: no company controls it. Once registered, your VerusID exists on the blockchain. No one can ban, freeze, or delete it — not even the Verus developers.

Traditional Account:
  You → Platform → Your Data
         ↓
  (Platform can lock you out)

VerusID:
  You → Blockchain → Your Data
         ↓
  (No single point of failure)

When you look up an identity with getidentity, you see its full structure. Here are the key components:

Every VerusID has:

• Name — The human-readable part (e.g., alice)
• Fully qualified name — Includes the chain namespace (e.g., alice.VRSCTEST@ on testnet, alice@ on mainnet)
• Identity address (i-address) — A permanent, deterministic address derived from the name. This never changes, even if the identity is updated.
• Primary addresses — One or more standard addresses (R-addresses) that control the identity. These can be changed.

A VerusID can have multiple primary addresses and a minimum signature threshold. This enables multisig control:

Single-sig (default):
  primaryaddresses: ["R_address_1"]
  minimumsignatures: 1
  → One key controls everything

2-of-3 Multisig:
  primaryaddresses: ["R_addr_1", "R_addr_2", "R_addr_3"]
  minimumsignatures: 2
  → Any two of three keyholders must agree

This is powerful for organizations, shared treasuries, or high-security setups. You can change your primary addresses at any time by updating the identity — so if a key is compromised, you can rotate it out without losing your name or identity.

Every VerusID has two special authorities:

• Revocation authority — An identity that can revoke (disable) this ID
• Recovery authority — An identity that can recover (re-enable) a revoked ID and assign new keys

By default, both point to the identity itself. But you can set them to different identities for security:

┌──────────────────────┐
│  alice@               │
│  Revocation: bob@     │  ← Bob can disable Alice's ID if compromised
│  Recovery: carol@     │  ← Carol can restore it with new keys
└──────────────────────┘

Why this matters: In traditional crypto, if your private key is stolen, your funds are gone forever. With VerusID, your recovery authority can revoke the compromised identity and restore control to you with new keys. It's like having a trusted friend who can freeze your credit card and issue you a new one.

Important constraints:

• Only the current revocation authority can change the revocation authority
• Only the current recovery authority can change the recovery authority
• This prevents an attacker who compromises your primary keys from reassigning these safety nets

Best practice: Set revocation and recovery to different identities that you control with separate keys, ideally stored in different locations. If all three (identity, revocation, recovery) share the same keys, you lose the safety net.

Every VerusID includes a content multimap — a key-value data store that lives directly on the blockchain. Keys are VDXF addresses (standardized identifiers in the Verus Data eXchange Format), and values can be any hex-encoded data.

┌─────────────────────────────────────────┐
│  Identity: yourapp@                     │
├─────────────────────────────────────────┤
│  contentmultimap:                       │
│  ├─ iK7a5FEI...  →  "profile data v1"  │
│  ├─ i8bC2xPQ...  →  "public key data"  │
│  └─ iD9eR3vW...  →  "service listing"  │
└─────────────────────────────────────────┘

VDXF keys are created deterministically from human-readable strings. For example, yourapp::data.v1.name always maps to the same i-address. This means anyone who knows the key name can look up the data — it's a universal namespace.

Use cases for content multimap:

• Store public profiles or service descriptions
• Publish public keys for encrypted communication
• Attach metadata (website links, social handles, configuration)
• Create attestations (proof of qualification, membership)

The content multimap is versioned — every update creates a new on-chain transaction. You can look up any historical version of an identity using getidentity with a specific block height. This creates an immutable audit trail: data can be updated but never erased from history.

The key insight: VerusID combines the self-sovereignty of a wallet (no one can take it from you) with the usability of a platform account (human-readable name, key recovery) and adds capabilities neither has (on-chain data, currency creation).

Understanding how names resolve is essential:

Format:              Resolves to:
─────────────────────────────────────────────
alice@               Top-level identity "alice" on current chain
alice.VRSCTEST@      Same as alice@ on testnet (fully qualified)
alice.yourapp@       SubID "alice" under "yourapp" namespace
alice.VRSC@          Same as alice@ on mainnet (fully qualified)

Key rule: alice@ and alice.yourapp@ are completely different identities. The first is a top-level ID; the second is a SubID under yourapp. If you use the wrong form, you'll get "Identity not found."

On testnet, the system appends .VRSCTEST to fully qualified names, so myid@ displays as myid.VRSCTEST@ in the fullyqualifiedname field. On mainnet, top-level names show as alice.VRSC@ in fully qualified form but can be referenced simply as alice@.

Every VerusID exists within a namespace — the chain or identity that serves as its parent. On the Verus mainnet, top-level identities like alice@ are in the VRSC namespace. On testnet, they're in the VRSCTEST namespace, appearing as alice.VRSCTEST@.

When you launch a currency or PBaaS chain, that currency's name becomes a new namespace. Anyone can register identities within it (if allowed by the currency's configuration).

A SubID is an identity registered under another identity's namespace. For example, if yourapp@ exists and has an active currency, someone could register alice.yourapp@.

Namespace hierarchy:

VRSC (root)
├── alice@                 ← Top-level identity
├── yourapp@               ← Identity with active currency
│   ├── alice.yourapp@     ← SubID
│   ├── bob.yourapp@       ← SubID
│   └── service.yourapp@   ← SubID
└── mypbaas@               ← PBaaS chain namespace
    ├── user1.mypbaas@     ← Identity on that chain
    └── user2.mypbaas@

SubIDs are useful for:

• Platforms that want to issue identities to users under their brand
• Organizations managing member identities
• Applications that need named, on-chain identities for components

The identity that owns the namespace controls the registration fee for SubIDs. This is set via definecurrency with the idregistrationfees parameter.

Registering a VerusID is a two-step process to prevent front-running:

1. Name commitment — You broadcast a commitment transaction that contains a hash of the desired name plus a secret salt. This locks in your claim without revealing the name. (See registernamecommitment)
2. Identity registration — After the commitment is confirmed (1 block), you broadcast the actual registration using the commitment's transaction ID and salt. (See registeridentity)

This two-step process ensures no one can see your desired name and race to register it first.

For SubIDs, the cost is set by the parent currency's idregistrationfees parameter. Verus uses 8 decimal places (satoshi values), so fees can potentially go very low. The 0.0001 VRSC standard transaction fee always applies on top.

When registering a root identity, you can specify a referral identity. This activates a multi-level referral chain that reduces the registrant's cost and rewards referrers.

How it works:

The registration fee (e.g., 100 VRSC) is divided into (levels + 2) equal parts, where "levels" is the idreferrallevels setting on the currency (min 0, max 5, default 3):

The parts are distributed as follows:

1. 1 part → discount (registrant pays less)
2. 1 part → burned / to rootID (miners/stakers)
3. 1 part per referral level → each referrer in the chain

If a referral level is unfilled (the chain isn't deep enough), that level's portion goes to miners/stakers instead.

Referral rewards are sent to each referrer's i-address (not their R-address).

Example — idreferrallevels=3 with a 2-level chain (verified on VRSCTEST):

We registered AgentOversight@ using SafeChat@ as referrer. SafeChat@ was registered using Verus Coin Foundation@ as referrer. The fee split into 5 parts of 20 VRSC each:

Power user strategy: If you own a chain of 3 identities (A → B → C, each referred the next), registering a 4th identity D using C as referrer costs 80 VRSC — but 60 VRSC flows back to your own identities (20 to C, 20 to B, 20 to A). Your net cost is only ~20 VRSC (the burned/rootID portion that goes to miners).

Note: The referral chain is visible on the public blockchain.

Command syntax:

verus registernamecommitment "newname" "controladdress" "referralidentity" "" "sourceoffunds"

The third parameter (referralidentity) accepts a friendly name like SafeChat@ or an i-address.

To enable referrals on your own currency, add "options": 8 (IDREFERRALS flag) to definecurrency and set idreferrallevels (0-5).

(Source: docs.verus.io — Defining Parameters)

To tie it all together, here's how VerusID maps to familiar concepts:

Each VerusID can optionally have attached private z-addresses (Sapling shielded addresses). This enables receiving private, shielded transactions directly to your VerusID. See Privacy & Shielded Transactions.

Verus Vault allows you to lock funds on your VerusID with a time delay. When locked:

• Funds cannot be spent until the timelock expires
• The identity can still stake its locked coins ("safe staking")
• Useful for trusts, vesting schedules, and protecting large holdings from theft

VerusIDs can create unforgeable, verifiable signatures on files, hashes, and messages. Anyone can verify the signature against the on-chain identity — providing non-repudiation tied to a human-readable name.

VerusID supports passwordless login to supported services. Instead of creating a username and password, you authenticate with your VerusID — proving ownership of the identity without exposing any private keys. This is similar to "Sign in with Google" but self-sovereign and decentralized.

VerusIDs, currencies, and tokens can be traded on the peer-to-peer on-chain marketplace using atomic offers. See Marketplace and Offers.

VerusID names can include all characters from all character sets except: / : * ? " < > | @ . — names are case-insensitive.

1. VerusID is more than a wallet — it's a complete identity system with naming, key management, data storage, and recovery built in.
2. You own it — Only you (or your designated revocation authority) can revoke your identity. No external party can shut it down.
3. It's recoverable — Unlike traditional crypto wallets, compromised keys don't mean permanent loss.
4. It's a namespace — Your identity can become a platform for SubIDs and currencies.
5. It's an on-chain database — The content multimap lets you publish verifiable data tied to your identity.

• getidentity — Look up any identity's full details
• registernamecommitment — First step to register a new identity
• listidentities — List identities in your wallet
• definecurrency — Launch a currency under your identity's namespace

As of Verus v1.2.x. Identity protocol version 3.