Ounce-Core: Four Outside Programs Pass a Switch Homebrew Oracle

By Indie Kings | November 4, 2026

Updated November 4, 2026: Ounce-Core is an experimental Rust runtime for original Switch homebrew, and it makes one claim and refuses to make any other: four outside homebrew programs render their first frame pixel-exact, each checked in CI against an oracle written before the run. Version 0.4.0 shipped on November 3, 2026 and reset every public claim to what a real program had proven. The project holds 211 stars and 21 forks under MIT.

Image: The Ounce-Core project banner, showing the six subsystem areas: CPU execution, memory, system services, graphics, audio and input, and verification. Credit: hffgzktbcc-blip/GitHub.

Per the official repository README, Ounce-Core is an experimental Rust research runtime that makes the conversation between instructions, memory, operating-system services and hardware observable. It brings together interpreters, tiered AArch64 execution, Horizon-style service models, software graphics and optional wgpu presentation. Its headline metric is four outside homebrew programs rendering their first frame pixel-exact. Everything the project claims rests on outside open-source homebrew passing a pre-registered pixel oracle in CI.

The repository is a research project in the old sense. It was created on October 24, 2026, is written in Rust, is MIT licensed, and is maintained by someone whose academic background is in psychology, education and research. That background is the explanation for the method, and the README says so without pretending it is a computer science credential. The emphasis is on careful experimentation, reproducible evidence and making complex systems understandable.

The oracle is the product

Four programs the author did not write, from the upstream switchbrew switch-examples collection at a pinned commit, have an expected frame written down before the run. Both the interpreter engine and the Tier-3 engine must match that frame exactly. The four are a raw framebuffer fill sequence, a deko3d graphics program, a RomFS program that reads both bundled files including a Unicode path, and a startup baseline that renders an initial console frame and exits on a scripted Plus press. Each one has its own oracle document, its own reproduction guide, and a CI run ID recorded in the README's table. That is the entire list of what is proven, and it is presented as a table rather than as a percentage.

The distinction between proven and tested is the project's whole discipline, and it is drawn in a sentence worth stealing: tested, not proven. The 25-stage harness, the unit tests and the nine cross-platform CI jobs run programs and inputs written for this repository. They guard the code against regressions. They do not show that any outside program works. The README also lists what a passing result must never be: host process exit zero, a budget stop, a black frame, or a successful preparation and build must never be counted as guest compatibility success.

The README also records how much of this is preparation rather than execution. A separate document on independent homebrew corpus preparation describes trials that are selected and unrestested, and it states at the top that no external sample has been built or executed by that change and that no compatibility milestone is complete. The corpus plan warns that the selected programs share an upstream repository and a libnx ecosystem, so they are not three independent toolchain implementations. That level of self-criticism is rare in emulator projects.

What the runtime actually contains

The architecture is five layers. A loader and memory model feed AArch64 execution, which feeds kernel and service models, which feed software graphics, audio and input, which feed headless, windowed or wgpu presentation. Execution regressions and evidence hang off the CPU and service layers. The core is designed to remain useful as a systems-research platform even when a particular external program fails, because a failure with a captured guest stop reason is useful diagnostic evidence rather than a compatibility pass.

The subsystem matrix is honest about each layer's boundary. The CPU is an AArch64 interpreter plus Tier-1, Tier-2 and Tier-3 engines, with an optional Tier-4 native recompiler, and it is described as a subset of the architecture whose external correctness is not universal. Memory is a 4 KiB page MMU with per-page permissions and no DRAM timing model. The kernel layer covers threads, events, mutexes, memory and process queries needed by the test programs. Services are modelled, not implemented: sm, set:sys, am, vi, hid, fsp-srv, pl:u, time:u, time:s, nvdrv and ro:1. Graphics is a CPU rasterizer with selected GPU method models and an optional wgpu host replay, and the README says in bold that a host-rendered image is not a verified guest-rendered frame.

Lists of what is modelled rather than implemented run long, and that is the point. The Vulkan HAL is a model only: structures and SPIR-V module checks, and it does not call a Vulkan loader or driver. The upscaler is a 2 times bilinear interpolation with sharpening and is explicitly not DLSS, because there is no neural network. Shader translation is partial on both paths, and neither path is validated against a hardware driver. Sound is implemented as a 64-voice software mixer with continuous non-blocking streaming to host audio. Input is implemented through host keyboard and physical gamepads. Containers are parsed, including PFS0, NSP, HFS0, XCI, NCA3, NSO0, NRO0, NPDM and RomFS. Crypto is implemented and tested against FIPS-197 vectors, but it works only with the in-repo synthetic test key.

Four execution tiers, one of them unsafe by design

The execution ladder is the project's most reusable idea. Tier-1 is a block cache, Tier-2 is decoded blocks, Tier-3 is fused blocks, and Tier-4 is an optional native recompiler in a separate crate that owns the one unsafe boundary for native code generation and executable memory. The root crate forbids unsafe Rust entirely. That is not a stylistic preference. It means the unsafe surface of the project is one named crate with a testable boundary, and it can be excluded from a build that does not need it.

The recompiler's own contract is careful. Guest writes to translated code stop the active block and invalidate stale translations, and code-patch and differential tests cover that path. The Tier-4 engine is not used for general run workloads. The harness stage that exercises it selects it explicitly, and its host MIPS figure is informational rather than a gate. The CI coverage is also described feature by feature, including which jobs do not run the 25-stage harness, which is the kind of detail that prevents a green badge from being misread as a compatibility result.

Timing is treated the same way. Host measurements of small synthetic programs are not comparable to hardware and are not pass or fail criteria. The harness reports 27 checks across 25 stages, and each stage passes when its guest program returns the expected exit code. The stages are named for what they check: Fibonacci through a block cache, a debug SVC, a calling convention, CMIF IPC, RomFS and PCM audio, AES-CTR and threads, an NSP boot with a textured triangle, crt0 and depth, NEON and the upscaler, an XCI container boot, an NVN command buffer, audren and the Vulkan model, a service handshake, an SDK-style HLE runtime, the Tier-3 and Tier-4 benchmark, loose packages, a shared font and clock, an applet and GPU model, FP16 SASS and an NVN ring, and a tensor core MMA checked against IEEE binary16 vectors.

The provenance problem, stated in the README

The sources and porting policy opens with a sentence that tells you exactly what kind of project this is: Ounce-Core is not a clean-room project. Besides public specifications, homebrew library source, and observation of outside homebrew, it may read and port MIT-licensed emulator code from nxnative and Ryujinx to Rust, keeping their notices and recording each port. GPL emulator code, Nintendo SDK code, firmware, keys, leaked material and retail games are never used.

The known-issues section is where the candour becomes unusual. A history cleanup has been discussed and completion is not verified. The project has previously identified commits before a named point, including two specific commit hashes, as containing firmware-derived or third-party-derived byte sequences and an external-payload loader. As of October 28, 2026, a checkout confirmed one of those commits is reachable from main, from the v0.3.0 through v0.3.2 tags, and from a set of fetched pull-request refs. The README says that is a dated, limited ref check rather than an inventory of every branch, tag, fork, clone or GitHub ref. The provenance register and the sources document are drafts and have not been legally reviewed. Known source comparisons and binary composition checks remain incomplete.

There is also a security advisory in the README stating that third parties may distribute executables labelled ounce-core that contain malware, and that the only source of the project is the repository. Build from source with the standard Rust toolchain. For an experimental project with a few hundred stars, publishing a malware warning about your own name alongside an incomplete provenance audit is a decision, and it is the right one.

The retail decryption policy is enforced in the loader: decryption is restricted to synthetic test vectors, retail keys are rejected, and research binaries must be supplied as unencrypted loose directories or homebrew packages. No firmware, no system archives, no encryption keys, no retail game content, no ROMs and no dumps are distributed. The legal notice says the software is provided as is, that anyone using it is responsible for complying with the copyright and anti-circumvention laws that apply where they are, and that they should consult a lawyer before any use beyond private research.

What it will not claim

The README says the project makes no claim to run Switch 2 software, commercial software or arbitrary homebrew. The plan is to move from four outside programs to twenty, with a pre-registered oracle per program recorded in CI, pass or fail. Switch 2 homebrew is waiting on public toolchains, and the proof required is an outside program passing a pre-registered oracle in CI. The corpus milestone is not complete until an outside developer reproduces it from a clean checkout.

Version 0.4.0 is the release that resets the claims. Its title in the release notes is "honest baseline", and the summary says plainly that this release resets every public claim to what a real program has proven. It drew only five downloads by the time we checked, against 144 for v0.3.2 and 89 for v0.3.1, which is what happens when a project deletes its own marketing.

Our take: we think this is the most honest emulator-adjacent project on GitHub right now, and also the one with the messiest provenance. Both of those are visible in the same README. The pre-registered oracle discipline is a real methodological advance that other projects could adopt tomorrow. The incomplete provenance audit and the still-reachable history are reasons to treat this as research literature rather than as a tool. Those two judgements do not cancel each other out.

FAQ

Can Ounce-Core run my Switch games?
No. Per the repository README, it makes no claim to run commercial software, Switch 2 software or arbitrary homebrew. The only proven claim is that four outside open-source homebrew programs render their first frame pixel-exact.

What does pixel-exact first frame mean?
Each of the four programs has an expected frame written down before the run, and both the interpreter engine and the Tier-3 engine must match it exactly. The README says a host process exit of zero, a budget stop, a black frame or a successful build must never be counted as compatibility success.

Do I need firmware or keys?
No, and the project rejects them. Per the README, no firmware, encryption keys or retail content are distributed, retail decryption is disabled by policy, and inputs must be already-decrypted homebrew or synthetic material.

Is it a clean-room project?
No. Per the README, it is not a clean-room project. It may read and port MIT-licensed emulator code from nxnative and Ryujinx to Rust, keeping their notices and recording each port. GPL emulator code and Nintendo SDK code are never used.

What is the provenance problem?
Per the README's known issues, earlier commits contained firmware-derived or third-party-derived bytes and an external-payload loader, a public history purge is not complete, and the provenance documents are drafts that have not been legally reviewed. The README also warns that third parties may distribute malware labelled ounce-core.

Which platforms does it run on?
Per the README, macOS on Apple Silicon, Linux and Windows, on aarch64 or x86_64 hosts, built from source with Rust 1.85 or newer. GPU presentation through wgpu is optional, using Metal on macOS and Vulkan or DX12 on Windows.

Bottom Line

Ounce-Core is a research runtime with the strongest evidence discipline in the emulator space: four outside homebrew programs, each with a pre-registered first-frame oracle, each run in CI, and a README that separates tested from proven in a single sentence. Version 0.4.0 reset every public claim to what a real program had proven, and the roadmap is to go from four outside programs to twenty.

The same README admits an incomplete provenance audit, a history that still contains firmware-derived material, and a malware warning about other executables using the same name. This is not a product and it is not a compatibility layer you can use. It is a methodology paper with code attached, and the methodology is worth more than the code.

Related: Eglantine: A Two-Day-Old Switch 2 Emulator Runs Mario Kart World, Switch Emulator: Nintendo Switch Games Run on Jailbroken PS5

Sources: per the official Ounce-Core repository README, independent corpus preparation document and v0.4.0 release notes at github.com/hffgzktbcc-blip/ounce-core, all fetched in full on November 4, 2026; repository metadata (211 stars, 21 forks, 3 open issues, MIT, created October 24, 2026, language Rust) re-verified via the GitHub API on November 4, 2026.