Delegated Keys
IDEX v3 and previous versions support private key wallets to prevent cumbersome signing and improve the user experience. Unfortunately private key support presents both a real and perceived security issue. For IDEX Perpetuals, a delegated key (DK) design replaces private key support. Delegated keys provide a similar UX as private keys but feature additional safety.
In the delegated key model:
The client generates a new standard Ethereum key pair.
The user signs the new delegated public key with their custody wallet when signing in to IDEX.
The client posts the delegated public key along with the signature to the server.
The server verifies the signature and subsequently allows actions on behalf of the user to be signed by the delegated key.
By associating a new key pair with a wallet, the user delegates trade authorization and eliminates the need to manually sign subsequent order placements and cancellations. The resulting UX is similar to a centralized exchange without putting the user’s custody wallet at risk.
Permissions
Delegated keys open the possibility of fine-grained controls on assigned permissions. Currently DKs only include the capability to place and cancel orders. Deposits and withdrawals require a custody wallet signature.
Expiration
In addition to permissions, delegated keys expire 30 days after creation. DKs’ UUID v1 nonce embeds a creation timestamp; additionally there is a DK expiration period configured as a single parameter across the system, contracts included. No user controls are provided for DK expiration dates.
Invalidation
IDEX includes a more robust mechanism for invalidating DKs. As noted in Contracts, invalidating a custody wallet’s nonce also precludes any further order authorizations from existing DKs. The off-chain components automatically cancel all open orders and revoke all associated DKs on receiving a nonce invalidation event.
Invalidation requests are authorized by custody wallet signature only and may be made for any active or expired associated DK.
The server validates the invalidation requests and cancels all open orders authorized by the target DKs.
The server updates the DK database row as revoked but does not clear the authorization signature. The authorization signature may be necessary for rebroadcasts and other operational concerns, and is ultimately public, as it is included in any prior settlement transactions for the DK.
Importantly, an order authorized by an expired but not invalidated DK is valid.
Last updated