SRBMiner-MULTI: one binary that mines four algorithms across CPU and three GPU vendors

Four device classes, and a table that reads like a compatibility matrix

SRBMiner-MULTI is a cryptocurrency miner supporting AMD, NVIDIA and Intel GPUs, as well as CPU mining, and the headline claim is that it can mine up to four different algorithms or coins at the same time.

The single most informative thing in the README is the algorithm table, because each row pairs a percentage figure with a set of device letters and an algorithm name. The letters are defined in the ALGORITHMS section: C for CPU, A for AMD GPU, N for NVIDIA GPU, and I for Intel GPU. A row therefore reads as a statement about which hardware can run which algorithm.

[0.85%]   [ C  A  -  - ]   argon2d_16000
[1.00%]   [ -  A  N  I ]   autolykos2
[2.00%]   [ -  A  N  I ]   blake3_an
[0.65%]   [ -  A  N  I ]   etchash
[0.85%]   [ C  A  N  - ]   lyra2v2_webchain

Two things are visible in those five rows. The CPU-only algorithms, the ones marked C and nothing else, are a distinct group, and they are dominated by the yespower family and the randomx and random variants, with cpupower, flex, mike, minotaurx, ghostrider and panthera among them. The GPU rows carry three or four device letters, which is the point of the tool, since an algorithm that works on an AMD card, an NVIDIA card and an Intel card can be run across a mixed machine.

The percentages in the left column are per algorithm figures, and they vary, which tells you the table is not a static label but something that shifts with the release. The row for argon2id_exfer reads 3.00 percent, xhash reads 3.00 percent, and yespowerurx reads 0.00 percent, which is a strange value to publish and a hint that the column reflects some measured quantity the author tracks rather than a constant.

Dual mining, which is the part that distinguishes this miner

Mining two algorithms on the same device at the same time is the feature that sets this tool apart from a single-coin miner, and the README gives the supported pairs explicitly.

- `fishhash` + `qhash`
- `fishhash` + `blake3_decred`
- `autolykos2` + `qhash`
- `autolykos2` + `blake3_decred`
- `autolykos2` + `heavyhash`
- `etchash` + `blake3_decred`
- `etchash` + `heavyhash`
- `ethash` + `blake3_decred`
- `ethash` + `heavyhash`
- `xhash` + `qhash`
- `xhash` + `blake3_decred`

The pattern in that list is worth reading rather than scanning. Every pair combines a primary algorithm with a secondary, and the second member of each pair is drawn from a small set, with qhash, blake3_decred and heavyhash doing most of the work. blake3_decred appears with fishhash, autolykos2, etchash, ethash and xhash, and heavyhash appears with autolykos2, etchash and ethash.

That clustering suggests the second algorithm is chosen for what the first one leaves idle on the hardware, rather than for a shared mining path. A card that is fully occupied by a memory or compute bound algorithm still has a second resource that is underused, and the second job is a way to fill it. That is also why the pairs are enumerated rather than claimed as a general capability, and why the list is finite.

There is a further category below the list. randomepic can be combined with any algorithm, and progpow_epic can be combined with any algorithm, which the README lists separately under an Additionally heading. Those two are treated as general-purpose companions rather than as members of specific pairs, which is a different contract from the enumerated list and worth knowing about before you assume any combination will work.

GPU support, and what the hardware list does not cover

The supported hardware section is organised by vendor, and the lists are generational rather than model-by-model.

For AMD, the list runs from RX 9xxx and RX 7xxx down through RX 6xxx and RX 5xxx, includes the VEGA parts in their 56, 64, FE and VII forms, then the older RX 470, 480, 570, 580 and 590 cards, and the BC-250 mining card.

For NVIDIA it is architecture names rather than chips: Blackwell, Hopper, Ada Lovelace, Ampere, Turing and Pascal. That covers the current generation back to the cards that launched with Pascal, and it means a card from any of those generations is in scope for the algorithms that support N.

For Intel the list is short: Battlemage and Alchemist, which are the Arc generations. Intel is the newest of the three to appear in a multi-vendor miner, and the algorithm list shows how much of it is shared with the other two: the GPU rows that carry A, N and I together are the ones where the newest Arc hardware can contribute.

The limit of this section is that it names hardware, not configuration. There is nothing in the README about clock, power limit, undervolting, temperature targets or driver versions, all of which are the settings that determine whether a card mines well on a given algorithm. The parameters that control that behaviour are presumably in the Parameters file in the repository root, but its contents are not part of what the README shows, so a reader has to open the file or the example configuration to learn the option names.

A repository with two files and a proprietary binary underneath

The repository layout is unusually small for a project of this kind. The top level holds Parameters, README.md and examples.md, and there is no source tree.

That is the single most important fact about this project and it is stated in the licence rather than left to inference. The software may be used only for lawful cryptocurrency mining on hardware or systems that you own or are authorized to use, and the user is stated to be solely responsible for complying with all applicable laws, regulations, network rules and third-party terms.

Then the proprietary part. All embedded or precompiled GPU binaries and machine code distributed with SRBMiner-MULTI are proprietary, and they may be executed only as part of an official or otherwise expressly authorized release. Extracting, copying, modifying, reverse engineering, decompiling, disassembling, redistributing, sublicensing, selling, publishing, incorporating into another product or otherwise using these binaries without prior written permission from the copyright holder is prohibited, except where applicable law provides otherwise. Third-party components remain subject to their respective licenses.

So the GitHub repository is a distribution point and a documentation site, not an open source project. The release list confirms the rhythm: 3.7.8 published on 2026-10-19, 3.7.7 the day before, and 3.7.6 on 2026-10-14, with the last push on 2026-10-19. The primary language is recorded as unknown, which is consistent with a repository that contains no code.

The licence also disclaims everything in the usual way, with the software provided as is, without warranty of any kind, express or implied, and the author not liable for any claim, damages or other liability arising out of the software or its use.

Where to get it, and what support looks like

There is no installation instruction in the README, and that is not an oversight. The DOWNLOAD section points at two places, the official website with a download page and the GitHub repository itself, and both lead to prebuilt releases rather than to a build from source.

That means the first-run experience for this project is: download a build for your platform, extract it, point it at a pool and a wallet, and start it. There is no package manager entry, no container image described in the README, and no compile step available to a user, because the code is not published.

The examples.md file in the repository root and the Parameters directory are therefore the practical documentation, and the README's own instruction to read them is doing the work that a usage section would otherwise do for an open source project. A user who wants to know the option names has to read the example configuration, and a user who wants to know the shape of a run has to read the example.

Support is offered through two channels, a Discord server and a BitcoinTalk thread with a topic identifier. Both are the usual venues for this category of software, and the BitcoinTalk thread in particular has the character of a running log of version notes and user reports rather than a support queue.

One practical thing to note when picking a build: the binaries are version specific and the licence ties execution to an official or expressly authorized release. An older binary from a previous tag is still tied to the release it came from, and the algorithm support in the table changes between versions, so a build from several weeks back may not support the coin you want to switch to.

Against a single coin miner and against a different hardware mix

The realistic alternative is not another multi-algorithm miner in the abstract, it is the choice a solo operator faces in practice: one miner per coin, or one miner per device.

A single algorithm miner is simpler in every way that matters for predictability. One algorithm, one set of parameters, one thing to tune, and a performance figure that means the same thing every run. The cost is that switching coins means switching software, and that a card which is good at one algorithm is idle or underused for another.

The approach here is different in kind. Because the same binary knows how to drive CPU, AMD, NVIDIA and Intel silicon, a machine with a mixed set of cards can point the ones that suit an algorithm at it and leave the others on a second job, and the dual mining pairs let a single device run two algorithms concurrently. For an operator whose hardware is heterogeneous, that flexibility is the whole argument.

Against building the miner yourself, the comparison is not close and should not be framed as if it were. Writing a GPU miner means writing a kernel for a specific algorithm, tuning it for a specific architecture, and maintaining that as new algorithms and new hardware appear. This project does that work commercially and sells the result.

The honest boundary is between capability and transparency. This miner will run algorithms the open source alternatives will not, on hardware the open source alternatives do not support well, and it will do so without a rebuild. What it will not do is let you read what it is doing, patch it when a coin changes its algorithm, or run it in a build pipeline you control. For an operator who treats the miner as a black box, that is a good trade. For anyone who needs to know why a share was rejected, it is not a trade at all.

Editorial conclusion

SRBMiner-MULTI fits a solo operator who wants one binary that covers CPU, AMD, NVIDIA and Intel silicon and can move between coins without rebuilding anything, and it does not fit a developer who needs to read or patch the miner, because the shipped GPU binaries are proprietary and the licence forbids reverse engineering, decompiling and redistribution. Before running it, check the release history, since the tags move quickly with versions published on consecutive days, and confirm that the algorithms you intend to mine appear in the current README with the device letters you expect, since the support matrix changes with every release and the bundled binaries are version specific.

Frequently asked questions

Official sources

1. doktor83/SRBMiner-Multi on GitHub
2. Issues
3. Project website
4. README
5. Releases