Midgard is an optimistic rollup designed for Cardano. Its goal is to increase Cardano's transaction throughput and reduce confirmation times and fees, while preserving Cardano's decentralization and security. Midgard achieves this by offloading transaction execution to Layer 2 (L2), while relying on the Cardano network (L1) for data availability (future), fraud resolution, and final settlement. Introduction Users interact with Midgard by depositing tokens (in the form of Cardano UTxOs) through Cardano transactions into a smart contract. Once tokens are deposited, users can issue Midgard transactions, which are processed off-chain by operators. These L2 transactions are faster and cheaper than L1 transactions because they avoid costly on-chain computation. Midgard operators provide pre-confirmations almost instantly to indicate the acceptance of transactions into an upcoming block. However, the final settlement of the block—and all the transactions it contains—depends on the absence of fraud and the completion of the challenge period on Cardano. Pre-confirmation is an optimistic promise that the transaction will finally settle if everything goes well. The Midgard user will receive the final settlement confirmation much later after receiving the pre-confirmation from Midgard. A Midgard can notify the user that the block containing their transaction has been added to Midgard's confirmed state. Additionally, the user can get confirmation that after the Midgard block was incorporated into the confirmed state, enough subsequent Cardano blocks were produced to make a reorganization (reorg) unlikely (it can be 2 minutes once Ouroboros Peras is implemented). The state queue is maintained through Cardano blocks. Depending on the length of the challenge period, once Midgard blocks are merged to a confirmed state, a blockchain reorganization with these blocks is unlikely. The specific information provided to the user depends on the user interface (UX). Network Participants Midgard is a permissionless protocol that introduces its own execution environment, rules, UTxO-based data model, and incentive structure. It involves two primary participants: Operators: Entities responsible for producing and publishing blocks, maintaining a local UTxO set, and executing user transactions. Watchers: Independent validators who monitor published blocks, verify their correctness and submit fraud proofs to L1 if rule violations are detected. Operators submit only block headers to the state queue maintained by the Cardano network. The full block data is stored separately in the data availability layer. Watchers monitor the state queue to retrieve block headers, as each new header represents the next desired state transition. To validate transactions, watchers must download the complete block from the data availability layer. They then verify that the block header from the state queue matches the block header from the data availability layer. If the headers match, the validation can proceed. If a block cannot be retrieved, it constitutes a violation of Midgard's rules. Blocks are produced sequentially by operators in a fixed order. Once a block is published, all watchers can begin validation immediately. Rapid validation is crucial to minimize the risk of significant rollbacks. In the figure, you can see that Operator 1 published a block header of Block 1 to the State Queue and stored the corresponding block in the DA layer (and archive). Watcher 3 retrieved Block 4 and submitted fraud proof. There are not all arrows in the figure for simplicity. All other watchers do the same job for all blocks that are in the challenge period. Blocks are produced sequentially. In addition to operators and watchers, the Cardano network is an important participant that controls all Midgard processes. Midgard cannot do without the security and decentralization anchor provided by Cardano. Interaction between networks is implemented through L1 smart contracts (scripts). State Transition Midgard maintains its own chain of blocks, where each block represents a state transition from one UTxO set to another. Blocks are produced exclusively by operators. Each Midgard block contains: A header and header hash A body, which includes: UTxO set snapshot List of deposits List of withdrawals List of Midgard transactions Blocks signify a transition from one state to another, with each state represented by a set of UTxOs. To transition to a new state, the events within the block must be processed. The events to be processed include withdrawals, Midgard transactions, and deposits. These events are handled in a specific order: Withdrawals Midgard transactions Deposits This event processing order ensures consistency and prevents front-running or reordering attacks. Once all events have been processed, the UTxO set is updated to reflect the changes. The previous UTxO set serves as the input for validating the transactions in the block. After processing the events, the outcome is a newly updated UTxO set. This updated set represents the new state. The new block contains a new set of UTxO which is the result of applying the block's events to the set of UTxO from the previous block. Operators and Scheduler Operator participation is open and permissionless. Anyone can register as an operator by submitting a transaction on Cardano. All registered operators are listed in an operator directory, which is maintained on-chain. To maintain network liveness and decentralization, only a subset of these operators is active at a given time. The Midgard Scheduler, implemented as a smart contract on Cardano, determines which operator is active during each time window, referred to as a shift (slot). Shifts are non-overlapping and rotate in key-descending order across the active operator set. Once the end of the operator directory is reached, the scheduler cycles back to the beginning. If a newly registered operator becomes eligible, the scheduler includes them in the next rotation. Data Availability and Storage The integrity of Midgard depends on reliable data availability. All block data must be publicly accessible during a defined challenge period. Watchers perform Data Availability Sampling (DAS) to verify that block data is accessible from the Data Availability (DA) layer. While the long-term goal is to use the Input Blocks from Ouroboros Leios (which would provide fast, short-lived, and frequent block slots), Midgard will initially use a DA solution based on multi-signature committees—similar in concept to Celestia—to store blocks off-chain. This ensures data availability even before Leios is implemented. Each active operator: Receives L2 transactions directly from users via a web API. Has the exclusive right to produce a block during its assigned shift (time window). Must include all valid transactions and event data (deposits/withdrawals) into a block. Publishing a block involves: Committing the block header to Midgard's state queue on Cardano. Storing the full block data temporarily in a DA layer. Archiving blocks permanently on Midgard archive nodes. High Throughput and Operator Autonomy Midgard operators are autonomous in block production. There is no global consensus among operators; each operator produces blocks independently during their assigned shift. Conflicts are avoided due to the deterministic scheduler and the exclusivity of block production rights per shift. Because Midgard execution occurs off-chain, the network can scale horizontally. Operators can increase computing resources without coordination overhead, and the L1 is only involved in verifying fraud when disputes arise. This process is efficient and it is expected and frauds occur rarely. This architecture enables significantly higher throughput than Cardano L1. Midgard blocks can be generated at a much faster rate compared to the minting of Cardano blocks. Although Midgard relies on Cardano's execution environment and is tied to the frequency of Cardano block minting, its own block production is not restricted. Cardano blocks are minted every 20 seconds on average. Within this time frame, Midgard can produce several blocks, which are then processed collectively in the next minted Cardano block. Challenge Period and Fraud Proofs All published Midgard blocks are added to a state queue on Cardano. A state queue is maintained to store Midgard block headers sequentially. This queue serves to track the confirmed state, distinguishing between immutable blocks and those still awaiting confirmation. After blocks are added to the queue, they must remain for a designated duration before being merged into Midgard's confirmed state. This fixed timeframe is known as the challenge period (or maturity period), a common feature of optimistic rollups. During this challenge period, any watcher (which can be anyone) can inspect the contents of a block header by retrieving the corresponding data from the data availability layer. Watchers evaluate whether the block is valid. If the block is deemed valid, no further action is required. However, if a violation of the rules is discovered, anyone can submit fraud-proof. Fraud-proof identifies specific violations of the protocol's rules, such as attempts to double-spend. The fraud-proof must be verified on L1 using Midgard's scripts. If the fraud-proof is confirmed to be valid, the block is declared invalid and will not be incorporated into the confirmed state. Deleting a fraudulent block can result in a larger rollback. During the challenge period the following happens: Watchers verify blocks against Midgard rules. If a block is valid, nothing happens. If a rule violation is detected (e.g., double-spending), a fraud-proof is submitted via an L1 transaction. Fraud proofs specify the violated rule and point to the invalid state transition. They are verified deterministically by Cardano smart contracts. If a fraud is detected and confirmed, the block and all subsequent blocks in the state queue are discarded, as they depend on the invalid state. This rollback mechanism ensures correctness but highlights the importance of minimizing the challenge period. Although optimistic rollups like Midgard typically default to longer challenge periods (e.g., several hours or days) to ensure liveness and censorship resistance, future versions may reduce this window to minutes as infrastructure and decentralization improve. Confirmed State and Midgard Consensus Midgard's confirmed state is maintained on Cardano and updated when a block: Completes its challenge period without fraud. Or it is explicitly validated via compliance proof. Cardano contracts execute these transitions automatically. This makes Midgard consensus trustless and transparent, as it is driven by smart contracts and Cardano’s security model. Midgard relies on Cardano’s decentralization to ensure that fraud proofs cannot be censored. While collusion between malicious operators and Cardano stake pool operators (SPOs) is theoretically possible, the presence of at least one honest SPO ensures that any valid fraud-proof can be included on-chain and acted upon. Settlement Queue: Deposits and Withdrawals Midgard also maintains a settlement queue. Midgard blocks that have been merged into the confirmed state and that contain withdrawals and deposits are inserted into the settlement queue. Confirmed blocks have already passed the challenge period, so they are deemed valid. There is no need to validate them again in the settlement queue. Deposits and withdrawals are handled by deterministic L1 smart contracts. Once withdrawals and deposits are processed, the current Midgard operator optimistically marks them as resolved. Once the waiting period expires, the operator removes the blocks from the settlement queue. In doing so, fees for withdrawals and deposits are claimed. These events are prepared during block execution but are only finalized and settled once the block's waiting period has elapsed. Deposit is done as follows: A user initiates a deposit by sending a token to a designated Midgard deposit contract on Cardano L1. The L1 UTxO is locked by the Deposit smart contract. This L1 transaction emits a deposit event. This event is then included in a Midgard block (off-chain). During execution of the Midgard block, a new L2 UTxO is created in Midgard’s UTxO set. This UTxO reflects the value and type of the deposited asset. The L2 UTxO cannot be spent yet. The block containing the deposit enters the state queue and must pass the challenge period. Only after the challenge period ends, the deposit is finalized. The confirmed deposit event is included in the settlement queue. The L1 smart contract verifies that the deposit event came from a confirmed Midgard block. Only after this, the corresponding L2 UTxO is officially released for use in Midgard. The original L1 UTxO stays locked and cannot be spent elsewhere. The deposit is described in the following two figures. The first shows the L1 transaction from the depositor up to the stage where a new Midgard block with a deposit request is inserted into the state queue. The second figure shows a situation where a block has passed the challenge period and has been merged into a confirmed state. The block has been put into the settlement queue so that the L1 smart contract can finalize the deposit. The contract will release the L2 UTxO. The depositor can submit a new Midgard transaction and spend the L2 UTxO. Withdrawal is done similarly: A user initiates a withdrawal request, which is included in a Midgard block. During block execution, the specified L2 UTxO is consumed (i.e., removed from Midgard’s UTxO set). The block enters the state queue, and again, must pass the challenge period. Once the block is confirmed, the withdrawal moves into the settlement queue. A Cardano UTxO is generated on L1 at the user’s address. Advantages of UTxO Model Midgard inherits Cardano's UTxO model, which offers distinct benefits compared to Ethereum-style rollups: Deterministic and parallelizable transaction validation. No need for centralized sequencers. Simpler fraud proofs due to transaction locality. Operators don’t need to coordinate globally, and watchers can verify frauds without replaying the global state. This lowers the complexity of rollup design and allows for a clean separation between L1 and L2. Midgard vs Ethereum Rollups: A Comparison Table Conclusion Midgard provides a modular, secure, and scalable Layer 2 for Cardano. By combining the efficiency of off-chain execution with Cardano’s robust on-chain enforcement, Midgard ensures high throughput, low fees, and security without compromising decentralization. Its use of the UTxO model, deterministic fraud proofs, and native token support positions it as a Cardano-native solution to blockchain scaling.
