Thought Experiment: GNO as Native Token

# Thought Experiment: GNO as Native Token ## Overview - I would like to put forward a thought experiment: GNO as a Native Token for Gnosis. - There have been a lot of discussions on this - There is a need to be objective in assessing whether this is a good idea or not - I outline a possible engineering solution - However: need stronger engineers to assess - However: there are massive issues that make it very dangerous - However: the "socio-economic impact" is far more critical - Fundamental question: is such a drastic action worth it? - Is the "Dai problem" truly fatal for the chain? - Do the long-term benefits outweigh the costs (and risks)? - Would such a move create "suicidal risk" for our ecosystem? - Do we have the resources to test this responsibly? - Will this halt BD efforts and "miss" the market? - Are there other more gentle, incremental solutions? > For the record, I think this is a terrible idea with potentially catastrophic outcomes. We should only do this as a last resort. ## High-level Problem - All native asset transfers in smart contracts will break - Impact on Bridges - Impact on dApps - Redenomination will need to occur at a specific block height - Ecosystem UIs need to switchover (e.g. Wallets, Explorers need to show GNO vs xDai) - Large surface area for catastrophic mistakes - Staking ironically will not be affected much > AFAIK no chain has ever swapped its native asset before (only redenominations) ## Possible Engineering Approaches ### Approach 1: Swap GNO into Native Asset Balances ![](https://i.imgur.com/40iLT6i.png) - At blockheight *k* - Migrate native asset balances for xDai to `wxDai` registry - Migrate `GNO` balances to world state trie balances - "Airdrop" GNO to users to solve for "no gas" problem - ~499k xDai holders vs 19,677 GNO holders - Rough cost: ~15.5k `GNO` to airdrop 1 `mGNO` to all current unique addresses - However: possible spam attack vector - *Idea:* Can be a "JIT" airdrop by using legacy RPCs to identify legacy xDai users and frontrun txns with an airdrop (see [Appendix 3]([#Appendix-](#Appendix-3-Using-%E2%80%9CLegacy-RPCs%E2%80%9D-to-identify-legacy-native-asset-transfers))) ### Approach 2: "Forced" conversion of xDai to GNO - At blockheight *k* - Forced conversion of `xDai` to `GNO` balances - Update world state trie balance - Mitigating community issues - 2-3 months grace period - Users can opt-out of conversion by bridging out ## Impacts ### Impact on dApps - [*For debate*] This will wreak **absolute havoc** across all contracts - Any native `.send()`, `call.value()`, `.gas()`, `.transfer()` will be affected - Contracts will have to work around block height transition (? Is there any other way?) - Add in logic around the switchover blockheight where native asset changes - However: un-upgradable contracts? - This might kill DeFi ecosystem on Gnosis - Anything that collateralizes either `xDai` or `GNO` - Significant chance for catastrophic error on Bridges - Both 3rd-party and native bridges that touch `GNO` or `xDai` - Possible attack vectors around switchover block - Possible Engineering Mitigations: - Different opcode for GNO native asset transfers - Two native asset balances in world state trie? - However, these only add even more engineering complexity to the chain ### Impact on Users - Biggest risk is users/contracts catastrophically submitting a `.send()` with xDai amount instead of GNO amount - e.g. I send you 30 GNO instead of 30 xDai - If wallets don't update, UI will show "30 xDai" vs 30 GNO - Possible mitigation: new transaction type? - i.e. Legacy transaction (i.e. pre-EIP-1559) - i.e. EIP-1559 transaction (Gnosis' variant of it) - i.e. GIP-?? transaction (i.e. GNO as native gas) ### Impact on Bridges - This is a very high highest risk factor - Danger: 1 Dai on Ethereum can "mint" 1 `GNO (Native)` on Gnosis - However: a move to GNO would solve the xDai Bridge tight coupling - Can deprecate the [xDai Block Rewards Contract](https://docs.gnosischain.com/bridges/tokenbridge/xdai-bridge#ethereum---gnosis-chain) ### Impact on Infra - Wreak havoc on all infra (e.g. explorers, indexers etc) - Would need to be aware of "switchover" time to update UI and other assumptions - Need to ensure "switchover block height" is public - i.e. Wallets will need to update UI at specific block - i.e. Explorers will need to update UI at a specific block - i.e. Bridges etc need to update UI at specific block - i.e. Indexers, TheGraph etc need to update UI and contracts ### Impact on Staking - Current GNO staking does not work like Ethereum's - We are staking a non-native asset (i.e. GNO vs xDai) - We utilize custom set of contracts (i.e. [SBC Deposit Contracts](https://github.com/gnosischain/deposit-contract/tree/develop/contracts)) - How would a native asset migration change this? - We can revert back to Ethereum Consensus Layer staking mechanics in the long-term - The SBC staking contracts will work just fine for now - However: need to do some more research to make sure `mGNO` is unaffected (i.e. unwraps to native GNO vs. legacy GNO) ## Alternatives ### Alternative 0: Do Nothing - Dai has its problems but it is still a "good enough" marriage - MakerDAO's error may be temporary - MakerDAO tends to self-correct after some time - Engineering risk is too high - This has never been done before and real risk of network "bricking" - We don't have the QA capabilities of Ethereum and are unlikely to be able to test this exhaustively - Product risk is too high - Catastrophic user error is very high - Catstrophic effect on dApps that use either wxDai or GNO (will single-handedly impact DeFi) - We don't currently have the PM or Ecosystem capabilities or legacy knowledge and relationships to make such a large change ### Alternative 1: Replace Dai with alternative asset? - It may be easier to fork MakerDAO and have an ETH-only stablecoin as gas - e.g. Liquity-like system that uses `GNO` instead of `LQTY` - However the "stablecoin-as-gas" will be a long-term architectural choice for Gnosis - In which case, we might as well embrace it - May have benefits for user adoption ### Alternative 2: Two Native Asset Balances + User opt-in "migration" - I actually think this is the "cleanest" way to do it - However needs custom implementation by EL clients - I am not the right person to parse how tough this will be - "Dual track" system that allows for gentle migration - Legacy transactions (use xDai) - xDai-1559 transactions (use xDai) - 3rd-type of txns (use GNO) - User "opt-in" migration - User will "migrate" their account by themselves - Handles migration of balances, but individually (vs. chain-wide) - "Legacy RPCs" will use xDai - Can be easily tracked and BD team can engage community - We can aim towards decline in such transactions - Eventual gentle deprecation of xDai native balances (in HF) - "New RPCs" will use GNO - Will not "break" the chain - "Enhanced airdrop" for people using this txn method ### Alternative 3: Gnosis-2 - Start with a fresh "Gnosis-2 Chain" - GNO as native gas - Rectify 5s blocktime issue (increases decentralization) - Focus Ecosystem Fund money on this effort - Bad: have to re-build Validator Network, dApp Ecosystem - xDai acquisition would have been pointless ## Appendix ### Appendix 1: Motivations for GNO as Native Asset - [*Strategic*] Move off Dai or "stablecoin" as long-term dependency - Dai's reliance on USDC is a long-threat to Gnosis being a decentralized chain - We are not keen to embrace the "Stablecoin as gas" narrative for the chain (vs. early xDai days) - Having stablecoin as native asset introduces risks and engineering complexity which we are not keen to manage long-term - [*Strategic*] Allow Gnosis to become a truly decentralized chain in the long-run - Narrative violation between "decentralization" and Dai dependence - Narrative violation between ["native tokens are secure"](https://docs.google.com/presentation/d/1LW5MVphz11TsyqU0PYar62qFC77juv-VTXC7LG73WjA/edit?pli=1#slide=id.g1ddc06e4d44_0_225) vs. using Bridged Dai as native asset - Get rid of all legacy PoA architecture (e.g. Dai, AuRA) - [*Engineering*] Reduce long-term diff from Ethereum - Gnosis has legacy diffs from Ethereum - e.g. EIP-1559 behavior (xDai basefees are not burnt but [go to Collector Address](https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Chains/xdai.json#L73)) - e.g. POSDAO, AuRa (i.e. largely undocumented) - e.g. Tight coupling of xDai Bridge with Consensus (xDai gets minted in [system call w/o transaction record](https://docs.gnosischain.com/bridges/tokenbridge/xdai-bridge#gnosis-chain---ethereum)) - Our current roadmap increases diffs from Ethereum (vs. reduce diff) - Current [Withdrawals HF](https://github.com/gnosischain/specs/blob/master/execution/withdrawals.md) will add to complexity as GNO is not the native token (see [Withdrawals Implementation](https://github.com/gnosischain/deposit-contract/pull/25)) - We are simply adding more and more entropy that will cost more and more to maintain long-term - Even documenting [how Gnosis is different from Ethereum](https://github.com/gnosischain/specs) is a significant undertaking (e.g. POSDAO, AuRA, Withdrawals) - Alternate Roadmap - Embark on 2.5-year roadmap w/ Nethermind and Erigon to make Gnosis equivalent to Ethereum (w/ param changes) - Matches up with 3-year grants to teams - Work with [Nethermind Research](https://nethermind.io/research/) to fully spec this out - [*Lesser extent*] Drive demand for GNO's tokenomics - Drive daily demand for GNO as a gas token - Adopt Ethereum's value accrual approach - Adopt EIP-1559 in totality - Increase holders and users of GNO - Current holders of GNO on ETH: [17,354](https://etherscan.io/token/0x6810e776880c02933d47db1b9fc05908e5386b96#balances) - Current holders of GNO on Gnosis: [19,677](https://gnosisscan.io/token/0x9c58bacc331c9aa871afd802db6379a98e80cedb#balances) - Number of active addresses of Gnosis in last 90d: [56,290](https://dune.com/gnosischain/GnosisChain-Usage) - Diversify GNO holders - Note: excludes exchange holders of GNO ### Appendix 2: mGNO or GNO as native token? - If we do indeed choose to go with GNO as a native asset - Is it better to use `mGNO` as `GNO (Native)` instead? - `mGNO` allows us to achieve parity with Ethereum - 32 `GNO (Native)` required for staking - Achieves parity with Ethereum - Reuse all staking logic ### Appendix 3: Using "Legacy RPCs" to identify legacy native asset transfers > This is a shower thought idea and needs more help - Assumption: Users need to re-add the network with a different native token - Native token: GNO - Cleanest method...? - Unless we can get wallet support? (unlikely) - We can use legacy RPCs to avoid catastrophic user error - Still shows `xDai` balances as native wallet - Should "error out" to prevent catastrophic mistake - Can we utilize "legacy" RPCs to achieve this? (e.g. `rpc.gnosischain.com`) - Use error message to point user to get more info - Possible idea: Airdrop GNO to allow for relayed "meta-transactions"? - Airdrop a GNO balance so user can make txns - "Legacy RPC" will relay transaction and deduct GNO balance - TBD: are there more sophisticated AA approaches that don't require dApp support?