One local key, one signing lane, no ungated path to the exchange.

What the signature actually covers.

Hyperliquid L1 actions (placing an order, canceling one) are not signed as EIP-712 typed data of the action struct. The action is first encoded with msgpack, a compact binary format, and hashed together with its nonce and vault binding. That hash then plays the role of connectionId inside a small Agent struct, which is what the EIP-712 signature actually covers. Hyperliquid calls this a phantom agent because no real on-chain agent contract exists; the domain is a set of fixed constants (packages/hyperliquid/src/Signing.ts:5-22).

The domain is { name: "Exchange", version: "1", chainId: 1337, verifyingContract: 0x0..0 }, pinned as HYPERLIQUID_EIP712_DOMAIN at Signing.ts:36-41. The chainId is 1337, never Arbitrum's 42161 or 421614, because this signature never touches a chain; it only has to match what the exchange verifies (Signing.ts:24). The source field of the Agent struct is "b" on testnet and "a" on mainnet (Signing.ts:21, :211).

One subtlety carries real weight: msgpack preserves the insertion order of the action's keys, so the hash depends on key order. Reordering fields in an action record changes the bytes being hashed and breaks the signature. The module doc is explicit that the implementation was "verified byte-for-byte against the reference algorithm in @nktkas/hyperliquid" (Signing.ts:2-3), and the construction is pinned by that reference, not by intuition.

What comes back is a 65-byte ECDSA signature: 32 bytes of r, 32 of s, and one recovery id. Internally the id is the raw 0 or 1; on the wire it is biased to 27 or 28, the Ethereum convention the exchange deserializes (Signing.ts:50-57, :266-276). The signer address is derived the standard way, the last 20 bytes of the keccak256 of the uncompressed public key, and is recorded as the signer of record on every execution (Signing.ts:231-237).

# packages/hyperliquid/src/Signing.ts:9-22
actionHash = keccak256(
  msgpack(action)   # insertion-order keys
  uint64BE(nonce)   # 8 bytes, big-endian
  vault marker      # 0x01 + address, or lone 0x00
  expiresAfter      # 0x00 + uint64BE, or nothing
)

domain = { name: "Exchange", version: "1",
           chainId: 1337,
           verifyingContract: 0x00..00 }

agent  = { source: "b" # testnet ("a" mainnet)
         , connectionId: actionHash }

digest = keccak256(0x1901, domainSeparator,
                   structHash(agent))

The Agent type hash is keccak256("Agent(string source,bytes32 connectionId)") and the final digest follows EIP-712 exactly (Signing.ts:117-119, :190-192). Nothing here is T3's invention; every constant is matched against the reference SDK so the exchange accepts the bytes.

# upstream T3 Code          # T3 Trade (this fork)
~/.t3                          ~/.t3trade
  state.sqlite                   userdata/   # runtime state
                                 dev/        # dev-build state
                                 secrets/
                                   hyperliquid-interim-signer-key.bin

T3CODE_HOME                    T3TRADE_HOME
# application-state override  # signer base only

Constants: T3_HOME_DIR_NAME = ".t3trade", DESKTOP_USER_DATA_DIR_NAME = "t3trade", and its dev twin "t3trade-dev" (forkPaths.ts:20-26). The secrets directory predates the rest of the state; the home grew around the key, not the other way round (forkPaths.ts:15-18).

Why ~/.t3trade and not ~/.t3.

T3 Trade ships as a separate application a user may install next to upstream T3 Code. The fork's own header comment explains why the paths must differ: two applications sharing ~/.t3 share one state.sqlite, and two writers on one SQLite database corrupt each other's results; two sharing an Electron user-data directory share the single-instance lock that lives inside it, so "the second launch is handed to the first app". Both failures are silent, and both hit a new user on their first run (forkPaths.ts:4-8).

So only the directory names fork. T3CODE_HOME keeps its name because it is opt-in: anyone who sets it means it, and renaming it would touch every call site to buy nothing (forkPaths.ts:10-13). T3TRADE_HOME is the separate signer-base override; it resolves the interim key beneath secrets and is not the general application-state override (KeyLocation.ts:29-33).

Within one machine the fork's instances cooperate instead of colliding: any number of T3 Trade runs, dev servers, worktrees, the packaged app, share the same read-only key file without conflicting, and a running T3 Code instance never reads or writes here (KeyLocation.ts:11-15).