Read for structure
- Application type and runtime composition
- Extension and module boundaries
- Transaction and state interfaces
- Indexer and service responsibilities
BUILD / EXAMPLES
Examples turn the module map into concrete application types, services, events, and operational flows. Use them to understand responsibility boundaries before designing a custom chain.
A module name explains intent. An example shows where the module enters the application, what it depends on, and how its output becomes observable.
The Coins chain example is the clearest source-backed composition used across the Nunchi site. It connects a runtime and CLOB extension through the generic application type.
use nunchi_clob::ClobExtension;
use crate::CoinsRuntime;
pub type Application =
nunchi_chain::Application<CoinsRuntime, ClobExtension>;CoinsRuntimeClobExtensionnunchi_chain::ApplicationThe Coins indexer is a separate service for observing consensus summary events. It shows how finalized activity becomes an observable stream a product can build on.
Validators produce notarization and finalization summaries.
The indexer exposes activity through /consensus/summary/ws.
A UI can present height, view, digest, timestamp, and transaction count.
PRESENTATION NOTE
A product UI can replay this stream as a simulation before connecting a live network. The event shape stays the same, so the presentation carries over.
Identify each process and its Cargo package.
Trace the runtime and extension types into their modules.
Follow one transaction from admission to finalized state.
Find the events and services that expose chain activity.
Choose the example closest to your workflow. Write down every change required by your state model, participants, data path, and controls. That difference becomes the first architecture scope.