WINR

Contract that allows challenging state rootsA cryptographic hash succinctly representing a state using a Merkle tree.. Can be called through the RollupProxy by ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier or the UpgradeExecutor.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1

Central contract for the project’s configuration like its execution logic hashA fixed-length fingerprint of variable-size input, produced by a hash function. (wasmModuleRoot) and addresses of the other system contracts. Entry point for Proposers creating new RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. Nodes (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both held by the ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier).

• Roles:
  • admin: UpgradeExecutor; ultimately Conduit Multisig 2, EOA 1
  • anyTrustFastConfirmer: WinrFastconfirmerMultisig; ultimately EOA 2
  • owner: UpgradeExecutor; ultimately Conduit Multisig 2, EOA 1
  • validators: EOA 11, EOA 13, EOA 15, EOA 18, EOA 2, EOA 20, EOA 23, EOA 25, EOA 27, EOA 28, EOA 29, EOA 3, EOA 4, EOA 5, WinrFastconfirmerMultisig; ultimately EOA 2

A sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. (registered in this contract) can submit transaction batches or commitments here.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1
  • batchPosters: EOA 10, EOA 12, EOA 14, EOA 16, EOA 17, EOA 19, EOA 21, EOA 22, EOA 24, EOA 26, EOA 6, EOA 7, EOA 8, EOA 9

Escrow contract for the project’s gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. messaging.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1

Central contract defining the access control permissions for upgrading the system contract implementations.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1
  • executors: Conduit Multisig 2, EOA 1

Facilitates sending L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. messages like depositing ETH, but does not escrow funds.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1

Facilitates L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. contract calls: Messages initiated from L2 (for example withdrawal messages) eventually resolve in execution on L1.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1

One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

This contract implements view only utilities for validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier.

One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine. This version uses the Blobstream DA bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. (ArbitrumBlobstream) as source of truth for the DA referenced by the fault proof.

One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

• Roles:
  • owner: UpgradeExecutor

Helper contract sending configuration data over the bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. during the systems initialization.

• Roles:
  • admin: ProxyAdmin; ultimately Conduit Multisig 2, EOA 1

One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

The Blobstream DA bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge.. This contract is used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. data commitments between Celestia and the destination chain. It specifies relayers that commit blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. ranges, but due to the lack of emitted events, there may be more relayers than are presented here.

• Roles:
  • admin: BlobstreamMultisig
  • guardians: BlobstreamMultisig
  • relayers: EOA 30, EOA 31

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v5.0.0).

This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts, routing each identifier to the corresponding verifier contract.

• Roles:
  • owner: SP1VerifierGatewayMultisig

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.0.0).

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).