Execution

N1 is agnostic to execution environments. Apps can run in specialized machines, general-purpose VMs, or language-native runtimes while communicating through ordered channels.

Overview

N1's default execution environment is an asynchronous network of virtual machines called processes. Each process can run a different VM and send messages to other processes through ordered channels.

For example, one process might be a TypeScript perpetuals exchange and another might be a Solidity contract. Both can interoperate without sharing one global state machine.

The gate app handles bridging assets from settlement and routing them to the correct app in the execution network. This simplifies topology and supports fast liquidity between apps.

Unique properties

N1's default execution network is unusual because it is designed to use the base layer for high-throughput data availability while letting apps specialize their own compute.

Dedicated compute

Existing blockchains run all applications on a shared VM. Sudden load creates state contention, gas spikes, and latency variance. That limits complex apps and makes developers optimize around chain constraints instead of product requirements.

In N1, each program runs in an isolated dedicated compute environment. That environment can use the full resources assigned to it and scale independently from unrelated apps.

Deploying can still feel familiar. Solidity developers can use Foundry, Rust developers can use WASM tooling, and TypeScript developers can use the tools they already know.

Instantaneous communication

Programs communicate point-to-point over ordered channels with binary messages. Each message triggers the receiver to execute the payload.

Unlike many bridge-style messaging systems, N1 messages can be executed as soon as they land in the destination process. Apps do not need to wait for a separate external bridge validation step for ordinary cross-app communication.

SNARK fraud proofs

A SNARK is a compact proof of computation. N1 uses this direction to support efficient execution today while preserving a path toward stronger verification over time.

In the optimistic model, SNARKs can be used as fraud proofs. A validator can replay data, detect an invalid state root, generate a proof showing the invalid transition, and submit that proof to the onchain verifier.

The process is non-interactive: once a challenger has a proof, it can be submitted directly. That avoids the long interactive dispute games used by some optimistic systems.

Data availability

Data availability is how N1 makes the history of transaction data downloadable by network nodes. Nodes use that data to reconstruct state transitions and verify that the state is legitimate.

This matters because an operator should not be able to withhold the data needed to create a fraud proof. N1 allocates data availability bandwidth on demand for apps, and that bandwidth is the main limit on app throughput.