> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notareum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

# 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 tuple `N = (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

```mermaid theme={"system"}
flowchart TB
    subgraph L1["Layer 1: Users"]
        U1[Individuals]
        U2[Dapps & Wallets]
        U3[Exchanges]
        U4[Institutions]
    end
    subgraph L2["Layer 2: SDK"]
        S1[TypeScript]
        S2[Python]
        S3[Rust]
    end
    subgraph L3["Layer 3: Smart Contracts"]
        C1[NotaRegistry]
        C2[VerificationEngine]
        C3[ValidatorStaking]
        C4[NOTA / veNOTA]
        C5[FeeManager]
        C6[SlashingManager]
        C7[AccessManager]
    end
    subgraph L4["Layer 4: Validators"]
        V1[Basic Validators]
        V2[Professional]
        V3[Enterprise]
        V4[Institutional]
    end
    subgraph L5["Layer 5: Chains"]
        B1[Ethereum]
        B2[Polygon / L2s]
        B3[Solana]
        B4[Bitcoin]
        B5[Cosmos]
    end
    L1 --> L2 --> L3
    L3 <--> L4
    L3 --> L5
```

**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](../sdks/overview.md).

**Layer 3: Smart Contracts.** The on-chain backbone. See the [Smart Contracts](../smart-contracts/overview.md) 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

1. **Chain Agnostic.** All major networks are first-class. The file format carries chain context in every record.
2. **Human Readable.** A `.nota` file is JSON you can open in a text editor.
3. **Cryptographically Verifiable.** Every file carries a signature.
4. **Extensible.** Schema versions and governance-added resource types enable evolution without breaking changes.
5. **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 deterministic `bytes32` identifier computed identically in every SDK and contract:

```mermaid theme={"system"}
flowchart LR
    A[uint8 resourceType] --> D[abi.encodePacked]
    B[uint256 chainId] --> D
    C[bytes identifier UTF-8] --> D
    D --> E[keccak256]
    E --> F[bytes32 resourceId]
```

```solidity theme={"system"}
resourceId = keccak256(abi.encodePacked(
    uint8(resourceType),
    uint256(chainId),
    bytes(identifier)
));
```

Any party can independently derive the canonical ID for any resource. This deterministic computation is central to cross-SDK interoperability.

## The .nota file lifecycle

```mermaid theme={"system"}
stateDiagram-v2
    [*] --> Unverified: register
    Unverified --> Pending: requestVerification
    Pending --> Verified: quorum approved
    Pending --> Unverified: quorum rejected
    Verified --> Disputed: dispute filed
    Disputed --> Verified: innocent verdict
    Disputed --> Revoked: guilty verdict
    Unverified --> Revoked: owner revokes
    Verified --> Revoked: owner revokes
```

A resource enters the registry as `UNVERIFIED`. 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

Let `P_err` denote the probability of sending funds to an incorrect address. In legacy copy-paste workflows:

```
P_err_legacy = P_input + P_spoof
```

After `.nota` integration with validator trust coefficient `V_t`:

```
P_err_nota = (1 - V_t) * P_spoof
```

At `V_t = 0.98`, error probability drops by more than 98% relative to legacy flows.

## Byzantine fault tolerance

For an `n`-validator quorum with independent failure probability `p`:

```
P_fail = p^n
```

At `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](nota-file-format.md) for the wire format
* [Resource Registry](resource-registry.md) for on-chain registration and aliases
* [Verification Engine](verification-engine.md) for the attestation lifecycle
* [Validator Network](validator-network.md) for the validator role
* [Staking and Tiers](staking-and-tiers.md) for validator economics
* [Slashing](slashing.md) and [Dispute Resolution](dispute-resolution.md) for misbehavior handling
* [Fee Model](fee-model.md) for fee economics
* [Governance](governance.md) for veNOTA and parameter management
* [Security](security.md) for the threat model