Open protocol · VerusID backed

Names you can trust.
Content you can verify.

VNR turns names like site.alice.VRSC@ into useful web addresses—owned through VerusID, resolved in the browser, and ready for signed, tamper-evident content.

Explore the flow Set up VNR
  • ✓ No daemon required
  • ✓ Provider choice
  • ✓ MIT licensed
Resolve a Verus name
V@
Verus Name ResolutionThe other address book.

1
NAMEsite.alice.VRSC@
valid
2
VERUSID RECORDvnr::name.route
query
3
DESTINATIONVerified HTTPS route
open

Interactive preview only. The extension queries your selected RPC provider.

Read-only lookup
VerusID backed
docs.alice.VRSC@ shop.maker.VRSC@ home.myid.VRSC@ blog.creator.VRSC@

Why VNR

A friendlier address.
A stronger foundation.

DNS tells your browser where to go. VNR adds a naming layer rooted in identities people control—and an optional content layer that proves exactly what was published.

01

Readable by humans.
Owned by an identity.

Publish a route beneath a VerusID you control. Registered subidentities can take precedence with records of their own.

02

Resolve your way

Use the public Verus RPC, a local gateway with failover, or your own synchronized daemon.

  • Public direct RPC
  • Local gateway
  • Custom provider
03

Verify every byte

Signed manifests bind publisher identity, revision, expiry, media type, size, and SHA-256 for every public file.

7c8f…e21a SHA-256

How it works

From a name to a verified destination.

VNR keeps the everyday flow simple while leaving the provider and trust choices in your hands.

  1. 01

    Type

    Enter a strict .VRSC@ name in the extension or use v + Space in the address bar.

  2. 02

    Resolve

    The client reads the active identity’s vnr::name.route record from your chosen provider.

  3. 03
    ✓

    Verify

    For signed sites, the server checks identity authority, on-chain binding, revision, expiry, and file hash.

  4. 04
    ↗

    Open

    NGINX serves verified bytes from an immutable cache over an ordinary HTTPS origin.

Trust model

Three layers.
One clear chain of trust.

Signed VNR content complements the web’s transport security. Each layer answers a different question.

i

HTTPS still matters. Verus signatures authenticate ownership and content; TLS protects the live connection and browser origin.

CONNECTION
⌁

TLS

01

Encrypts the connection and gives the browser a recognized secure origin.

PUBLISHER
V@

VerusID

02

Authenticates who signed the canonical site manifest.

CONTENT
#

SHA-256

03

Authenticates the exact size and bytes of every public file.

Get started

Pick your side of the address bar.

Browse in minutes, or publish a name and signed site you control.

FOR BROWSERS ↗

Resolve a VNR name

Load the build-free Chrome extension, keep the public read-only provider, and start from the popup or address bar.

  1. 1

    Open chrome://extensions

  2. 2

    Enable Developer mode and load client/extension

  3. 3

    Type v + Space, then your VNR name

Preview resolution
FOR PUBLISHERS ⌘

Publish a route

Encode a canonical route record, publish it in your identity’s contentmultimap, then increment the revision whenever it changes.

Terminal
PYTHONPATH=client/src python3 -m vnr.cli record \
  --name site \
  --target https://example.com \
  --revision 1
Add signed content
SIGNED CONTENT SERVER

Ready to authenticate the site itself?

Build a manifest, sign it with the owning VerusID, publish its hash on-chain, and let the VNR verifier authorize files for NGINX.

Build manifest→Sign with VerusID→Pin hash on-chain→Serve verified bytes

The other address book

Give the web a name
that belongs to you.

Start with VNR