> ## 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.

# The trust layer

# The Trust Layer

Notareum positions itself as a dedicated trust layer for Web3, sitting between users and the underlying blockchain infrastructure. Just as HTTPS added a trust layer on top of HTTP, Notareum adds a trust layer on top of raw blockchain resources. The parallel is not superficial: HTTPS did not replace HTTP, it wrapped every HTTP interaction in a verifiable envelope. Notareum does the same thing for blockchain identifiers.

## Where the trust layer sits

```mermaid theme={"system"}
flowchart TB
    subgraph User["User Experience"]
        A[Wallets / Dapps / Exchanges]
    end
    subgraph Trust["Notareum Trust Layer"]
        B[.nota File Format]
        C[Resource Registry]
        D[Verification Engine]
        E[Validator Network]
    end
    subgraph Infra["Blockchain Infrastructure"]
        F[Ethereum / L2s / Solana / Bitcoin / Cosmos]
    end
    A --> B
    B --> C
    B --> D
    D --> E
    C --> F
    E --> F
```

Applications consume verified resources through SDKs. The trust layer handles parsing, signature verification, on-chain status lookup, and validator attestation aggregation. The underlying blockchain is the settlement substrate for the registry and the staking economy, but consumers of a `.nota` file never need to touch the chain directly unless they want to double-check verification status.

## Three roles in the layer

**Issuers** create and sign `.nota` files for resources they own or authorize. An individual signs their own wallet address. A DAO signs its treasury. A contract deployer signs its deployment. An exchange signs its deposit addresses.

**Validators** stake NOTA and attest to the authenticity of submitted resources. They earn verification fees and rewards for honest participation. They lose stake through slashing if they attest to fraudulent resources and lose disputes.

**Consumers** are wallets, dapps, custodians, and end users who read `.nota` files and check their verification status before acting. Consumers never need to stake or register anything. They only need an SDK or a small piece of verification logic.

## Offline verification

A key property of the trust layer is that signature verification works fully offline. A `.nota` file can be sent over SMS, printed on paper, or scanned from a QR code, and any party with the sender's public key can verify the signature without network access. On-chain verification status adds a second layer of trust that requires a read-only RPC call, but it is optional for many use cases.

```mermaid theme={"system"}
flowchart LR
    A[.nota file] --> B[Parse JSON]
    B --> C[Reconstruct signed message]
    C --> D[Recover signer address]
    D --> E{Matches claimed address?}
    E -->|Yes| F[Offline verified]
    E -->|No| G[Reject]
    F --> H{On-chain check?}
    H -->|Optional| I[Query registry]
    H -->|Skip| J[Accept with offline trust]
    I --> K[Check attestations + status]
```

## Trust is layered, not monolithic

The protocol deliberately separates levels of trust so integrators can pick what matches their use case.

* **Signature only.** Confirm the file was signed by the claimed address. Cheap, instant, fully offline.
* **Registry anchored.** Additionally confirm the resource is registered on-chain by its owner. Costs one RPC call.
* **Basic verification.** Three validators attested. Suitable for common consumer flows.
* **Enhanced verification.** Seven validators attested at 75% threshold. Suitable for high-value transfers.
* **Institutional verification.** Fifteen validators attested. Suitable for treasuries, custodians, and regulated flows.

Every step increases confidence at measurable cost. Integrators choose the right level for each surface. A consumer wallet might require "basic verified" before unhiding a saved contact. An institutional settlement system might require "institutional verified" before releasing a nine-figure wire.

## Why this design is open

Notareum is an open protocol, not a product. The specifications are public. The reference contracts are open source. The SDKs in TypeScript, Python, and Rust are MIT licensed. Anyone can run validators, register resources, and integrate verification without permission. The NOTA token coordinates the validator economy, but the file format itself is free for any use.

This matters for adoption. A chain-agnostic trust layer only works if it is adopted broadly, and broad adoption requires that no single party controls the protocol. Notareum Labs maintains the reference implementations and stewards the specification, but the protocol is designed to outlive any single steward.

## Next steps

* Read the [Protocol Overview](../protocol/overview.md) for the full architecture
* Skip to the [Quick Start](quickstart.md) to integrate
* Study the [.nota File Format](../protocol/nota-file-format.md) to understand the wire format
* Explore [Use Cases](../use-cases/wallet-address-sharing.md) for applied examples