github dydxprotocol/v4-chain protocol/v6.0.3
Protocol v6.0.3

latest releases: protocol/v7.0.2, indexer/v7.0.1, protocol/v7.0.1...
one month ago

Highlights

This release includes changes in following major areas:

  • Integration of x/marketmap
  • Marketmap Revenue sharing
  • Timestamp Nonce
  • Individual Vault Parameters

Detailed Changes

Integration of x/marketmap

Integrated the x/marketmap module, which is created by the Skip team. This module enables on-chain tracking of listable markets, which opens the possibility of users’ permissionlessly listing markets in the near future.

Check out this blog post for more information about this integration.

The market map can be updated via a Market Mapper, voted on through governance. The Market Mapper will continuously add new listable markets to the market map that users may want to trade, as well as update the metadata (e.g. liquidity and reference price) of existing markets when market conditions change. Revenue share functionality has been created to compensate Market Mappers and can also be voted on by governance: #1733

x/marketmap becomes the source of truth for which markets and oracle sources the sidecar will query prices from. As such, it is now required for a market to exist in the market map before an oracle market can be created for it: #1960.

x/marketmap will contain all listable markets, but for performance reasons, prices should not be fetched for a market if it is not tradable on chain. The enabled flag for each market in the market map determines if prices should be fetched for it and this flag will be set to true when a new oracle market is created for it in x/prices: #1948

New markets added to the market map are required to have their enabled flag set to false because these markets are not yet tradable and prices should not yet be fetched for them, and for any markets already tradable, updates to these markets in the market map are not allowed to change the enabled flag to false so that prices will always be fetched for them: #1962

On upgrade, all existing tradable markets (markets in x/prices) will have a market map entry created with enabled set to true: #1922

Marketmap Revenue Sharing

Includes the addition of the x/revshare module, which houses all the logic to incentivize the marketmapper to add new markets to x/marketmap .

The marketmapper will receive a certain configurable percentage of the new market trading fee proceeds for upto a certain configurable time period. These configurable parameters will be set through governance.

This feature implements changes to set the above mentioned parameters through governance, record revshare details during market creation and distribute the trading fee revenue share whenever the new market gets traded.

Timestamp Nonce

Transaction sequence number validation has been expanded to accept either a timestamp nonce (unix millisecond timestamp) or incremental sequence number (existing method). If a timestamp nonce is supplied as the sequence number, it will be validated using new timestamp nonce rules. Otherwise, the sequence number use the existing workflow which requires incremental values. This feature allows users to submit transactions without the need to get/store their current sequence number, while still enabling protection from replay attacks.

A timestamp is a valid timestamp nonce if:

  1. now - 30s ≤ timestamp ≤ now + 30s
  2. timestamp is strictly larger than any of the largest 20 timestamp nonces previously submitted in the account’s lifetime
  3. timestamp has never been used before

If the timestamp is invalid, users can expect the following error messages:

  1. 'timestamp nonce {timestamp} not within valid time window: incorrect account for validation 1
  2. 'timestamp nonce {timestamp} rejected: incorrect account sequence' for validations 2 or 3

Individual Vault Parameters

Each vault now can have its own parameters that determine how it quotes in the corresponding market, allowing vaults to better cater to the characteristics of the markets they quote in. Governance can set such parameters of a specific vault by submitting MsgSetVaultQuotingParams in a proposal. When a vault does not have individual parameters, it defaults to DefaultQuotingParams, a module-wide variable that can also be updated via MsgUpdateDefaultQuotingParams in a governance proposal.

Don't miss a new v4-chain release

NewReleases is sending notifications on new releases.