Skip to main content

​
Whitepaper

The Notareum Protocol whitepaper is the canonical long-form reference for the protocol’s design rationale, cryptographic model, economic analysis, and roadmap. It is MIT-licensed alongside the rest of the project and built from LaTeX source at github.com/notareum/whitepaper.

​
Download

The PDF is regenerated on every tagged release. Tag names follow the protocol version (v1.0.0-alpha, v1.0.0, etc.). Each release attaches:
  • notareum-whitepaper.pdf (paper body)
  • notareum-whitepaper.tex.tar.gz (source archive)
  • SHA256SUMS (file hashes)
  • SHA256SUMS.sig (GPG signature over the SHA256SUMS)

​
Sections

The whitepaper is organized into six major sections. Line counts below are approximate for the current alpha release.

​
1. Introduction and motivation

Framing the problem Notareum addresses: the absence of a cryptographically verifiable, chain-agnostic identity layer for blockchain resources. Discusses the cost of phishing, address substitution, and impersonation in the current stack, with estimates of aggregate user losses. States the design goals: chain-agnostic, human-readable, cryptographically verifiable, extensible, lightweight.

​
2. Protocol specification

Formal definition of the protocol as the tuple N = (U, V, F, Sigma, Gamma) where:
  • U is the set of users and issuers.
  • V is the validator set.
  • F is the mapping from users to registered resources.
  • Sigma is the set of cryptographic signatures over .nota payloads.
  • Gamma is the governance and slashing ruleset.
Specifies the .nota file schema (v1.0), canonical serialization rules, and the deterministic resourceId computation. Details the verification request lifecycle, attestation structure, dispute window mechanics, and revocation semantics.

​
3. Cryptographic model

Defines signing and verification for every supported chain family:
  • EVM: ECDSA over secp256k1 with Ethereum’s personal-message domain separator.
  • Solana: Ed25519 over canonical bytes with no domain separator overhead.
  • Bitcoin: BIP-340 Schnorr signatures over secp256k1 with tagged hashes.
  • Cosmos: secp256k1 ECDSA with Amino-compatible canonical encoding or direct encoding as applicable.
Analyzes the Byzantine fault tolerance of the validator set under honest-majority assumptions. For an n-validator quorum with independent failure probability p, the quorum-fail probability is bounded by:
where r is the required approval ratio. At the Institutional level (n=15, r=0.75, p=0.05), P_fail < 1e-3; with the additional dispute window and slashing, the effective post-dispute failure rate is several orders of magnitude lower.

​
4. Economic model

Establishes the incentive structure:
  • Fee flows. Registration, verification, and dispute fees paid in NOTA, split 40% treasury, 20% burn, 40% validator rewards.
  • Staking yield. Baseline yield funded from the treasury validator-incentive allocation.
  • Attestation rewards. Per-round allocation proportional to tier multiplier.
  • Slashing losses. Rates per tier per reason; destination splits send shares to burn, treasury, and disputer.
Derives the equilibrium validator population under varying fee and reward parameters. Models attacker cost as C_attack = n * stake_tier + expected_slash_loss and shows that for Institutional-level attacks the cost exceeds the achievable gain by an order of magnitude under reasonable assumptions.

​
5. SDK coverage

Describes the three production SDKs (TypeScript, Python, Rust), their unified surface (ntm.nota, ntm.registry, ntm.verification, ntm.staking, ntm.governance, ntm.fee), and the byte-identical canonical serialization that ensures cross-SDK interoperability. Lists language-specific choices: ethers v6 for TS, web3.py 7 for Python, alloy for Rust. Summarizes test coverage: 159 TypeScript tests, 189 Python tests, approximately 127 Rust tests passing across unit, integration, and property-based suites.

​
6. Roadmap

Outlines the release milestones from alpha through mainnet, including:
  • Audit completion and formal verification of core invariants.
  • Additional chain integrations beyond the initial EVM + Solana + Bitcoin + Cosmos set.
  • ZK-attestation scheme for privacy-preserving verification without exposing issuer identity.
  • Governance decentralization milestones: foundation multisig phase-out, fully on-chain governance.
  • Ecosystem programs for wallet integrations, validator onboarding, and developer grants.

​
Building from source

Requirements:
  • TeX Live 2023 or newer (with xelatex).
  • latexmk.
  • biber for bibliography processing.
  • GNU Make.
A Docker build context is provided for reproducibility:
The Docker build pins every TeX package and font, producing bit-identical PDF across environments.

​
Citing

BibTeX entry:

​
Errata and updates

Corrections and clarifications are tracked in ERRATA.md at the whitepaper repository root. Substantive changes (new sections, corrected formulas) produce a new tagged release. Minor fixes (typos, formatting) are collected into each release without retroactive republication.