A Switch 2 Emulator Engine Launched This Week. Its Own Commit Log Retracted the Claim

2026-10-26 · News and analysis

Affiliate disclosure: This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

A project called ounce-core appeared on 24 October 2026. Within two days it had 167 stars and a round of coverage saying a Switch 2 emulator engine had been released for PC, capable of running native 64 bit files and captured machine code from firmware 23.0.1 dumps.

We went and read it. Here is the first line of its own summary.

It is a test harness for studying these subsystems. It is not a console emulator and makes no claim of compatibility with any commercial software.

That is the project describing itself, as of this morning. The claim in the headlines is one the project removed from its own repository, and it documented the removal in public.

This is worth walking through carefully, because the paper trail is unusually clear and it teaches you how to read the next one of these.

The Short Version

• ounce-core is not a Switch 2 emulator and does not claim to be. Its own documentation says so in the abstract.
• It cannot decrypt a retail game. Decryption is limited by policy to a synthetic test key. Retail keys are disabled.
• No GPU is involved at all. Its graphics layer is described as "model only" and never calls a graphics driver.
• A pull request merged on 26 October removed code taken from Switch 2 firmware and, in the author's words, corrected "claims the code does not support."
• The same pull request removed a hardcoded floor from a benchmark. One performance stage could not report a number below 105.4 MIPS no matter what the machine did.
• Total downloads across every release file: 21. Almost nobody has run this.
• Nothing has changed for emulation. No commercial Switch 2 game runs under any public emulator, on any hardware.

What ounce-core Actually Is

Strip the framing away and it is a research harness written in Rust. It models pieces of an ARM based system: an instruction interpreter, a paged memory model, a handful of operating system calls, and software stand-ins for graphics, audio and input.

That is a legitimate thing to build. Early emulator work looks exactly like this. The problem is the distance between that and "an emulator engine has been released."

Its own status table is the clearest guide, and it is refreshingly blunt about the limits:

• Graphics are a software model. The entry for its Vulkan layer reads "Model only. It does not call a Vulkan loader or driver." Elsewhere: "No GPU API is called." Anything drawn is drawn by the CPU into a window.
• The shader translator is unvalidated. It emits bytes that are supposed to be GPU code, and the documentation says they have never been checked against a driver.
• The file named after DLSS is not DLSS. The project says so itself. It is 2x bilinear interpolation with a sharpening pass, and there is no neural network in it.
• Services are synthetic. The system services a real game would talk to are simulated stubs.
• Retail decryption is off. Game containers can only be decrypted with a built in synthetic test key. The documentation states retail key decryption is disabled and that anything you load has to be unencrypted already.

Put those together and you have something that cannot take a Switch 2 game and run it, by design, as its author now describes it.

The Tests It Passes Are Tests It Wrote

The project advertises a 24 stage verification harness, and the coverage treated that as evidence.

Read what the stages do. Every one of them runs a small program the project wrote itself, then checks whether that program returned the number the project expected. The expected values are invented markers like 0xBBB, 0xCCC, 0xDDD and 0xEEE.

That is a useful thing for a developer. It tells you your own code did not regress. It tells you nothing about whether real software works, and the documentation is honest about this too. It says timing figures are host measurements of small synthetic programs, that they are not comparable to hardware, and that "behaviour that is not in the test suite should be assumed unverified."

The Pull Request Is the Story

On the morning of 26 October, the author opened a pull request against their own repository and merged it. The title is the news:

legal: remove third-party and firmware-derived material; correct overclaims

The summary describes removing "byte sequences captured from Switch 2 firmware and from a third-party project" and correcting "claims the code does not support." Four specific changes stand out.

Firmware code was in the project. Blocks the summary identifies as nnSdk and nnCompatThin, plus event, thread and payload code, were replaced with ARM programs written from scratch for the repository. nnSdk is Nintendo's own software development kit. A project that describes itself as clean room cannot have contained that, and the README still carries the clean room framing on the line above the paragraph admitting the removal.

The code that looked like it ran real firmware was reading a file off the disk. A function called get_test_nso_payload had been loading a file named ns2jb_ro_payload.bin out of the working directory. That filename refers to ns2jb, the Switch 2 jailbreak released four days earlier, which we covered in the Switch 2 jailbreak piece. The function was renamed to synthetic_nso_payload. So the impressive sounding capability was "if you put a jailbreak payload next to the program, it will read that file."

A Nintendo font string was swapped for a placeholder. The literal text NintendoStandardFont was replaced with the four characters OUNC.

The benchmark had a floor built into it. This is the detail worth remembering. The commit summary says, plainly: "MIPS floor removed. Stage 20 printed max(measured, 105.4)."

Read that again. The performance stage took whatever speed it actually measured, compared it to 105.4, and printed whichever was higher. A slow result was impossible to observe. Any performance number anyone quoted from that stage before this morning was a number the program was incapable of going below.

The history was rewritten to hide the evidence, and it did not finish. The README's known issues section says the git history was rewritten across all commits to strip those firmware bytes, and that purging GitHub's own cache and the pull request references is "pending support ticket resolution." The author is waiting on a support ticket to finish deleting it.

Signals You Can Check in 60 Seconds

None of this requires reading Rust. It is all visible from the repository's front page and its history.

The star count is the one people trust and it is the one that means least. 167 stars in two days measures how far a headline travelled. The download count measures how many people actually tried it, and 21 is the real number.

The cryptocurrency token address sitting in the description of an unrelated repository on the same account is not proof of anything by itself. It is the sort of thing worth noticing before you install software from a stranger.

The Project Warns About Itself

One more line from its own README deserves to be quoted, because it is the most practical warning in this whole story:

Third parties may distribute executables labelled "ounce-core" that contain malware.

A project with 21 downloads and a viral news cycle is exactly the bait a fake installer wants. If you searched for this after reading a headline, the thing you find on a download aggregator is far more likely to be malware than anything the author wrote. We are not linking to any of it.

This Has Happened Twice Already This Year

The pattern matters more than this one project.

In July 2026, a group calling itself Hassaku Emulator claimed it had begun rendering Switch 2 titles. The claim fell apart quickly. There were no Switch 2 game files in circulation at the time, and the proof turned out to be video playing over a grainy background.

Now this. Two days old, firmware code inside it, a benchmark with a floor, and a round of coverage built on a claim the author has since deleted.

The two projects actually doing this work take the opposite tone. Pound and oboromi are real, and one of them carries an all caps notice in its own documentation saying it will not be ready for a decade minimum. Neither has ever claimed to run a commercial game. We go through both in Switch 2 Emulators in 2026.

Being slow and saying so is what a credible project in this space looks like right now.

What This Changes for Handheld Owners

Nothing, and it is worth being direct about why.

No commercial Switch 2 game runs under any public emulator. Not on a PC, not on a Steam Deck, not on an Android handheld. That was true before the jailbreak four days ago, it was true before ounce-core, and it is true today.

The reason is that getting files off a Switch 2 was never the hard part. The hard part is reimplementing a custom NVIDIA graphics chip, an operating system and a security model. That is a multi year problem, and a two day old repository with a software rasterizer has not made a dent in it.

If what you want is a handheld that plays your library today, that is still a dedicated device, and the current crop is genuinely good.

How to Judge the Next One

There will be a next one. These are the checks that would have caught this one in a minute.

1. Read the project's own description before the coverage. ounce-core told you it was not an emulator, in its abstract, in plain English. No reporting required.
2. Look at downloads, not stars. Stars measure reach. Downloads measure use.
3. Check the repository's age against the claim. Emulating a modern console in two days is not a thing that happens.
4. Read the commit log. It is public, it is in chronological order, and it is where a project tells on itself. "Correct overclaims" is a phrase you can search for.
5. Be suspicious of a benchmark with no methodology. A performance number with no stated hardware, scene or method is not a measurement.
6. Check whether it needs files it cannot legally include. If a project claims to run commercial software but ships no way to decrypt it, those two claims are in conflict.

We have a longer version of this, built around the AI argument currently splitting the native port scene, in how to tell which port to trust.

The Bottom Line

ounce-core is a young research project whose current documentation is reasonably honest about being a young research project. The story is not that someone built a Switch 2 emulator. The story is that a claim travelled across a dozen outlets in 48 hours, and the author quietly deleted it, in public, with a commit message explaining what was wrong.

The author's current position and the headlines are two different things. We would rather report the first one.

Frequently Asked Questions

Is ounce-core a working Switch 2 emulator?

No. Its own documentation says "it is not a console emulator and makes no claim of compatibility with any commercial software." It cannot decrypt a retail game, its graphics layer never calls a graphics driver, and every test it passes is a test it wrote for itself.

Can I play Switch 2 games on PC with ounce-core?

No. There is no Switch 2 emulator that plays commercial games, on PC or anything else. ounce-core's game decryption is restricted to a built in synthetic test key, so it cannot open a retail game even if you dumped one yourself.

Why are websites calling ounce-core a Switch 2 emulator engine?

The early coverage was based on claims that have since been removed from the project. A pull request the author merged on 26 October 2026 is titled "remove third-party and firmware-derived material; correct overclaims" and deleted code taken from Switch 2 firmware along with the capability claims built on it.

What was the hardcoded benchmark in ounce-core?

One performance stage printed the higher of the measured result and a fixed value of 105.4 MIPS, so it could never report a slow result. The author removed it in the same pull request, described in the commit summary as "MIPS floor removed."

Did AI write ounce-core?

A share of its commits are attributed to an AI coding agent, Anthropic's Claude, including the merge that stripped the firmware derived code. The project does not disclose this in its README. AI assistance is not automatically a problem, and several respected projects disclose it, but an undisclosed AI built project making large claims in its first 48 hours is worth extra scepticism.

Is it safe to download ounce-core?

The project's own README warns that third parties may distribute executables labelled ounce-core that contain malware. With 21 legitimate downloads and a viral news cycle, anything you find through a search or a download aggregator is a poor bet. We do not link to it.

Does the Switch 2 jailbreak make Switch 2 emulation closer?

No. Getting files off the console was never the bottleneck. The bottleneck is reimplementing the graphics chip, the operating system and the security model. We cover the jailbreak itself in The Switch 2 Has Been Jailbroken.

Which Switch 2 emulator projects are real?

Two: Pound and oboromi. Both are proof of concept work, neither can run a commercial game, and one states in its own documentation that it will not be ready for a decade minimum. Switch 2 Emulators in 2026 covers where each actually stands.

Related Reading

• Switch 2 Emulators in 2026: Do Any Actually Exist Yet?
• Switch 2 Emulation in 2026: What Actually Works on Handhelds
• The Switch 2 Has Been Jailbroken. Nintendo Pulled the Game, Not the Bug
• Switch 2 Games Are Being Dumped. Nothing Can Play Them Yet
• The Recomp Scene Split Three Ways Over AI
• Is That Viral Mod Video Real? How to Check

Written 26 October 2026. Every claim about ounce-core comes from its own README, commit log, merged pull request and the GitHub API, retrieved that day. This is a fast moving repository whose author is actively revising both the code and the claims, so the project's description of itself may have changed again by the time you read this. We have not run the software and we publish no performance figures of our own.