Skip to main content

· 6 min read
0xarmagan

Greetings everyone, and welcome to the weekly Gnosis Core Devs Call. Just a quick reminder that this meeting takes place every Wednesday.

Participants: Erigon, Gateway, Nethermind, Geth, Gnosis DevOps, Gnosis Core Devs, Gnosis DevRels, Gnosis Comms team and the contributors.

The main topic of discussion during the meeting was the withdrawals contract. The team is currently making preparations for the forthcoming Shapella upgrade. Furthermore, updates were given on Devnet, the Client team, Chain infrastructure, and POSDAO.

Watch on Gnosis Chain YouTube channel

Topics

  • Withdrawals Contract
  • Shapella Upgrade
  • Core Dev Team updates
  • Client Team Update
  • Chain Infrastructure Updates
  • Devnet
  • POSDAO

Call Notes

Withdrawals contract

  • Should be finalized
  • Being audited by Adam
  • If the transfers can’t occur (insolvency case), they will be queued and cleared when new GNO is supplied
  • Dapplion is asking for help from Nethermind to pick a safe value of the number of failed transactions to execute per block
  • Might be useful to test on mainnet because on devnets the entire state can be cached
  • Ruben suggests a default of 16 for both, so 32 in the worst case scenario
  • If we have one day worth of failed amounts, then clearing the queue would take a day as well
  • In any case, this would be an unlikely scenario Would require a massive exit
  • Lukasz: is there an estimation of gas usage for those transactions?
  • Dapplion: we don’t have those numbers but we should compute them
  • Based on this, we could choose a number for the failed transactions per block
  • Dapplion: will ask Ihor to get some numbers
  • Need to assign tokens to Deposit Contract
    • Should have some 0x01 addresses
    • Method 1: Jorge’s “Merge” method of just overwriting storage slots
    • Nethermind and Erigon have support for storage allocations
    • Makes it possible to give tokens to users in contracts
    • Method 2: Assign code as constructor bytecode (?)

Devnet

  • Are there blockers?
    • Actual withdrawals contract (currently using mocks)
  • Can we start spinning one up?
  • Status‍
    • Nethermind
      • Started an internal devnet using a mock contract a few days ago
      • So far, everything seems to be good
      • Starts with AuRa blocks, then Merges (Bellatrix) and then enables Withdrawals
      • Lighthouse might not be compatible with TTD = 0
      • Devnet is simple to set up because it’s mostly automated
      • Current state‍
        • A dozen of validators
        • Went through Shanghai without any issues
        • Withdrawals have not been tested yet
        • Figuring BLS addresses out
        • The nodes are public, so an RPC can be shared
        • Erigon can also join this devnet, but the mock contract is still used, so that needs to be configured‍
    • Erigon‍
      • Not implemented yet
      • Can be done this week
    • General
      • We can spin up a devnet with both clients end of next week (March 2nd)
    • Gnosis DevOps
      • Will run Nethermind first?

Client team updates

Execution Layer

  • Nethermind‍

    • Running devnet for withdrawals
    • Issues regarding 1.17
    • Attestations down
    • We’ll investigate and contact Nethermind on Telegram
  • Erigon

    • Chiado now works
      • Linked to dead peers on Nethermind
      • Enabled snapshots
    • Light client works for Gnosis and Chiado
      • DevOps is working on spinning up more Nimbus peers
  • Guillaume

    • Trying to run latest Prysm on mainnet
    • Will be working on geth sync for the rest of the month
    • Will be working on geth sync for the rest of the month

Consensus Layer

Chain Infra

  • Gateway‍

    • Half of the traffic on Chiado
    • 25% traffic on mainnet
      • Everything’s good and planning to increase traffic
    • Gnosis Bridge Validator
      • 1-of-7
      • Work can be slow during EthDenver
  • Beaconchain

    • Not ready till T+1 after Ethereum Shanghai/Capella
    • For the 0x00 -> 0x01 address conversion

Timeline

  • When is a realistic time for Withdrawals?

    • Need to prep community
    • We should not overpromise‍
  • DevNet

    • Next steps (can be done without Erigon)
    • Deploy a new one with the actual smart contract
      • With upgrade from mainnet bytecode if possible, but not essential
      • Can be put in the genesis bytecode
    • The contract should be pre-funded to simulate the current state on mainnet
    • Would be great to test the insolvency case
    • Test the deposit contract update
      • Start with the bytecode of the current deposit contract
      • Go through the upgrade
    • Can probably be done this week
  • Shadow forks‍

  • Chiado

    • Deposit contract for Genesis
    • Start testing tooling
      • Dappnode
      • Withdrawal credentials in general‍
  • Mainnet‍

    • Deposit contract needs to be updated
    • Requires testing
      • On devnet
      • On chiado
      • Emulate it as close to mainnet as possible

Additional Workstreams

  • Shutterized Beacon Chain
  • Account Abstraction

Tests

Hive

  • Dapplion: Should be the option in the long term
    • Marek agrees because Ethereum also supports Hive tests
    • However, the initial effort will be more important as we have nothing yet

POSDAO

  • Currently: Truffle test suites
  • Really annoying to work with
  • Still-relevant
    • Deprecated, but still necessary for nodes being synced from Genesis:
      • Pre-merge testing of POSDAO - rotation of validator set, voting etc
      • Test that we can still go thru the Merge without going thru forks or nodes getting start
    • Still relevant:
      • xDai Block Rewards
      • Has prevented really bad problems from happening
        • Syncing from Genesis

None of them are being worked on

  • Would anyone have capacity to do either?
    • Nethermind: Hive tests are written in Go
      • Nethermind has devs, but not sure anyone is available
    • Erigon: Andrew will ask around, but probably no capacity
  • Would be great to have long term ownership of Gnosis tests
    • Especially for shutterized beacon chain etc in the future
  • We wouldn’t need a suite as extensive as Ethereum’s for now
    • The withdrawal tests are relatively succinct

Miscellaneous

  • The xDai team did an attempt at implementing withdrawals
  • There will be no trace (logs) of withdrawals on explorers
    • We need to work with explorers to display them
    • Ideally they add a new tab, similar to “internal” / “ERC-20” for withdrawals
    • We can probably piggy-back from the mainnet implementation
    • Caveat: insolvency case, might require some specific logic
    • Beaconcha.in
    • Gnosisscan
    • Blockscout
  • Lukasz: should withdrawals be shown in traces somewhere?
    • Lukasz: mixed feelings
    • We should maybe ask block explorers / users what they want?
    • Dapplion: let’s keep it simple

· 6 min read
Lion - dapplion
0xarmagan

Hello everyone from the weekly Gnosis Core Devs Call. This meeting is repeated on Wednesday every week. Watch on Gnosis Chain YouTube channel. ‍

Participants: Erigon, Gateway, Nethermind, Geth, Gnosis DevOps, Gnosis Core Devs, Gnosis DevRels, Gnosis Comms team and the contributors.

In the focus of this meeting, opinions on the implementation of withdrawals contract were evaluated. difficulties and solutions to current problems were discussed. also shared EL and CL team updates.

Topics

  • Withdrawals Contract
  • “Native” GNO and mGNO
  • Core Devs Team updates
  • Client Team Update
  • Chain Infrastructure Updates

Feb 15, 2023

  • Withdrawals contract

    • https://www.notion.so/Shanghai-Capella-Withdrawals-13fa64960f304abbac23b73187436058
    • Create a PR with a semi-final implementation
    • Insolvency Case
    • How many failed withdrawals should the system call process?
      • Should it be hardcoded or a chain parameter?
      • Withdrawals are passed as calldata to the contract
      • Only way to fail is if there’s not enough GNO in the contract -> withdrawal stored as failed
      • On every block, failed withdrawals are processed again, in case there’s now enough GNO
      • The question is: how many of those failed withdrawals can we process per block to keep appropriate block times
      • Martin: this situation should never happen ideally
        • Lion: The withdrawal could also fail for other reasons because we’re calling other contracts (?)
        • Goes back to the discussion of whether there should be minting capabilities or not
          • Not realistic to implement this in a timely fashion
      • Daniel: would having two balances (xDAI + GNO) in execution layer (or CL)be an option?
        • Probably too much work / maintenance to be worth it
      • Guillaume: can we get rid of xDAI as native token?
        • Replace it with GNO, and then we basically move to the standard Ethereum way
        • Martin: Probably not viable
        • Is this good for the chain?
          • Would force users to convert their $ into GNO
        • Would it even be feasible?
          • xDAI (or wrapper xDAI) is used in many contracts, where it might be assumed that the native currency is worth a dollar
        • Dan: Move xDai balances into ERC-20 registry?
      • Could we mint something on withdrawals that would allow users to get their original GNO back on Ethereum
    • Need to work with Comms team on instruction guides for community
      • 0x00 addresses can’t withdraw, so these addresses would need to be converted
      • 16 validators withdrawals can be processed per block
        • Dapplion: More withdrawals per block = higher load on processing. Could EL devs benchmark the cost of a withdrawal in gnosis?
        • Cost of withdrawal is more expensive in Gnosis because withdrawals are implemented in EL
        • Marek: best way is to start the devnet and observe block processing time with withdrawals
  • “Native” GNO

    • Ihor: Could lead to bad economical effect
      • Martin: We’re removing the ability of the bridge to mint unlimited GNO on Gnosis’ side, which should only increase security
      • Would be putting the burn promise in code by only having 3m tokens on Gnosis side
    • Need to upgrade Bridge Contracts (?)
      • Omnibridge cannot mint addition GNO.gnosis, needs custom code to pull from 3mn minted
      • GNO.ethereum <> GNO.gnosis (from 3mn) thru 3rd party bridges
    • What’s the current plan of releasing GNO rewards on beacon chain?
      • Right now we can just increase the storage slot in the GNO smart contract on the execution layer side so the token doesn’t need to be upgraded for minting
        • Igor: That has to be done on the execution layer anyways
      • The way this works on Ethereum is just to increase the native balance (no contract interaction)
        • The idea is to call a contract that does it (Ihor’s withdrawal contract) instead of hacking it together
    • Dapplion
      • Thinks it’s a good idea
      • But would probably require a team that would dive into this to make sure everything work as it should and analyze how feasible this is
      • To be considered for inclusion in future hardfork
      • Basically we need expertise on this
    • Let’s do an assessment of whether this is doable or not and how much time it would take
  • mGNO

    • Should it be “user-facing”?
    • Should we get rid of it?
  • Client Team Updates

    • EL
      • Nethermind
      • Erigon
        • Looking into Chiado connectivity issues
        • Nethermind might privilege Nethermind nodes, meaning that they might drop Erigon nodes that are “useless”
        • Nethermind doesn’t think that’s the case and will investigate this
          • --Network.DiagTracerEnabled true can be used for debugging
        • Progress on light CL
        • Stable as a read-only node
        • For validators: treat with caution
          • Misses more attestations than Nethermind and Geth on mainnet
          • Sometimes gets stuck, but not for long
          • From Lukasz, regarding useless peers
            • Invalid NetworkId
            • Capabilities not matched
            • TxFlooding (we are spammed with transaction broadcasts)
            • When someone tries to snap sync from us (as we don't implement snap-server)
            • There’s also another issue that Lukasz is investigating
    • Geth
      • No update
  • Consensus Layer

    • Prysm

      • Merged the changes
    • Nimbus (Philippe Schommers)

      • ghcr.io/filoozom/gnosis-nimbus-eth2:latest
        • Not used by the public yet
    • Gnosis deployed some nodes for testing and Erigon CL

    • Housekeeping

  • Chain infra

    • Gateway
      • Been running an Erigon archival node on Gnosis
        • All the nodes were stuck on the same block number
        • Indexing
      • Figuring out re-org
      • The RPC test is going fine
  • Additional Workstreams (will join this call in the future)

    • Shutterized Beacon Chain
    • Account Abstraction

· 3 min read
Ale Banzas
0xarmagan

Hello everyone from the weekly Gnosis Core Devs Call. This meeting is repeated on Wednesday every week. Watch on Gnosis Chain YouTube channel. ‍

Participants: Erigon, Gateway, Nethermind, Geth, Gnosis DevOps, Gnosis Core Devs, Gnosis DevRels, Gnosis Comms team and the contributors.

TL;DR

At this week's short meeting, the latest status updates on the withdrawal contract was talked and possible implementation scenarios were evaluated. In addition, opinions were shared about Shanghai testing tools and POSDAO testnet. Updates from Core Dev Team updates on Erigon, Gateway, Nethermind, Geth, Prysm were included in the agenda.Additionally, updates from the Core Dev Team updates about Erigon, Gateway, Nethermind, Geth, Prysm were included in the agenda.

Topics:​

  • Withdrawals Contract
  • Core Dev Team updates
  • Shanghai testing tools
  • Base Fee

Let’s take a look at the core devs call updates.

Call Notes

Withdrawals Contract

  • Not many changes since last week
  • Waiting for feedback before continuing the implementation _ 3 possibilities 1. Declare that the GNO token on the GC is a canonical token _ Mint it when the contract has not enough tokens _ Violates the first principles of the GNO token 2. Mint an GNO on GC token when the contract has not enough tokens _ Violates the bridge pledge logic 3. Do not issue a token when the contract has not enough tokens, but instead leave a note that in the future the user will be able to receive funds if they will be on the withdrawal contract (violates the logic of creating an mGNO token because of staking) E.g. “promissory”GNO

Chain Infra

  • Gateway
    • 20% of Chiado traffic goes to Gateway RPC
    • Need to start getting traffic from Mainnet RPC

Core Dev Team updates

  • EL
    • Erigon
      • No updates
    • Nethermind
      • Working on running devnets for withdrawals with mock contracts
      • The withdrawal spec is going to be different on Gnosis than on mainnet, so testing would be quite useful
      • Wrote a script to verify if some bytecodes are used
      • Resource utilization is apparently lower than before
    • Geth
    • Philippe
      • Added Chiado chainspec to Lodestar
      • Added deposit blocks for Gnosis and Chiado to
    • Erigon
      • To allow for –prune=r without having to specify –prune.r.before=firstDepositBlock
      • WIP: Light clients for CL for Gnosis and Erigon
      • WIP: Nimbus + Erigon

Other issues

  • Bridge Coordinator
    • Will update in subsequent week

Issues

  • Gateway
    • Shanghai testing tools?
    • Igor might have been working on this already
    • Waiting for him and dapplion
  • POSDAO tests?
    • Need to add withdrawals tests

· 4 min read
Ale Banzas
0xarmagan

Hello everyone from the weekly Gnosis Core Devs Call. This meeting is repeated on Wednesday every week. Watch on Gnosis Chain YouTube channel ‍

Participants: Erigon, Gateway, Nethermind, Geth, Gnosis Core Devs, Gnosis DevRels, Gnosis Comms team and the contributors.

TL;DR

During this week's meeting, the topic of the Withdrawal Contract was thoroughly discussed. The latest updates regarding xDai fees, which were brought to the table last week, were also discussed. Additionally, updates from the Core Dev Team (Erigon, Gateway, Nethermind, Geth, Prysm) were included in the agenda.

Topics:​

  • Withdrawals Contract
  • xDai “fees”
  • Core Dev Team updates
  • InterOp update
  • Base Fee

Let's take a look at the core devs call updates.

Call Notes

  • Chain Infra

  • Ale: from Discord

    • Source of “block rewards” GNO
      • Withdrawals contract (with Ihor)
      • Option 1: Large reserve that pays out GNO rewards (bridged from ETH)
      • Option 2: Hardfork to “mint” GNO on-chain native to Gnosis Chain
  • Withdrawals Contract

    • Current status
    • Need to decide on approach given differences between ETH & GNO
      • Ethereum = ETH is native, while mGNO is not
      • Withdrawals on GNO will “withdraw” it from the deposit contract
    • The “deposit contract” option is being taken for now _ Withdrawal contract will rely on “reserve” contract that will be funded before/after _ Treasury will need to send more GNO to the Withdrawal contrat to account for block rewards https://etherscan.io/token/0x6810e776880c02933d47db1b9fc05908e5386b96#balances https://github.com/gnosischain/concepts/specs/blob/master/execution/withdrawals.md
    • Alternative approach
      • Minting mGNO on Gnosis Chain thru increment the mGNO token registry thru system call (i.e. “issue” mGNO)
      • Ihor: how do we maintain total token balance (i.e. sum(GNO on Ethereum chain) == 3_000_000)
    • There is no way to convert mGNO to GNO
      • Ihor is implementing mGNO to GNO unwrapping logic in the mGNO wrapper
      • Upgradeable contract
    • Long-term business direction
      • GNO on Ethereum is a “claim” against native GNO on Gnosis
      • Reduce dependency of GNO on GNO on Etheruem or Bridges
    • Need to write a forum post on Gnosis Forum
  • xDai “fees”

  • Core Dev Team updates

    • Erigon
      • Fixing issues with eth_blockNumber
      • Prep EIP-170 with Shanghai update
        • Contract code size limit
        • Previously omitted in Gnosis Chain - POSDAO had code size limit in POSDAO contract (permissionContract)
        • EIP-3860 - relies on EIP-170
      • Prep for Withdrawals work
    • Nethermind
      • Waiting on Withdrawals spec
      • Proof-of-concept implementation based on what Nethermind team knows about withdrawals
      • Can do some local testing on
      • Scanning chain for opcodes +
    • Gateway
      • Igor: This week we finalized Chiado checkpoint sync endpoint, I fixed some tracing issue in Erigon reported by our users, waiting for more traffic from Gnosis RPC
    • Geth
      • Full Sync
      • Snap Sync - some issues
    • Prysm
      • Merged the PR
      • Should be able to run stock on Prysm - pass in config file
      • Let Guillaume know if we encounter issues
  • Any other issues

    • Philippe: Erigon + Nimbus are publishing blocks
  • Base Fee

    • Spam protection
    • 1 gwei would allow it to kick in within ~10min of full blocks, vs hours
    • Tomasz had strong objections - should table it
  • InterOp update?

    • Withdrawals + Shanghai - shadowforks are working
    • SSZ in execution layer (vs RLP for txns)
      • SSZ (CL) vs RLP (EL)
      • Backward compatibility of txns in SSZ
    • EOF - shelved
    • Specs
      • Danube - 4844
      • Electra - verkle (Guillaume)
  • Consensus Spec tests

    • Needed for Nimbus merge

· 2 min read
Ale Banzas
0xarmagan

Call Info

Hello everyone from the weekly Gnosis Core Devs Call. This meeting is repeated on Wednesday every week. Watch on Gnosis Chain YouTube channel ‍ Participants: Erigon, Gateway, Nethermind, Gnosis DevOps, Gnosis Core Devs, Gnosis Comms team and the contributors.

Topics:

  • Shanghai upgrades details from Nethermind
  • RPC updates from Gateway
  • Suggestion from Stefan: Increase base fee to 1GWEI?

Let's take a look at the core devs call updates.

Erigon

  • Chiado: Might be finished this month
  • Mainnet: Erigon got stuck while syncing mainnet twice, reboot helped
  • Also affects other networks
  • Not seen in 2.36.1 yet
  • Work going on for withdrawals (for Ethereum mainnet)
  • We should review the specs for Gnosis when everyone is back, because there’s some new context

Gateway

  • Launched archival RPC (Gnosis mainnet)
  • Will launch a website with the new public RPC
  • Launching checkpoint sync for Chiado (probably today)
  • Fixed an issue with the rate limiter that was too eager
  • Looking into looking a bridge validator on Chiado, and then on mainnet
  • Waiting for Giacomo to accept traffic on the RPC

Nethermind

  • Implementation for withdrawals on Gnosis (and mainnet)
  • Only missing part is the smart contract used for withdrawals
  • Stefan: Ihor will write the contracts (WIP, ETA: 1 month)

Stefan: Increase base fee to 1GWEI? ‍

  • Allows us to make constant spamming very costly. Currently it is too cheap.
  • Current base fee: 7 wei -> extremely cheap to spam the network for a long time
  • Increasing the base fee to 1 gwei would make it expensive to spam the network even for 10 minutes
  • Would require a simple hard fork, which could be included in another hard fork ‍

Jorge (Nethermind)‍

  • No strong opinion
  • The computation limit is bound by the gas limit anyways
  • Sustained loads would increase the gas price exponentially as per EIP-1559
  • On Chiado, a spam of 30 - 60 minutes increased the base fee to hundreds of gwei
  • The main idea is to prevent nefarious actors to put relevant transactions on hold for some time, which would degrade user experience

Gnosis DevOps

  • Chiado RPC routing implemented (testing with Gateway), then mainnet
  • 2 Chiado long-term bootnodes
  • Update configs

· One min read
Lion - dapplion
Plato

Overview

At Block 6,306,357, the Gnosis Execution Layer network successfully merged with the Consensus Layer network.

The Merge was uneventful, which was the best possible outcome after months of hard work and testing by the team.

Resuming Bridge Operations

After a ~36 hour observation period, the Gnosis Governance Multisig proceeded to restore the pre-merge limits for the Bridge.

The xDai Bridge, Arbitrary Message Bridge and Omnibridge resumed regular operation at 10 Dec 2022 03:21 UTC.

· 2 min read
Lion - dapplion
Plato
deprecated update

Check the latest and recommended bootnodes in the network page.

Overview

Problem

  • On 7 Dec 2022, a subset of Bootnodes that were baked into the Gnosis client releases stopped functioning normally.
  • This resulted in instances of new nodes being unable to find peers unless they specified custom bootnodes.
  • This became a problem for newly-introduced nodes (current nodes unaffected).

Fix

  • Core Devs have put together a alternative list of temporary bootnodes that will be active for Dec 2022.
  • These Bootnodes are run by various teams in the Gnosis ecosystem.
  • Node operators will need to specify custom bootnodes when running a fresh Execution or Consensus node.
  • Core Devs will bake updated set of long-term Bootnodes into the next client releases

Execution Layer

Nethermind

Nethermind utilizes the flag --Discovery.Bootnodes to specify custom bootnodes.

Docs: Nethermind Github

nethermind
--config gnosis
--Discovery.Bootnodes ... # comma separated enode addresses

List of EL Bootnodes

caution

Note: Temporary Nodes provided below are unlikely to be the long-term Bootnodes. You should not expect them to be operational post Jan 2022.

Comma-Separated Values

enode://a8558c4449bdb4ed47b8fd0ceaee8cf56272cd308e98e693a838d58b9abd2411b71b9b7e2d63a50b140fd9b0a2e05e83f338c3906dd925e9f178f0feda0c4ca7@165.232.138.187:30303,enode://e52280c512cd1f023135d7f70f31904bda7bb699d4300346182a2e3fc5a07637c25cc4349b48101ffe2fe6229b3b165ed7929ad9db971d847d02e21192989ce5@143.198.156.24:30303,enode://8ed1893f617f1ed2c6a978fa92fa38ac19db6de5596c93bf21921c40ed34f63b63a93234ddedf9b385192dd7aa652e1d4b55efed299961b0ae5d4318ecb985ec@159.223.213.61:30303,enode://cc3f99a19360edd73f91f04c6fe728ff8da431f8445a35c02a0fd99fee2be5d9f5ea75a416b08f4a019e0a0d3afa8aece93a560bbe3ce0509eec54bbddc00bb8@178.62.194.136:30303,enode://8f3a63b270cd32692f5b825874b9f3acef3cf90dec40fe54848267f568b7275349efb830812c1b24f1781774f745fb00e595d2feef642fd6867e173f05108cc4@178.62.192.195:30303,enode://075d567bcc5b6bbcb5c9922bf7f17a706408bed141dcefb5d387cfe6e0c7c9407e450a5d17b9180b25fb07b3e82943639d011752ea44a2d868b3c37f48a318b9@167.99.209.14:30303,enode://bb19f1fcf0d0667d9752bec2f4230e24331a7764e5a73a41006378861ef79f9a4386f646e239e1842e4bb721ade9369be8f2fd81b407d9febec2e150ccb7f257@137.184.228.83:30303,enode://529cc11acd013d5e92aa38d4139636619285b2bb4221bcdf7c5dbf171e828d05b88934e6154b984f8164953d7d7530b49c6d0e030fade3a3737d28092a289704@164.92.96.111:30303,enode://9d41c6f8c77a1ac3069cc9326068c04465b9fc56abaaf84fa753fc723511f278dd1d65c22753eb60dfd95f60fe942d0f670c490660e3d6cd518ddafb986682d2@178.62.196.104:30303,enode://874ac7df642fc2abffcca71991c3646a5634a415a4a6513112a89429f7ae43914ad6f1d2ea73a96a19f302c17a7c5e07a0dd01fed70c9294a6fd5615b86710b7@159.223.213.166:30303,enode://5d1a11b5f19afb7d2d04406a4877ed7de92a4ca898ee0d36ff54729b99664e4ac787877e553043a38a38f878aab43fc0d757673e0c11ee8eb606f1ea4681ce3c@147.182.204.197:30303,enode://144d125c790100f6405d957dea8c3a1647199109d915889e90d7f6c2940c8737b16e68e2a3af57327971ec28ed77408f9bc96035b2589da6496f3112ec72e037@137.184.183.65:30303,enode://ac8e8a62f5b54c35f4d7eb565079e9c81e241a150c0d6b2bb5bb32b068e8e4930b14a5b504f77d34014c8e9f14ec0307cc6b239e8c56be85fdcc68d4956cce7c@159.223.213.157:30303,enode://20b0de013d851ae5b667f41a923f2856420161fe0a46030cdea6d81db8da3c5b04070834219a2a6ca41d8f2c6c813870414ce473ab25736742163b0be6191861@159.223.209.185:30303,enode://3c8de197987eb896488ed60037b44c5201878d7cb47d22a322d6d73b999b1d5482820e0456dc08676665ba1ce96906900a2b5f830b2eea73730ca7532c227c7b@159.223.217.249:30303,enode://644ad8205801f9dba1d6eff107590d49479d5276c8d078f8631f351a2077d70b7bed2822219cb1c7590ba68149b89751968a45236e7d02c1025e493d647dd776@159.223.213.162:3030

Array

[
"enode://a8558c4449bdb4ed47b8fd0ceaee8cf56272cd308e98e693a838d58b9abd2411b71b9b7e2d63a50b140fd9b0a2e05e83f338c3906dd925e9f178f0feda0c4ca7@165.232.138.187:30303",
"enode://e52280c512cd1f023135d7f70f31904bda7bb699d4300346182a2e3fc5a07637c25cc4349b48101ffe2fe6229b3b165ed7929ad9db971d847d02e21192989ce5@143.198.156.24:30303",
"enode://8ed1893f617f1ed2c6a978fa92fa38ac19db6de5596c93bf21921c40ed34f63b63a93234ddedf9b385192dd7aa652e1d4b55efed299961b0ae5d4318ecb985ec@159.223.213.61:30303",
"enode://cc3f99a19360edd73f91f04c6fe728ff8da431f8445a35c02a0fd99fee2be5d9f5ea75a416b08f4a019e0a0d3afa8aece93a560bbe3ce0509eec54bbddc00bb8@178.62.194.136:30303",
"enode://8f3a63b270cd32692f5b825874b9f3acef3cf90dec40fe54848267f568b7275349efb830812c1b24f1781774f745fb00e595d2feef642fd6867e173f05108cc4@178.62.192.195:30303",
"enode://075d567bcc5b6bbcb5c9922bf7f17a706408bed141dcefb5d387cfe6e0c7c9407e450a5d17b9180b25fb07b3e82943639d011752ea44a2d868b3c37f48a318b9@167.99.209.14:30303",
"enode://bb19f1fcf0d0667d9752bec2f4230e24331a7764e5a73a41006378861ef79f9a4386f646e239e1842e4bb721ade9369be8f2fd81b407d9febec2e150ccb7f257@137.184.228.83:30303",
"enode://529cc11acd013d5e92aa38d4139636619285b2bb4221bcdf7c5dbf171e828d05b88934e6154b984f8164953d7d7530b49c6d0e030fade3a3737d28092a289704@164.92.96.111:30303",
"enode://9d41c6f8c77a1ac3069cc9326068c04465b9fc56abaaf84fa753fc723511f278dd1d65c22753eb60dfd95f60fe942d0f670c490660e3d6cd518ddafb986682d2@178.62.196.104:30303",
"enode://874ac7df642fc2abffcca71991c3646a5634a415a4a6513112a89429f7ae43914ad6f1d2ea73a96a19f302c17a7c5e07a0dd01fed70c9294a6fd5615b86710b7@159.223.213.166:30303",
"enode://5d1a11b5f19afb7d2d04406a4877ed7de92a4ca898ee0d36ff54729b99664e4ac787877e553043a38a38f878aab43fc0d757673e0c11ee8eb606f1ea4681ce3c@147.182.204.197:30303",
"enode://144d125c790100f6405d957dea8c3a1647199109d915889e90d7f6c2940c8737b16e68e2a3af57327971ec28ed77408f9bc96035b2589da6496f3112ec72e037@137.184.183.65:30303",
"enode://ac8e8a62f5b54c35f4d7eb565079e9c81e241a150c0d6b2bb5bb32b068e8e4930b14a5b504f77d34014c8e9f14ec0307cc6b239e8c56be85fdcc68d4956cce7c@159.223.213.157:30303",
"enode://20b0de013d851ae5b667f41a923f2856420161fe0a46030cdea6d81db8da3c5b04070834219a2a6ca41d8f2c6c813870414ce473ab25736742163b0be6191861@159.223.209.185:30303",
"enode://3c8de197987eb896488ed60037b44c5201878d7cb47d22a322d6d73b999b1d5482820e0456dc08676665ba1ce96906900a2b5f830b2eea73730ca7532c227c7b@159.223.217.249:30303",
"enode://644ad8205801f9dba1d6eff107590d49479d5276c8d078f8631f351a2077d70b7bed2822219cb1c7590ba68149b89751968a45236e7d02c1025e493d647dd776@159.223.213.162:30303"
]

Consensus Layer

Teku

Teku utilizes the flag --p2p-discovery-bootnodes to specify custom bootnodes.

Docs: https://docs.teku.consensys.net/en/latest/Reference/CLI/CLI-Syntax/#p2p-discovery-bootnodes

teku
--network=gnosis
--p2p-discovery-bootnodes=... # comma-separated ENR addresses
...

Lighthouse

Lighthouse utilizes the flag --boot-nodes to specify custom bootnodes.

Docs: Lighthouse CLI .help

lighthouse 
beacon_node
--network=gnosis
--boot-nodes=... # comma-separated ENR addresses

Lodestar

Lodestar utilizes multiple --bootnodes flags to specify custom bootnodes.

Docs: https://chainsafe.github.io/lodestar/beacon-management/networking/#peer-discovery-discv5

lodestar
beacon
--network=gnosis
--bootnodes=... # first ENR (1 per line)
--bootnodes=... # second ENR (1 per line)

List of CL Bootnodes

caution

Note: Temporary Nodes provided below are unlikely to be the long-term Bootnodes. You should not expect them to be operational post Jan 2022.

Comma-separated Values

enr:-Ly4QClooKhmB409-xLE52rTmC2h9kZBO_VFXR-kjqLDdduuZoxsjfwTxa1jscQMBpqmezG_JCwPpEzEYRM_1UCy-0gCh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhKXoiruJc2VjcDI1NmsxoQLLYztVAaOL2dhsQf884Vth9ro6n9p2yj-osPfZ0L_NwYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QHO5_3Zuosjt9IJQF3ovGroSWyB4rMZFUulOl5R5PkjcfVwtYewEp2TvUpo9tvHYMGKpDxgAYmjjTJcGasqn9uoCh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhI_GnBiJc2VjcDI1NmsxoQJqvGdusfukoXNx3F84umajVgkfVs0wasHeY45qcYgwf4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QPd8v1jzDOHuEAEJ-NPgbLgRRbsuuz4KZOSZ2YiIaD0dQ-BMbbzEw0Cix5wst0suFVrsrB73dg0_980zpbKKzzEBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhJ_f1T2Jc2VjcDI1NmsxoQNdZWlOxiBbJltPxilQgdllvE_cNF6sC1bpyRUyWegVjohzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QAOrFTIBlS__dwh0hhMLcGB-mbRTgMJc1P4MfMyd15-dX75_TBq7RsqWMLsZzdidoU41zO0fvI8-w7N8dHrpA54Bh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhLI-woiJc2VjcDI1NmsxoQKeJ-BUNBGaVYX1MgnAsvjgJpGXVKgEMZa1_FMG8fTYl4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QM0mWWtb978oZpY46_DVEY9SOkyDKprDlu6NyI6cjRX0TDYGp9txkyREyRw3mIkXWFDsdhONUZqKzjD09lp3iLIBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhLI-wMOJc2VjcDI1NmsxoQNXBYeo4Oa9Hksc247JWokwgpZAJzZxWMMK1KG3UYl4w4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QDnJWKfiGm6U6SyLr8r-BfM6zHlI90VPsgbxiXb6GhIUVcDmeGw_IRxLpUAelnu2sH8TtF9uenfIGdAshoUZHAUBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhKdj0Q6Jc2VjcDI1NmsxoQIrmmOVYy87sV-n8x8QxfCKLsf_eKqwk6Rl5Gj-YLV8wYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-L24QJHzedzjOM6Xm53qSdrbP635LvqpxFCJy_2T84rZvVVjV81kS_kRKp7vV_PFPS2EHdSzpXtDMJCugvzdhjRZeGkGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhIm45FOJc2VjcDI1NmsxoQPHxbRx1Ev72MVVUergKeLznxrchLhB3lK9ljWCbCuGWYhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg,enr:-L24QK00qalnMGv7PVg5k9Z7OjPFhIFoHLm6SDP8DjKOgFO5aUHzCqecoA9S3Y_0nI8mOF8sF1mYqYEE7byacE1Vq6YGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhKRcYG-Jc2VjcDI1NmsxoQPUtWI-6bkId_18Hy0KCautFQ5GJD-f2cgYCqNS5EekRIhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg,enr:-L24QPdWmlPHi-0fQKptAjtkhKG50novgUHWeP5amyi_lGSWcQPAahWl7Ci3kW2p1Sd6WRtqlgkxSyvc6wioeaQl9ZIGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhLI-xGiJc2VjcDI1NmsxoQLNCuDR6ik6JcTW8uAsoPn6AMgtNvGq65kCnJmA2HY2JIhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg,enr:-L24QICiK4pSRAOgkO7R3yQVbjJXGVt1vbdvXsom0yA-UqlMIHO98f8tZyEKbz0lrgrdy89Vw_agSKzuGS7Hgi3QsygGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhJ_f1aaJc2VjcDI1NmsxoQKyGQswAJ5pJaPF9WRpGU4Lp8CdxiSlm8AHJsr1naz_7YhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg,enr:-KG4QKWOgedErRLsanl1AUjTFnHB-RO9OsyFP-vtSrX2VGxRBdvoJVrzBJwgGYLIBiDjqy0eYJ2r8ZosAjkWhQ02koUGhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39WdiXNlY3AyNTZrMaEDYAuZlJpKwWdGtbSrVgy6N5sdMjehVglGMGGkBCFg_VeDdGNwgiMog3VkcIIjKA,enr:-KG4QBart9YQV5Ju3EMxUUnJ0ntgYf7J6jDbEPySiR7R8gJ9DcTp22gArHqWSMQVyt0-TMnuZrZQCprcaka5J8B9JN8GhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39G5iXNlY3AyNTZrMaED13MHlUcbr4978YYNRurZtykey8gTY_O5pQ4a427ZICuDdGNwgiMog3VkcIIjKA,enr:-KG4QLk-EkZCAjhMaBSlB4r6Icrz137hIx6WXg5AKIXQl9vkPt876WxIhzu8dVPCLVfaPzjAsIjXeBUPy2E3VH4QEuEGhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39n5iXNlY3AyNTZrMaECtocMlfvwxqouGi13SSdG6Tkn3shkyBQt1BIpF0fhXc-DdGNwgiMog3VkcIIjKA,enr:-KG4QDXI2zubDpp7QowlafGwwTLu4w-gFztFYNnA6_I0vrpaS9bXQydY_Gh8Dc6c7cy9SHEi56HRfle9jkKIbSRQ2B8GhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39WiiXNlY3AyNTZrMaECZ2_0tLZ9kb0Wn-lVNcZEyhVG9dmXX_xzQXQq24sdbZiDdGNwgiMog3VkcIIjKA,enr:-LK4QPnudCfJYvcmV-LjJBU5jexY3QTdC1PepWK08OHb4w_BJ3OgFbh0Bc2nb1WRK6p2CBNOPAixpPrtAvmNQPgegDgBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpBW_bXgAQAAZP__________gmlkgnY0gmlwhJO2zMWJc2VjcDI1NmsxoQKk8-B9o94CY2UUK2bxPpl-T_yHmTtE7rAPaT26M4w09YN0Y3CCIyiDdWRwgiMo,enr:-LK4QArhQjC_S3CwptV7balWpNP5IVKweAqZzvq93vz_zN_ZSruOxBU5ECgqOBUFHO1nYUveOYVeiEKswg637rOURDABh2F0dG5ldHOIAAAAAAAAAACEZXRoMpBW_bXgAQAAZP__________gmlkgnY0gmlwhIm4t0GJc2VjcDI1NmsxoQIj9iJm4h7OAhhCoUcqfn41_fj9F7UfKnISj_-xqKH834N0Y3CCIyiDdWRwgiMo,enr:-Ly4QMU1y81COwm1VZgxGF4_eZ21ub9-GHF6dXZ29aEJ0oZpcV2Rysw-viaEKfpcpu9ZarILJLxFZjcKOjE0Sybs3MQBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhANLnx-Jc2VjcDI1NmsxoQKoaYT8I-wf2I_f_ii6EgoSSXj5T3bhiDyW-7ZLsY3T64hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QJcPfzPTwhknVlYmCMYo1vtOqItLLV9iiydSuMYoCcJ6G38V6JiJaRNQUTR-1sivBsJIESP9A4KhoO_k9vOR9ZoBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhBLGgjaJc2VjcDI1NmsxoQPKKRjNBuhorFa1FbCJ8xgkbhu5Jm-uYyafBiLIN-mIiYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QLjZUWdqUO_RwyDqCAccIK5-MbLRD6A2c7oBuVbBgBnWDkEf0UKJVAaJqi2pO101WVQQLYSnYgz1Q3pRhYdrlFoBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhANA8sSJc2VjcDI1NmsxoQK4TC_EK1jSs0VVPUpOjIo1rhJmff2SLBPFOWSXMwdLVYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA,enr:-Ly4QKwX2rTFtKWKQHSGQFhquxsxL1jewO8JB1MG-jgHqAZVFWxnb3yMoQqnYSV1bk25-_jiLuhIulxar3RBWXEDm6EBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhAN-qZeJc2VjcDI1NmsxoQI7EPGMpecl0QofLp4Wy_lYNCCChUFEH6kY7k-oBGkPFIhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA

One-per Line

enr:-Ly4QClooKhmB409-xLE52rTmC2h9kZBO_VFXR-kjqLDdduuZoxsjfwTxa1jscQMBpqmezG_JCwPpEzEYRM_1UCy-0gCh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhKXoiruJc2VjcDI1NmsxoQLLYztVAaOL2dhsQf884Vth9ro6n9p2yj-osPfZ0L_NwYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QHO5_3Zuosjt9IJQF3ovGroSWyB4rMZFUulOl5R5PkjcfVwtYewEp2TvUpo9tvHYMGKpDxgAYmjjTJcGasqn9uoCh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhI_GnBiJc2VjcDI1NmsxoQJqvGdusfukoXNx3F84umajVgkfVs0wasHeY45qcYgwf4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QPd8v1jzDOHuEAEJ-NPgbLgRRbsuuz4KZOSZ2YiIaD0dQ-BMbbzEw0Cix5wst0suFVrsrB73dg0_980zpbKKzzEBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhJ_f1T2Jc2VjcDI1NmsxoQNdZWlOxiBbJltPxilQgdllvE_cNF6sC1bpyRUyWegVjohzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QAOrFTIBlS__dwh0hhMLcGB-mbRTgMJc1P4MfMyd15-dX75_TBq7RsqWMLsZzdidoU41zO0fvI8-w7N8dHrpA54Bh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhLI-woiJc2VjcDI1NmsxoQKeJ-BUNBGaVYX1MgnAsvjgJpGXVKgEMZa1_FMG8fTYl4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QM0mWWtb978oZpY46_DVEY9SOkyDKprDlu6NyI6cjRX0TDYGp9txkyREyRw3mIkXWFDsdhONUZqKzjD09lp3iLIBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhLI-wMOJc2VjcDI1NmsxoQNXBYeo4Oa9Hksc247JWokwgpZAJzZxWMMK1KG3UYl4w4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QDnJWKfiGm6U6SyLr8r-BfM6zHlI90VPsgbxiXb6GhIUVcDmeGw_IRxLpUAelnu2sH8TtF9uenfIGdAshoUZHAUBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhKdj0Q6Jc2VjcDI1NmsxoQIrmmOVYy87sV-n8x8QxfCKLsf_eKqwk6Rl5Gj-YLV8wYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-L24QJHzedzjOM6Xm53qSdrbP635LvqpxFCJy_2T84rZvVVjV81kS_kRKp7vV_PFPS2EHdSzpXtDMJCugvzdhjRZeGkGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhIm45FOJc2VjcDI1NmsxoQPHxbRx1Ev72MVVUergKeLznxrchLhB3lK9ljWCbCuGWYhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg
enr:-L24QK00qalnMGv7PVg5k9Z7OjPFhIFoHLm6SDP8DjKOgFO5aUHzCqecoA9S3Y_0nI8mOF8sF1mYqYEE7byacE1Vq6YGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhKRcYG-Jc2VjcDI1NmsxoQPUtWI-6bkId_18Hy0KCautFQ5GJD-f2cgYCqNS5EekRIhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg
enr:-L24QPdWmlPHi-0fQKptAjtkhKG50novgUHWeP5amyi_lGSWcQPAahWl7Ci3kW2p1Sd6WRtqlgkxSyvc6wioeaQl9ZIGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhLI-xGiJc2VjcDI1NmsxoQLNCuDR6ik6JcTW8uAsoPn6AMgtNvGq65kCnJmA2HY2JIhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg
enr:-L24QICiK4pSRAOgkO7R3yQVbjJXGVt1vbdvXsom0yA-UqlMIHO98f8tZyEKbz0lrgrdy89Vw_agSKzuGS7Hgi3QsygGh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhJ_f1aaJc2VjcDI1NmsxoQKyGQswAJ5pJaPF9WRpGU4Lp8CdxiSlm8AHJsr1naz_7YhzeW5jbmV0c4gAAAAAAAAAAIN0Y3CCIyg
enr:-KG4QKWOgedErRLsanl1AUjTFnHB-RO9OsyFP-vtSrX2VGxRBdvoJVrzBJwgGYLIBiDjqy0eYJ2r8ZosAjkWhQ02koUGhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39WdiXNlY3AyNTZrMaEDYAuZlJpKwWdGtbSrVgy6N5sdMjehVglGMGGkBCFg_VeDdGNwgiMog3VkcIIjKA
enr:-KG4QBart9YQV5Ju3EMxUUnJ0ntgYf7J6jDbEPySiR7R8gJ9DcTp22gArHqWSMQVyt0-TMnuZrZQCprcaka5J8B9JN8GhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39G5iXNlY3AyNTZrMaED13MHlUcbr4978YYNRurZtykey8gTY_O5pQ4a427ZICuDdGNwgiMog3VkcIIjKA
enr:-KG4QLk-EkZCAjhMaBSlB4r6Icrz137hIx6WXg5AKIXQl9vkPt876WxIhzu8dVPCLVfaPzjAsIjXeBUPy2E3VH4QEuEGhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39n5iXNlY3AyNTZrMaECtocMlfvwxqouGi13SSdG6Tkn3shkyBQt1BIpF0fhXc-DdGNwgiMog3VkcIIjKA
enr:-KG4QDXI2zubDpp7QowlafGwwTLu4w-gFztFYNnA6_I0vrpaS9bXQydY_Gh8Dc6c7cy9SHEi56HRfle9jkKIbSRQ2B8GhGV0aDKQgkvkMQIAAGT__________4JpZIJ2NIJpcISf39WiiXNlY3AyNTZrMaECZ2_0tLZ9kb0Wn-lVNcZEyhVG9dmXX_xzQXQq24sdbZiDdGNwgiMog3VkcIIjKA
enr:-LK4QPnudCfJYvcmV-LjJBU5jexY3QTdC1PepWK08OHb4w_BJ3OgFbh0Bc2nb1WRK6p2CBNOPAixpPrtAvmNQPgegDgBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpBW_bXgAQAAZP__________gmlkgnY0gmlwhJO2zMWJc2VjcDI1NmsxoQKk8-B9o94CY2UUK2bxPpl-T_yHmTtE7rAPaT26M4w09YN0Y3CCIyiDdWRwgiMo
enr:-LK4QArhQjC_S3CwptV7balWpNP5IVKweAqZzvq93vz_zN_ZSruOxBU5ECgqOBUFHO1nYUveOYVeiEKswg637rOURDABh2F0dG5ldHOIAAAAAAAAAACEZXRoMpBW_bXgAQAAZP__________gmlkgnY0gmlwhIm4t0GJc2VjcDI1NmsxoQIj9iJm4h7OAhhCoUcqfn41_fj9F7UfKnISj_-xqKH834N0Y3CCIyiDdWRwgiMo
enr:-Ly4QMU1y81COwm1VZgxGF4_eZ21ub9-GHF6dXZ29aEJ0oZpcV2Rysw-viaEKfpcpu9ZarILJLxFZjcKOjE0Sybs3MQBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhANLnx-Jc2VjcDI1NmsxoQKoaYT8I-wf2I_f_ii6EgoSSXj5T3bhiDyW-7ZLsY3T64hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QJcPfzPTwhknVlYmCMYo1vtOqItLLV9iiydSuMYoCcJ6G38V6JiJaRNQUTR-1sivBsJIESP9A4KhoO_k9vOR9ZoBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhBLGgjaJc2VjcDI1NmsxoQPKKRjNBuhorFa1FbCJ8xgkbhu5Jm-uYyafBiLIN-mIiYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QLjZUWdqUO_RwyDqCAccIK5-MbLRD6A2c7oBuVbBgBnWDkEf0UKJVAaJqi2pO101WVQQLYSnYgz1Q3pRhYdrlFoBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhANA8sSJc2VjcDI1NmsxoQK4TC_EK1jSs0VVPUpOjIo1rhJmff2SLBPFOWSXMwdLVYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA
enr:-Ly4QKwX2rTFtKWKQHSGQFhquxsxL1jewO8JB1MG-jgHqAZVFWxnb3yMoQqnYSV1bk25-_jiLuhIulxar3RBWXEDm6EBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpCCS-QxAgAAZP__________gmlkgnY0gmlwhAN-qZeJc2VjcDI1NmsxoQI7EPGMpecl0QofLp4Wy_lYNCCChUFEH6kY7k-oBGkPFIhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA

· 4 min read
barichek
Ale Banzas
Plato

Overview

  • Gnosis will be temporarily pausing its Native Bridges for the duration of the Merge
  • This is a risk-management operation that will be rolled back once normal operation of the chain has been verified post-Merge
  • This will affect both the Omnibridge and xDai Bridge, and any 3rd-party bridges or dApps that utilize the Native Bridge contracts.

Pausing of Bridges

24 hours prior to the Merge TTD (currently tracking for ~8th Dec 2022 18:43 UTC), the Gnosis Bridge Governance Multisig will execute a transaction to set the the following bridge parameters.

BridgeDetails
xDai BridgeDailyLimit set to 0 on all Bridge Contracts

This will prevent any transaction from going through.
Arbitrary Message Bridge
Omnibridge
SetMaxGasPerTx set to 0 on all Bridge Contracts

This will prevent any arbitrary message call from going through.

Unpausing of Bridges

There will be an 96 hour observation period post-merge to ensure that the chain finalizes without incident. Once this observation period has passed without incident, the Gnosis Bridge Governance Multisig will execute the following transactions to restore the pre-Merge bridge limits. GnosisDAO may also elect to unpause the bridges earlier.

BridgeDetails
xDai BridgeLimits restored to Pre-Merge limits
Arbitrary Message Bridge
Omnibridge
Arbitrary Messages can be sent.
Omnibridge limits restored to Pre-Merge limits

Details

xDai Bridge

Bridge ContractInitial LimitTemporary Limit
Gnosis
HomeBridgeERCtoNative
100000000000000000000000010
Ethereum
ForeignBridgeERCtoNative
100000000000000000000000000

AMB & Omnibridge

Ethereum - Gnosis

Bridge ContractInitial LimitTemporary Limit
Gnosis
HomeAMB
20000000
Ethereum
ForeignAMB
40000000

Gnosis - BNBChain

Bridge ContractInitial LimitTemporary Limit
Gnosis
HomeGC <-> BSC
20000000
Ethereum
ForeignGC <-> BSC
50000000

FAQs

Will the Bridge Contracts remain operational during this time?

  • Bridge Contracts are smart contracts, and remain active on chain
  • The "pause" refers to parameters that are being set on these smart contracts that effectively limit their usage

Will Bridge Validators continue to operate during this time?

  • Bridge Validators will continue to be operational, but will not relay any messages as the events they listen to will not trigger due to the limits set

Can my dApp continue to use the AMB?

  • The Arbitrary Message Bridge (AMB) will not relay messages between the supported networks, as _sendMessage requires a non-null gas limit.
  • Both the OmniBridge and xDai Bridge won’t initiate since the established values will prevent it.

Can I continue to use the Omnibridge?

  • No, you will not be able to use the Omnibridge as it depends on the Arbitrary Message Bridge, which is unable to relay messages due to the gas limit.

What are the conditions by which the bridges will be enabled again?

A few of the conditions we will be monitoring post-Merge:

  • Gnosis Chain should be able to finalize
  • Execution Layer and Consensus Layer "merge" without incident
  • Validators are not experiencing major issues
  • Bridge Validators are operational

After confirming the successful merge of Gnosis mainnet and the beacon chain, we will restore OmniBridge and xDai Bridge initial parameters.

· 13 min read
Archive Post

This post is more than one year old. The information may be outdated. Check the latest posts.

Representatives from xDai (Igor Barinov) and Gnosis (Stefan George) answered questions about the proposed merger. Questions were also collected throughout the past week and some are listed below. Questions below the AMA video give some additional context and see responses to popular questions that may not have been raised during the call.

The proposal is available here for reference.

Questions from the Community

We include some questions and answers here from the initial form sent out to the community. Some questions were redundant and not included, or edited for clarity. We will update with the recording and other relevant questions after the AMA.

1. What motivated the developers to propose this?

Both teams have worked together for some time, and looking ahead there are some big changes coming to Ethereum and associated scaling solutions. To come from a position of strength, it makes sense to combine forces and consolidate resources when two conditions are met:

  1. The teams share the same values in building technically excellent products in the spirit of open innovation. Both Gnosis and xDai are committed to fostering network effects without locking users in. Both Gnosis and xDai champion self-sovereign network participants.
  2. The technology stacks being developed by both teams compliment each other and together provide a comprehensive scaling solution for users.

2. Are the holdings of the developers in GNO and STAKE made public?

The initial STAKE distribution for the xDai team and investors is available here. These tokens have mostly been distributed and team holdings besides the distributions remaining to the ecosystem fund have been dispersed.

A partnership announced between the teams last year resulted a Gnosis investment in xDai for 250K STAKE.

Beyond these distributions STAKE tokens are held by the greater community and all trades are transparent on BlockScout & Etherscan. The following includes contracts holding STAKE as well as EOAs.

3. While Gnosis is planning to split the governance power of GNO into COW and SAFE for their other products, do you think it is reasonable to proceed with the merger based on the current value of GNO (which actually includes the governance value of their products that will likely have a separate governance token)? Why not wait for their token splits from GNO?

Gnosis holders will benefit significantly from the launch of the COW and SAFE tokens, both directly via an airdrop and a much coveted investment opportunity into the projects. The value of GNO is additionally backed by 700M in crypto assets (excluding GNO) that are in the process of being move to the DAO (and under the direct control of the GNO token holders)

  1. GNO holders will benefit directly from the token launches of the spin-off projects.
  2. GNO holders control a very significant treasury (USD 700M in ETH and other tokens, excluding GNO).

4. What changes will be made to the GNO issuance policy and distribution methodology?

400k GNO held by the DAO (currently ~190m USD) will be used to incentivize adoption of Gnosis Chain. The DAO (i.e. all current GNO holders) holds 8m GNO. It is likely that the DAO will decide to burn some of these tokens.

5. How can the merge benefit the xDai community with respect to the STAKE holders?

In the event of a merge, STAKE holders will become GNO holders and retain the ability to voice opinions and steer directions for the chain. STAKE holders will hold 20% of the GNO in circulation at the proposed token merge rate. The idea is that combining forces of these 2 projects will result in a stronger and more complete entity, with the hope that the market would acknowledge this and the Gnosis Chain & GNO would benefit accordingly.

6. How will the chain be secured? If only 1 Gno is req for running a node, the price of Gno needs to have a big upside or the chain can be easy overtaken by others? How will it be decentralized?

There will be many more validators with the beacon chain, along with random validator shuffling to prevent attacks and collusion. This is a good resource to understand how the validator and proposer functionality works and what to expect with the beacon chain (this is for the ETH Beacon chain but methods will work similarly on the mirrored beacon-chain https://ethos.dev/beacon-chain/. The chain has the potential to be much more decentralized as many more regular users around the world can participate with a lower economic barrier to entry. There are some ideas to subsidize hardware to encourage participation.

7. What exactly are the metrics/statistics of some of the 'marketing objectives' / branding strength is Gnosis offering?

These types of metrics will be developed by a newly created team dedicated to marketing and project/application growth. There will be a strong commitment to growing and promoting the chain. Expect marketing initiatives with defined, transparent goals that have not been possible so far with xDai’s limited marketing resources.

8. How would the merge affect the existing projects like xDai Punks, xDai Tigers or even De-Fi Platforms like Agave and 1Hive ?

GnosisDAO will reserve 400k GNO (~$190 million) to develop the Gnosis Chain ecosystem and incentivize usage. GnosisDAO can consider adding liquidity to various DeFi protocols on the xDAI chain to support their adoption, including Agave and 1Hive. Aspiring NFT projects like xDai Punks, xDai Tigers and xDai Bots may consider rebranding to support the Gnosis brand (although xDai will still be the native transactional token, so no changes are required).

The base currency will remain as xDai, with all the benefits of a stable token. Transaction fees will still be paid with xDai. Governance and staking on the beacon chain will use GNO.

9. Seeing as xDai chain has the potential to offer the Ethereum ecosystem as a cheap and fast scalability solution, why is XDAI team going ahead with this merger proposal at a low conversion rate? All our price discovery potential is ahead of us, why is the team and Gnosis setting a 14-day TWAP price right before token price potentially goes exponential?

Unfortunately there is no crystal ball, so it's hard to say if the token price was headed in one direction or another. The community expectations for items like the London HF activation or rebranding initiatives (comparing the effort to the Matic -> Polygon rebrand) were likely not in alignment with the reality of the situation.

  • So far, less than 0.20 xDai has been burned with London activated for 3 days. This will increase if chain usage increases, however at this time the amount burned is insignificant and will not result in any tangible results from associated STAKE burn.
  • The branding refresh by RaidGuild is nearly finished with the purpose of clearing up confusion among the community and users. There was no planned name change etc. The primary goals include explaining dual token mode, purpose of the STAKE token in the ecosystem, creating new logos which are currently absent, etc.

10. If the xDai community isn't behind this trade will it be forced through by the team and Gnosis? Gnosis holds many hundreds of thousands of STAKE and we know which way they will vote, will they be ruled out of voting on this proposal so that we can see what the xdai community actually wants?

The GnosisDAO holds 250K STAKE, which makes them part of the community. Signaling snapshot vote is used to capture the sentiment of all STAKE holders. We also plan to potentially prepare multiple signaling snapshot votes to capture community sentiment as much as possible.

Technically STAKE holders cannot stop the swap from happening if GnosisDAO decides to create the swap contract. However, going against the xDai community is not in the interest of GnosisDAO.

Currently it is impossible to discern how STAKE holders are feeling about the proposal overall, there is a very vocal group concerned about the conversion rate. How big this group is and what the sentiment is overall amongst STAKE holders will be captured in the snapshot vote.

11. As far as I got it, the validation till SBC will be done as it is now by using Stake in the Validator pools. So the merger will happen when SBC goes live?

The current plan is to merge xDai into the Stake/Gnosis Beacon Chain one week ahead of the ETH mainnet merge. Until then the network will be working as it is working now; secured by POSDAO consensus.

Beacon chain will be launched only with the GNO token so everyone interested to be a validator will need to swap STAKE into GNO once the swap contract is live. The current proposal is that the swap contract will be live for 6 months, however this may be subject to refinement based on tax implications or other concerns. The endpoint/timeline can be changed if there is support and reasoning to extend or shorten the deadline.

12. Who's idea was this - xDai or Gnosis? How much did the Gnosis team pay the xdai team for this? Do they get the same swap value or did they get other monetary compensation as well?

All terms of the proposal are public and published on the Gnosis and xDai forums. xDai team is not receiving any payments or incentives. xDai team members who hold STAKE have the same swap rate as other holders.

xDai team has been looking for investors/partners to support the Eth 2.0 roadmap and accelerate the growth of the chain via new partnerships, marketing, and listings. Gnosis’s investment and partnership can fuel xDai’s expansion by helping the chain grow and optimize its ecosystem and increase its community.

13. Incentive programs using STAKE, like on Agave, have really helped push liquidity to projects and have helped positively increase mindshare for xdai as a whole. Would there be replacement incentive programs to take place for those done with STAKE to now use GNO instead?

There will definitely be some incentives programs from the GNO side, with a much larger infusion of incentives than have occurred previously. Lack of liquidity has been an ongoing issue for DEXs and other projects deploying on xDai, and has led to users fleeing to other chains with higher liquidity. Referencing the current proposal, GnosisDAO will reserve 400k GNO (~$190 million) to develop the Gnosis Chain ecosystem and incentivize usage.

14. Which network in your opinion would benefit the most with the merge? xDai or Gnosis?

Our hope is that both orgs, along with users of the new chain, will benefit. In this alliance based on merged branding and shared tokenomics, marketing will increase, incentives and liquidity will increase, more projects will deploy and greater alignment with the Eth2 ecosystem will be achieved. The xDai team will remain autonomous but have access to more resources, and the Gnosis team will benefit by expanding into a comprehensive & scalable environment.

15. Which unique aspects of the counterparty's chain do you value the most?

xDai: Gnosis safe has been a huge benefit to the blockchain space. So many projects and DAOs use it for multi-sig governance. Looking forward, Circles may prove to be something that goes beyond blockchain to help level the playing field for society with a Universal Basic Income. It’s a huge idea and one that Gnosis is committed to. It’s very exciting and potentially life-changing for many people.

Gnosis: xDai has been committed to building excellent technology that makes Ethereum compatibility scaleable from the get go and is fully aligned with the Gnosis values of fostering network effects without locking users in. Both xDai and Gnosis believe in the power of decentralized technology to empower individuals. However, with the gas price development on Eth1 as it stands, the once very inclusive Ethereum needs compatible layer ones to not price out all users but the biggest whales. To us, xDai is that solution.

16. I would like to know why Gnosis? In addition to providing money, Gnosis has other ways to raise the STAKE ecosystem? Who will be the CEO after the merger? Will the STAKE team stay in the new company? Does the merger affect the original ecosystem projects - for example SUSHI?

In addition to providing money, Gnosis has other ways to raise the STAKE ecosystem?

A new BizDev unit will be established to drive business development and marketing activities of the Gnosis Chain. Such activities will include attracting well-performing and well-known multi-chain protocols to launch on the Gnosis Chain. Gnosis Chain will cover the costs associated with such deployments. A new marketing unit will also be implemented to drive marketing activities of the Gnosis Chain.

Who will be the CEO after the merger? Will the STAKE team stay in the new company?

GnosisDAO (the entity governed by GNO holders that holds Gnosis assets) does not have a CEO. The CEO for Gnosis the company will continue to be Martin. Igor will remain the "CEO" of xDai. Both entities will render services to the Gnosis\DAO.

How do both teams (xDAI and Gnosis) see a successful cooperation in the time after the merger? Will team members be swapped or maybe leave?

There are no organizational changes planned in the xDai core and dev teams. RnD teams in both organizations will remain autonomous. New autonomous units will be created for BizDev and Marketing. All dev talents on the xDai team will be encouraged to stay.

Does the merger affect the original ecological project? For example SUSHI?

GnosisDAO can consider adding liquidity to the various DeFi protocols on the xDAI chain to support their adoption using the 400k GNO (~$190 million) fund reserved for that purpose.

17. How do you imagine attracting new dev talents to the chain?

Gnosis team has a well-defined and successful recruiting process and is committed to help hire new developers for the chain and other associated products. Additional units such as BizDev and Marketing will be established to drive adoption of Gnosis chain including a push to hire top talent.

18. Will you keep the goals (becoming an official ETH testnet with real value in stake) of xDai?

Gnosis Chain will continue xDai’s intent to follow the Ethereum roadmap as closely as possible. Future goals include:

  • Offer the highest degree of compatibility between Gnosis Chain and Ethereum
  • Set up a Gnosis Beacon Chain (in preparation of a later merge)
  • Develop over time a role similar to what Kusama is to Polkadot

· One min read
Archive Post

This post is more than one year old. The information may be outdated. Check the latest posts.

Weekly Newsletter

info

In-depth weekly highlights are on Substack. You can sign up to receive in your email or view the newsletter anytime without signing up.

📰Weekly News for November 5: https://xdai.substack.com/p/-xdai-weekly-newsletter-november

Tweets of the Week

Follow xDai on Twitter for regular news and updates