Protocol Overview
The Notareum Protocol is an open standard for a Universal Transfer Interface (UTI) that enables verifiable, portable sharing of blockchain resources. This page gives the full architectural picture: the five layers that make up the system, how they interact, and where to look next for each detail. Formally, the protocol is a tupleN = (U, V, F, Sigma, Gamma) where U is the set of users, V the validator set, F the mapping from users to registered resources, Sigma the set of cryptographic signatures, and Gamma the governance and slashing ruleset.
The five layers
Layer 1: Users. Any entity that creates, sends, or consumes a.nota file. Individuals, dapps, wallets, exchanges, custodians, and institutions all live here.
Layer 2: SDK. Client libraries in TypeScript, Python, and Rust that wrap file creation, signing, parsing, validation, registry calls, and staking interactions. See the SDK Overview.
Layer 3: Smart Contracts. The on-chain backbone. See the Smart Contracts section for per-contract details. The core contracts are NotareumNotaRegistry, NotareumVerificationEngine, NotareumValidatorStaking, NotareumNOTAToken, NotareumVeNOTA, NotareumFeeManager, NotareumSlashingManager, and NotareumAccessManager.
Layer 4: Validators. Staked NOTA holders who submit attestations on verification requests. Organized into four tiers (Basic, Professional, Enterprise, Institutional) with corresponding stake minimums, daily limits, slash rates, and reward multipliers.
Layer 5: Chains. The protocol is chain-agnostic. EVM chains (Ethereum, Polygon, Arbitrum, Optimism, Base, BNB, Avalanche), non-EVM chains (Solana, Bitcoin, Cosmos ecosystem), and Layer 2 rollups are all supported as resource contexts in .nota files.
Core design principles
- Chain Agnostic. All major networks are first-class. The file format carries chain context in every record.
- Human Readable. A
.notafile is JSON you can open in a text editor. - Cryptographically Verifiable. Every file carries a signature.
- Extensible. Schema versions and governance-added resource types enable evolution without breaking changes.
- Lightweight. Typical file size is 1 to 2 KB with a maximum of 64 KB, enabling transport over messaging apps, QR codes, and NFC.
Resource identifier computation
Every on-chain resource has a deterministicbytes32 identifier computed identically in every SDK and contract:
The .nota file lifecycle
A resource enters the registry asUNVERIFIED. A verification request moves it to PENDING. Validator attestations either push it to VERIFIED (on quorum approval) or back to UNVERIFIED (on rejection). Verified resources can be challenged into DISPUTED and resolved by the arbitration committee. The owner can revoke a resource at any time, moving it to REVOKED.
Trust reduction model
LetP_err denote the probability of sending funds to an incorrect address. In legacy copy-paste workflows:
.nota integration with validator trust coefficient V_t:
V_t = 0.98, error probability drops by more than 98% relative to legacy flows.
Byzantine fault tolerance
For ann-validator quorum with independent failure probability p:
p = 0.05 and n = 15, P_fail = 3.05e-20, which is effectively negligible. Verification time complexity is O(k * log n) where k is the average attestation count per resource.
Where to go next
Each subsequent page dives into a specific layer.- .nota File Format for the wire format
- Resource Registry for on-chain registration and aliases
- Verification Engine for the attestation lifecycle
- Validator Network for the validator role
- Staking and Tiers for validator economics
- Slashing and Dispute Resolution for misbehavior handling
- Fee Model for fee economics
- Governance for veNOTA and parameter management
- Security for the threat model