[ANN][MAINNET] QADO - BLAKE3 (account-based L1) | Windows x64 binary

[Laheeboo]

All the info is disclosed in the original miner release post

at the comment above in "More Info"

but also here to be clear as well : https://bitcointalk.org/index.php?topic=5577419.0

it is also displayed on the GitHub page.

[detnonzero]

Qado v0.4.3 update

I have added a solo mining API to the node.

This means external miner developers can now build a miner for Qado without needing to read the Qado source code and without reimplementing consensus logic like:
- target calculation
- coinbase creation
- merkle building
- final block serialization
- P2P block submission

The node now exposes:

Code:

POST /v1/mining/job
POST /v1/mining/submit

The intended flow is simple:
1. Request a node-generated mining job
2. Scan nonces locally on CPU/GPU
3. Submit job_id + nonce + timestamp back to the node

I also added dedicated miner documentation for third-party developers, including:
- request/response formats
- PoW header layout
- timestamp and nonce offsets
- optimized fields for GPU miners
- stale job behavior and submit error reasons

So if anyone wants to build an external CUDA/OpenCL/CPU miner, the integration path is now documented and much cleaner than before.

docs: https://github.com/detnonzero/Qado/blob/main/docs/MINER_INTEGRATION.md
Download / Source: https://github.com/detnonzero/Qado
Download / Binaries: https://github.com/detnonzero/Qado/releases/latest

[Laheeboo]

Qado v0.4.3 update

I have added a solo mining API to the node.

This means external miner developers can now build a miner for Qado without needing to read the Qado source code and without reimplementing consensus logic like:
- target calculation
- coinbase creation
- merkle building
- final block serialization
- P2P block submission

The node now exposes:

Code:

POST /v1/mining/job
POST /v1/mining/submit

The intended flow is simple:
1. Request a node-generated mining job
2. Scan nonces locally on CPU/GPU
3. Submit job_id + nonce + timestamp back to the node

I also added dedicated miner documentation for third-party developers, including:
- request/response formats
- PoW header layout
- timestamp and nonce offsets
- optimized fields for GPU miners
- stale job behavior and submit error reasons

So if anyone wants to build an external CUDA/OpenCL/CPU miner, the integration path is now documented and much cleaner than before.

docs: https://github.com/detnonzero/Qado/blob/main/docs/MINER_INTEGRATION.md
Download / Source: https://github.com/detnonzero/Qado
Download / Binaries: https://github.com/detnonzero/Qado/releases/latest

Thank you so so so much you made my life much easier, Again the miner I made was out of pure hobby and fun and interest in your coin, if the wallet miner is good enough no need for a miner, specially if the speeds will match.
my whole goal was to get more speed for less electric and if that's what's happening on the main wallet then no need for external miner, but, that doesn't mean I won't spend hours testing and trying haha.

great update thank you

[Redluk77]

Hi Laheeboo, first of all thanks for the work you’ve put into LMiner, really appreciated.

I’m testing LMiner v2.0 on Windows with the latest Qado release on an RTX 5070 Ti.

LMiner starts fine, detects the GPU correctly, reads the pubkey from lminer_config.json, but then it just stays on:

“Waiting for node...”

I checked the local Qado API and it is definitely running on:
http://127.0.0.1:18080

These endpoints work fine:
- GET /v1/health -> 200 OK
- GET /v1/network -> OK
- GET /v1/tip -> OK
- GET /v1/address/<pubkey> -> OK

But when I try:
- POST /v1/mining/job

I get:
- 404 Not Found

So it looks like the node is up and reachable, but the mining endpoint LMiner is expecting doesn’t seem to be available on my side.

Do you know if:
- LMiner needs a specific Qado version,
- /v1/mining/job is no longer the correct route,
- or maybe the current Windows Qado build doesn’t expose the mining endpoint at runtime?

Thanks again for the miner and for any help.

[detnonzero]

Hi Laheeboo, first of all thanks for the work you’ve put into LMiner, really appreciated.

I’m testing LMiner v2.0 on Windows with the latest Qado release on an RTX 5070 Ti.

LMiner starts fine, detects the GPU correctly, reads the pubkey from lminer_config.json, but then it just stays on:

“Waiting for node...”

I checked the local Qado API and it is definitely running on:
http://127.0.0.1:18080

These endpoints work fine:
- GET /v1/health -> 200 OK
- GET /v1/network -> OK
- GET /v1/tip -> OK
- GET /v1/address/<pubkey> -> OK

But when I try:
- POST /v1/mining/job

I get:
- 404 Not Found

So it looks like the node is up and reachable, but the mining endpoint LMiner is expecting doesn’t seem to be available on my side.

Do you know if:
- LMiner needs a specific Qado version,
- /v1/mining/job is no longer the correct route,
- or maybe the current Windows Qado build doesn’t expose the mining endpoint at runtime?

Thanks again for the miner and for any help.

The important detail is that /v1/mining/job is a POST endpoint. If you enter the URL in a browser, that is only a GET, so that does not properly test the mining route.

On Windows, please test it directly from PowerShell like this:

Code:

$body = @{
miner = "<your_pubkey>"
} | ConvertTo-Json

Invoke-RestMethod -Method Post
-Uri "http://127.0.0.1:18080/v1/mining/job" -ContentType "application/json"
-Body $body

If the endpoint is working, you should get a JSON response with fields like:

Code:

job_id
height
prev_hash
target
timestamp
header_hex_zero_nonce
precomputed_cv
block1_base
block2
target_words

So for now I would verify the node API directly first. If PowerShell returns a mining job, then the Qado endpoint is working and you should look at LMiner compatibility separately. If PowerShell still returns 404, then the node instance you are hitting does not currently expose that route and you should download the latest binaries.

[Redluk77]

Thanks, that makes sense.

Just to clarify, I did already test it directly from PowerShell with a real POST request, not from the browser, and /v1/mining/job still returns 404.

So it seems the problem is not the request method on my side, but that the mining route is simply not exposed here.

I’m using the latest Windows Qado binary I downloaded on March 16, and these all work fine:
- /v1/health
- /v1/network
- /v1/tip
- /v1/address/<pubkey>

Only /v1/mining/job returns 404.

So would that suggest the current Windows build does not expose the mining endpoint at runtime, or is there maybe some mismatch between the documented API and the actual binary?

Just trying to understand whether I should look at Qado itself or at LMiner compatibility.

[detnonzero]

Thanks, that makes sense.

Just to clarify, I did already test it directly from PowerShell with a real POST request, not from the browser, and /v1/mining/job still returns 404.

So it seems the problem is not the request method on my side, but that the mining route is simply not exposed here.

I’m using the latest Windows Qado binary I downloaded on March 16, and these all work fine:
- /v1/health
- /v1/network
- /v1/tip
- /v1/address/<pubkey>

Only /v1/mining/job returns 404.

So would that suggest the current Windows build does not expose the mining endpoint at runtime, or is there maybe some mismatch between the documented API and the actual binary?

Just trying to understand whether I should look at Qado itself or at LMiner compatibility.

I uploaded the latest binaries today at 1:00 AM.

https://github.com/detnonzero/Qado/releases/tag/latest

[Redluk77]

Got it, thanks — that explains it.

I downloaded my current Windows binary on March 16, so I’ll grab the binaries you uploaded today and retest /v1/mining/job first from PowerShell before trying LMiner again.

If it works with the new build, then that was the issue.
If it still returns 404, I’ll report back with the exact result.

[Redluk77]

Got it, thanks — that explains it.

I downloaded my current Windows binary on March 16, so I’ll grab the binaries you uploaded today and retest /v1/mining/job first from PowerShell before trying LMiner again.

If it works with the new build, then that was the issue.
If it still returns 404, I’ll report back with the exact result.

Quick update.

With the new Qado binaries, /v1/mining/job now works correctly on my side from PowerShell and returns a valid mining job, so the old 404 issue is gone.

However, LMiner v2.0 still stays stuck on:
“Waiting for node...”

I also tested it after:
- recreating lminer_config.json from scratch
- re-entering the pubkey
- setting global_size again to 4194304

I also checked Windows TCP connections while LMiner was running, and there were no active TCP connections owned by the LMiner process at the time it was stuck on “Waiting for node...”.

So at this point it looks like Qado is exposing the mining endpoint correctly, but LMiner still isn’t moving past node detection / initialization on my setup.

Any idea what LMiner checks after /v1/mining/job, or what could keep it stuck there?

[Redluk77]

Thanks, that makes sense.

Just to clarify, I did already test it directly from PowerShell with a real POST request, not from the browser, and /v1/mining/job still returns 404.

So it seems the problem is not the request method on my side, but that the mining route is simply not exposed here.

I’m using the latest Windows Qado binary I downloaded on March 16, and these all work fine:
- /v1/health
- /v1/network
- /v1/tip
- /v1/address/<pubkey>

Only /v1/mining/job returns 404.

So would that suggest the current Windows build does not expose the mining endpoint at runtime, or is there maybe some mismatch between the documented API and the actual binary?

Just trying to understand whether I should look at Qado itself or at LMiner compatibility.

I uploaded the latest binaries today at 1:00 AM.

https://github.com/detnonzero/Qado/releases/tag/latest

Hi detnonzero, just wanted to say: great job on the new official binary.

I tested it on my RTX 5070 Ti, and the difference compared to the previous build is huge. I was getting around 3.1 GH/s before, and now I’m seeing about 10.0 GH/s after 1 hour of mining.

So this update made a very real difference in practice, not just on paper.

Power usage is definitely higher, but performance and overall efficiency both look much better now.

Really appreciate the fast update and the work you’re putting into the chain.

[Laheeboo]

Got it, thanks — that explains it.

I downloaded my current Windows binary on March 16, so I’ll grab the binaries you uploaded today and retest /v1/mining/job first from PowerShell before trying LMiner again.

If it works with the new build, then that was the issue.
If it still returns 404, I’ll report back with the exact result.

Quick update.

With the new Qado binaries, /v1/mining/job now works correctly on my side from PowerShell and returns a valid mining job, so the old 404 issue is gone.

However, LMiner v2.0 still stays stuck on:
“Waiting for node...”

I also tested it after:
- recreating lminer_config.json from scratch
- re-entering the pubkey
- setting global_size again to 4194304

I also checked Windows TCP connections while LMiner was running, and there were no active TCP connections owned by the LMiner process at the time it was stuck on “Waiting for node...”.

So at this point it looks like Qado is exposing the mining endpoint correctly, but LMiner still isn’t moving past node detection / initialization on my setup.

Any idea what LMiner checks after /v1/mining/job, or what could keep it stuck there?

Hi Redluk77

as of right now Lminer will not work with the latest wallet update as many things were changed by the dev

on the bright side, the latest wallet update has a built in miner, that is ever faster than Lminer at almost twice the speed with some electricity increase.

I am working to optimize the miner to work by itself without needing the wallet to only submit the shares to the node directly but the logic of the miner is it needs to use the wallet to send the share to the network.

Once I figure out a way to optimize everything, I will release the updated version of the miner, as well as ways to change your power draw vs speed. Yes the wallet miner is the fastest, BUT, It's running my 5090 at 600w+ at ALL times, and I don't want to burn a card that's worth more than my pc combined, so I'm trying to never go over 80~85% power, trying to reach the same speed or close to it.

Once it's done I will post an update here as well as on the miner page https://bitcointalk.org/index.php?topic=5577419.0 and trying to work at the same time on releasing a linux version of the miner so people who are renting rigs or have hive os can join this coin too.

[Redluk77]

Got it, thanks — that explains it.

I downloaded my current Windows binary on March 16, so I’ll grab the binaries you uploaded today and retest /v1/mining/job first from PowerShell before trying LMiner again.

If it works with the new build, then that was the issue.
If it still returns 404, I’ll report back with the exact result.

Quick update.

With the new Qado binaries, /v1/mining/job now works correctly on my side from PowerShell and returns a valid mining job, so the old 404 issue is gone.

However, LMiner v2.0 still stays stuck on:
“Waiting for node...”

I also tested it after:
- recreating lminer_config.json from scratch
- re-entering the pubkey
- setting global_size again to 4194304

I also checked Windows TCP connections while LMiner was running, and there were no active TCP connections owned by the LMiner process at the time it was stuck on “Waiting for node...”.

So at this point it looks like Qado is exposing the mining endpoint correctly, but LMiner still isn’t moving past node detection / initialization on my setup.

Any idea what LMiner checks after /v1/mining/job, or what could keep it stuck there?

Hi Redluk77

as of right now Lminer will not work with the latest wallet update as many things were changed by the dev

on the bright side, the latest wallet update has a built in miner, that is ever faster than Lminer at almost twice the speed with some electricity increase.

I am working to optimize the miner to work by itself without needing the wallet to only submit the shares to the node directly but the logic of the miner is it needs to use the wallet to send the share to the network.

Once I figure out a way to optimize everything, I will release the updated version of the miner, as well as ways to change your power draw vs speed. Yes the wallet miner is the fastest, BUT, It's running my 5090 at 600w+ at ALL times, and I don't want to burn a card that's worth more than my pc combined, so I'm trying to never go over 80~85% power, trying to reach the same speed or close to it.

Once it's done I will post an update here as well as on the miner page https://bitcointalk.org/index.php?topic=5577419.0 and trying to work at the same time on releasing a linux version of the miner so people who are renting rigs or have hive os can join this coin too.

Thanks, that makes sense.

That explains exactly what I’m seeing on my side.

So for now the issue is not my setup, but simply that LMiner is not compatible yet with the latest wallet update.

And yes, I can confirm the new official wallet miner is much faster now on my RTX 5070 Ti compared to the previous build.

I’ll keep an eye on your next update, especially if you manage to get close to wallet speed with lower power draw, because that could be very interesting in practice.

Thanks for the clarification and good luck with the optimization work.

[Redluk77]

Hi detnonzero, I noticed something interesting while checking my mined blocks and wanted to make sure I’m understanding it correctly.

The reason I started digging into this is that I saw one payout credited as 20.5 QADO instead of the usual 20, so I wanted to understand where that extra 0.5 came from.

Looking at the blocks around that time in the Qado wallet UI, the only two blocks credited to my miner address (72865e...) in that time window are height 8021 at 05:35:40 UTC and height 8037 at 05:50:20 UTC.

When I queried both blocks through the API, both showed:
- tx_count = 1
- the same txid
- and the same raw_tx_hex

The tx itself is the usual coinbase-style one:
- from = 0000...
- to = my address
- amount_atomic = 20000000000
- fee_atomic = 0
- nonce = 0

So my question is:
is coinbase intentionally deterministic in Qado, meaning that if the miner, reward and fee are identical, the exact same txid / raw_tx_hex can legitimately appear in multiple different blocks?

I’m asking because that seems to be what I’m seeing here, and I just want to confirm whether that is expected behavior by design, or whether I’m misreading something in the API / wallet UI.

Also, regarding the 20.5 payout, I’m trying to understand whether that extra 0.5 came from fees, from the way payouts are indexed/displayed, or from something else entirely.

Thanks again.

[detnonzero]

Hi, I checked this in the current Qado implementation.

This is not an inflation bug.

At block height 8334, the total state sum is exactly 166,680 QADO, which matches the expected supply. So no extra coins were created.

On the txid point: yes, coinbase txids are deterministic in Qado. If miner, amount, fee and nonce are identical, the same raw_tx_hex and txid can legitimately appear in different blocks. So that part is expected behavior.

For the specific address you mentioned (72865e...), the extra 0.5 QADO came from block 8075, not from 8021 or 8037. That block had tx_count = 2, so the payout there was:

20.0 subsidy + 0.5 fees = 20.5 QADO

Up to height 8334, that address had 103 coinbase payouts totaling exactly 2060.5 QADO, with no normal incoming transfers. So the balance is fully explained by mining rewards plus that one fee bonus.

Your report is still useful though, because tx lookup by txid alone can be ambiguous when the same deterministic coinbase appears in multiple blocks. I’ve noted that down and will adjust the API in the next patch to make this clearer.

Thanks for pointing it out.

[Redluk77]

Thanks, that clears it up very well.

So now it makes sense.

I appreciate the detailed explanation.

And yes, the txid-only lookup ambiguity was exactly the confusing part from the user side, so it’s great to hear you’ll make that clearer in the next patch.

Thanks again for checking it so carefully.