Search for projects by name or address
Gnosis Chain is a community-owned EVM-based sidechain operated by a proof-of-stake validator set aiming to be the first chain in the Ethereum Economic Zone (EEZ). Its canonical Ethereum bridge ('Gnosis Bridge') is validated by dedicated bridge validator... multisigs (not the PoS validator set) and supports the yielding bridge for the chain's gas-token xDAI as well as token transfers and messaging. This page looks at both the PoS chain and the canonical bridge to Ethereum from an Ethereum-centric perspective.
Gnosis Chain is a community-owned EVM-based sidechain operated by a proof-of-stake validator set aiming to be the first chain in the Ethereum Economic Zone (EEZ). Its canonical Ethereum bridge ('Gnosis Bridge') is validated by dedicated bridge validator... multisigs (not the PoS validator set) and supports the yielding bridge for the chain's gas-token xDAI as well as token transfers and messaging. This page looks at both the PoS chain and the canonical bridge to Ethereum from an Ethereum-centric perspective.
Gnosis Chain has an external validator set that validates its state transitions. This is an additional trust assumption since Ethereum does not, the external validators do not commit or stake anything on Ethereum.
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
Fusaka upgrade
2026 Apr 14th
Gnosis Chain activates its Fusaka networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. upgrade.
USDS migration on xDAI bridge
2025 Nov 7th
The xDAI 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. makes USDS the default Ethereum-side backing asset.
Gnosis Chain is a community-owned EVM-based sidechain operated by a proof-of-stake validatorIn 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 set aiming to be the first chain in the Ethereum Economic Zone (EEZ). Its canonical Ethereum 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. (‘Gnosis Bridge’) is validated by dedicated bridge validator multisigs (not the PoS validator set) and supports the yielding bridge for the chain’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 xDAI as well as token transfers and messaging. This page looks at both the PoS chain and the canonical bridge to Ethereum from an Ethereum-centric perspective.
Gnosis chain in its current form does not derive or benefit from Ethereum’s decentralisation apart from being developed as a close fork to re-use Ethereum tooling and infrastructure. Its censorship resistance relies on an open set of 52,352 active validatorIn 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 indices, although the clustering and stake distribution among entities is intransparent. Users who are censored selectively on an otherwise live networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. benefit from the fast 5s 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. time and non-committee-gated, stake-weighted proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. rotation, resulting in an inclusion probability of 99% in less than a minute even if up to 50% of the Gnosis stake is censoring them. There are also a few thousand validators who run custom ‘shutter network’ nodes that support threshold-encrypted transactions. For a case of active blanket censorship (>50% stake) by all current validators, users have no way apart from a hardfork to get their transactions included or save the chain. In the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. walkaway scenario, new sequencers could stake and join the set permissionlessly.
Users can permissionlessly become 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. (validatorIn 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) by staking a minimum of 1 GNO to join the queue and wait to obtain 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. production rights. There is no specific censorship resistance mechanism against selective censorship by parts of the active validator set nor a way to force transactions from Ethereum 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..
Ethereum contracts do not validate Gnosis Chain state transitions. 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. messages are accepted after threshold signatures from dedicated bridge 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.
Data is made available by an external proof of stake networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. of 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. Since there is no 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., Ethereum cannot verify whether any data was made available on Gnosis Chain or whether incoming messages originate from state that was attested to by the PoS network.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
The Gnosis Chain 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. is not validated by its PoS validatorIn 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 set. Withdrawals through the xDAI bridge require 4/7 validator signatures, while AMB and Omnibridge withdrawals require 4/7 validator signatures. The bridge validators can freeze bridge transactions and/or steal bridge-locked and minted assets. Transactions on Gnosis Chain itself cannot be forced from Ethereum. If the chain has a livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. failure due to blanket censorship or operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. walkaway the only recourse are new validators joining the open validator set.
Gnosis Chain transaction data is published to Gnosis Chain and propagated by its validatorIn 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 and nodeA software client that participates in the network. networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.. The Ethereum 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. contracts do not verify data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. and only process bridge messages after bridge-validator signatures are submitted.
Funds can be frozen if transaction data is unavailable and bridge validators cannot reconstruct or sign the messages needed to exit.
Gnosis Chain is an independent proof-of-stake chain. Ethereum contracts do not check whether Gnosis state transitions are valid. Cross-chain messages are executed when the relevant 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. contract receives enough validatorIn 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 signatures: 4/7 for the xDAI bridge and 4/7 for AMB and Omnibridge.
Funds can be stolen if bridge validators sign fraudulent messages that release more assets on Ethereum than were burned or locked on Gnosis.
Funds can be stolen if the Gnosis validator set finalizes an invalid chain state and the bridge validators sign messages derived from it.
Funds can be frozen if bridge validators stop signing messages or Gnosis Chain stops finalizing blocks.
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
Validator signer swaps and 7702 delegation.
Validator signer swaps and 7702 delegation.
| EOA (eth:0x57B11cC8F93f2cfeC4c1C5B95213f17cAD81332B) { | |
| +++ description: None | |
| proxyType: | |
| - | "EOA" |
| + | "EIP7702 EOA" |
| sourceHashes: | |
| + | ["0x1f44812af62d28f019e30e8eb2af596fb36c7db9d34576972c0405e110a6ef45"] |
| values: | |
| + | {"$implementation":"eth:0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B","delegationManager":"eth:0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3","DOMAIN_VERSION":"1","eip712Domain":{"fields":"0x0f","name":"EIP7702StatelessDeleGator","version":"1","chainId":1,"verifyingContract":"eth:0x57B11cC8F93f2cfeC4c1C5B95213f17cAD81332B","salt":"0x0000000000000000000000000000000000000000000000000000000000000000","extensions":[]},"entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getDeposit":0,"getDomainHash":"0x38d1f93af4f5e2dfafd980746296a0d3cf287e61c748fc95f684b0ac2164a2ff","getNonce":0,"NAME":"EIP7702StatelessDeleGator","PACKED_USER_OP_TYPEHASH":"0xbc37962d8bd1d319c95199bdfda6d3f92baa8903a61b32d5f4ec1f4b36a3bc18","VERSION":"1.3.0"} |
| } | |
| contract XDai Bridge Validators (eth:0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.1: | |
| - | "eth:0xAeE7C90Ef0fC461ec63c4d451B12c340642bc656" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.5: | |
| + | "eth:0xA2746D5eE860a6A9cbb79C34533313144d467CA8" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| - | "eth:0x156c0DAAb0cD73c224a424a781866d35f0F8Fade" |
| + | "eth:0x59D3C2829900Ae20D02Ca547082b09FD27380eA6" |
| } | |
| contract AMB Validators (eth:0xed84a648b3c51432ad0fD1C2cD2C45677E9d4064) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.1: | |
| - | "eth:0xCC46a3873BfCaa08a6a946a308bB621535D6E6Dd" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.5: | |
| + | "eth:0x5524b7a3e2Dc024f4C9c2Ecd7FE003ee316ac624" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| - | "eth:0x156c0DAAb0cD73c224a424a781866d35f0F8Fade" |
| + | "eth:0x59D3C2829900Ae20D02Ca547082b09FD27380eA6" |
| } | |
| contract HomeAMB Validators (gno:0xA280feD8D7CaD9a76C8b50cA5c33c2534fFa5008) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.1: | |
| - | "gno:0xCC46a3873BfCaa08a6a946a308bB621535D6E6Dd" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.5: | |
| + | "gno:0x5524b7a3e2Dc024f4C9c2Ecd7FE003ee316ac624" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| - | "gno:0x156c0DAAb0cD73c224a424a781866d35f0F8Fade" |
| + | "gno:0x59D3C2829900Ae20D02Ca547082b09FD27380eA6" |
| } | |
Four signers were rotated in each of the three 4-of-7 bridge validator sets.
Four signers were rotated in each of the three 4-of-7 bridge validator sets.
| contract XDai Bridge Validators (eth:0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.0: | |
| - | "eth:0x4D1c96B9A49C4469A0b720a22b74b034EDdFe051" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.1: | |
| - | "eth:0xc073C8E5ED9Aa11CF6776C69b3e13b259Ba9F506" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.3: | |
| - | "eth:0x97630E2aE609D4104aBdA91F3066C556403182dd" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| - | "eth:0x7117F73aFBDec3221bDD50DdCbf73204b3998302" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.3: | |
| + | "eth:0x82b00cA9D162859f645B51967746E55bb6498DfC" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| + | "eth:0x2245bFAD58a6cD50e9e413084d4091C497281911" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.5: | |
| + | "eth:0xC9f0d7e76E7970590e217c57Af5d2B7d07A62c13" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| + | "eth:0x156c0DAAb0cD73c224a424a781866d35f0F8Fade" |
| } | |
| contract AMB Validators (eth:0xed84a648b3c51432ad0fD1C2cD2C45677E9d4064) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.0: | |
| - | "eth:0x105CD22eD3D089Bf5589C59b452f9dE0796Ca52d" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.1: | |
| - | "eth:0x459A3bd49F1ff109bc90b76125533699AaAAf9A6" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.3: | |
| - | "eth:0xbDc141c8D2343f33F40Cb9edD601CcF460CD0dDe" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| - | "eth:0x7117F73aFBDec3221bDD50DdCbf73204b3998302" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.3: | |
| + | "eth:0x4A07b8AE561CC558eDD3f1836365AB8e02C52dE2" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| + | "eth:0xAD93BffBC65002cC75AD2d5770d3AAfFdefd8D55" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.5: | |
| + | "eth:0xE9fc29AE64c2923FeBb615cB016b77aF9492EBcE" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| + | "eth:0x156c0DAAb0cD73c224a424a781866d35f0F8Fade" |
| } | |
| contract HomeAMB Validators (gno:0xA280feD8D7CaD9a76C8b50cA5c33c2534fFa5008) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.0: | |
| - | "gno:0x459A3bd49F1ff109bc90b76125533699AaAAf9A6" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.1: | |
| - | "gno:0x105CD22eD3D089Bf5589C59b452f9dE0796Ca52d" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.3: | |
| - | "gno:0xbDc141c8D2343f33F40Cb9edD601CcF460CD0dDe" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| - | "gno:0x7117F73aFBDec3221bDD50DdCbf73204b3998302" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.3: | |
| + | "gno:0x4A07b8AE561CC558eDD3f1836365AB8e02C52dE2" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| + | "gno:0xAD93BffBC65002cC75AD2d5770d3AAfFdefd8D55" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.5: | |
| + | "gno:0xE9fc29AE64c2923FeBb615cB016b77aF9492EBcE" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| + | "gno:0x156c0DAAb0cD73c224a424a781866d35f0F8Fade" |
| } | |
Swap one validator signer.
Swap one validator signer.
| contract XDai Bridge Validators (eth:0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| - | "eth:0x6236925FF8Aa09f29f1609a9BcD54Af20e4be6B4" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| + | "eth:0xb54B5572F3C4f70fF3cc8F67C19C8cddb838FBaA" |
| } | |
| contract AMB Validators (eth:0xed84a648b3c51432ad0fD1C2cD2C45677E9d4064) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| - | "eth:0x6236925FF8Aa09f29f1609a9BcD54Af20e4be6B4" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| + | "eth:0xb54B5572F3C4f70fF3cc8F67C19C8cddb838FBaA" |
| } | |
| contract HomeAMB Validators (gno:0xA280feD8D7CaD9a76C8b50cA5c33c2534fFa5008) [gnosis/BridgeValidators] { | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.4: | |
| - | "gno:0x6236925FF8Aa09f29f1609a9BcD54Af20e4be6B4" |
| +++ description: Array of the signers in the validator multisig | |
| values.$members.6: | |
| + | "gno:0xb54B5572F3C4f70fF3cc8F67C19C8cddb838FBaA" |
| } | |
re-add entire gnosis disco incl bridge, consensus and Hashi.
re-add entire gnosis disco incl bridge, consensus and Hashi.
| + | Status: CREATED |
| contract Gnosis Bridge Multisig (Ethereum) (eth:0x42F38ec5A75acCEc50054671233dfAC9C0E7A3F6) | |
| +++ description: None | |
| + | Status: CREATED |
| contract XDaiForeignBridge (eth:0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016) | |
| +++ description: Ethereum-side ERC20-to-native bridge used to lock DAI or USDS on Ethereum and authorize xDAI minting on Gnosis. Message execution is validated by a dedicated validator set and can additionally be gated by Hashi. | |
| + | Status: CREATED |
| contract Hashi Multisig (Ethereum) (eth:0x4b5F5231e2F08Ad49d79Ce5672A8339a63Cfbd43) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ForeignAMB (eth:0x4C36d2919e407f0Cc2Ee3c993ccF8ac26d9CE64e) | |
| +++ description: Ethereum-side Arbitrary Message Bridge endpoint that verifies validator signatures before relaying cross-chain calls to Gnosis. Hashi can be enabled as an additional verification layer. | |
| + | Status: CREATED |
| contract ForeignOmnibridge TokenFactory (eth:0x71d5ba4e37de72415F685490B684538Aae8f0424) | |
| +++ description: Factory used by Omnibridge to deploy wrapped tokens representing assets native to the other chain. | |
| + | Status: CREATED |
| EOA (eth:0x839395e20bbB182fa440d08F850E6c7A8f6F0780) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ForeignOmnibridge (eth:0x88ad09518695c6c3712AC10a214bE5109a655671) | |
| +++ description: Ethereum-side Omnibridge mediator used for arbitrary token transfers between Ethereum and Gnosis via the AMB bridge. | |
| + | Status: CREATED |
| contract BridgeRouter (eth:0x9a873656c19Efecbfb4f9FAb5B7acdeAb466a0B0) | |
| +++ description: Entry router for bridging between Ethereum and Gnosis. It routes DAI and USDS through the legacy xDAI bridge, ETH through the WETH Omnibridge router, and other ERC20 tokens through Omnibridge. | |
| + | Status: CREATED |
| contract WETHOmnibridgeRouter (eth:0xa6439Ca0FCbA1d0F80df0bE6A17220feD9c9038a) | |
| +++ description: Router that wraps native ETH into WETH before sending it through Omnibridge and unwraps it again on Gnosis when bridge messages are executed. | |
| + | Status: CREATED |
| contract BridgeRouter ProxyAdmin (eth:0xD7e65A32bEd4ce8cc57Ec188F2bBb8016dc4b1cd) | |
| +++ description: None | |
| + | Status: CREATED |
| contract XDai Bridge Validators (eth:0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E) | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| + | Status: CREATED |
| contract AMB Validators (eth:0xed84a648b3c51432ad0fD1C2cD2C45677E9d4064) | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| + | Status: CREATED |
| contract SBCDepositContract (gno:0x0B98057eA310F4d31F2a452B414647007d1645d9) | |
| +++ description: Gnosis Beacon Chain deposit contract escrowing all validator-staked GNO. Differs from the similar contract on Ethereum by being upgradable, allowing critical permissioned function access and using the non-gastoken GNO as its staking token. | |
| + | Status: CREATED |
| contract HomeOmnibridge Fee Manager (gno:0x5dbC897aEf6B18394D845A922BF107FA98E3AC55) | |
| +++ description: Fee manager used by HomeOmnibridge to calculate and distribute bridge fees to a configured reward address list. | |
| + | Status: CREATED |
| contract HomeOmnibridge Gas Limit Manager (gno:0x68A3674028a785A8BCE19bA81B9ab7c9942BA3ED) | |
| +++ description: Module used by HomeOmnibridge to choose default, selector-specific, and token-specific gas limits for cross-chain Omnibridge message execution. | |
| + | Status: CREATED |
| contract HomeAMB (gno:0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59) | |
| +++ description: Gnosis-side Arbitrary Message Bridge endpoint that verifies validator signatures before relaying cross-chain calls to Ethereum. Hashi can be enabled as an additional verification layer. | |
| + | Status: CREATED |
| contract Omnibridge Fee Distributor Safe (gno:0x77bcb57ba7037e39063f1567ce734452bbD7a5F0) | |
| +++ description: Safe that currently receives Omnibridge fees distributed by the HomeOmnibridge fee manager. | |
| + | Status: CREATED |
| contract Gnosis Multisig (Gnosis) (gno:0x7a48Dac683DA91e4faa5aB13D91AB5fd170875bd) | |
| +++ description: None | |
| + | Status: CREATED |
| contract GNO token (gno:0x9C58BAcC331c9aa871AFD802DB6379a98e80CEdb) | |
| +++ description: Immutable GNO token smart contract contract, administered from the Ethereum side by the Gnosis Bridge contract. | |
| + | Status: CREATED |
| contract HomeAMB Validators (gno:0xA280feD8D7CaD9a76C8b50cA5c33c2534fFa5008) | |
| +++ description: Validator set contract used by the bridge to require threshold signatures before cross-chain messages can be executed. | |
| + | Status: CREATED |
| contract HomeOmnibridge Forwarding Rules Manager (gno:0xd4D8c07097F9b87EcC4C1a838C4b71DBebcd2286) | |
| +++ description: Module used by HomeOmnibridge to decide whether specific tokens, senders, or receivers must use the oracle-driven lane or the manual lane for bridge requests. | |
| + | Status: CREATED |
| contract HomeOmnibridge TokenFactory (gno:0xEAAE83ac10f975a6456f4C4E48c45Ea2d8e1b5d2) | |
| +++ description: Factory used by Omnibridge to deploy wrapped tokens representing assets native to the other chain. | |
| + | Status: CREATED |
| contract Hashi Multisig (Gnosis) (gno:0xEF138856d0581641A57245Ee5CFfc9ceaA059623) | |
| +++ description: None | |
| + | Status: CREATED |
| contract HomeOmnibridge (gno:0xf6A78083ca3e2a662D6dd1703c939c8aCE2e268d) | |
| +++ description: Gnosis-side Omnibridge mediator used for arbitrary token transfers between Gnosis and Ethereum via the AMB bridge. | |
Gnosis Chain uses a permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. proof-of-stake validatorIn 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 set with stake-weighted proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. rotation and a 5 second slot time. The Ethereum-like committee-free 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. production architecture combined with the short block time lead to fast theoretical inclusion times, even with high rates of censorship. In contrast to Ethereum, blocks on Gnosis chain are usually built locally, meaning that validators do not delegate block production to specialised builders. There is no public information on the decentralisation of the Gnosis validator set.
| Sequencer set spec sheet | |
|---|---|
| L2 block time | 5s |
| Proposer rotation | |
| Number of block producers | 300.64 K GNO |
| Access to block production rights | Open |
| Stake per validator | |
| Rate-limit to join | |
| Deterministic CR gadget | No |
| Additional CR gadgets | Shutter encrypted mempool beta |
T99 inclusion delay in a static sequencer set by censoring fraction of sequencers/validators
The chart uses the Ethereum-style single-proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. formula with Gnosis-specific constants. It excludes finalityStrongest confirmation rule that can be given on the ordering of transactions. On Ethereum, a transaction is finalized when the corresponding epoch becomes final, which currently takes around 15 mins from transaction inclusion. A rollup transaction can be said to be final when the corresponding data is published to L1 and its ordering cannot be reverted. If outputs, i.e. state diffs are published, then also a proof proving their correctness must be verified to consider the transaction final., inactivity leaks, validatorIn 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-set changes, hard forks, and blanket-censorship resistance gadgets.
Gnosis Chain does not have dedicated censorship resistance gadgets, but the 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. set is open and there are no committees that can 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. inclusion.
Even with high percentages of stake censoring, users have very fast inclusion times. There are also initial tests of an out-of-protocol solution for encrypting transactions in the mempool (Shutterized Gnosis Chain).
There is no way to circumvent the validatorIn 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 set from Ethereum in a case of active censorship by all (or a majority of) validators.
Since the validator set is open, new validators can join it in case validators passively stop block production. If all validators stop at the same time, a social recovery and hard fork would be necessary.
Users can be censored if at least half of the active stake censors them, or if current validators coordinate blanket censorship and the chain requires social recovery.
A subset of Gnosis Chain 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 is currently running a modified nodeA software client that participates in the network. version that supports threshold-encrypted transaction payloads. This allows to ‘encrypt the mempool’ and protect against malicious MEV and censorship with significant caveats. To encrypt the transaction, users have to either use custom wallets or a trusted encrypting rpc proxy. Decryption is handled by participating validators sharing their decryption key shares at the target 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., allowing the proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. to decrypt the transaction and include and execute (or censor) it.
Omnibridge uses token factories to deploy wrapped ERC20 representations for assets native to the other chain. The token factory owner can change the implementation used for newly deployed wrapped tokens.
Funds can be stolen if a malicious or vulnerable wrapped token implementation is configured for newly bridged assets.

A Multisig with 8/15 threshold.
A Multisig with 4/7 threshold. ValidatorIn 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 set contract used by 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. to require threshold signatures before cross-chain messages can be executed.
mintingFinished state, which disallows further minting HomeAMB → HomeOmnibridgeA Multisig with 2/3 threshold. Member of Gnosis Multisig (Gnosis).
Member of HomeAMB 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.
A Multisig with 8/15 threshold.
A Multisig with 2/3 threshold. Member of Gnosis 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. Multisig (Ethereum).
A Multisig with 4/7 threshold. ValidatorIn 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 set contract used by 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. to require threshold signatures before cross-chain messages can be executed.
A Multisig with 4/7 threshold. ValidatorIn 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 set contract used by 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. to require threshold signatures before cross-chain messages can be executed.
Member of XDai 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. 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.
Member of AMB 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.
Member of XDai 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. 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, AMB Validators.


Gnosis Beacon Chain deposit contract escrowing all validatorIn 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-staked GNO. Differs from the similar contract on Ethereum by being upgradable, allowing critical permissioned function access and using the non-gastoken GNO as its staking token.
Immutable GNO token smart contract contract, administered from the Ethereum side by the Gnosis 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. contract.
Fee manager used by HomeOmnibridge to calculate and distribute 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. fees to a configured reward address list.
Module used by HomeOmnibridge to choose default, selector-specific, and token-specific 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. limits for cross-chain Omnibridge message execution.
Gnosis-side Arbitrary Message 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. endpoint that verifies validatorIn 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 signatures before relaying cross-chain calls to Ethereum. Hashi can be enabled as an additional verification layer.
Module used by HomeOmnibridge to decide whether specific tokens, senders, or receivers must use the oracle-driven lane or the manual lane for 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. requests.
Factory used by Omnibridge to deploy wrapped tokens representing assets native to the other chain.
Gnosis-side Omnibridge mediator used for arbitrary token transfers between Gnosis and Ethereum via the AMB 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..
Ethereum-side ERC20-to-native 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. used to lock DAI or USDS on Ethereum and authorize xDAI minting on Gnosis. Message execution is validated by a dedicated validatorIn 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 set and can additionally be gated by Hashi.



Ethereum-side Arbitrary Message 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. endpoint that verifies validatorIn 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 signatures before relaying cross-chain calls to Gnosis. Hashi can be enabled as an additional verification layer.
Factory used by Omnibridge to deploy wrapped tokens representing assets native to the other chain.
Ethereum-side Omnibridge mediator used for arbitrary token transfers between Ethereum and Gnosis via the AMB 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..
All supported tokens in this escrow are included in the value secured calculation.
Entry router for bridging between Ethereum and Gnosis. It routes DAI and USDS through the legacy xDAI 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., ETH through the WETH Omnibridge router, and other ERC20 tokens through Omnibridge.
Router that wraps native ETH into WETH before sending it through Omnibridge and unwraps it again on Gnosis when 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. messages are executed.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).