Nocturne
  • Introduction
    • Introduction
    • Protocol Overview
    • Compliance
  • Protocol Concepts
    • Keys and Stealth Addresses
    • Notes, Commitment Tree, Nullifiers, and JoinSplits
    • Deposits
    • Operations
  • Protocol Details
    • Algebraic Primitives & Notation
    • Keys & Key Derivation
    • Stealth Addresses
    • Signatures
    • Encodings
    • Commitment Tree
      • Subtree Update Circuit
    • JoinSplit Circuit
    • Note Encryption
    • Contracts
      • Deposit Manager
      • Teller
      • Handler
      • ETH Adapters
      • Canonical Address Registry
    • Offchain Actors
      • Deposit Screener
      • Bundler
      • Subtree Updater
  • Users
    • MetaMask Snap
    • FAQ
  • Developers
    • Contract Addresses
    • Trusted Setup
    • Security
    • Guardrails
    • Source Code
Powered by GitBook
On this page
  1. Protocol Details
  2. Contracts

Canonical Address Registry

PreviousETH AdaptersNextOffchain Actors

Last updated 1 year ago

As a UX feature, Nocturne supports mappings between Ethereum addresses and Nocturne canonical addresses via the Canonical Address Registry. This allows individuals to pay each other via Ethereum addresses and ENS names instead of manually keeping track of canonical addresses.

To register a mapping, the registrant calls the setCanonAddr function on the registry contract. To prevent "squatting" and fraudulent mappings, we require that:

1. The registrant calls the contract from the Ethereum address they'd like to register.

2. The registrant proves that they own the canonical address they're mapping via a using their spending key. Since verifying Baby JubJub signatures on-chain is expensive, we do this in a ZKP.

The digest being signed in the BJJ Schnorr signature is computed using EIP-712. The digest includes the Ethereum address, the canonical address to map to, a per-canonical-address nonce for replay protection, and the other standard EIP-712 info (e.g. chainId).

signature