API key giełdy to para API Key i API Secret. Za pomocą tej key programy i usługi pracują z kontem przez API: odczytują saldo, otwierają i zamykają transakcje oraz wykonują inne operacje dozwolone dla tej key bez logowania do panelu webowego.
Cel materiału: opisać ograniczenia, które giełda stosuje wobec zapytań API: weryfikację podpisu przez API Secret, prawa key (permissions), powiązanie źródła zapytania z IP whitelist, ograniczenia wypłat przez whitelist adresów oraz izolację salda przez sub-accounts. Te ograniczenia zmniejszają ryzyko, że wyciek pary API Key + API Secret doprowadzi do wypłaty aktywów lub stratnych transakcji.
🧭 Jak działa kontrola dostępu API na giełdach crypto
API keys są używane przez trading boty, terminale, usługi raportowe i integracje wewnętrzne. Giełda wykonuje zapytanie API dopiero po sprawdzeniu podpisu (API Secret), praw do operacji (permissions), adresu IP źródła (IP whitelist) oraz czasu zapytania (timestamp i recvWindow). Kontrola czasu blokuje późniejsze powtórzenie zapytania, nawet jeśli zapytanie zostało przechwycone.
Ryzyko API zmniejsza się przez ustawienia key. IP whitelist przyjmuje zapytania tylko z określonych adresów IP. Permissions ograniczają zestaw operacji, które giełda wykona przy użyciu key. Whitelist adresów wypłat ogranicza listę odbiorców. Sub-accounts rozdzielają saldo i keys między sub-accounts, aby jedna key nie miała dostępu do wszystkich aktywów konta.
🔍 Jak giełda weryfikuje zapytanie API: podpis, prawa, IP i czas
API key składa się z API Key (identyfikatora key) oraz API Secret (secret do podpisu). Podpis potwierdza giełdzie, że zapytanie zostało utworzone z użyciem API Secret i nie zostało zmienione po drodze.
- Tworzenie parametrów zapytania do API endpointu giełdy (adresu API, który przyjmuje konkretną operację)
- Zapytanie określa operację: otworzyć lub anulować order, pobrać saldo, wykonać transfer albo uruchomić wypłatę.
- Zapytanie zawiera znacznik czasu (timestamp) i czasem dopuszczalne okno czasu (recvWindow). Giełda porównuje te wartości ze swoim czasem i odrzuca zapytanie, jeśli wychodzi poza dozwolony przedział.
- Podpisanie parametrów zapytania przez HMAC
- HMAC to podpis hash tworzony przy użyciu secret key. Ciąg parametrów jest podpisywany kluczem API Secret.
- Giełda ponownie oblicza HMAC dla tych samych parametrów i porównuje podpis. Brak zgodności oznacza, że nadawca nie posiada API Secret albo parametry zostały zmienione.
- Sprawdzenie ograniczeń key i decyzja o wykonaniu
- Permissions określają, jakie operacje są dozwolone dla key (read/trade/transfer/withdraw na większości giełd scentralizowanych, CEX).
- IP whitelist ogranicza źródła zapytań. Giełda odrzuca zapytanie, jeśli IP nadawcy nie znajduje się na whitelist key.
- Wykonanie operacji i zwrot wyniku
- Jeśli prawa są niewystarczające, giełda zwraca odmowę i nie wykonuje operacji, nawet przy poprawnym podpisie.
- Jeśli IP się nie zgadza, giełda zwraca odmowę na etapie autoryzacji i nie przechodzi do operacji tradingowej ani wypłaty.
Komponenty dostępu API kontrolowane przez giełdę
Giełda zmniejsza ryzyko API przez trzy kontrole w każdym zapytaniu: podpis przez API Secret, permissions dla operacji oraz IP whitelist dla źródła zapytania.
- API Secret jest przechowywany tylko w secrets vault i w pamięci procesu, który podpisuje zapytania.
- Permissions są włączane pod zadanie key: odczyt dla raportowania, trading dla bota, wypłata tylko dla płatności operacyjnych.
- IP whitelist zawiera tylko adresy IP serwerów, które faktycznie wysyłają zapytania, aby lista nie rozszerzała powierzchni ataku.
Jeśli atakujący uzyska API Key bez API Secret, giełda odrzuci zapytanie z powodu niepoprawnego podpisu. Jeśli atakujący uzyska API Key i API Secret, giełda odrzuci zapytanie, gdy permissions nie pozwalają na operację albo IP nie znajduje się na whitelist.
🎯 Jakie straty są możliwe przez API: wypłata, transfery i strata tradingowa
Szkoda przez API zależy od włączonych permissions oraz od salda dostępnego dla tej key. Trade-only key niesie mniejsze ryzyko na sub-account z niewielkim saldem roboczym i większe ryzyko na sub-account z kapitałem głównym.
Trzy scenariusze wykonywane przez giełdę przez API
Straty przez API powstają przez wypłatę, transfer wewnętrzny albo transakcje, które prowadzą do straty po cenie wykonania.
- Bezpośrednia wypłata: key z withdraw permission uruchamia wypłatę na adres, który giełda przepuści po swoich kontrolach i zasadach whitelist.
- Transfer wewnętrzny: key z transfer permission przenosi aktywa między portfelami produktu albo między sub-accounts, jeśli giełda pozwala na takie operacje przez API.
- Strata tradingowa bez wypłaty: key z trade permission wystawia ordery na parze o niskiej płynności i wykonuje transakcje po gorszej cenie, tworząc stratę wynikającą ze slippage, spreadu i prowizji.
Wyłączone withdraw permission usuwa bezpośrednią wypłatę. Trade permission pozostaje źródłem straty, jeśli w trading wallet przechowywane jest duże saldo, a key nie jest ograniczona po IP i instrumentach.
Sygnały, po których kontrola API staje się konieczna
- Pojawiły się ordery, które nie odpowiadają logice trading system ani harmonogramowi uruchomienia.
- Pojawiły się transfery między walletami lub sub-accounts bez przyczyny operacyjnej.
- W ustawieniach key pojawiły się nowe permissions albo usunięto IP whitelist.
- W logach trading system pojawiły się błędy podpisu i wzrosła częstotliwość zapytań przy niezmienionym kodzie.
🌐 IP whitelist: powiązanie key z serwerem źródłowym zapytań
IP whitelist zmusza giełdę do przyjmowania zapytań tylko z wcześniej wskazanych adresów IP. Jeśli API Secret trafi do kodu, logów, backupów albo usługi zewnętrznej, atakujący nie będzie mógł wysłać zapytania z IP, którego nie ma na whitelist.
Wybór stabilnego źródła zapytań API
- VPS (wirtualny serwer prywatny) ze stałym publicznym IP nadaje się do IP whitelist i do ciągłej pracy trading system.
- Domowe łącze internetowe z dynamicznym IP nie jest odpowiednie, ponieważ zmiana IP powoduje odmowy zapytań API do momentu aktualizacji whitelist.
Konfiguracja IP whitelist dla API key
- IP whitelist obejmuje IP serwera trading system oraz serwera zapasowego, jeśli serwer zapasowy jest faktycznie używany.
- Jeśli giełda obsługuje CIDR (zapis podsieci, na przykład 203.0.113.10/32), ustawia się najmniejszy zakres, aby nie rozszerzać listy źródeł.
Sprawdzenie odporności dostępu API na awarie
- Zapasowa API key na osobnym IP jest używana podczas migracji infrastruktury i zmiany adresu serwera.
- Procedura aktualizacji IP whitelist jest dokumentowana z wyprzedzeniem, aby zmiana IP nie zbiegła się z utratą kontroli nad orderami.
W infrastrukturze cloud zapytania mogą wychodzić do internetu przez NAT (translację adresów na granicy sieci). W takim przypadku zewnętrzny IP widziany przez giełdę może różnić się od IP kontenera lub maszyny wirtualnej. W IP whitelist wskazuje się egress IP (zewnętrzny IP ruchu wychodzącego), inaczej giełda będzie odrzucać zapytania.
IP whitelist nie chroni przed kompromitacją VPS. Po przejęciu serwera atakujący wyśle zapytania z tego samego IP, dlatego ochrona dostępu do VPS i kontrola aktualizacji pozostają częścią ochrony API.
IP whitelist blokuje zapytania z obcych serwerów, ponieważ giełda porównuje IP źródła z whitelist i odrzuca zapytanie przed wykonaniem operacji tradingowej albo wypłaty.
🔑 Permissions: jakie prawa są nadawane key pod konkretne zadanie
Permissions określają, które API endpointy giełda pozwoli wywoływać przy użyciu tej key. Nazwy praw zależą od giełdy, ale schemat zwykle jest taki sam: read do odczytu, trade do orderów, transfer do transferów wewnętrznych i withdraw do wypłaty na blockchain.
| Zadanie | Zezwolić | Zablokować | Blokowana operacja |
|---|---|---|---|
| Screener/analityka | Read | Trade; Transfer; Withdraw | Wystawianie orderów i przemieszczanie aktywów |
| Trading bot | Read; Trade | Withdraw | Bezpośrednia wypłata środków przez API |
| Raportowanie | Read | Trade; Transfer; Withdraw | Operacje przy kompromitacji usługi raportowej |
| Transfery operacyjne | Read; Transfer | Trade; Withdraw | Operacje tradingowe i wypłata na blockchain |
Read-only key do monitoringu i raportowania
Read-only key jest używana, gdy system musi odczytywać salda, historię transakcji i statusy pozycji, ale nie może zmieniać stanu konta.
- Read-only key blokuje wystawianie i anulowanie orderów, ponieważ giełda odrzuca trading endpoints dla tej key.
- IP whitelist ogranicza dostęp do danych do konkretnego serwera i blokuje zapytania z obcych IP przy wycieku API Secret.
- Osobna read-only key do raportowania oddziela ryzyko usługi raportowej od ryzyka trading key.
Read-only key ujawnia saldo i historię, ale nie pozwala na wypłaty ani transakcje, ponieważ giełda odrzuca endpointy trade/transfer/withdraw.
Trade key dla trading system bez wypłat
Trade key jest używana do wystawiania i anulowania orderów. Withdraw permission nie jest potrzebne do operacji tradingowych.
- Trade permission daje dostęp do zarządzania orderami i pozycjami w ramach rynków konta.
- Wyłączone withdraw permission blokuje wypłaty, ponieważ giełda odrzuca withdrawal endpoints dla tej key.
- IP whitelist wiąże key z serwerem trading system i blokuje zapytania z obcych maszyn przy wycieku API Secret.
Trade-only key tworzy ryzyko dla środków w trading wallet, dlatego trading sub-account zwykle utrzymuje saldo robocze, a nie kapitał główny.
Transfer key do przemieszczeń wewnętrznych
Transfer key jest używana do transferów wewnątrz giełdy: między portfelami produktu albo między sub-accounts, jeśli giełda zezwala na takie operacje przez API.
- Transfer permission pozwala wykonywać transfery wewnętrzne, które nie wychodzą na blockchain.
- Wyłączone trade permission wyklucza transakcje, ponieważ transfer key nie może tworzyć orderów.
- Wyłączone withdraw permission wyklucza wypłatę na blockchain przy kompromitacji transfer key.
Rozdzielenie transfer i trade na różne keys zmniejsza szkodę przy wycieku, ponieważ jedna key nie daje jednocześnie dostępu do transakcji i przemieszczania aktywów.
Permissions określają, jaką operację giełda dopuści dla tej key. Nadmiarowe permissions rozszerzają zestaw działań, które giełda wykona przy użyciu skompromitowanej key, dlatego prawa włącza się tylko pod konkretny proces.
🏷️ Ochrona wypłat: whitelist adresów, potwierdzenia i limity
Withdraw permission pozwala API key zainicjować wypłatę środków z salda giełdowego na blockchain. Ochrona wypłat opiera się na whitelist adresów odbiorcy, kontroli zmian whitelist i limitach wypłat.
W integracjach tradingowych withdraw permission zwykle jest wyłączane. Ordery, anulowanie i odczyt salda wykonują się wewnątrz giełdy i nie wymagają wypłaty do sieci. Do monitoringu i raportowania wystarcza prawo read. Do tradingu algorytmicznego wystarcza prawo trade.
Przykład: trading bot działa na key z trade permission i bez withdraw permission. Przy kompromitacji key atakujący będzie mógł otwierać i zamykać transakcje przez trading endpoints. Zapytanie o wypłatę giełda odrzuci, ponieważ key nie ma withdraw permission.
Whitelist adresów ogranicza odbiorcę wypłaty: giełda wysyła środki tylko na wcześniej dodane adresy. Na wielu giełdach dodanie adresu do whitelist wymaga 2FA (uwierzytelniania dwuskładnikowego) i potwierdzenia przez osobny kanał, na przykład email, aplikację albo hardware key. W takim przypadku wypłata na nowy adres zależy nie tylko od API key, ale także od kontroli tych kanałów potwierdzeń.
Opóźnienie zmiany whitelist (security lock, hold) nie aktywuje dodanego adresu od razu. Przy włączonym opóźnieniu wypłata na nowy adres jest blokowana na czas hold, dlatego dodanie adresu można zauważyć przed pierwszą wypłatą.
API connection trading botów, trade-only keys i IP whitelist są opisane w materiale „Zarabianie z crypto trading botami”.
Limity wypłat ograniczają sumę strat, jeśli atakujący uzyska key, która przechodzi kontrole whitelist i potwierdzeń. Limit dzienny ustawia się pod kwoty regularnych wypłat operacyjnych, a nie pod całkowite saldo konta, aby jeden cykl wypłaty nie pozwolił wyprowadzić całego depozytu.
Kompromitacja emaila zwiększa ryzyko, ponieważ na wielu giełdach potwierdzenia dodania adresów i reset ustawień bezpieczeństwa są powiązane z emailem, w tym linki potwierdzające i powiadomienia o zmianie whitelist.
Withdraw permission bez whitelist adresów sprawia, że wyciek API key staje się bezpośrednim kanałem wypłaty na blockchain. Withdraw permission z whitelist adresów i opóźnieniem zmiany whitelist przenosi krytyczne ryzyko na kompromitację kanałów potwierdzeń. Limity wypłat ograniczają sumę strat przy obejściu pozostałych ograniczeń.
🛡️ Sub-accounts: izolacja salda, keys i procesów
Sub-accounts rozdzielają saldo i API keys wewnątrz jednej giełdy. Przy wycieku key operacje są ograniczone do aktywów konkretnego sub-account.
- Rozdzielenie storage i tradingu na różne sub-accounts
- Storage sub-account utrzymuje kapitał główny i nie używa stałych trading API keys.
- Trading sub-accounts utrzymują salda robocze dla konkretnych botów i strategii.
- Kontrola transferów wewnętrznych przez API
- Wyłączenie transfer permission na trading keys zmniejsza możliwość przemieszczania aktywów przy wycieku trading key.
- Wydzielona transfer key jest używana, gdy transfery wewnętrzne wchodzą w proces operacyjny.
- Ograniczenie instrumentów key przy obsłudze whitelist par tradingowych
- Whitelist par tradingowych blokuje transakcje na instrumentach, które nie należą do trading system.
- Ograniczenie par zmniejsza ryzyko straty na rynkach o niskiej płynności.
Schemat izolacji dla kilku trading systems
Schemat izolacji rozdziela saldo przez sub-accounts i rozdziela dostęp przez API keys, permissions oraz IP whitelist.
- Jeden trading system na jednej giełdzie działa przez osobny sub-account i trade-only key powiązaną z IP VPS.
- Raportowanie podłącza się przez read-only key na osobnym serwerze, aby leak raportowania nie ujawniał trading key.
- Transfery operacyjne wykonuje się przez transfer key bez trade i withdraw permissions.
Przy wycieku key trading system giełda wykonuje operacje tylko w ramach salda jego sub-account, dlatego straty ograniczają się do salda roboczego.
🗄️ Przechowywanie secrets i rotacja: jak API Secret wycieka z infrastruktury
API Secret częściej wycieka nie przez giełdę, lecz z infrastruktury trading system: z repozytoriów kodu, pipeline’ów CI/CD (zautomatyzowanych procesów build i deployment), logów aplikacji, dumpów baz danych, screenshotów i backupów. Zarządzanie secrets określa miejsca przechowywania API Secret oraz role, które mogą uzyskać do niego dostęp.
API Secret nie przechowuje się w kodzie aplikacji. Wartość secret jest podstawiana przy starcie usługi z chronionego storage i nie jest zapisywana w plikach projektu ani w repozytorium. W kodzie i konfiguracji pozostaje referencja do secret, a nie jego wartość.
Przykład: trading bot jest wdrażany przez CI/CD. W repozytorium przechowywana jest tylko nazwa secret, a wartość API Secret jest podstawiana na etapie deploymentu z chronionego storage. Przy wycieku kodu i historii commitów API Secret nie znajduje się w tych danych.
W production API Secret przechowuje się w secret manager — usłudze, która trzyma secrets w postaci zaszyfrowanej i wydaje je tylko procesom z uprawnieniem przez IAM (zarządzanie dostępem przez role). Ten schemat oddziela production secrets od środowisk dev i usług testowych.
Behawioralne przyczyny błędów w pracy z ryzykiem i planem tradingowym są opisane w materiale „Psychologia tradera”.
Rotacja API keys zmniejsza ryzyko długotrwałego leaku. Rotacja obejmuje utworzenie nowej key na giełdzie, przełączenie systemu na nowy API Secret oraz unieważnienie starej key, aby giełda przestała przyjmować podpis po starym secret.
Przełączenie planuje się na okres bez otwartych pozycji i aktywnych orderów limit, aby zmiana API Secret nie przerwała zarządzania orderami i ryzykiem.
Minimalne zasady przechowywania API Secret
- API Secret jest przechowywany w secret manager albo w zaszyfrowanym storage z kontrolą dostępu.
- API Secret nie trafia do Git, Docker image, CI artifacts ani backupów w jawnej postaci.
- Production secret jest niedostępny ze środowiska dev i niedostępny dla ról, które nie uruchamiają trading system.
- Rotacja obejmuje unieważnienie starej key po przełączeniu, aby stary secret przestał działać po stronie giełdy.
Permissions, IP whitelist i whitelist adresów chronią po stronie giełdy, a secret management zmniejsza ryzyko wycieku API Secret z kodu i logów po stronie infrastruktury.
🧩 Zewnętrzne terminale i boty: jak podłączenie wpływa na ryzyko
Usługa zewnętrzna otrzymuje API Key i API Secret, aby podpisywać zapytania w imieniu konta. Jeśli usługa przyjmuje key w panelu webowym, API Secret jest przechowywany w infrastrukturze dostawcy. Przy incydencie u dostawcy atakujący będzie mógł podpisywać zapytania i przechodzić weryfikację podpisu po stronie giełdy.
✅ Oznaki kontrolowanego ryzyka
- Usługa działa z read-only i trade-only keys oraz nie wymaga withdraw permission do tradingu i raportowania.
- Usługa pokazuje dziennik działań API: utworzone ordery i wywołane endpointy.
- Usługa obsługuje podłączenie przez osobny sub-account z ograniczonym saldem roboczym.
❌ Oznaki podwyższonego ryzyka
- Usługa wymaga withdraw permission dla funkcji, które nie są związane z wypłatami operacyjnymi.
- Usługa wymaga wyłączenia IP whitelist i nie oferuje modelu z agentem po stronie użytkownika oraz stałym IP.
- Usługa nie udostępnia historii działań API, dlatego analiza opiera się na pośrednich sygnałach.
Przykład konfiguracji: sygnały i raportowanie używają read-only key, operacje tradingowe używają trade-only key na sub-account z saldem roboczym, a wypłaty przez API są wyłączone.
Usługa zewnętrzna nie znosi ograniczeń giełdy. Sub-account, IP whitelist, minimalne permissions i wyłączone withdraw permission ograniczają ryzyko do salda roboczego.
🧯 Reakcja na wyciek key: zatrzymanie wykonania i utrwalenie śladów
Przy podejrzeniu wycieku pary API Key + API Secret ryzyko rozwija się szybko, ponieważ giełda wykonuje operacje natychmiast po sprawdzeniu podpisu, praw, IP i czasu zapytania. Reakcja zaczyna się od zatrzymania autoryzacji po key i utrwalenia śladów operacji.
- Unieważnienie key po stronie giełdy
- Wyłączenie lub usunięcie key zatrzymuje przyjmowanie podpisanych zapytań dla tej API Key.
- Wyłączenie wszystkich keys sub-account stosuje się, jeśli źródło wycieku nie zostało określone.
- Utrwalenie śladów operacji
- Lista otwartych orderów i historia transakcji za okres anomalii pokazują, jakie operacje zdążyły się wykonać.
- Historia wypłat i zmiany whitelist adresów pokazują próby wypłat oraz przygotowanie adresów.
- Zamknięcie dodatkowych kanałów dostępu do konta
- Zmiana hasła i kontrola 2FA zmniejszają ryzyko wejścia do interfejsu webowego.
- Kontrola bezpieczeństwa emaila jest potrzebna, ponieważ potwierdzenia wypłat i zmiany whitelist często są powiązane z emailem.
- Przywrócenie dostępu roboczego
- Nową key tworzy się z minimalnymi permissions i z IP whitelist dla aktualnego serwera.
- API Secret aktualizuje się w secret manager, aby stary secret przestał być używany.
Unieważnienie key zatrzymuje wykonanie działań, ponieważ giełda przestaje przyjmować podpis dla tej API Key, nawet jeśli zapytania nadal napływają.
✅ Konfiguracja zmniejszająca ryzyko wypłaty przy wycieku key
Ryzyko wypłaty po wycieku pary API Key + API Secret zmniejsza się, gdy trade key nie ma withdraw permission, zapytania są ograniczone przez IP whitelist, a kapitał główny jest oddzielony od trading sub-account.
Minimalny zestaw parametrów dla trade key trading system
- Trading system działa na VPS ze stałym IP, a ten IP jest dodany do IP whitelist key.
- Key ma permissions read + trade i nie ma withdraw permission.
- Trading sub-account zawiera saldo robocze, a kapitał główny jest przechowywany osobno bez stałych trading keys.
- API Secret jest przechowywany w secret manager albo w zaszyfrowanym storage i nie trafia do repozytoriów ani logów.
IP whitelist, minimalne permissions, whitelist adresów dla rzadkich wypłat i izolacja przez sub-accounts ograniczają szkodę do salda roboczego i zmniejszają ryzyko wypłaty na blockchain przez skompromitowaną key.
❓ FAQ dotyczące bezpieczeństwa API keys
Dlaczego IP whitelist chroni nawet przy wycieku API Secret?
Giełda porównuje IP źródła zapytania z IP whitelist key i odrzuca zapytanie, jeśli IP się nie zgadza. Podpis HMAC może być poprawny, ale operacja nie zostanie wykonana, ponieważ kontrola IP odbywa się po stronie giełdy.
Kiedy withdraw permission jest naprawdę potrzebne?
Withdraw permission jest potrzebne do automatycznych wypłat operacyjnych na blockchain. Do tradingu, monitoringu i raportowania withdraw permission nie jest potrzebne, ponieważ te procesy używają trading i read endpoints wewnątrz giełdy.
Dlaczego trade-only key może prowadzić do strat bez wypłaty?
Trade-only key pozwala wystawiać ordery. Przy dostępie do trade-only key atakujący może wykonywać transakcje po gorszej cenie na parze o niskiej płynności i tworzyć stratę ze slippage, spreadu i prowizji przy dużym saldzie w trading wallet.
Po co osobny sub-account dla każdego trading system?
Sub-account ogranicza saldo dostępne dla key. Przy wycieku key trading system szkoda jest ograniczona do aktywów tego sub-account, ponieważ giełda wykonuje operacje wewnątrz salda konkretnego sub-account.
Jak rotować keys bez utraty kontroli nad orderami?
Rotacja obejmuje utworzenie nowej key, przełączenie trading system na nowy API Secret i unieważnienie starej key. Przełączenie planuje się na okres bez otwartych pozycji i aktywnych orderów limit, aby zmiana key nie przerwała zarządzania orderami.
Jak ogranicza się ryzyko przy podłączeniu zewnętrznego terminala?
Ryzyko ogranicza trade-only key na sub-account z saldem roboczym, IP whitelist (jeśli zapytania idą przez agenta po stronie użytkownika) oraz wyłączone withdraw permission, gdy terminal nie uczestniczy w wypłatach operacyjnych.
🧷 Jak ograniczenia API zmniejszają ryzyko wypłat i szkód tradingowych
Ryzyko API zależy od dozwolonych operacji i od kontroli, które giełda stosuje wobec każdego zapytania: podpisu (API Secret), permissions, IP whitelist oraz parametrów czasu zapytania.
- Wyłączone withdraw permission blokuje wypłatę na blockchain przez API, ponieważ giełda odrzuca withdrawal endpoints dla key bez tego prawa.
- Whitelist adresów wypłat ogranicza odbiorcę, ponieważ giełda wysyła środki tylko na wcześniej dodane adresy.
- IP whitelist ogranicza źródło zapytań, ponieważ giełda odrzuca zapytania z IP, których nie ma na liście key, nawet przy poprawnym podpisie.
- Sub-accounts ograniczają skalę strat, ponieważ key uzyskuje dostęp do salda konkretnego sub-account, a nie do wszystkich aktywów konta.