出典確認済みリサーチ: Exchange API KEY IP

Decision Matrix

Source Map

• OKX: OKX API Guide (s1)
• OKX: OKX API Agreement (s2)
• Binance Support: How to Create API Keys on Binance? (s3)
• Bitget API: REST API Documentation (s4)
• Kraken Support: API Key Security (s5)

Control Notes

1. IP-bound trade and withdraw keys

IP-bound trade and withdraw keys is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means venues disclose different controls for keys that can trade, transfer or withdraw. The useful action is to tag every venue record with permission type and whether IP binding is documented. The unresolved edge is private account exceptions and unsupported regional account variants, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, ip-bound trade and withdraw keys should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material. The record can stay simple: the official source URL, the date checked, the product or network under review, and a non-secret note describing why the next step is acceptable. Screenshots should avoid balances, identity documents, API keys, recovery phrases, private keys, passphrases, verification codes and support-ticket private data.

2. Inactivity expiry

Inactivity expiry is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means OKX explicitly describes inactivity-expiry behavior for certain unbound keys. The useful action is to schedule stale-key reviews rather than waiting for a production failure. The unresolved edge is whether other venues have undocumented or account-specific expiry rules, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, inactivity expiry should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

3. Rotation evidence

Rotation evidence is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means API agreements and help pages often make rotation a user-side duty after suspected compromise. The useful action is to record the delete, disable and recreate path for every connected venue. The unresolved edge is whether old keys remain in CI secrets, local env files or third-party bots, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, rotation evidence should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

4. Radar scoring

Radar scoring is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means the radar should score disclosure completeness rather than hidden operational quality. The useful action is to mark missing public evidence as unknown instead of fail or pass. The unresolved edge is future documentation changes after the radar snapshot, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, radar scoring should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

5. Publication boundary

Publication boundary is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means this is original synthesis from public docs, not private penetration testing. The useful action is to publish only source-mapped facts and avoid credential collection. The unresolved edge is user balances, API secrets, IP addresses and account-level security state, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, publication boundary should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

Known Unknowns

• private account exceptions and unsupported regional account variants
• whether other venues have undocumented or account-specific expiry rules
• whether old keys remain in CI secrets, local env files or third-party bots
• future documentation changes after the radar snapshot
• user balances, API secrets, IP addresses and account-level security state

Practical Takeaway

The safest version of this article is the one that stays boring and exact. A practical exchange API radar should track three public disclosure fields before automation goes live: whether withdraw or trade keys require IP binding, whether inactive unbound keys expire, and whether each venue tells users how to rotate or delete compromised keys. The useful output is a dated control inventory, not a claim that any venue is safest. The user outcome is a clearer next inspection step, not a promise that a platform, API, transfer route or tokenized asset will work under every future condition.