# Overview & Architecture
Regen Network's architecture connects blockchain-based state with semantic metadata and modular application layers for displaying and sharing ecological data. Together, these components form a *registry system* which prioritizes interoperability, transparency, and long-term verifiability of climate and ecosystem claims.
## System Design
Regen’s architecture is guided by several core principles that ensure integrity, inclusivity, and adaptability across the ecosystem.
* **Transparency** — The system uses **public ledger** to establish integrity and provenance. Users anchor canonical registry actions—credit issuance and transfers, project registrations, governance, marketplace activity, and attestations—cryptographically on-chain to create an immutable, timestamped reference for each claim or dataset, so anyone can independently verify that off-chain content matches its on-chain commitment.
* **Interoperability** — The system stores information as linked data, emphasizing relationships—how projects, methods, evidence, places, and outcomes connect—rather than isolated tables. Shared vocabularies and standardized schemas makes datasets composable across systems so independent apps can publish and query ecological data without bespoke integrations.
* **Extensibility** — Applications can query, cache, and present registry information without running full nodes or duplicating backend logic. Public indexing and resolution services connect on-chain state with referenced metadata, letting multiple apps build on the same verifiable dataset—supporting bioregional registries, impact dashboards, or marketplaces with minimal overhead.
* **Data Privacy & Soverignty** — The system should support public verifiability while protecting sensitive information. Contributors can keep raw data permissioned or off-chain, while exposing only cryptographic proofs and descriptive metadata. This balances integrity, privacy, and community control over data access.
## Architecture Overview
The system comprises four interconnected layers, each serving a distinct role while remaining modular for flexible integration:
* **Regen Ledger** Serves as the verifiable integrity and provenance backbone. Rather than functioning as a full data store, the ledger acts as the **trust anchor**—ensuring that every claim, transaction, or governance action traces back to an immutable, timestamped, and verifiable on-chain reference.\
It records all stateful information (credit classes, projects, batches, ownership, retirements, marketplace orders, governance proposals) and stores immutable references (IRIs) to associated metadata with cryptographic proofs, allowing anyone to validate metadata against its on-chain hash.
* **Indexers** Listen to events from Regen Ledger and mirror them into structured databases for fast querying. This layer handles metadata resolution and caching, fetching RDF datasets, documents, or retirement information from IPFS or HTTPS endpoints, validating their hashes, and connecting on-chain state to its off-chain context.
* **Storage** manages persistent off-chain data: metadata files, supporting documentation, evidence, and media assets. This includes databases for indexed data, IPFS for distributed file storage, and RDF graph stores for semantic queries via SPARQL.
* **Applications** consume indexed and resolved data to create end-user experiences. The Regen App is the primary example, providing registry search, project views, and retirement certificates. Other developers can use the same data surfaces to build bioregional registries, dashboards, or marketplaces.
These layers work together but remain independent—applications don't depend on specific indexer implementations, indexers don't dictate storage formats, and everything ultimately verifies against the same ledger state. This modularity means developers can integrate at any level: query the ledger directly for maximum trust, use indexer APIs for convenience, or build entirely new interfaces on top of shared, verifiable data.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://guides.regen.network/technical-documentation/overview-and-architecture.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.