# L1 Rollup Protocol: On-Chain Inputs and Outputs

This is a protocol implemented as a smart contract through which an on-chain UTxO represents the state of a rollup. 

Let’s look at the basic operations of the L1 rollup protocol.

1. The on-chain rollup state UTxO can be updated to reflect transactions added to the rollup.
2. Then the on-chain money can be added to the rollup state UTxO to make the funds available to its owner on the rollup.
3. On-rollup money can be removed from the rollup state UTxO and sent to an on-chain address of the owner’s choosing. 

The L1 rollup protocol does not define how the rollup data is stored off-chain or how transactions are added to it. But it merely defines the protocol through which changes to the rollup off-chain are reflected on-chain, and money can be added to and subtracted from the rollup. 

### Contract specification 

The L1 protocol respects a well-defined lifecycle for proof-state objects, such that they can be initialized, tracked, altered, and then finally shut down cleanly. 

Each proof state can be initialized with an NFT Asset Class to be used as a unique ID (UID) to track the proof state over its entire lifecycle. 

Having a well-defined lifecycle for proof-state objects allows the “NoFundsLocked” property to be satisfied so that no funds are ever stuck at a script address. 

## Validator Mechanics 

A given Orbis validator is parameterized with different asset classes for 

1. Identification 
2. Authentication
3. Assets accepted 

### Fallback mode 

In the event that the prover is offline for a protracted period of time (3 days), the validator will allow for a fallback option that allows users to retrieve their funds from the rollup. 

In this special case, users may submit a Fallback redeemer containing a list of UTxOs that they would like to retrieve from L2. 

The arithmetic circuit in this case will attempt to verify that: 

1. Only burn transactions have taken place in the rollup. 
2. Those burn transactions on L2 are signed by the users. 
3. The UTxOs burned on L2 correspond to the TxOuts provided in the redeemer on L1. 
4. At least 3 days have passed since the last L2 non-burn transaction. 

### Upgrade and governance process 

The validator will also allow the prover to move the UTxO to a new script address through the use of an “Upgrade” redeemer. 

The included zk-SNARK will prove that *n* of *m* members of the board (the governing body of Orbis) have signed off on the upgrade. 

Here, *n* and *m* are protocol parameters, and *m* is the number of board members; both numbers are potentially subject to change. The list of members of the board is part of the contract state and part of the statement to be proven. 

The coefficients of the fee calculation can be updated without upgrading the contract as long as *n* of the members of the board have signed off. In case of voting for an approval for a new board, the included zk-SNARK will prove that *n* of *m* members of the board have signed off on the election of the new board and that an approving vote for the new board occurred.