GIP-71: Should GnosisDAO support hosted Blockscout explorer for Chiado testnet?
Let’s do this!
Make no changes
0voters
GIP: 71
title: Should GnosisDAO support hosted Blockscout explorer for Chiado testnet?
author: Blockscout team
status: Draft
type: Funding
created: 2022-01-11
Chiado testnet is an important new part of the Gnosis ecosystem as a developer testnet. A reliable explorer is required for developers to be productive on Gnosis. A Blockscout instance should be set up as soon as possible to support Chiado now and into the future. This instance will rely on a dedicated node supported by Gateway. Gateway is already working with Chiado and can quickly spin up and support the required node infrastructure and RPC endpoint.
To expedite the process, which is necessary as the merge is coming very quickly, we are proceeding directly to phase 2. In case this proposal is supported by Gnosis community, Blockscout team is ready to prioritize this integration, and will try to launch the instance within one month after passing the proposal. We’ll plan for minimal branding based on the current Gnosis Chain explorer with monochrome colors to differentiate Chiado. The instance will be hosted at Gnosis Chain Chiado (Gnosis) Explorer.
As detailed in GIP-54, costs for hosting additional instances are $50,000 annually and cover high-capacity bandwidth, infrastructure upgrades, and data storage for the network. Feature enhancements and priority support are also included.
To fund this instance, we request $50,000 in $BOB tokens paid to Blockscout’s zkBob address: 6SLGxjMB5DchL2MmschK3c8a88KKEPKnMTxFM7Ek7jjev2wUfcEyLgY63At9mHm
Fully support this proposal, and grateful to the Blockscout team for integrating Chiado.
I am also in favor of paying in $BOB to experiment with it. For those who are not aware, a Bob is a stablecoin that uses zk-proofs, and has pretty awesome (optional) privacy features. You can swap 1 USDC for 1 BOB on 1inch.
Hi @Mojmir, great to see a proposal to improve Chiado usability!
I do have two questions to try to better understand how this proposal integrates with GIP 70.
My interpretation from that GIP was that Gateway made a commitment to deliver a Blockscout block explorer for Chiado:
Without implying Gateway is covering all requirements, what is the additional work that’s included in this GIP? Apologize if this is obvious to others.
Though I agree that $BOB is a very interesting project, I wonder if we could still execute this payment in other stablecoins that are more easily available in Gnosis Chain or Mainnet, like xDAI. I am sure we can coordinate other exercises to experiment with it, like a demo. Is there a benefit for the DAO in executing this payment in $BOB?
Gateway will host a standalone Blockscout instance at separate URL (just as Gnosis Devops do now), whilst this one is for adding Chiado to blockscout.com, along with other chains there.
This proposal is separate and not related to GIP-70. At its core, Blockscout is the most widely used open-source block explorer, and there are more than 80 different chains we know of using it. This means that anyone can spin up a new instance for desired EVM chain. To do so, you need to have the required expertise and self-host the instance on your own. As Mandrigin said, there is already one instance managed by Gnosis Devops and Gateway intends to launch another one on its own.
However, running your own Blockscout instance, and block explorer in general, is no easy feat. We, the core Blockscout team have seen this first-handedly in the last 5 years of its existence. This proposal aims to provide the same kind of service for Chiado as the Gnosis Chain instance is currently receiving after the successful implementation of GIP-54. This means that instance is run by the core Blockscout team, hosted on blockscout.com, receives priority support and automatic updates to the newest and most stable version. Also, all new features and enhancements are always rolled out to hosted versions first. In short, everything is done by our core team, and Gnosis doesn’t need to allocate dev resources to run its own instance if it doesn’t wish to.
The bottom line is that block explorer diversity is something we see absolutely necessary in a path to true decentralization in this space. As you shouldn’t rely on just one node for a chain, you also shouldn’t rely on just one block explorer as a sole source of truth for the presented data. That’s why if there are more Blockscout instances, or instances of any other block explorer, being run by independent teams, it is only good for the network itself.
$BOB
To obtain $BOB, all one needs to do is use Uni v3/1inch and make a swap with absolutely minimal slippage. Then using the zkBob application itself to deposit $BOB into the pool and make a transfer within it is very straightforward as well. I believe the use of zkBob/BOB can be beneficial for GnosisDAO and for any DAO in general, and this proposal can act as an excellent first testing opportunity. We are, of course, happy to provide any help and guidance needed to make this as easy as possible.
Right now BOB is backed 100% with GNO onchain liquidity on UNIv3. This means, if GNO price increases, the team is dumping GNO for BOB. Moreover, if someone sells BOB and it depegs, the only onchain counterparty is GNO.
I’m trying to understand the rationale behind supporting a token that poses a threat to GNO in its current state and it’s not deployed on Gnosis Chain, only on Polygon.
What’s the plan to change this situation? Thank you!
Right now BOB is backed 100% with GNO onchain liquidity on UNIv3.
This is not true. $BOB is a rather new model of a multi-collateral stablecoin. We can call it inventory-based and it is not backed by GNO.
$BOB is currently deployed not only on Polygon but also on ETH mainnet and Optimism where on each chain it is utilizing concentrated Uniswap v3 liquidity pools with USDC pairing. The token has not been deployed on Gnosis Chain as Uniswap v3 is not available there.
Right now BOB is backed 100% with GNO onchain liquidity on UNIv3.
There are two logical types of LP positions on Univ3 for BOB.
Operated by the protocol (“inventory”) such as (BOB/USDC, BOB/BUSD) where the governance deploy liquidity in one sided pairs on Univ3 only in stable pairs. Circulating supply of BOB can be only purchased from the inventory. The range of inventory positions is very tight to keep BOB stable. There is no known way to depeg inventory but only drain.
Non-inventory LP positions, which don’t involve minting of BOB such as (BOB/WETH, BOB/GNO, BOB/WMATIC, BOB/OP) are provided by users of the protocol. They have to get BOB from the open market.
This means, if GNO price increases, the team is dumping GNO for BOB.
So far, GNO was sold for BOB till the left end of the range
If price of GNO goes up that will make both tokens more liquid. I am sure that many holders of GNO will be happy if liquidity BOB/GNO will be in more wild ranges. Please consider to add non-inventory position.
and it’s not deployed on Gnosis Chain
What’s the plan to change this situation? Thank you!
When Univ3 is deployed on GC it’s likely that BOB can be deployed on GC. So far, it’s delayed after Nomad’s hack.
As a second option, is to collaborate with Sushi to deploy a newer version of Sushi with stable pairs support
example for Polygon:
it’s suboptimal for BOB’s use cases comparing to Univ3 since both tokens need to be provided initially.
Another option, which quite extreme but beneficial for many parties, is it to add BOB as an additional minter for xDai bridge and move all liquidity to BOB/Dai pair on Mainnet (controlled by 2/2 multisig by Bob and Gnosis communitues). Similar transition was recently done on Binance where deposits of USDC were converted to BUSD.
It doesn’t make much difference which stable is providing native transfers on sidechain while it keeps the legal tender feature for entering and exiting the chain. Having BOB as a native token unlocks more efficient stable coin (no stability fees, no over collateral) and built-in optional privacy for users of Gnosis.
I plan to move this proposal to phase 3 on Monday once the phase 2 vote is finished, and want to make sure that there isn’t a need to attach any payload to the Snapshot vote. Is this assumption correct?
After discussing with @Sisyphos from the Karpatkey team, we have decided to change the payment method for this proposal. We no longer require BOB payment within the zkBob pool. The payment should still be made in BOB stablecoin, but instead, it should be a simple transfer to the 0x address on the Ethereum mainnet.
The address to which the 50,000 BOB tokens should be sent, in case this proposal is supported by the GNO holders, is: 0x242ba6d68FfEb4a098B591B32d370F973FF882B7
. Hope we’ll get it later on gc too.
