Smartchains with on-chain computations have developed a number of strategies to mitigate the cost of global consensus. Developers take pains to optimize every line of code for on-chain execution; every additional line of code carries economic risk from gas price volatility. Layer-2 rollups help at the cost of complexity, requiring developers to think about cross-chain state, bridge security, fragmented liquidity, and losing composability.
The NockApp framework eliminates this tradeoff. Applications built with NockApp define their own intents while remaining composable through Nockchain's shared proof layer. Applications built using NockApp are sovereign—each application can set its own appropriate rules while inheriting Nockchain's security and proof system. They are permissionless with no pre-approval or gatekeeper to deploy (and Nockchain is built to be censorship-resistant). And they're provable, taking advantage of the mathematical provability of the Nock ISA. With NockApp, developers spend their time building features instead of optimizing for on-chain gas costs. Sovereign applications compose trustlessly for a superior user and developer experience.
What Are Sovereign Applications?
Sovereignty means each NockApp defines its own consensus rules while settling to Nockchain's proof layer. A decentralized exchange can implement custom order matching algorithms—pro-rata, time-priority, or novel mechanisms. A game can use internal tokens with its own economic rules, convertible to $NOCK when players cash out. A DAO can define governance mechanisms that fit its community rather than adapting to platform constraints.
Each application maintains its own state and rules, but all can compose trustlessly through Nockchain's shared sequencing and atomic proof verification. This differs fundamentally from deploying separate chains or L2s (which fragment liquidity) or using shared platform rules (which limits the design space). Sovereign applications get both: custom consensus and seamless composability.
Architecture: Kernel and Runtime
Most developers will encounter NockApp as a two-component architecture, a runtime or virtual machine program which is internally running a Nock ISA program as a kernel.
The runtime is written in Rust and orchestrates:
- Network communications
- Nockchain connectivity
- File operations
- HTTP
- gRPC
- REPL/command-line interfaces, and other input/output operations
The kernel is written in the Nock ISA using a higher-level language like Hoon or Jock and contains the application's business logic—the part that needs to be provable. The kernel presents a standard interface for all interactions and effects.
A kernel presents several entry points as a standard interface. (We write these with a + to accord with Hoon's usage.)
+loadis used in upgrades, allowing the kernel to update itself in-place.+peekgrants read-only access to a kernel; sometimes this is called a scry. A peek requests data at a specific path. This is a lightweight way to obtain state information.+pokeaccepts and processes events, returning a list of events and an updated state. A poke event includes arbitrary nouns.
For example, the Nockchain wallet has a runtime that handles command-line arguments and Nockchain connectivity, and a kernel that contains the business logic for managing keys, constructing transactions, and interpreting blockchain state. When you query your balance, the runtime fetches data and the kernel processes it. When you send a transaction, the kernel validates and signs it, then the runtime broadcasts it.
Solid-State Programs
NockApp applications are "solid-state machines" that retain their state from previous execution with durable persistence. The application state is a Nock noun—a binary tree of unsigned integers. That's it: no hidden driver state or OS state that matters to the kernel.
With NockApp, there are no databases to configure, no object-relational mapping, and no serialization libraries. The application state is simply the deterministic result of the events it has processed. When an event arrives—a transaction from Nockchain, user input, a timer—the kernel processes it as a pure function:
old-state + event → new-state + effects
The runtime automatically persists the new state. The kernel never touches the filesystem, network, or any I/O. It just computes: given this state and this event, here's the new state and the effects I want to happen (send a network message, write a file, etc.). The runtime handles those effects.
For example, the wallet's state is roughly [keys balances last-block-height preferences]. When you receive $NOCK, the kernel processes the block event: old balances + incoming transaction = new balances. The runtime persists the updated state. Next time you start the wallet, it loads that state and continues from where it left off.
Intent-Based Execution
NockApp applications use an intent-based execution model. Instead of writing imperative transactions ("transfer 100 tokens from Alice to Bob"), developers express declarative intents ("swap 100 tokens for ETH at rate X or better").
Off-chain solvers (miners) find execution paths that satisfy valid intents, generate zero-knowledge proofs of correct execution, and submit these proofs to Nockchain for verification. Nockchain doesn't execute your application code on-chain: miners verify that execution happened correctly. (In practical terms, intents are architected on Nockchain as locks.) This also enables easier composability across independent applications: one application can watch another's state and behaviors from block to block.
This architectural choice enables trustless composition: multiple intents from independent sovereign applications can be bundled together with explicit dependency graphs, ensuring atomic execution without coordination overhead.
Why This Differs from Layer-2 Rollups
The NockApp architecture differs from traditional layer-2 rollups in fundamental ways:
- Motivation: Rollups exist to alleviate congestion on gas-based chains, batching transactions to reduce L1 costs and improve throughput. NockApp exists to enable sovereignty—each application has custom consensus while inheriting Nockchain's security.
- Execution model: Rollups compress computation but maintain the imperative transaction model. NockApp applications use declarative intents with consistent off-chain execution and on-chain verification.
- Composability: Rollups require trusted sequencers, complex bridges, or asynchronous message passing. NockApp sovereign applications compose trustlessly through intent bundling and atomic proof verification on a shared settlement layer.
- Elastic scalability: Because Nockchain blocks consist of proof hashes rather than full computation, and because blocks are elastic, NockApp applications don't need to optimize for on-chain execution. Nockchain's popularity doesn't degrade its performance: more applications and more usage simply mean more proofs being verified in parallel.
- Transparency: Sovereign applications built using NockApp check and post their own consistency checks over the chain's global state. You can think of this as a private consensus, but the upshot is similar to naive rollups: an internal but real consensus specific to the application and its requirements. And unlike many L2 consensus states, the base state of the distributed application can be recovered directly from Nockchain's global state as appropriate.
The base state of any NockApp can be recovered directly from Nockchain's global state. There's no separate data availability layer, no optimistic dispute periods, and no exit games. Just proofs.
Developer Experience
The runtime includes NockVM, which executes Nock code with performance optimizations called “jets”. These are hand-written implementations of common operations that run much faster than interpreting Nock directly, while remaining semantically identical. The code runs fast without sacrificing its formal verifiability.
As a general-purpose framework, NockApp provides a growing library of runtime capabilities:
- Stock I/O drivers (filesystem, HTTP, gRPC)
- Nockchain connectivity (local or remote)
- Template applications to start from
- Development tools (REPL, debugging, profiling)
Most developers won't need to write Rust directly. Templates through the Nockup build manager provide starting points for common application types. The upcoming Jock language will provide a more accessible alternative to Hoon for kernel development, with familiar syntax and powerful type inference.
Example: A Simple Counter
Here's a minimal NockApp kernel—an HTTP server with a counter that increments and decrements:
The runtime (sans imports):
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
let cli = boot::default_boot_cli(false);
boot::init_default_tracing(&cli);
let kernel = fs::read("out.jam").map_err(|e| format!("Failed to read out.jam: {}", e))?;
let mut nockapp: NockApp = boot::setup(&kernel, Some(cli), &[], "http-server", None)
.await
.map_err(|e| format!("Kernel setup failed: {}", e))?;
nockapp.add_io_driver(http_driver()).await;
nockapp.run().await.expect("Failed to run app");
Ok(())
}
The kernel (in Hoon):
/+ *http
/= * /common/wrapper
=>|%
+$ server-state [%0 value=@]
++ page
^- tape
%- trip
'''
<!doctype html>
<html>
<body>
<h1>Hello NockApp!</h1>
<div class="counter-display">
Count: COUNT
</div>
<form method="POST" action="/increment" style="display: inline;">
<button type="submit" class="increment-button">Increment Counter</button>
</form>
<form method="POST" action="/reset" style="display: inline;">
<button type="submit" class="reset-button">Reset Counter</button>
</form>
</body>
</html>
'''
--
::
=>|%
++ moat (keep server-state)
::
++ inner
|_ state=server-state
:: +load: upgrade from previous state
::
++ load
|= arg=server-state
^- server-state
arg
:: +peek: external inspect
::
++ peek
|= =path
^- (unit (unit *))
~> %slog.[0 'Peeks awaiting implementation']
~
:: +poke: external apply
::
++ poke
|= =ovum:moat
^- [(list effect) server-state]
=/ sof-cau=(unit cause) ((soft cause) cause.input.ovum)
?~ sof-cau
~& "cause incorrectly formatted!"
~& now.input.ovum
!!
:: Parse request into components.
=/ [id=@ uri=@t =method headers=(list header) body=(unit octs)] +.u.sof-cau
::
?+ method [~[[%res ~ %400 ~ ~]] state]
%'GET'
:_ state
:_ ~
^- effect
:* %res id=id %200
['content-type' 'text/html']~
%- to-octs
%- crip
^- tape
=/ index (find "COUNT" page)
;: weld
(scag (need index) page)
(scow %ud value.state)
(slag (add (need index) ^~((lent "COUNT"))) page)
== ==
::
%'POST'
?: =('/increment' uri)
:_ state(value +(value.state))
:_ ~
^- effect
:* %res id=id %200
['content-type' 'text/html']~
%- to-octs
%- crip
^- tape
=/ index (find "COUNT" page)
;: weld
(scag (need index) page)
(scow %ud +(value.state))
(slag (add (need index) ^~((lent "COUNT"))) page)
== ==
::
?> =('/reset' uri)
:_ state(value 0)
:_ ~
^- effect
:* %res id=id %200
['content-type' 'text/html']~
%- to-octs
%- crip
^- tape
=/ index (find "COUNT" page)
;: weld
(scag (need index) page)
(scow %ud 0)
(slag (add (need index) ^~((lent "COUNT"))) page)
== ==
==
--
((moat |) inner)
(There is an “outer kernel” which serves as a wrapper to provide operational details for the standard, or “inner kernel”. This will typically be invisible to the application developer.)
Use Cases
NockApp enables applications that were previously impractical:
- Decentralized Exchanges: Implement custom matching algorithms (pro-rata, time-priority, auction-based), dynamic fee structures, circuit breakers, and risk management—all formally verified and composable with other DeFi protocols.
- Autonomous Worlds: Build games with deterministic physics, verifiable randomness, and sovereign economies. Internal tokens can represent in-game assets, convertible to $NOCK through proven exchange rates.
- Novel Governance: DAOs and other online-first organizations can implement custom voting mechanisms, delegation schemes, or futarchy-style decision markets without platform constraints. Each DAO's rules are proven correct through ZK proofs.
- Oracles and Data Feeds: Build oracle networks with custom consensus rules, stake-weighted voting, or dispute resolution mechanisms. Multiple oracle NockApp applications can compose to provide redundant data sources with cryptographic guarantees.
- Financial Protocols: Create lending markets with private central limit order books, custom risk models, derivatives with proven settlement, or payment channels with formal correctness guarantees—all while composing trustlessly with other financial primitives.
The common thread for NockApp sovereign applications runs from seamless composability and mathematical guarantees to custom rulesets and structures.
Getting Started
Nockchain and the Nockchain CLI wallet are built atop NockApp, demonstrating the framework's production readiness. These also serve as reference implementations: examine their code to see how real applications structure their kernels and runtimes.
Template applications through Nockup make getting started straightforward. Choose a template that matches your use case, customize the kernel logic, and deploy. The runtime handles the infrastructure.
Conclusion
NockApp transforms how building blockchain applications works. By separating provable logic from I/O concerns, enabling sovereign consensus, and using intent-based execution, NockApp lets developers focus on application features rather than blockchain constraints.
Sovereignty without fragmentation. Composability without trusted bridges. Formal verification without performance penalties. These aren't aspirations—they're architectural properties of the NockApp framework, the infrastructure for the next generation of provable software.