Security Risks of Connecting MPC Wallets to dYdX: A Technical Analysis

·

In the rapidly evolving Web3 ecosystem, digital asset security remains paramount. As decentralized applications (dApps) grow in complexity and functionality, their integration with advanced wallet technologies like Multi-Party Computation (MPC) introduces new attack surfaces that demand rigorous scrutiny.

Recently, the Safeheron security team conducted a comprehensive audit of popular dApps, uncovering critical vulnerabilities in how certain platforms handle cryptographic key derivation—particularly when interacting with MPC-based self-custodial wallets. This analysis focuses on dYdX, a leading decentralized exchange, where a design choice rooted in user convenience inadvertently creates significant security risks under specific conditions.

The core issue centers around what Safeheron has termed Signature-derived Key Risk: the practice of using ECDSA signature outputs as seeds for deriving secondary keys. While seemingly harmless, this mechanism can bypass hardware wallet protections and compromise the fundamental principles of MPC-based custody.

Understanding the Cryptographic Foundation

To grasp the implications, it’s essential to understand two foundational concepts: deterministic signatures and distributed signing in MPC protocols.

ECDSA and Deterministic Nonces (RFC6979)

In standard ECDSA signing, a temporary random value k is used. If k is truly random, repeated signing of the same message yields different signatures—even with the same private key.

However, most EVM-compatible wallets follow RFC6979, which specifies a deterministic method for generating k. This ensures that signing the same message twice produces identical signatures. This consistency is useful for recovery mechanisms but becomes a liability when signatures themselves are used as secret inputs.

dYdX leverages this predictability to enable users to regenerate their Layer-2 authentication keys (STARK Key and API Key) from L1 wallet signatures—a feature designed for usability, not security.

MPC Signing Protocols: Randomness by Design

Conversely, MPC wallets (e.g., those using GG18, GG20, or MPC-CMP) prioritize security over determinism. These protocols generate k randomly during each signing operation to prevent leakage attacks. As a result:

This design ensures no single party can reconstruct the full private key—but also means that any signature generated during dApp onboarding may be captured and reused by the MPC coordinator.

How dYdX Derives Authentication Keys

dYdX employs three authentication methods:

  1. Ethereum Key Authentication – Used for registration and emergency actions.
  2. STARK Key Authentication – Enables trading and withdrawals on Layer 2.
  3. API Key Authentication – Required for all private API interactions.

Notably, once registered, users only need the STARK and API keys to execute sensitive operations—no further Ethereum-level signing is required.

Here’s how these keys are derived:

  1. The user signs a typed message "dYdX STARK Key" using eth_signTypedData_v4. This produces _stark_key_signature_.
  2. The user signs another message "dYdX Onboarding" to generate _api_key_signature_.
  3. Both signatures are used locally to derive fixed STARK and API key pairs via cryptographic hashing.
  4. Since most wallets use RFC6979, these signatures—and thus the derived keys—are reproducible.

👉 Discover how secure wallet integrations should work in modern DeFi ecosystems.

Because the signatures are deterministic, anyone who obtains them can regenerate the exact STARK and API keys—without ever accessing the user’s private key.

Identified Security Vulnerabilities

1. Bypassing Hardware Wallet Protection

Hardware wallets (cold wallets) protect private keys by requiring physical confirmation for every signature. However, once a user signs the dYdX onboarding messages, the resulting _stark_key_signature_ and _api_key_signature_ are exposed to the host environment.

From that point forward:

Thus, the hardware wallet’s security is effectively circumvented after initial setup.

2. Undermining MPC Wallet Self-Custody Principles

MPC wallets distribute private key shards across multiple parties, ensuring no single entity controls funds. But because MPC signers collectively produce full signatures—and all participants receive the output—the MPC service provider (e.g., wallet platform) can capture the onboarding signatures.

Once obtained:

This breaks the core promise of self-custody: the platform should never have unilateral control.

3. Asset Loss Risk for Non-RFC6979 Wallets

Wallets that use random k values (non-RFC6979 compliant) will produce different signatures each time. If such a wallet connects to dYdX:

While Ethereum Key Authentication allows forced withdrawal, the process is complex and inaccessible to average users—posing a real risk of permanent asset loss.

Frequently Asked Questions

Q: Does this vulnerability affect all dApps?
A: No. Only dApps that derive long-lived authentication keys from deterministic wallet signatures are at risk. dYdX is one prominent example due to its StarkEx architecture.

Q: Can attackers steal my main wallet funds?
A: Not directly. The exploit grants access to dYdX-specific assets (L2 balance), not your underlying Ethereum wallet. However, stolen L2 assets can be withdrawn to attacker-controlled addresses.

Q: Is my MPC wallet unsafe now?
A: Your L1 assets remain secure. The issue arises only when connecting to dApps like dYdX that misuse signature outputs. Avoid linking high-value MPC wallets until fixes are implemented.

Q: How can I recover access if I lose my STARK Key?
A: Use Ethereum Key Authentication to force-close your position and withdraw funds. This requires interacting with smart contracts directly—consult technical documentation or support teams.

Q: Are hardware wallets still recommended?
A: Yes—for L1 transactions. But understand they offer limited protection on L2 systems like dYdX if onboarding signatures are compromised.

👉 Learn how next-generation custody solutions are addressing these emerging threats.

Recommended Mitigations

For dApp Developers (e.g., dYdX)

For MPC Wallet Providers

For End Users

The Path Forward

Safeheron has initiated responsible disclosure, and dYdX has responded by pausing L2 trading functionalities to mitigate immediate risks. Meanwhile, Safeheron is open-sourcing an MPC-ECDSA implementation supporting STARK curve, enabling secure multi-signer management of Layer-2 keys without compromising custody principles.

As Web3 matures, we must balance innovation with security rigor. Features built for convenience—like deterministic key recovery—must be re-evaluated in light of evolving threat models.

Collaboration between protocol teams, wallet developers, and security researchers is essential. Only through shared standards and transparent practices can we build a truly secure decentralized future.

👉 Explore cutting-edge tools designed to protect digital assets across L1 and L2 environments.