Security Risks Analysis of Connecting dYdX with MPC Wallets

Digital asset security remains the top priority

Introduction

Safeheron recently launched its Web3 product suite, enabling secure interactions with dApps via its browser extension under MPC and TEE protection. This addresses multi-user asset management needs while ensuring security. However, dApps vary in security design, prompting Safeheron’s team to routinely audit dApps for potential vulnerabilities.

During a recent review, Safeheron identified authorization flaws in certain dApps:

1. Bypassing Hardware Wallet Protections: Some dApps allow connections without hardware wallet authorization, compromising private key security.
2. MPC Wallet Risks: While MPC wallets typically require user consent for transactions, connecting to specific dApps may enable platform-level control over user assets without explicit authorization—circumventing preset policies or former employees retaining access.

Safeheron terms this Signature-derived Key Risk. This article examines dYdX’s security pitfalls as a case study.

Background

RFC6979 Deterministic ECDSA Signatures

ECDSA’s temporary key (k) determines signature consistency. RFC6979 ensures deterministic signatures (same output for identical inputs), whereas random k generators produce varying results.

MPC Distributed Signing Protocols

MPC protocols like GG18/GG20 differ from single-key ECDSA:

• Random k generators yield non-deterministic signatures.
• All signing parties receive the signature result.

dYdX’s STARK & API Key Derivation

Authentication Methods

dYdX uses three auth types:

1. Ethereum Key: For registration and admin actions.
2. STARK Key: For L2 transactions (ECDSA on STARK curve).
3. API Key: Required for private operations.

Sensitive actions (e.g., trading) only need STARK + API Keys, bypassing Ethereum Key authorization.

Key Derivation Flow

1. Sign dYdX STARK Key → stark_key_signature.
2. Sign dYdX Onboarding → api_key_signature.
3. Derive STARK Key from stark_key_signature (fixed per RFC6979).
4. Derive API Key from api_key_signature (fixed per RFC6979).
5. Onboard users via /v3/onboarding with STARK public key + api_key_signature.

👉 Explore MPC wallet security

Security Issues

• Hardware Wallet Bypass: Once signed, stark_key_signature and api_key_signature exist outside hardware wallet protections.
• MPC Self-Custody Breach: MPC platforms can capture these signatures, enabling unauthorized dApp asset control.
• Random k Wallets: Non-RFC6979 wallets risk losing dYdX access if signatures aren’t recoverable.

Solutions

For dYdX & Similar dApps

• Adopt STARK-compatible wallet standards (e.g., native STARK curve support).
• Audit wallets for RFC6979 compliance during connection.

For MPC Platforms

• Block risky dApps or warn users explicitly.
• Implement MPC-ECDSA for STARK curve (Safeheron plans to open-source this).

For Users

• Use dedicated devices for dYdX (e.g., clean MacBook, no plugins).
• Migrate funds to new accounts if exposed.

FAQs

Q1: Can hardware wallets fully protect dYdX assets?
A1: No—once signed, derived keys operate independently, bypassing hardware auth.

Q2: How do MPC wallets violate self-custody here?
A2: Platforms retain signatures, enabling unauthorized dApp asset control.

Q3: What if my wallet uses random k?
A3: You may lose dYdX access; ensure RFC6979 compliance.

👉 Learn about secure MPC integrations

Conclusion

Safeheron’s disclosure prompted dYdX to suspend L2 trading temporarily. Collaborating with StarkWare and the community, Safeheron aims to:

• Open-source STARK-curve MPC-ECDSA.
• Enhance StarkEx/StarkNet support.

Security requires collective vigilance—Safeheron remains committed to advancing Web3 safety.