IMPORTANT
Due to security risks with the dApp, we have temporarily blocked all access to dYdX from our wallets. Should you wish to continue working with dYdX, please reach out to us and we will grant you access.
The issue exists in dYdX v4. dYdX access will resume its default-on status once the security issues are resolved.
Background: dYdX implementation on Web3
dYdX is a perpetual trading decentralized exchange that is built as a Layer-two (L2) application. dYdX v4 is built using a dedicated Cosmos-based chain. When using the dYdX Web3 application, dYdX derives a key pair from an Ethereum typed message signature and stores it in the user’s web browser cache. As long as the key pair exists in the cache, the user has access to their perpetual positions and is able to place orders signed with this L2 key without having to sign a transaction again. It is important to note, however, that the key pair does not grant access to the underlying L1 Fireblocks wallet.
dYdX’s private key storage mechanism
Upon first connection to the dApp, dYdX generates a key pair for its users. If the user chooses the "Remember Me" option, dYdX saves the private key in the user’s web browser cache. Therefore, if a dYdX user’s machine is infected by malware, the malware can access the cache, obtain the private key, and gain control over the user’s dYdX account. This would allow the attacker to trade the user's funds. The attacker can cause loss of funds with bad trading or leveraging low-volume tokens to transfer some of the funds.
This is not aligned with the security guarantees you normally get with Fireblocks or our security principles, since:
- The dYdX Web3 application generates its own private key that is not protected by Fireblocks’ multi-layer security.
- Control over all movement of funds and trading is lost.
dYdX’s derivation scheme
When generating a dYdX Web3 key, don't assume that signatures are secrets. Wallets treat signatures as public information as they are usually publicly available on-chain data and transmitted outside of secure environments.
dYdX asks its users to sign an Ethereum typed message (EIP-712) and uses the result to derive a key pair consisting of a private key and a public key. This mechanism assumes that the result of the signature request is a secret since it is possible to gain the private key using the signature.
This assumption is wrong. In particular:
- Most non-MPC wallets do nothing to protect the signature result. In some cases, they even save the signature result in plain text in a non-secure storage.
- When using MPC wallets, all involved parties – including Fireblocks – are exposed to the signature result.
- Many wallets (MPC and non-MPC) utilize signature caching for performance reasons, making the signature accessible for later fetching.
Once signed into dYdX using a web browser, your dYdX-created private key and interactions are no longer protected by Fireblocks’ security mechanisms, including MPC and TAP.