TrueHold

BlogSelf-custody

Can a read-only API key be used against you? An honest threat model

A read-only key cannot move funds. The real risks are quieter: privacy, profiling, forgotten keys. The full threat model, including what vendors skip.

Azat Tulegenov3 min read

Short answer: a read-only API key cannot be used to steal your funds. The exchange enforces its permissions server-side, and a key without trade or withdrawal scopes has no path to your money, no matter who holds it. That is the comforting half. The honest half is that "cannot move funds" is not the same as "zero risk", and it is worth knowing exactly what the remaining risk is.

What a leaked read key actually exposes

Balances, positions, and trade history. In the wrong hands that is a privacy loss with teeth: someone now knows what you are worth, which makes you a better target for phishing, social engineering, and in extreme cases physical coercion. A scammer who can quote your real balance and your last three trades sounds a lot more like your exchange than one who cannot.

What it cannot do, mechanically

  • Place, modify or cancel orders. The trade scope is a separate permission the key never had.
  • Withdraw or transfer anything. Exchanges guard this scope hardest, often refusing to enable it without extra restrictions.
  • Change account settings, add withdrawal addresses, or reset credentials.
  • Escalate itself. A read key cannot grant itself new permissions; only you can, logged in, with 2FA.

The second-order risks vendors skip

Two are worth naming. First, personalized phishing: the attacker uses what the key showed them to craft a message that passes your smell test. The defense is procedural, not technical: no legitimate service asks you to move funds or share a seed phrase, ever. Second, stale keys: the key you created for an app you abandoned two years ago still works. Nobody is watching it, including you. Forgotten access is unaudited access.

The hygiene that closes the gap

  • One key per app, named after the app, so revoking one never breaks another.
  • Treat the key pair like a password. It is a credential, and it belongs in the same mental category.
  • Audit your API list quarterly and delete anything you cannot name the purpose of.
  • Prefer tools that never display your secret again after setup and store it encrypted.
  • Read the emails your exchange sends about API activity. They are the alarm system.

Where TrueHold sits in this model

TrueHold accepts read-only keys and public addresses, and nothing else. There is no flow anywhere in the product that requests trade or withdrawal scopes, and revoking access takes one click on either side. The threat model above is exactly why the product is built this way: a tracking credential should be boring to steal.

Frequently asked questions

Has anyone lost funds through a read-only API key?

Not through the key itself: without trade and withdrawal scopes there is no mechanism. Losses attributed to API keys involve keys that had trading or withdrawal permissions enabled.

Should I use an IP allowlist on a read-only key?

If your exchange and your tracker both support it, it is a free hardening step. Many cloud tools use changing IPs and cannot be allowlisted; for a read-only key that trade-off is usually acceptable.

How often should I rotate read-only keys?

Rotate when you stop using a tool, when a provider reports an incident, or roughly once a year as routine. Rotation is cheap: delete the old key, create a new one, paste it once.

See your whole portfolio in one view

Read-only by design. Paste a wallet, link an exchange, and watch every chain. Free to start.