What is the main security question?
Identify what can authorize a trade or transfer, where that authority is stored, and how it can be restricted or revoked. Withdrawal-disabled keys reduce transfer risk but still permit loss-making orders.
Security models across reviewed products
| Product | Architecture | API and withdrawal model | Public security evidence | Incidents and confidence |
|---|---|---|---|---|
| Coinrule | Cloud / SaaS | Official guidance instructs users to enable trading but not transfers or withdrawals; IP restrictions are documented for supported exchanges.Withdrawal: Not required | Coinrule says it encrypts API credentials with AES-256 using separate per-user keys and uses TLS, Cloudflare and 2FA. Those are vendor assertions without a public independent assurance report. Trade access can still create substantial losses. | No qualifying incident identifiedEvidence confidence: Moderate |
| Pionex | Cloud / SaaS | Not required for built-in bots. Bots trade assets held in a Pionex exchange account.Withdrawal: Not applicable to bot connection; Pionex separately controls exchange-account withdrawals | Pionex removes the third-party API-key layer by running bots inside its own exchange, but this concentrates custody and operational risk. A 2023 point-in-time reserve report is limited evidence. The 2025 US order's information-security finding applies to Pionex Inc. and should not be generalized beyond its scope. | No qualifying incident identifiedEvidence confidence: Moderate |
| 3Commas | Cloud / SaaS | Exchange API keys are used for trading. Documentation says withdrawal access is not required and advises IP restrictions where supported.Withdrawal: Not required for documented bot connections | 3Commas is non-custodial in the sense that connected funds stay at the exchange, but trading API keys remain powerful credentials. Official documentation says withdrawal permission is unnecessary and describes an isolated signing system. The 2022 key exposure materially limits confidence until users can review current independent assurance. | DocumentedEvidence confidence: Moderate |
| Cryptohopper | Cloud / SaaS | Official onboarding emphasizes trading access without withdrawal permission. Exact scopes vary by exchange.Withdrawal: Not required for documented exchange connections | Cryptohopper connects to external exchanges rather than holding connected balances itself and says withdrawal permissions are unnecessary. Users still delegate order authority. The 2024 phishing-related incident shows that non-trading account data and session credentials also matter. | DocumentedEvidence confidence: Moderate |
| Bitsgap | Cloud / SaaS | Bitsgap says keys need trading, balance and history access and that withdrawal-enabled keys are rejected.Withdrawal: Rejected by the platform according to its documentation | Bitsgap says it encrypts API keys, supports 2FA and rejects keys with withdrawal permission. These are sensible controls, but they remain vendor-described and do not remove malicious-trading, exchange or account-takeover risk. | No qualifying incident identifiedEvidence confidence: Moderate |
| HaasOnline | Self-hosted or hybridNon-custodial software; funds remain on connected exchanges | User-controlled exchange API keys place orders. Cloud stores credentials on HaasOnline infrastructure; self-hosted TradeServer keeps the runtime and credentials on user infrastructure.Withdrawal: Not required for normal exchange trading automation | HaasOnline's dual deployment model requires separate assessment. Cloud centralizes operational controls; self-hosting localizes secrets but exposes users to server-administration mistakes. | No qualifying incident identifiedEvidence confidence: Moderate |
| Altrady | Cloud / SaaSNon-custodial SaaS; connected assets remain at exchanges | Trade-only or read-only API connections; IP allowlisting is available and encrypted API keys are stored server-side after client-side encryption.Withdrawal: Never requested according to current pricing and security pages | Altrady documents a thoughtful cloud API model, including client-side encryption, encrypted server storage, IP restrictions, read-only mode and 2FA. | No qualifying incident identifiedEvidence confidence: Moderate |
| TradeSanta | Cloud / SaaSNon-custodial SaaS; funds remain at connected exchanges | Exchange keys require account viewing and trading; documentation repeatedly instructs users not to enable withdrawals.Withdrawal: Must remain disabled | TradeSanta's most useful control is repeated guidance to disable withdrawals. Public detail on server-side key encryption and audit assurance is limited. | No qualifying incident identifiedEvidence confidence: Moderate |
| WunderTrading | Cloud / SaaSNon-custodial SaaS for connected exchange accounts | Trading-only exchange keys; pricing FAQ requires withdrawals disabled and supports IP allowlisting.Withdrawal: Explicitly disabled | WunderTrading requires withdrawal-disabled exchange keys and supports exchange-level IP whitelisting. Cloud order authority and storage remain material risks. | No qualifying incident identifiedEvidence confidence: Moderate |
| Quadency | Cloud / SaaSHistorically mixed terminal/API and direct transaction services; current model requires confirmation | The current security page describes limited-permission exchange API keys, 2FA and encrypted storage; exact scopes and implementation assurance were not independently verified.Withdrawal: Company says funds remain at connected exchanges; exact current exchange scopes remain unverified | The current security page describes encryption, HSTS/TLS, AWS controls, rate limits, OWASP-based testing, limited API permissions and 2FA. These are company claims without a public platform-wide assurance report. | No qualifying incident identifiedEvidence confidence: Limited |
| Gunbot | Self-hosted or hybridSelf-hosted, non-custodial software; exchange funds remain on exchanges | Exchange credentials are encrypted and stored locally. Users configure required exchange trading scopes and should disable withdrawals.Withdrawal: Usually unnecessary and should remain disabled | Gunbot's local model removes a central cloud key database but makes each installation its own security perimeter. | No qualifying incident identifiedEvidence confidence: Moderate |
| OctoBot | Self-hosted or hybridSelf-hosted or managed non-custodial exchange automation; optional self-custody wallet features change the key model | Self-hosted keys remain within the user's installation; cloud connection and permission details vary by exchange and need narrow trade-only scopes.Withdrawal: Not required for normal CEX bot trading | OctoBot's public code and local option are meaningful, but users must distinguish source visibility from assurance and secure their own installations. | No qualifying incident identifiedEvidence confidence: Moderate |
| Cornix | Cloud / SaaSNon-custodial SaaS; connected funds remain on exchanges | Each exchange API key consumes a slot. Company security guidance recommends no withdrawal permissions; keys are company-described as encrypted before storage.Withdrawal: Recommended disabled | Cornix documents encrypted storage and no-withdrawal keys. The larger practical risk is often the external signal source and automated execution authority. | No qualifying incident identifiedEvidence confidence: Moderate |
| goodcryptoX | Cloud / SaaSCEX assets stay at exchanges; DEX uses non-custodial MPC/smart-contract wallets and session keys | CEX keys are encrypted on device, transmitted and stored encrypted, and do not have withdrawal rights. DEX session keys grant granular on-chain trading permissions.Withdrawal: Not permitted for CEX keys; DEX session-key scope is separate | goodcryptoX documents separate CEX and DEX security models rather than collapsing them into one claim. Public audit artifacts remain the main evidence gap. | No qualifying incident identifiedEvidence confidence: Moderate |
| CryptoHero | Cloud / SaaSNon-custodial SaaS for connected exchange funds | CryptoHero says it requires read and trade permissions only; public detail on key encryption and storage is limited.Withdrawal: Not required | CryptoHero's scoped permission model is appropriate, but the public evidence does not expose enough implementation and assurance detail for a high security score. | No qualifying incident identifiedEvidence confidence: Moderate |
Cloud systems
The provider operates the runtime and must be able to use an exchange credential when executing an order. Evaluate storage, decryption boundaries, staff access, IP restrictions, 2FA and incident response.
Self-hosted systems
Local deployment can reduce provider custody of credentials, but moves patching, dashboard exposure, backups, malware and secret management to the user. Public code is not the same as an audit.
Custodial and on-chain systems
Built-in exchange bots do not need a third-party API key because funds already sit at the venue. Wallet automation may instead use private keys, smart contracts, approvals or session keys.