ECDSA Authentication

Every mutating operation requires a secp256k1 ECDSA signature from the account owner.

Vela uses the secp256k1 elliptic curve — the same curve used by Ethereum for transaction signing. Signatures are produced using the EIP-191 personal sign standard, which prepends the Ethereum message prefix before hashing. This prevents signatures from being confused with or repurposed as raw transaction signatures.

The personal sign standard prepends the following prefix to the message before hashing:

"Ethereum Signed Message:
" + len(message)

For example, signing the string "vela:auth:abc123" (16 characters) produces a hash of:

keccak256("Ethereum Signed Message:
16vela:auth:abc123")

Order parameters are serialized to a deterministic colon-delimited string and signed. The format is:

"{market}:{side}:{price}:{quantity}:{order_type}:{tif}:{user}:{nonce}"

The engine deserializes the request, reconstructs this canonical string from the request parameters, and verifies that the provided signature recovers to the user address. If the signature is invalid or the recovered address does not match, the order is rejected with E_SIG_MISMATCH.

ECDSA signatures on secp256k1 support public key recovery: given a message and a valid signature, you can deterministically recover the public key that produced the signature. Vela uses this property to avoid requiring users to separately register their public keys — the address is recovered from every signed request, on the fly.

WebSocket connections for private channels use a separate challenge-response authentication that also relies on personal sign. See Private L3 Feeds for the full flow. HTTP requests for private endpoints include authentication in the request body via the order signature mechanism described above.