gravity

Prop 212: The Apollo Upgrade

The Apollo Upgrade

This proposal intends to deploy the Apollo upgrade on Gravity Bridge Chain, which includes the following changes:

  • Add the Auction module
  • Set the Auction module Params according to Proposals #200-#203
  • Send half of all collected Send To Eth ChainFees to the Auction Pool according to Proposal #204
  • Add support for EIP712 transaction signing (a.k.a. MetaMask signing)

Auction Module Differences

Leading up to the Apollo upgrade, the community voted to pass Proposals #200 through #204. These previous proposals affect the Params which will be set during the Apollo migration logic, however they described auction module behavior which is no longer accurate.

The previous descriptions of the Auction module mentioned that the source of funds for all of the auctions will be the Community Pool. To prevent problems like unintended auctions (including the large GRAV balance in the Community Pool), and accidental auction of lost tokens destined for other chains, the Auction Module will instead pull from a new module-controlled account called the Auction Pool.

The Auction module includes a new "Enabled" Param, which when false can halt in-progress auctions until made true again.

The NonAuctionableTokens list still controls which tokens may be put up for auction, but if the Auction Pool account holds a balance of any token on the NonAuctionableTokens list then those balances will be transferred to the Community Pool at the start of the next Auction Period. These transfers to the Community Pool ensure that tokens will not become stuck in the Auction Pool.

Finally, the fees described in Proposal #204 will be instead directed to the Auction Pool and not the Community Pool. This change preserves the intention of Proposal #204, as the collected fees are meant for Auction module use, but avoids safety concerns involved with automatically taking funds from the Community Pool. The name of the Gravity module Param has also changed from chain_fee_community_pool_fraction to chain_fee_auction_pool_fraction to reflect the change in destination.

Auction Module Behavior

With these differences in behavior, it is important to understand the full updated Auction module behavior:

The Auction module is a CosmosSDK module which regularly takes all of the balances in the Auction Pool (except for those on the non_auctionable_tokens list) and puts them up for auction. Each token held in the Auction Pool will be a separate auction, so if the pool only holds USDC, WBTC, and PAXG then there would be 3 new auctions to bid on. These auction balances are then transferred out of the Auction Pool and into the Auction module account. The auctions are only open for a period of time known as the Auction Period (determined by the auction_length parameter), during which anyone may bid on an auction by submitting a MsgBid. Every bid requires paying at least a minimum fee (determined by the min_bid_fee parameter) and locks the provided amount of GRAV (ugraviton) in the Auction module. At the end of the auction period the highest bidder will be transferred the full balance of the auction tokens, and their bid will either be burned or sent to the Community Pool (depending on the burn_winning_bids parameter). Once an auction period is over, the next one begins with the new Auction Pool balances.

For a more thorough description of the Auction module and how fees feed the Auction Pool, see the official documentation here.

Params Set by the Apollo Migration Logic

The following Gravity Param will be added and set accordingly:

  • chain_fee_auction_pool_fraction will be set to "0.5" so that 50% of collected Send To Eth ChainFees are directed to the Auction Pool account, based on Proposal #204

The following Auction Params will be added and set accordingly:

  • enabled will be set to true so that the Auction module is immediately active
  • auction_length will be set to 85600 in accordance with Proposal #201
  • min_bid_fee will be set to 3110 in accordance with Proposal #203
  • non_auctionable_tokens will be set to ["ugraviton"] in accordance with Proposal #200
  • burn_winning_bids will be set to true in accordance with Proposal #202

EIP712 Transaction Signing

Previously, with the Polaris upgrade, Gravity Bridge added support for Ethereum key transaction signing, enabling users to sign transactions using Ethereum SECP256K1 private keys. The support offered with the Polaris upgrade restricted users to only signing a hash of the transaction, which offers no understanding as to what they are signing. By adding support for EIP712 transaction signing, users are able to sign CosmosSDK transactions using their preferred Ethereum wallet interface and have great visibility about precisely what they are signing. EIP712 makes it much easier to work with wallets like MetaMask to provide a familiar experience for Ethereum users interacting with Cosmos.

Relevant Links

Proposal #200: https://commonwealth.im/gravity-bridge/proposal/200-set-nonauctionable-tokens-to-ugraviton Proposal #201: https://commonwealth.im/gravity-bridge/proposal/201-set-auction-length-parameter-to-85600 Proposal #202: https://commonwealth.im/gravity-bridge/proposal/202-set-burn-winning-bids-parameter-to-true Proposal #203: https://commonwealth.im/gravity-bridge/proposal/203-set-minimum-bid-fee-parameter-to-3110-grav Proposal #204: https://commonwealth.im/gravity-bridge/proposal/204-send-50-of-send-to-eth-fees-to-the-community-pool

EIP-712: https://eips.ethereum.org/EIPS/eip-712

Field
Data
info
{"binaries": {"linux/amd64": "https://github.com/Gravity-Bridge/Gravity-Bridge/releases/download/v1.11.1/gravity-linux-amd64"}}
name
apollo
time
0001-01-01T00:00:00Z
height
9244100
upgraded_client_state