NOOSChain Overview

NOOSChain is a permissioned encrypted ledger for shared project and organization data. It combines signed transactions, role-aware nodes, bucket-level access control, encrypted payload handling, deterministic chain execution, replay verification, snapshots, operational runbooks, and a WASM smart-contract layer.

It is designed for environments where multiple known parties need a common source of truth, but not all data should be public to all participants. The chain records authoritative state transitions. Sensitive payloads are encrypted, hash-linked, and made available only to actors with the right keys and permissions.

What NOOSChain Solves

NOOSChain exists for shared data workflows where auditability, controlled access, and operational recovery matter at the same time.

A typical deployment has organizations, users, nodes, buckets, records, and validators. Users and operators submit signed transactions. Validator nodes order those transactions into blocks. Domain handlers apply the transactions deterministically. Encrypted record payloads stay outside the consensus-critical state, but their hashes, metadata, permissions, and key-sharing rules are tracked on-chain.

This gives the system three useful properties:

• The chain can be replayed and verified.
• Sensitive payloads can remain encrypted.
• Operators can recover, monitor, and audit the system with explicit runbooks.

Main Building Blocks

NOOSChain is organized around a small set of core concepts.

Organizations and users are identity-bearing actors. They can own resources, submit transactions, and receive permissions depending on the current chain state.

Nodes run the NOOSChain software. Validator nodes participate in consensus and block production. Observer nodes sync and serve read-oriented workflows without producing blocks.

Buckets are permissioned containers for records. Bucket policies and access rules decide who can read metadata, write records, administer the bucket, or access encrypted payloads.

Records represent stored project data. Their public metadata and indexes may be searchable, while sensitive payloads are encrypted.

Bucket keys and key envelopes control encrypted payload access. Payload encryption keys can be shared with allowed recipients without exposing plaintext to the whole network.

Transactions are signed state-change requests. Examples include creating organizations, registering users, creating buckets, updating bucket policy, writing encrypted record metadata, deploying contract code, or calling a contract.

Blocks are ordered batches of transactions. Consensus decides block order. Chain execution applies block contents deterministically.

Snapshots and replay verification support recovery and auditability. A node can export, verify, import, and replay chain state to prove that stored state matches the transaction history.

Smart contracts extend the system with deterministic WASM logic. Contracts are packaged, signed, registered, deployed, instantiated, called, upgraded, and monitored through explicit developer and operator workflows.

Architecture At A Glance

NOOSChain can be understood as a layered system.

At the edge are the API, CLI, admin GUI, and SDKs. These are the surfaces used by operators, applications, and smart-contract developers.

Below that is authentication and identity resolution. Requests are mapped to known actors, and transactions are signed so chain actions can be attributed and verified.

The transaction layer validates incoming transactions, gossips them between peers when enabled, and prepares them for consensus.

The consensus layer orders transactions into blocks. NOOSChain currently documents single-node mode, Noosraft, and a HashiCorp Raft sidecar path. These are crash-fault-oriented backends, not Byzantine-fault-tolerant consensus systems.

The execution layer applies transactions through deterministic domain handlers. This is where organizations, users, buckets, access rules, records, contracts, governance, and state-root behavior become chain state.

The encrypted payload layer stores payload bytes outside the consensus-critical state while keeping hashes, metadata, counters, and availability information tied to the chain.

The state, replay, and snapshot layer provides verification and recovery. Nodes can verify chain ranges, replay state, export snapshots, import snapshots, and use checkpoints depending on the configured state-root engine.

The observability and operations layer exposes health, readiness, metrics, alerts, repair commands, backup/restore procedures, incident response, and production gates.

The smart-contract layer provides a WASM runtime, host APIs, package provenance, ABI declarations, events, returns, migration workflows, and runtime readiness checks.

Normal Data Flow

A typical write starts with a user, operator, SDK, or contract workflow preparing a transaction.

The transaction is signed by an actor. The receiving node authenticates the request and resolves the actor against chain state. The transaction is validated and, in multi-node modes, propagated or submitted through the consensus path.

Validators order accepted transactions into blocks. Each node applies the block in the same deterministic order. Domain handlers update chain tables, such as identities, bucket rules, contract registry entries, record metadata, or governance state.

If the transaction refers to encrypted data, the plaintext is not placed directly into consensus state. Instead, the encrypted payload, payload hash, key envelopes, and access metadata are handled through the encrypted payload model. The chain can verify that the payload matches its recorded hash without making the payload public.

Later, operators and developers can verify the resulting state through replay checks, state-root checks, snapshots, observability endpoints, and production readiness commands.

Security Model

NOOSChain assumes a permissioned environment. Participants are known through configured identities, registered users, organizations, and node credentials.

The main security boundaries are:

• Signed transactions identify the actor responsible for state changes.
• Bucket permissions define who can read, write, administer, or access encrypted payloads.
• Payload encryption keeps sensitive bytes outside public chain state.
• Key envelopes distribute decryption capability only to intended recipients.
• Node credentials and TLS/mTLS documentation define trusted peer communication paths.
• Operator and observability APIs are admin surfaces, not public chain APIs.
• Smart contracts run inside a constrained WASM runtime with package, provenance, compatibility, and readiness checks.

NOOSChain's current Raft-based consensus documentation describes crash-fault-oriented backends. These are not Byzantine-fault-tolerant consensus mechanisms. That boundary should be clear to operators and system designers.

Consensus And Node Roles

NOOSChain supports different consensus modes for different maturity and deployment needs.

Single-node mode is useful for local development and simple deployments where one node owns block production.

Noosraft is an in-process Raft path used for development and integration scenarios.

HashiCorp Raft uses an external sidecar-style engine and has its own deployment, supervision, TLS, recovery, and operational guidance.

Validator nodes participate in consensus. Observer nodes sync chain state and support read-oriented workflows without producing blocks. Governance and membership reconciliation docs describe how validator and observer membership is represented and changed.

Smart Contracts

Smart contracts are a deterministic extension layer for NOOSChain.

Contracts are authored with the AssemblyScript contract SDK, compiled to WASM, described by manifests and ABI metadata, packaged, signed, registered, deployed, instantiated, and called through transaction workflows.

The contract system includes:

• Contract identity and registry state
• Package provenance and signing policy
• Runtime activation gates
• ABI methods, events, and return values
• Contract-to-contract calls
• Bucket access integration
• State migrations and upgrade workflows
• Runtime compatibility checks
• Operator monitoring and incident runbooks

This split matters: contract authors need authoring and publishing docs, while operators need launch gates, runtime rollout, monitoring, and recovery docs.

Operations

NOOSChain includes operational surfaces because running the chain is part of the product, not an afterthought.

Operators use the CLI, admin GUI, observability APIs, readiness checks, logging configuration, backup/restore procedures, repair recipes, incident response flows, and production monitoring rules.

Operational docs cover:

• Node configuration
• Operator authentication
• Organization, user, and bucket recipes
• Production readiness
• Monitoring and alerting
• Backup, restore, and rejoin
• Incident diagnosis and recovery
• Raft sidecar operations
• Nervos/state-root activation and recovery
• Smart-contract runtime operations

Evolving NOOSChain

Nooschain developers work below the user-facing and operator-facing surfaces.

The main evolution areas are:

• Protocol versioning
• Domain handlers
• Transaction schemas
• Consensus adapters
• Raft sidecar integration
• State-root engines
• Replay verification
• Snapshot formats
• Payload availability and backfill
• Smart-contract runtime integration
• Testing, benchmarks, soak suites, and generated reference docs

Generated TypeDoc reference is kept under the reference section. Human-authored docs should explain intent, architecture, workflows, and operational behavior. Generated reference should document exported code APIs.

Current Maturity

NOOSChain is documented as a permissioned encrypted ledger with active operator, smart-contract, state-root, consensus, and testing workflows.

Some areas represent production-readiness gates or intended operational boundaries rather than a claim that every backend is suitable for every production threat model. In particular, current Raft paths are not BFT. Operator APIs require administrative treatment. Smart-contract runtime activation and package provenance should be treated as controlled release processes.

Where To Go Next

• New to the system: read Quick Start, Data Buckets, Permission Model, Consensus Overview, Node Roles, and State Root.
• Writing contracts: go to Smart Contract Developer Documentation.
• Running nodes: go to Operator Documentation.
• Changing NOOSChain itself: go to Nooschain Developer Documentation.