Capsule Runtime & .mod Economy

Overview

The .mod system is the atomic execution and distribution unit in NØNOS.

A .mod capsule is:

Self-contained

• zkProof-bound (execution is provable)

• Mesh-native (can be seeded, executed, and verified entirely off clearnet)

• Economically integrated (micro-fees for operators baked into lifecycle)

This model deprecates “apps” and replaces them with verifiable compute capsules.

---

Lifecycle of a Capsule

Phase	Component	Description
Creation	Dev Kit / SDK	Developer builds .mod package via NØN Dev Kit. Capsule includes manifest, dependencies, and proof schema.
Signing	Local Signer	Capsule is signed with developer's ed25519 key.
Seeding	Mesh Node	Capsule is announced via mesh beacon.rs, with metadata for discoverability.
Execution	Capsule Runtime	Capsule runs inside deterministic, isolated environment (capsule.rs) with syscall restrictions.
Proof	zkExec Engine	Execution produces zkProof of correctness and adherence to manifest policy.
Settlement	Fee Module	Proof triggers micro-fee distribution to capsule seeders and execution nodes.

---

Deterministic Execution Environment

The runtime is non-POSIX and syscall-constrained, meaning:

No uncontrolled network calls

No uncontrolled file I/O

All syscalls go through verifiable syscall interface

Capsule state is hashed at every checkpoint via state.rs

Why? This allows zkProof circuits to validate execution without needing to trust the host OS, ensuring capsules can run across any NØN node without hidden behavior.

---

.mod Manifest

A .mod manifest contains:

[meta]
name = "zk-search"
version = "1.0.3"
author = "[email protected]"

[exec]
binary = "./bin/main"
hash = "sha256:..."
proof_schema = "./proofs/circuit.zkp"

[resources]
cpu = "500m"
mem = "256MiB"
net = "mesh-only"

[fees]
base = "0.0001 NONOS"
share_seeders = true
share_verifiers = true

---

Proof-of-Execution

Capsule runtime integrates with the zkExec engine:

Proof circuits are shipped inside capsule.

Execution trace is collected and passed through circuit.

Proof is verified locally first — mesh verification optional but incentivized.

Integration Points

verify.rs — local proof verification.

gossip.rs — rebroadcast proof receipts to mesh.

trust.rs — update peer trust score upon valid proof relay.

---

Micro-Fee Revenue Model

.mod execution generates three possible revenue streams for operators:

Actor	Revenue Trigger	Payout
Seeder	Capsule requested from cache	Base fee split
Executor	Capsule run completed w/ valid proof	Execution fee
Verifier	Third-party proof verification	Verification bounty

---

Fees are denominated in $NONOS and logged in local revenue ledger (depin.rs), enabling operators to track earnings even if temporarily disconnected from the blockchain.

---

Blockchain Settlement

While NØN-OS is mesh-first, settlements can be anchored to blockchain for:

Operator payouts

Capsule license enforcement

Historical proof registry

Workflow:

Revenue ledger batches micro-fees locally.

zkRollup batch constructed.

Settlement broadcast to blockchain.

This allows low-latency execution with eventual settlement — preventing high network fees from blocking capsule usage.

---

Economic Attack Resistance

Double Execution Attack → Each proof is bound to a nonce + execution hash; replays are rejected.

Fake Seeder Attack → Seeders must deliver correct capsule hash; mismatch slashes trust score.

Proof Forgery → zk circuits ensure execution trace is tied to binary + manifest hash.

---

Developer Incentives

Devs can embed royalty fees into capsule manifest.

Capsules can be open-source, closed-source, or zk-encrypted (logic hidden but provable).

Fee splits programmable (e.g., 50% to dev, 25% to seeders, 25% to verifiers).

---

.mod in DePIN Context

NØNOS .mod economy turns every operator into a DePIN node:

Operators contribute compute, bandwidth, and storage.

Every contribution is cryptographically provable.

Every provable contribution earns micro-fees.

Unlike traditional DePIN projects, NØN-OS:

Does not rely on centralized scheduling.

Allows operators to remain anonymous and sovereign.

Scales horizontally — more nodes = more capsule redundancy.

---

¨Next Steps

On-Chain Capsule Registry — discoverable by mesh & blockchain clients.

Post-Quantum zkProof Backend — future-proof against cryptographic break.

Capsule Composability — allow .mod capsules to call other .mod capsules within same proof context.