Skip to main content

Settlement

N1's settlement layer provides the minimum functionality required to host and secure the network's execution - including its native financial modules - and keep their data, state transitions, and bridges verifiable.

Execution example​

To see what settlement guarantees, consider an execution environment running on N1 - for example the network's native financial modules. To prove honest execution for each block, the operator needs to:

  • Make transaction data available to users and validators.
  • Produce and verify a proof or receipt for correct execution.
  • Show that deposits and withdrawals were routed correctly.

N1 provides broadcast and verification primitives for that flow.

  1. Broadcast transaction data. The operator sends the block data to the data availability network, where it can be erasure coded and sharded across validators.
  2. Collect data availability proofs. The network keeps the data recoverable and binds it to a commitment that other clients can fetch and verify.
  3. Execute the block. The execution environment produces a receipt that binds the state transition to the data availability commitment.
  4. Verify and sign the receipt. Validators check the receipt, the data commitment, and the fork choice rule before signing a state transition certificate.
  5. Submit the certificate. The certificate is stored by the network and can be fetched by any client. Withdrawals are pushed into the operator outbox.

This avoids forcing every validator into a full two-phase commit for every network operation. Most writes can be treated as unordered set replication, and only bridging needs full ordering.

Liveness​

In a single-operator setting, the operator can go down or refuse to construct blocks. N1 uses the L1 as a clock and inbox for forced inclusion. Governance and monitoring can take over or force withdrawals if the operator stops serving users.

The operator model is flexible: the network can begin with a single operator and later move to a decentralized operator set for stronger liveness guarantees.

Bridging​

N1 supports the verification primitives required to bridge assets. Assets are bridged in with an operator-owned address and metadata that tells the network how to route them.

The settlement log holds an inbox of bridged assets for the operator. Withdrawals move in the opposite direction: the operator pushes messages to an outbox that is enforced by the state transition function.

Validator strategy during the transition​

Settlement security rests on validators, and the network increases how much of it does so over time.

Today: Proton single-operator model​

The network today runs on Proton with a curated operator. The driver streams deposits, batches actions into blocks, and commits those blocks to the Bridge contract. Validators monitor proposed blocks and halt withdrawals if they detect a bad update.

Next: Jito (Re)staking shared security​

The next phase integrates Jito (Re)staking on Solana. NCNs define how work is proven and slashed, Operators run workloads, and Vaults custody restaked SPL tokens and delegate stake.

Stake activates only when the NCN, Operator, and Vault all opt in. This gives N1 modular slashable security while broadening the operator set, strengthening the trust guarantees behind the network's native financial modules.

Future: Native N1 validators​

As the N1 validator set comes online, data availability sampling, proof verification, and rewards accounting move into the protocol. The network can still choose the operators and security model it needs, but the root of trust shifts from a curated setup to a broader validator set.