On April 5, 2024, the dYdX community voted to upgrade the dYdX Chain live deployment protocol software to v4.0.0. 

The v4.0.0 software upgrade includes advanced order book features, risk and safety improvements, and Cosmos SDK-related enhancements. More information about the v4.0.0 upgrade is available in the Release Notes, dYdX Trading Inc.’s Blog, and the dYdX Request for Comments (“DRC”).

This post dives deeper into several new features included in this software upgrade that should contribute to elevating security, increasing efficiency, and improving the user experience on the dYdX Chain: the x/authz module, community-enabled slashing, and expedited proposals.

^{‍On April 8, 2024, the v4.0.0 software upgrade led to a temporary halt of the dYdX Chain operations. However, the dYdX chain resumed functionality following the introduction and upgrade to software version v4.0.2. This blog post refers to the v4.0.0 software upgrade for simplicity.} 

x/authz

The x/authz module enables one wallet address (the granter) to authorize another (the grantee) to execute messages on their behalf. After a MsgGrant authorization, when the grantee sends messages on behalf of the granter, dYdX Chain nodes will recognize the relationship between the two wallet addresses and permit the grantee account to complete the authorized action on behalf of the granter.

The x/authz module includes the following authorization types: 

• GenericAuthorizations: Allows the grantee to execute specific message types on the granter’s behalf.
• SendAuthorizations: Empowers the grantee to make transfers, with the potential for the granter to limit the number of tokens sent in a transfer (SpendLimit) and/or restrict transactions to certain accounts (AllowList).
• StakeAuthorizations: Designates the grantee to manage staking actions (delegate, undelegate, redelegate) on behalf of the granter, with the potential for the granter to set caps on token amounts in staking actions (MaxTokens) and/or restrict validator interactions through an AllowList or a DenyList. 

Use Cases 

The x/authz module could provide the following benefits and use cases, among others:

• Operational security: Validators and other users may grant permissions to a separate account to vote on governance proposals or perform certain actions, enhancing account and key security.
• Streamlining operations: Validators, multisig users, and hardware wallet users can authorize a separate account to perform certain actions without needing to access validator keys, obtain multiple signatures on a multisig, and/or sign into a hardware wallet. It is worth noting that while authz can be used to grant permissions to execute messages under the native Cosmos SDK modules, it is currently not enabled for granting permissions to custom dYdX Chain messages, such as placing orders or performing subaccount transfers.
• subDAO Operational Efficiency: A multisig account of a subDAO may grant execution rights to individual DAO members for specific actions, subject to customizable limitations. 
• A step towards Automated Staking Reward Compounding: In other Cosmos networks, authz facilitates the utilization of REStake and equivalent services for the automated compounding of staking rewards, thereby enhancing yield optimization for delegators. However, this functionality is presently unavailable on the dYdX Chain due to specific challenges associated with staking rewards. The main obstacles hindering the implementation of automated staking reward compounding through authz on the dYdX Chain include (1) the necessity for users to authorize more complex permissions to validators or third parties, and (2) the requirement to convert staking rewards, which are denominated in USDC, into DYDX tokens through interchain accounts. We encourage the community to think about and propose potential inventive approaches to address these issues.
• A step towards Complex Delegation: The concept of complex delegation, where delegators can transfer their voting rights to a preferred representative before their respective validator(s) inherit(s) the voting rights associated with the delegators’ tokens, represents an innovative leap. The authz feature technically enables a delegator to grant another account the authority to vote on a given governance proposal with the delegator’s voting power by granting the authority to send MsgVote. Nevertheless, the operational complexity in tallying vote results is a technical barrier that currently prevents authz from fully unlocking the full potential of complex delegation.

‍Warning 

A recent advisory note from ProDelegators sheds light on the considerable benefits that the x/authz module can provide, but also underscores the need for user caution. Users need to have a clear understanding of the permissions they're extending and to whom they are extending the permissions. Staying vigilant is key given the absence of explicit alerts with authz transactions. 

Community Enabled Slashing

With the upgrade to version 4.0.0, the dYdX Chain will take a step forward in enhancing the integrity and fairness of its trading environment. This update introduces a robust measure against MEV abuses through the addition of community-enabled slashing through a new governance module, govplus, and the introduction of a new message type, MsgSlashValidator. Before discussing MsgSlashValidator, we briefly discuss the importance of validator selection and the dYdX community's approach to MEV so far.

‍The Importance of Validator Selection 

An important aspect of community-enabled slashing is its potential impact on stakers. Subject to a dYdX community governance vote, tokens staked with a validator engaging in MEV, depending on the SlashFactor,  may be subject to slashing. This risk underscores the importance for DYDX stakers to choose the validators that they stake to wisely. The dYdX Foundation has outlined several key criteria in "A Take on Good Practices for dYdX Chain Validators and Stakers" and its “Stake Delegation Principles'' that stakers may use as practical references in choosing validators to delegate to.  Delegators should conduct their own research and due diligence before staking their tokens to validators. 

The dYdX Community's Approach to MEV

Validators play, as a decentralized collective, a pivotal role in the dYdX Chain. The validator set is responsible for maintaining the orderbook, processing transactions, and ensuring the continuity of the network. However, this position of trust can be exploited through practices such as MEV, where validators can censor transactions and/or manipulate transaction orders for personal gain, which harms the end user of the protocol. This behavior not only undermines the fairness of the trading environment but also the trust in the dYdX Chain platform itself.

Recognizing the potential threat posed by MEV, the dYdX community voted to launch a social mitigation strategy for MEV on December 3, 2023. The proposal contemplated appointing a committee to leverage Skip’s dashboard to monitor on-chain behavior and catch bad actors who are performing malicious MEV. 

Since inception, the committee has not identified any clear cases of malicious MEV; however, the committee has had a meaningful impact on flagging above-average levels of cumulative orderbook discrepancy, which has arguably improved the trading experience for dYdX Chain users (MEV Committee - January Report).   

Community-enabled Slashing (MsgSlashValidator)

Community-enabled slashing is a mechanism that empowers the dYdX community to penalize validators (and their respective stakers) who are engaging in MEV and/or other malicious practices. By leveraging a new govplus module, the dYdX community can propose and vote on slashing a certain percentage of a misbehaving validator's bonded tokens. It is important to note that all bonded tokens, that is, a validator’s self-delegated tokens plus delegations from other delegators, are subject to slashing depending on the SlashFactor. More information about community-enabled slashing is available here. 

The key parameters of a slashing proposal include:

• ValidatorAddress: The consensus address of the validator to be penalized.
• InfractionHeight: The block height at which the validator is deemed to have engaged in MEV and/or any other applicable malicious practice, which is the block height used to determine which accounts can be slashed. It is important to note that, after redelegation, a delegator's slashing risk remains with the initial validator for the length of the unbonding_period.  
• TokensAtInfractionHeight: The number of DYDX tokens bonded to a given validator at the time of an infraction. This represents the total number of DYDX tokens that can be slashed. 
• SlashFactor: A multiplier indicating the severity of the slash and the number of tokens that will be slashed from a validator and their respective delegators, ranging from 0 to 1.

In addition to the above, below are a few important notes to bear in mind in connection with a slashing proposal:

• Slashing shall occur when the relevant governance proposal passes, and not at the InfractionHeight.
• For community-enabled slashing to achieve its purpose, the InfractionHeight should be set so that the period between the block height that a community slashing proposal passes and the InfractionHeight is less than the unbonding period. 

In sum, the possibility of community-enabled slashing could contribute to further disincentivizing MEV extraction on the dYdX Chain. If necessary, a proposal to slash a validator’s tokens is a potentially valuable tool that the dYdX community may leverage to mitigate MEV extraction on the dYdX Chain. Given the severity of slashing, we encourage the dYdX community and the MEV committee to discuss and iterate on a scale of escalating responses to MEV and/or other relevant malicious conducts and to transparently outline details around the potential use of slashing. 

Expedited Proposals

It is worth noting that the dYdX Chain v4.0.0 software upgrade included upgrading the Cosmos SDK to v0.50.3, which features expedited proposals: a type of governance proposal with a shorter voting duration and a higher tally threshold. If an expedited proposal fails to meet the threshold within the scope of the shorter voting duration, the expedited proposal is then converted into a regular proposal and restarts voting under regular voting conditions.

We encourage the dYdX community to discuss the types of dYdX Chain governance proposals, if any, that could be suitable for expedited proposals in the future.