How exchange keys are kept

What happens to a key after connecting, who can see it, and what the worst case looks like.

In short

The exchange key you connect is encrypted the moment it is connected and from then on exists nowhere in the clear: not in the database, not in logs, not in the interface. It is opened only for a request to the exchange, in an isolated part of the system the application servers cannot reach, and only for the duration of that request. A key with withdrawal rights is not accepted at all.

What happens when you connect

1. One read request to the exchange — to confirm the key works and has no withdrawal right. A

key with that right is not stored. A key with trading rights connects but is flagged, and we advise replacing it with a read-only one.

1. The key is encrypted. Each key has its own encryption key, and those are protected by a managed

key service with a hardware module in a European region (Frankfurt), from which the master key is never exported — by anyone, us included. The database holds ciphertext only.

1. From then on the interface shows only the first and last four characters of the key. Showing it

whole is impossible: that function does not exist, for you or for us.

How the key is used

• The only thing the product does with the key is read the history of fills and payments. It

places no orders, moves no funds, reads no balance.

• Decryption happens in a separate isolated service with no public address and no database access.

The servers that take your requests never see the keys and cannot open them.

• Every use of the key is recorded: connection, check, import, deletion. So is every call to the key

service — in an independent log we cannot edit.

• The connection form lists the addresses we call the exchange from. Restrict the key to them on the

exchange's side and it becomes useless from anywhere else.

The worst case

• A copy of the database leaks. It holds ciphertext without the encryption keys — unreadable.
• An application server is compromised. The keys are not there and cannot be opened from there.
• Someone reaches the key itself. A read-only key with an IP restriction gives exactly what Arbiq

gets: trade history. It cannot withdraw or trade — it has no such rights.

• You delete the key. It is erased for good, at once. Imported drafts and journal records remain

yours.

What you can do

• Create the key read-only, without withdrawal — the journal needs nothing more.
• Restrict the key by IP to the addresses from the connection form.
• Make a separate key for Arbiq and revoke it on the exchange whenever you like: deleting the key

on the exchange stops the import instantly.

• On DEXes: Hyperliquid works with no secret at all, by public address; on Aster we hold only the

API wallet's private key, whose rights you revoke on the exchange with one click. More in Connecting DEXes.