---
# System prepended metadata

title: '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?