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 direct transfer risk but still permit loss-making orders.
Seven execution and security architectures
These models are not a safety ranking. A hybrid product can expose more than one boundary, and individual implementation evidence still matters.
| Architecture | Credential authority | Custody | Withdrawal model | Execution | Key risks | Current examples |
|---|---|---|---|---|---|---|
| Cloud third-party API | Provider-usable exchange trading credential | Assets generally remain at the exchange | Should be disabled; exact scope must be verified | Provider cloud | Central credential storage, provider compromise, outages and harmful trading authority | Coinrule, 3Commas, Cryptohopper |
| Self-hosted / local | Credential stored on user-controlled infrastructure | Assets generally remain at the exchange | Normally unnecessary and should remain disabled | User host | Host exposure, patching, secrets, dependencies, backups and availability | Gunbot, Hummingbot, Freqtrade |
| Exchange-native | No external bot API key | Exchange custody | External-key scope is Not Applicable | Exchange platform | Exchange account, custody, solvency, region and strategy configuration | Pionex, Binance Trading Bots, OKX Trading Bots |
| Signal execution | Webhook or signal can trigger connected trading authority | Usually remains at the connected venue | Normally unnecessary; connector-specific | Provider cloud, browser or user host | Webhook leakage, malformed signals, latency, duplicate orders and connector scope | Autoview, Alertatron, TV-Hub |
| Institutional automation | Contract- and deployment-specific venue, liquidity or custody connectivity | Usually remains with client-selected venues or custodians | Must be mapped across each connected provider | Institutional platform, APIs and configured counterparties | Powerful credentials, tenant and role controls, liquidity dependencies, outages and implementation error | CoinPanel, CoinRoutes, Talos |
| Managed strategy | Provider or strategy logic directs trades | Exchange, custodian or product-dependent | Model-specific; must be confirmed | Provider-managed | Opaque methodology, model drift, concentration, fees and company-reported outcomes | Stoic AI, Mudrex, Zignaly |
| On-chain automation | Wallet signing, private-key or smart-contract authority | Wallet or protocol-dependent | CEX withdrawal scopes do not describe wallet authority | Blockchain, smart contract and provider routing | Approvals, signing, contracts, routing, MEV, slippage, gas and key recovery | Mizar, DeFi Saver |
Source: Riven Trust, Dataset 2026-08.4. Examples and counts come from current product-level architecture fields.
Security models across reviewed products
| Product | Architecture | API and withdrawal model | Public security evidence | Incidents and confidence |
|---|---|---|---|---|
| Coinrule | Cloud SaaSCloud SaaS · Provider Cloud | 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 | Exchange-NativeExchange-Native · Exchange Platform | 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 SaaSCloud SaaS · Provider Cloud | 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 SaaSCloud SaaS · Provider Cloud | 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 SaaSCloud SaaS · Provider Cloud | 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 | HybridHybrid · Mixed | 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 SaaSCloud SaaS · Provider Cloud | 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 SaaSCloud SaaS · Provider Cloud | 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 SaaSCloud SaaS · Provider Cloud | 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 SaaSCloud SaaS · Provider Cloud | 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-HostedSelf-Hosted · User Infrastructure | 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 | HybridHybrid · Mixed | 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 SaaSCloud SaaS · Provider Cloud | 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 | HybridHybrid · Mixed | 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 SaaSCloud SaaS · Provider Cloud | 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 |
| Hummingbot | Open SourceSelf-Hosted · User Infrastructure | Credentials are configured in the user-controlled deployment. CEX live trading requires exchange API authority; DEX connectors can introduce wallet and signing authority.Withdrawal: Not required for ordinary CEX trading; DEX wallet permissions require connector-specific review | Hummingbot keeps execution and secrets on infrastructure controlled by the user, but that control is useful only with prompt updates, restricted network exposure and careful connector permissions. | No qualifying incident identifiedEvidence confidence: High |
| Freqtrade | Open SourceSelf-Hosted · User Infrastructure | Live trading uses exchange keys stored in the local configuration or environment. Dry-run does not require live-trading keys.Withdrawal: Not required; configure trade-only exchange permissions | Freqtrade provides strong visibility and local control, while explicitly warning that its web interface should not be directly internet-exposed. | No qualifying incident identifiedEvidence confidence: Moderate |
| Jesse | HybridSelf-Hosted · User Infrastructure | Live execution stores exchange credentials in the user's Jesse environment; official setup guides recommend trade permission and optional IP allowlisting where supported.Withdrawal: Not required for ordinary exchange trading | Jesse keeps the runtime and exchange secrets under user control, while its closed live plugin and license delivery prevent full end-to-end source inspection. | No qualifying incident identifiedEvidence confidence: Moderate |
| Stoic AI | Managed StrategyManaged Strategy · Provider Cloud | Stoic requests balance-read and trading permissions on connected exchange accounts and says withdrawal permission must remain disabled.Withdrawal: Not requested; official help says Stoic cannot withdraw | Stoic's no-withdrawal API model is a meaningful control, but the provider can still trade the connected balance and its credential storage assurance is limited. | No qualifying incident identifiedEvidence confidence: Moderate |
| CryptoRobotics | Cloud SaaSCloud SaaS · Provider Cloud | Connected exchanges use API keys with trading authority; the provider says withdrawals should be disabled and keys are not exposed to the frontend.Withdrawal: Not required; official integration copy says no withdrawal ability | CryptoRobotics documents a trade-only API model, but its security language does not provide enough detail to assess encryption, staff access, segregation or independent testing. | No qualifying incident identifiedEvidence confidence: Moderate |
| RevenueBot | Cloud SaaSCloud SaaS · Provider Cloud | The service stores or uses exchange API credentials for cloud execution and instructs users to enable trading but disable withdrawals.Withdrawal: Official terms say RevenueBot has no withdrawal access | RevenueBot's explicit no-withdrawal policy is useful, but there is insufficient technical or independent evidence about credential storage, access control and incident assurance. | No qualifying incident identifiedEvidence confidence: Limited |
| Binance Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Not applicable: bots execute inside the user's Binance account without an external provider API key.Withdrawal: Not applicable to bot connection; Binance controls custody and account withdrawals separately | The native design eliminates an external bot credential, but the account, assets, strategy and execution all depend on Binance. | No qualifying incident identifiedEvidence confidence: Moderate |
| OKX Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Not applicable: native bots execute within the OKX account.Withdrawal: Not applicable to bot connection; OKX account custody and withdrawals remain separate | OKX's native architecture removes external bot keys but concentrates bot capital and execution at the exchange. | No qualifying incident identifiedEvidence confidence: High |
| Bybit Trading Bot | Exchange-NativeExchange-Native · Exchange Platform | Not applicable: orders execute inside the Bybit account without an external bot API key.Withdrawal: Not applicable to bot connection; Bybit account withdrawals remain separate | Bybit bots avoid external credentials but remain fully dependent on Bybit custody, internal account transfers, platform availability and account security. | No qualifying incident identifiedEvidence confidence: High |
| KuCoin Trading Bot | Exchange-NativeExchange-Native · Exchange Platform | Not applicable: bots run inside the user's KuCoin account.Withdrawal: Not applicable to bot connection; exchange-account withdrawals remain separate | KuCoin's native bot design avoids external credentials but leaves assets, execution and availability within the exchange. | No qualifying incident identifiedEvidence confidence: Moderate |
| Gainium | HybridHybrid · Mixed | Cloud connections use encrypted exchange credentials and can support server-IP allowlisting; the Community Edition stores and uses credentials on user infrastructure.Withdrawal: Not required; provider instructions specify trading permissions without withdrawals | Gainium documents encrypted cloud secrets, trade-only exchange keys and optional IP allowlisting. Community Edition changes the trust boundary rather than eliminating it. | No qualifying incident identifiedEvidence confidence: Moderate |
| Passivbot | Open SourceSelf-Hosted · User Infrastructure | Users place exchange credentials in a local configuration file and control host access and key scopes.Withdrawal: Not required; use trading permissions without withdrawals | Passivbot's public code and local credential boundary improve inspectability, but users remain responsible for secure files, dependencies, host access and exchange permissions. | No qualifying incident identifiedEvidence confidence: High |
| Superalgos | Open SourceSelf-Hosted · User Infrastructure | Exchange keys are configured inside the user's workspace; official tutorials instruct users not to enable withdrawals.Withdrawal: Not required; official tutorials specify keys without withdrawal permission | Superalgos keeps execution and exchange secrets on user infrastructure and publishes its source, but secure defaults, patching and workspace protection remain operator duties. | No qualifying incident identifiedEvidence confidence: High |
| Autoview | Signal ExecutionHybrid · Mixed | Cloud mode stores encrypted broker/exchange credentials; legacy extension mode keeps credentials in the browser. Current guidance specifies read/trade access without withdrawals.Withdrawal: Not required; current security guidance specifies no withdrawal permission | Cloud users depend on Autoview's encryption and webhook validation; legacy users depend more on browser security. In either mode, trade-only authority can still create losses. | No qualifying incident identifiedEvidence confidence: Moderate |
| Alertatron | Signal ExecutionCloud SaaS · Provider Cloud | Users connect exchange accounts for cloud order execution; current public docs did not provide a complete cross-exchange storage and permission-control specification.Withdrawal: Not disclosed comprehensively in current public documentation; users should grant only required trading scopes and disable withdrawals | Alertatron requires meaningful cloud order authority. Public material supports the execution model but not a comprehensive current security-control assessment. | No qualifying incident identifiedEvidence confidence: Limited |
| TV-Hub | Signal ExecutionCloud SaaS · Provider Cloud | Official setup guidance calls for read and trade permissions, encryption at rest and optional IP whitelisting.Withdrawal: Not required; official setup guidance says never enable withdrawal permission | TV-Hub documents a sensible exchange-key model, but users must trust unverified provider-side encryption and an unidentified operator. | No qualifying incident identifiedEvidence confidence: Limited |
| Flipr.Cloud | Signal ExecutionCloud SaaS · Provider Cloud | Terms state that cloud-stored exchange credentials are encrypted and should be limited to trading.Withdrawal: Not required; terms specify no withdrawal access | Flipr.Cloud documents encryption and trade-only credentials, but these remain claims from an unidentified beta operator without public audit evidence. | No qualifying incident identifiedEvidence confidence: Limited |
| Mizar | On-Chain AutomationCloud SaaS · Provider Cloud | The current product uses wallet/private-key or signing authority rather than a conventional CEX trade-only API key. Public pages say keys are encrypted and protected by 2FA.Withdrawal: Not applicable to CEX API scope; wallet signing authority can authorize on-chain transactions and must be assessed separately | Mizar's current wallet architecture is not directly comparable with trade-only exchange APIs. Users need explicit answers about key custody, signing, recovery, approvals and shutdown access. | No qualifying incident identifiedEvidence confidence: Limited |
| CoinPanel | Institutional AutomationCloud SaaS · Provider Cloud | CoinPanel describes encrypted API-key connections and isolated environments; exact scopes and controls depend on the exchange and enterprise configuration.Withdrawal: Not documented as required; customers should confirm each exchange integration and disable withdrawals unless explicitly necessary | CoinPanel's non-custodial and encrypted-key claims are relevant but insufficient for an institutional control conclusion without scoped independent assurance. | No qualifying incident identifiedEvidence confidence: Moderate |
| Capitalise.ai | Multi-Asset AutomationCloud SaaS · Provider Cloud | Execution occurs through linked broker accounts and partner integrations; credential and authorization mechanics depend on the partner rather than one universal exchange-key model.Withdrawal: Not presented as a withdrawal-capable crypto API connection; confirm authority with the selected broker integration | Capitalise.ai keeps assets at connected brokers and executes through partner integrations. Each partner's authorization, data sharing, MFA and order controls must be assessed separately. | No qualifying incident identifiedEvidence confidence: Moderate |
| Veles | Cloud SaaSCloud SaaS · Provider Cloud | Users connect exchange API credentials with trading authority; Veles publishes trusted server IP addresses for allowlisting.Withdrawal: Not required; current documentation says Veles cannot withdraw exchange funds | Veles uses provider-cloud credentials with order authority. Withdrawal-disabled keys, exchange subaccounts and published IP allowlists reduce exposure but do not prevent harmful trades from a compromised service or credential. | No qualifying incident identifiedEvidence confidence: Moderate |
| KryllOS | Self-HostedSelf-Hosted · User Infrastructure | Current live exchange execution is not generally available. Official architecture material says future credentials remain on the user's machine or VPS.Withdrawal: Not applicable to currently available editor and backtesting functions; future live connections should not require withdrawals | KryllOS moves runtime responsibility to the user's workstation or VPS. Local custody is not automatic safety: exposed SSH, weak host controls, dependencies and backups can compromise future trade credentials. | No qualifying incident identifiedEvidence confidence: Moderate |
| MoonTrader | HybridSelf-Hosted · User Infrastructure | Users place exchange keys in the self-hosted Core. Official guidance says keys should trade but not withdraw.Withdrawal: Not required; MoonTrader instructs users to disable withdrawals | MoonTrader's Core is user-hosted and retains execution authority. Protect the host, memory, backups and remote controls; local storage is not equivalent to independent security assurance. | No qualifying incident identifiedEvidence confidence: Moderate |
| Phemex Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Not Applicable: bots execute inside the user's exchange account and do not require a separate third-party API key.Withdrawal: Not Applicable to bot API authority; the exchange itself has custody and account-level withdrawal capability | Native bots execute with the exchange's own account authority. Enable strong MFA and anti-phishing controls, use conservative allocation and review account sessions. This profile does not score the full exchange security program. | No qualifying incident identifiedEvidence confidence: Moderate |
| Gate.io Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Not Applicable: bots execute inside the user's exchange account and do not require a separate third-party API key.Withdrawal: Not Applicable to bot API authority; the exchange itself has custody and account-level withdrawal capability | Native bots execute with the exchange's own account authority. Enable strong MFA and anti-phishing controls, use conservative allocation and review account sessions. This profile does not score the full exchange security program. | No qualifying incident identifiedEvidence confidence: Moderate |
| Bitget Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Not Applicable: bots execute inside the user's exchange account and do not require a separate third-party API key.Withdrawal: Not Applicable to bot API authority; the exchange itself has custody and account-level withdrawal capability | Native bots execute with the exchange's own account authority. Enable strong MFA and anti-phishing controls, use conservative allocation and review account sessions. This profile does not score the full exchange security program. | No qualifying incident identifiedEvidence confidence: Moderate |
| BingX Trading Bot | Exchange-NativeExchange-Native · Exchange Platform | Not Applicable: bots execute inside the user's exchange account and do not require a separate third-party API key.Withdrawal: Not Applicable to bot API authority; the exchange itself has custody and account-level withdrawal capability | Native bots execute with the exchange's own account authority. Enable strong MFA and anti-phishing controls, use conservative allocation and review account sessions. This profile does not score the full exchange security program. | No qualifying incident identifiedEvidence confidence: Limited |
| MEXC Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Not Applicable: bots execute inside the user's exchange account and do not require a separate third-party API key.Withdrawal: Not Applicable to bot API authority; the exchange itself has custody and account-level withdrawal capability | Native bots execute with the exchange's own account authority. Enable strong MFA and anti-phishing controls, use conservative allocation and review account sessions. This profile does not score the full exchange security program. | No qualifying incident identifiedEvidence confidence: Moderate |
| Mudrex | Managed Crypto AutomationManaged Strategy · Exchange Platform | No external exchange API key is needed for Coin Sets. Mudrex controls the custodial platform and executes portfolio transactions.Withdrawal: Not an API permission model; Mudrex has custody and processes user-requested withdrawals under platform terms | Mudrex is custodial. Account MFA and platform controls matter, but users also face withdrawal, operator, counterparty and jurisdiction risk that cannot be reduced through a trade-only API key. | No qualifying incident identifiedEvidence confidence: Moderate |
| Tealstreet | Signal ExecutionHybrid · Mixed | Users connect external exchange keys. Tealstreet states that account data and keys are encrypted on the user's device.Withdrawal: Not required; current terms say deposits and withdrawals cannot be performed through Tealstreet | Tealstreet does not hold exchange assets or enable withdrawals, but connected keys can trade. The endpoint, browser/device, local storage and webhook secrets all become part of the security boundary. | No qualifying incident identifiedEvidence confidence: Moderate |
| NautilusTrader | Open SourceSelf-Hosted · User Infrastructure | Users configure venue credentials locally; required scopes depend on each adapter and strategy, and withdrawals are not a normal execution requirement.Withdrawal: Not required for normal trading adapters; users control key scopes and local secret storage | Public code, signed releases, provenance artifacts and security-pipeline documentation improve inspectability. They do not secure the user's host, strategy or venue keys. | No qualifying incident identifiedEvidence confidence: High |
| DeFi Saver | On-Chain AutomationHybrid · Mixed | No exchange API key is required. Users authorize smart-wallet modules and on-chain automation permissions; upgrades and execution controls are documented separately.Withdrawal: CEX withdrawal scopes are not applicable; risk centers on wallet authorization, smart-contract permissions and transaction execution | Public contracts, multiple scoped audits, on-chain trigger checks, separated multisigs and a 24-hour upgrade timelock provide meaningful assurance. External protocols, wallets, oracles and configuration remain dependencies. | No qualifying incident identifiedEvidence confidence: High |
| TradersPost | Signal ExecutionCloud SaaS · Provider Cloud | Users connect supported broker or exchange accounts; current documentation recommends a dedicated account and venue-appropriate MFA and permissions.Withdrawal: The software transmits orders and states it does not custody or manage customer funds; users must verify each connected account scope | Current documentation covers account connections, webhook handling and MFA recommendations, but no independent platform-wide audit or current SOC report was located. | No qualifying incident identifiedEvidence confidence: High |
| CoinRoutes | Institutional AutomationCloud SaaS · Provider Cloud | Institutions connect venue and custody relationships through FIX, REST or WebSocket integrations; exact credential storage and permission controls are deployment-specific and not fully public.Withdrawal: CoinRoutes presents execution connectivity rather than custody; withdrawal authority must be confirmed in each institutional integration | Institutional connectivity and client-controlled venue relationships are documented, but a public current SOC report, penetration-test summary or detailed credential-control architecture was not located. | No qualifying incident identifiedEvidence confidence: Moderate |
| Talos | Institutional AutomationCloud SaaS · Provider Cloud | Institutional clients connect venues and providers through platform, FIX, REST and WebSocket workflows; contractual and deployment-specific key controls are not fully public.Withdrawal: Talos states it is not party to client liquidity arrangements; custody and transfer authority remain with selected providers and integrations | A published historical SOC 2 Type 2 examination and enterprise control language are meaningful. Current report period, scope, subservice organizations and client-control responsibilities must be obtained directly. | No qualifying incident identifiedEvidence confidence: High |
| Wyden | Institutional AutomationCloud SaaS · Provider Cloud | The platform documents single-tenant architecture, authentication, RBAC and audit logs; venue credential controls depend on deployment and institutional configuration.Withdrawal: Wyden is trading infrastructure rather than a custodian; transfer and withdrawal authority must be defined with each connected venue or custodian | Single-tenant deployment, authentication, RBAC, audit logs and certification claims are documented. The underlying certificates and current report periods were not independently inspected. | No qualifying incident identifiedEvidence confidence: High |
| Crypto.com Trading Bots | Exchange-NativeExchange-Native · Exchange Platform | Built-in bots do not require an external exchange API key; they execute as authorized instructions within the user's exchange account.Withdrawal: Not applicable to bot-layer credentials; the bot operates inside the custodial exchange account | Native execution avoids third-party API credentials and can use exchange subaccounts. It remains fully dependent on Crypto.com account security, custody and platform controls. | No qualifying incident identifiedEvidence confidence: High |
| BitMart Trading Bot | Exchange-NativeExchange-Native · Exchange Platform | Built-in bots operate within a BitMart account and do not require an external API key; current documentation describes segregated AI Hub subaccounts or shared contract-account operation.Withdrawal: Not applicable at the bot layer; user assets remain in custodial BitMart accounts | Native bots avoid third-party credentials, but security depends on BitMart custody and account controls. The provider documents historical remediation while current full reserve evidence remains incomplete. | DocumentedEvidence confidence: Moderate |
| Zignaly | Managed Crypto AutomationManaged Strategy · Provider Cloud | Investors do not supply their own exchange API keys for Profit Sharing; approved managers trade pooled accounts through Zignaly-linked infrastructure.Withdrawal: Investors request withdrawals through Zignaly procedures; this is a managed/custodial model rather than trade-only API software | Zignaly documents Fireblocks and broker-infrastructure controls, RSA key handling, isolated withdrawal systems and 2FA. These remain provider-controlled without a reviewed current independent platform-wide assurance report. | No qualifying incident identifiedEvidence confidence: Moderate |
Method and source context
This page uses product-level fields from the current dataset. The 54 products, 168 claims and 328 source records are distinct denominators. Source count does not measure security quality.
Primary documentation can establish a published control or architecture statement but not its implementation effectiveness. Independent evidence must match the platform and control scope; multiple provider pages remain company-controlled evidence.