N1's settlement layer provides the minimum necessary functionality to host
execution environments and ensure data availability. The new primitive we
provide is unordered set replication, with a hybrid storage model that
stores both ordered logs and unordered sets. Before explaining what these
concepts mean, let's start with an illustrative example. Suppose we want to run
a zk-rollup on N1 that provides an Ethereum Virtual Machine (EVM). We also want
to be able to bridge assets in and out from N1. To prove to our users that we
are acting honestly, we need to, for each Ethereum L2 block:

• Ensure transaction data is downloadable by all users.

• Construct and verify a SNARK proving correct execution of the block.

• Show that asset bridging was done correctly.

To do so, we'll use broadcast primitives provided by the network. The steps
taken for each block by the operator are as follows:

1. Broadcast transaction data

   The operator broadcasts the current block's transaction data to the data
   availability network. The data is erasure coded so that it can be efficiently
   sharded across the validators. The amount of client bandwidth used is then
   proportional to the size of the block for maximum efficiency.

2. Collect data availability proofs

   From here on, the network will continuously ensure data availability. During
   broadcast, the operator constructed a commitment to the data. This commitment
   binds us to the data and allows for verification and recovery. We include this
   commitment in our state transition proof. Any other client is able to fetch and
   verify the data.

3. Execute the block

   We run the block in the zkEVM, which produces a receipt proving that the
   transition was correct and that the block data matches the data availability
   commitment. This is important as it binds the receipt of the execution to the
   data availability from the network.

4. Verify and sign receipt

   The operator again broadcasts the zk proof and requests it be verified and
   signed by the validators. These signatures are aggregated into what we call a
   state transition certificate. While verifying, the validators also check
   the zkEVM's receipt to validate the data availability commitment and ensure the
   fork choice rule is respected. This prevents the operator from pushing invalid
   blocks. Only >2/3 of the validators are required to sign the certificate.

5. Submit certificate to the network

   Finally, the operator broadcasts the certificate to the network. Each validator
   checks the signature against the current validator set, and if it's correct,
   stores it. This certificate can be fetched and verified by any client. This
   write has no ordering constraint with writes by any other clients, hence why we
   say we're writing to an unordered set. The certificate also contains a list of
   withdrawals. The withdrawals are pushed to the operator's outbox and the operator's
   account balances are updated accordingly.

This is all that's needed to construct a rollup for the EVM. You'll notice that
at no point do the validators need to do the typical 2 phase commit protocol,
which has a quadratic number of messages exchanged. Instead, the operator is
analogous to the leader and handles the 2 phase commit. The number of messages
is linear in the number of validators, and the latency is constant. More
importantly, no other client is blocked from making progress. The key
primitives we need are various variants of broadcast. Specifically:

• Certifying and store a state transition certificate.

• Ensuring avalability of arbitrary data.

• Bridging assets in and out of an operator-owned account.

The only step that needs full ordering is the last one, for bridging. Given
that almost all operations remain within the L2, contention between
applications is minimal.

Liveness

In a single-operator setting, how do we ensure liveness? The operator could
always go down or refuse to construct any new blocks. The solution lies in the
ability to use the L1's blocks as a clock. The L1 can act as an inbox for
forced transaction inclusion, and also to enforce that the operator stay live.
Governance can be used to take over the operator and force withdraw remaining
funds. Additionally, we place no constraints on how the operator is run. It may
be run as a decentralized set of nodes as well to provide additional liveness
guarantees.

Bridging

The network supports the necessary verification primitives to construct
bridges. We provide a native IBC bridge to Solana and Ethereum. Assets are
bridged in specifying an operator owned address and VM-specific metadata
indicating how to route the asset within the VM. The N1's log holds an inbox of
bridged assets that the operator consumes. Similarly, for bridging assets out,
the operator pushes messages to the outbox which are enforced by the state
transition function.

Validator strategy during the transition

Today: Proton single-operator model

Each app today is operated by a single team running the Proton stack: the driver
streams deposits from Solana, batches the app’s actions into BlockFacts, and
commits them to the Bridge contract, which unlocks withdrawals only after
finalization. This model lets us ship dedicated compute with sub-second latency
while keeping the surface area small enough to iterate quickly. Meanwhile a
validator committee tracks every proposed block and halts withdrawals the moment
anything is wrong, forcing the operator to submit a corrected state update before
funds can move.

Next: Jito (Re)staking shared security

The next rollout phase integrates Jito (Re)staking on Solana so that NCNs,
Vaults, and Operators form explicit staking relationships:

• NCNs define how work is proven, how rewards flow, and how slashing occurs
  for a particular service or app.

• Operators run the off-chain workloads (apps, rollups, oracles) and agree
  to abide by NCN rules.

• Vaults custody restaked SPL tokens, mint liquid Vault Receipt Tokens
  (VRTs), and delegate stake to approved operators.

Stake only activates when all three parties opt in, giving us modular,
slashable security without rebuilding staking from scratch. Jito’s Solana
runtime enforces rewards, fees, and penalties at high throughput while we
expand the operator set.

Future: Native N1 validators

As N1’s own validator set comes online, data availability sampling, proof
verification, and rewards accounting migrate from the NCN into the protocol
itself. The handshake model survives; apps can still pick the operators and
security flavor they need; but the root of trust shifts from a curated NCN to a
broad set of restaked N1 validators, preserving performance while steadily
decentralizing responsibility.