LOW-LEVEL PRIMITIVES
Commonware
Runtime, peer communication, consensus, storage, cryptography, and reusable coordination components.
UNDERSTAND / ARCHITECTURE
A finance layer between primitives and product.
Commonware supplies replaceable low-level primitives. Nunchi connects them to finance-specific state and modules. Your team defines the application and operating model.
The three-layer model
FINANCE-SPECIFIC LAYER
Nunchi SDK
Financial state, authority, data, market modules, composition patterns, and developer examples.
PRODUCT
Your application chain
Your workflow, participants, controls, transaction policy, operating model, interfaces, and user experience.
CORE IDEA
Build the product-specific layer from reusable parts.
The chain can specialize its state, block behavior, data path, and controls while retaining a coherent set of finance-oriented components.
Responsibility boundaries
| Layer | Supplies | Primary references |
|---|---|---|
| Commonware | Runtime, networking, consensus, storage, cryptography, and coordination primitives. | Commonware index and crate-level Rust documentation. |
| Nunchi SDK | Finance-specific modules, composition patterns, chain scaffolding, and examples. | Nunchi repository, module source, and examples. |
| Your application | Workflow, product rules, participants, controls, operating assumptions, interfaces, and user experience. | Your product specification and deployment plan. |
Composition flow
Choose
Select the smallest set of infrastructure and financial modules required by the workflow.
Compose
Connect the runtime, extension modules, interfaces, and application state around product rules.
Operate
Run, observe, test, and evolve the network under its defined participant and security model.
Supported network shapes
Trading chain
Own order flow, financial state, oracle paths, and liquidity logic for a specialized exchange.
Private network
Compose a financial system around explicit participants, assets, permissions, and operating controls.
Sequencer or rollup
Use finance-oriented modules inside a settlement, execution, or interoperability architecture.
Architecture decisions
Before choosing modules, document the decisions that shape every layer of the system.
- Participant modelWho may submit, validate, operate, and observe?
- State modelWhich financial values must be canonical?
- Data pathWhich external data and cross-network messages are trusted?
- Transaction policyHow are transactions admitted, ordered, and executed?
- OperationsHow will the system be upgraded, monitored, and recovered?