What the actual fee really is in the custom VNISH and PITBIT firmware.

The check was performed using AI Kimi 3.1

Anyone can do this themselves - simply by sending Kimi the firmware file with a very simple prompt.
You will get detailed information about the fee, a full algorithm for calculating the developer fee, and the way it is withheld.

VNISH - fee 3%.
The fee size is set by a remote server, and it can be changed by the developer at any time. The agent made 12 requests, and in all 12 cases the server set the fee to 3%.

Code:

VNISH DevFee Research / VNISH.NET
Research date: 2026-11-04. Network responses are dynamic and describe the state of the servers at the time of the
checks.
Summary
The examined VNISH 1.3.5 firmware images contain their own DevFee commission. The DevFee addresses
and client-side logic are hardcoded in cgminer; the fee proxy itself resides on remote VNISH/HashCore
servers, not on the ASIC.
When the DevFee pool is initialized, the code sets a starting value of 1.0. After Stratum authorization, the
remote server sends mining.fee with the parameter [3], which replaces the starting value with a target rate of 3%.
Repeated successful server responses consistently returned [3], not [2.8].
The public VNISH documentation for the standard S19/S21 build states 2.8%. This differs from the observed
server-side target rate by 0.2 percentage points.
This proves a discrepancy between the public description and the server configuration, but by itself it does
not prove deliberate deception. To conclude actual user losses, a long-term measurement of shares accepted
by the pool is required, accounting for rejected/stale and possible Refund operations.
Images Examined
VNISH S21 Pro
File: vnishnet-s21pro-aml-nand-v1.3.5.tar.gz
SHA-256: 93ac154cd36e4adb0ea3b52c552a1ac2bc8d39a2e2d804de3bf61d662bca9fbd
fw_version: 1.3.5
build_name: vnishnet
build_time: 2026-07-30 13:26:45
build_uuid: 1da1d324-e358-4b6e-abb2-ccdff5e753b0
ramdisk: vnish/ramdisk
cgminer SHA-256: 2f89042e35b953feba2fa91c6a0f1d053e5e177d0bf89ed15331929e4684ce92
Partner VNISH.NET S21
User-provided file: vnishnet-s21-aml-nand-v1.3.5.tar.gz
SHA-256: 4f6e32b14402ad4a6f6e6fc7c285cd62450892b98995b68c82ce60b04fc0b02b
fw_version: 1.3.5
build_name: vnishnet
build_time: 2026-07-30 13:24:10
build_uuid: d27d5df1-0476-4d32-bcd4-ce3ce5feae34
ramdisk after unpacking: vnish/partner_s21_v1.3.5/ramdisk
cgminer SHA-256: 0bc618611f53fc79bb95fe0ef2bb8c5c1750164590f859fea669df464d58a068
In these two images, dashd, hwscan and updater are byte-for-byte identical. The UI, OpenAPI, init scripts
and components.json also match. Component versions match, including cgminer_btm=9f9b64d5. cgminer
differs in obfuscation but uses the same DevFee logic and the same network strings.
What Is Hardcoded in cgminer
The main file analyzed: vnish/ramdisk/usr/bin/cgminer.
The strings reside in the writable .data section and are hidden by XOR obfuscation. The decryption code
confirms the keys and string lengths.
Value File Offset XOR Key
mining.fee 0x5c03aa 0xb7
devfee.anthill.farm 0x5c1846 0x20
devfee.hashcore.com 0x5c185a 0x04
devfee.vnish.com 0x5c186e 0x5a
:7070 0x5c187f 0x8b
:7080 0x5c1885 0x0d
Pointers to the three domains are located in a table at addresses 0x5db2b4–0x5db2bc.
The partner cgminer uses different XOR keys, but the same domains and mining.fee are recovered. No
separate strings partner, partner_id, hotel, cashback, referral, or a separate partner pool were found.
Fee-proxy Is Not in the Image
The ramdisk contains no separate server-side fee-proxy process. The image contains only the DevFee client
in cgminer.
At the time of the check, the domains resolved to the following addresses:
185.125.219.145
23.183.245.194
45.12.18.110
devfee.vnish.com, devfee.anthill.farm and devfee.hashcore.com use the same infrastructure. devfee.vnish.net
was not found in DNS.
Server TLS certificate:
subject: CN = fee-proxy-v2
issuer: CN = HashCore Root CA
SHA-256:
7C:38:25:E0:71:DC:3A:81:0B:55:5E:ED:63:67:98:89:B1:98:DF:26:BC:0C:85:2F:A1:2F:23:79:
This confirms that fee-proxy-v2 is a remote server-side component of VNISH/HashCore.
How the Firmware Receives the Percentage and Work
Stratum over TLS is used:
1. cgminer selects a hardcoded DevFee endpoint.
2. It sends mining.subscribe.
3. It sends mining.authorize with a DevFee worker.
4. The server returns the custom extension mining.fee.
5. The server sends mining.set_extranonce, mining.set_difficulty and mining.notify.
6. The scheduler directs part of the ASIC's work to the DevFee pool.
7. In normal operation, results are sent via mining.submit.
My checks were performed only up to receiving mining.fee; no shares or computation results were
submitted.
Example of an actual exchange:
{"id":1,"method":"mining.subscribe","params":["xminer/1.0"]}
{"id":2,"method":"mining.authorize","params":["test","x"]}
Responses:
{"id":1,"result":[[["mining.set_difficulty","1"],["mining.notify","1"]],"00",8]}
{"id":2,"result":true}
{"method":"mining.fee","params":[3]}
After that, the server issued BTC jobs via mining.notify. The captured jobs included ViaBTC
infrastructure. The recipient of the commission reward is determined by the coinbase data, which is formed
by the remote server, not by the ASIC's user configuration.
Starting 1% and Server 3%
In S21 Pro, when the DevFee pool is created, the double value 1.0 is written at virtual addresses 0x2568c–
0x256a0.
The formula for target DevFee work found:
target_devfee = pool_value_0xa0 * total_work / 100
It is located near 0x25fa8–0x25ff0.
The mining.fee handler near 0x19470–0x194c8 reads the JSON array and updates the pool parameters.
The first element of the array sets the new value. Therefore, the starting 1% is not the final rate: after the
response [3], the target rate becomes 3%.
The API field fee_percent is computed separately from the actually accounted work:
fee_percent = 100 * accounted_devfee_work / total_work
Its instantaneous value may deviate from the target 3%.
Partner VNISH.NET
The official VNISH.NET page describes the partner program as:
personal commission rates;
fee proxying to any pool of the partner;
1% cashback.
The image analysis shows that:
the shared DevFee fee-proxy is used in both the regular and the partner build;
the separate partner rate and reward distribution are determined by the server-side configuration;
the Refund pool type is present, but its connection to partner cashback is not proven;
hotelfee.json is absent from the image; S13restore:36-37 only copies it if it already exists;
partner.anthill.farm is used for release notes, not for the commission;
fee.anthill.farm:443 relates to the network configuration of dashd, but contains no proven logic for
assigning the partner percentage.
Workers test, hashcore and vnishnet all received the same [3]. This does not rule out different handling of a
real partner worker or a registered device.
Thus, 3% is the observed target commission of the device. The share of VNISH and the share of the partner
within this commission cannot be determined from the image.
Checking All Servers with the Script
Script: re/vnish-devfee/check_vnish_fee.py.
It uses only the Python standard library, verifies the SHA-256 of the certificate, and does not submit shares.
By default, all six combinations are queried:
devfee.vnish.com:7070;
devfee.vnish.com:7080;
devfee.anthill.farm:7070;
devfee.anthill.farm:7080;
devfee.hashcore.com:7070;
devfee.hashcore.com:7080.
For each domain, the script connects separately to every DNS address, preserving the original domain in
SNI. With three DNS addresses, this makes 18 Stratum connections. Both successful responses and errors per
IP are included in the summary.
Run:
python3 re/vnish-devfee/check_vnish_fee.py
One domain and all of its IPs:
python3 re/vnish-devfee/check_vnish_fee.py devfee.vnish.com --port 7080
Additional options:
python3 re/vnish-devfee/check_vnish_fee.py --verbose
python3 re/vnish-devfee/check_vnish_fee.py --worker hashcore
python3 re/vnish-devfee/check_vnish_fee.py --fingerprint "AA:BB:CC:..."
python3 re/vnish-devfee/check_vnish_fee.py --no-pin
Results of repeated checks:
successful mining.fee responses consistently contained [3];
[3] was received on both ports of devfee.vnish.com;
[3] was also received via the aliases devfee.anthill.farm and devfee.hashcore.com;
some connections ended in a timeout before the mining.subscribe response; this is an availability
issue of a specific connection/node, not a different rate.
Result of the Last Check
Check time: 2026-11-04 10:04 UTC. Command:
python3 re/vnish-devfee/check_vnish_fee.py --timeout 10
The script made a separate connection to each IP with the original domain in SNI:
Endpoint 185.125.219.145 23.183.245.194 45.12.18.110
devfee.vnish.com:7070 [3] [3] timeout
devfee.vnish.com:7080 [3] [3] timeout
devfee.anthill.farm:7070 [3] [3] timeout
devfee.anthill.farm:7080 [3] [3] timeout
devfee.hashcore.com:7070 [3] [3] timeout
devfee.hashcore.com:7080 [3] [3] timeout
Total:
12 successful Stratum handshakes, and all of them received mining.fee with the value [3];
6 connections to 45.12.18.110 timed out before a response was received;
no differences in commission were found between domains, ports, and responding IPs;
the script's exit code was 1, because one of the three nodes was unavailable; this is reflected in the
summary and not hidden.
Claimed 2.8% vs. Observed 3%
The official article VNISH Dev Fee Explained states for the standard build:
2.8% on Antminer S19/S21;
2% on L7/L9.
For the examined S21/S21 Pro configuration, the server-side target rate is 3%:
observed rate − stated rate = 3.0% − 2.8% = 0.2 percentage points
If this rate is fully realized without compensation, on a hypothetical 100 TH/s the additional difference
amounts to 0.2 TH/s of commission hashrate compared to the stated 2.8%.
Can This Be Called Deception
Confirmed facts:
the publicly stated standard rate is 2.8%;
the server repeatedly sets the target rate to 3%;
the difference is 0.2 percentage points;
the script allows anyone to independently reproduce the response.
Limitations:
the server can change the rate dynamically;
the documentation may describe a different version or configuration;
partner terms may differ from the standard ones;
the short-term fee_percent is not equal to the actual share of accepted shares over a long period;
the effect of rejected/stale and possible Refund operations was not measured in this check;
the developers' intent cannot be established from the network response.
Therefore, the correct conclusion is: the stated 2.8% does not match the observed server-side target rate of
3% for the examined configuration. If Refund or another compensation does not return the difference, users
pay a commission above the stated one. However, based on the available data, it cannot be called proven
deliberate fraud.
To finally verify the actual commission, one should compare, over a long period, accepted shares by pool
type (UserPool, DevFee and Refund) via the device API, while simultaneously recording rejected/stale and
all mining.fee messages.

Checking the 10% Penalty
Multiplications of the hashrate by 0.9 were found in cgminer at addresses 0xc815c and 0xc9308. This
confirms the existence of the 10% adjustment, but does not prove that it is enabled specifically when DevFee
is unavailable.
No direct branch offline -> fee=10 was found. Other constants 10.0 relate to timeouts or the rejectedshares threshold.
The public VNISH description claims that the protection mode "burns" 10% of hashrate when fee servers are
blocked, rather than paying 10% to the developer: see the Bits.Media discussion. For the examined image,
this condition requires a separate dynamic check on a device.
Conclusion
Technically confirmed:
DevFee is implemented via a remote Stratum fee-proxy;
the hardcoded starting rate is 1%;
the current server-side target rate in successful checks is 3%;
the partner share is determined by the server-side configuration;
the public 2.8% differs from the observed 3%;
deliberate deception and the exact actual share of accepted shares require a separate long-term
measurement.

PITBIT - fee 3%.
The fee logic and size are hardcoded directly into the firmware. Out of a pool of 1000 solutions, 30 are sent to the developer(every 33rd solution).

Code:

PITBIT S21 Pro: Developer Fee Analysis
Date of analysis: 2026-11-04.
1. Subject of Research
File: Ant_S21Pro_Aml_PitBit_20260909_160337_v90__full.zip
Archive SHA-256: ddcd833f78e50545bfcf610625ef4af169781e31a725eb5e7ce5c9aff0dfcefc
According to firmware_info.json :
model: Antminer S21 Pro;
control board: Amlogic;
partner: PitBit;
delivery type: full/public;
base version: 90;
package build date: 2026-09-09 16:03:37.
Main miner analyzed: rootfs/usr/sbin/incm .
Version string in the binary:
[C087] incm miner C087 2026.08.26 21:03 (0ccf28be)
Reference hashes:
incm: 76afb79a4a5cd6d004e78871b3e56eccb79865d8083345c71d703b72b62b30ee;
incmm.conf: bce4fa9228c433c6629e3a9b08783a4a610aff8d8e87f08ac5209817c62ce175.
Both files were extracted byte-for-byte from ramdisk.cpio and verified by SHA-256 against the
analyzed copies. Thus, the conclusions apply precisely to the submitted image, not to another version of
PITBIT.
Method: static analysis of the configuration, strings, symbol table, and ARM Thumb disassembly. No runs
on physical ASIC hardware and no live Stratum traffic capture were performed.
2. Summary
The nominal developer fee in this firmware is 3.0% of the total planned work volume.
Scheduler cycle:
970 jobs to the main pool + 30 dev fee jobs = 1000 jobs
Therefore:
30 / 1000 = 0.03 = 3.0%
PITBIT S21 Pro: Developer Fee Analysis
Relative to user jobs only, the ratio is 30 / 970 ≈ 3.093%, but the dev fee share of the total volume remains
exactly 3%.
This is not timer-based pool switching and not interception of every thirtieth nonce. The fee is
implemented by selecting the work source for the ASIC and sending shares to separate developer Stratum
endpoints.
The nominal time equivalent is about 43.2 minutes per day; however, the actual mechanism is tied to jobs,
not wall-clock time.

3. Miner Startup and Reading the Parameter
The standard watchdog starts the miner with the command:
nohup incm mine --confpath=/etc/incmm.conf &
Source: re/pitbit/strings/iwatchdog.txt:1833 .
In the configuration rootfs/etc/incmm.conf , the following is set:
[mining]
fee=30
Location: pitbit/rootfs/etc/incmm.conf:87-98 .
The configuration parsing code reads the fee key from the mining section, converts it to an integer, and
limits the range to 0…1000.
Disassembly evidence:
0x935dc : loading the string fee ;
0x935de : loading the string mining ;
0x935ee–0x935f4 : clamping to the value 0x3e8 = 1000 ;
0x935fa : storing the result as a 16-bit value;
0x93610 : log string INCM fee detected. fee(1/1000)= .
File with annotated disassembly: re/pitbit/config_parse_2.asm:27-49 .
Thus, the units of the parameter are directly designated by the binary itself as thousandths: fee=30 means
30‰, that is, 3%.
3.1. Locally Set Percentage and External Data
The base fee percentage is set locally inside the firmware; it is not computed by a remote PITBIT server or
a monitoring panel. At startup, incm reads /etc/incmm.conf , gets fee=30 , and independently builds a
local scheduler of 970 user jobs and 30 dev-fee jobs per 1000 jobs.
At the same time, the expression “hardcoded” requires clarification:
the value is not an immutable constant in machine code — it is placed in an INI file inside the image;
for the standard 3% fee, no percentage needs to be fetched from the internet at every startup or during
mining;
local modification of the configuration or its replacement by a firmware update is possible;
it is impossible to fully rule out separate remote configuration management functions, but in the
analyzed standard mechanism no remote download of the fee percentage was found and none is
needed.
The mining jobs themselves do come from outside. Dev-fee pools send Stratum work and difficulty, and
the miner returns the found shares. Roles are therefore distributed as follows:
the nominal 3% and the 30/1000 cycle are set by the local firmware;
work for dev-fee jobs comes from external servers;
pool accepted/rejected responses and difficulty changes affect the actual accepted-ratio, but not the INI
value fee=30 ;
when external dev-fee servers are unavailable, a fallback to other work sources is used, after which the
user-share decimation described below may engage.
In other words, the percentage is in the firmware, but fee mining is not autonomous: external Stratum
connections are required to obtain work and send fee shares.

4. Exact Fee Collection Mechanism
4.1. Table of 1000 Work Sources
Function: incm::coins::c_job_provider::configure_fee(int, int) — address 0xe0d8d .
Its actions:
1. Fills an array of size 0x3e8 = 1000 bytes with the value 1 — main pool.
2. With a non-zero dev fee, computes floor(1000 / fee) .
3. Evenly replaces exactly fee elements with the value 2 — dev fee.
4. If a separate hotel fee is set, similarly adds source 3 .
5. Handles collisions so that the number of assigned slots matches the parameter.
Disassembly: re/pitbit/configure_fee.asm .
At fee=30 :
step = floor(1000 / 30) = 33
Dev-fee slots:
0, 33, 66, 99, 132, 165, 198, 231, 264, 297,
330, 363, 396, 429, 462, 495, 528, 561, 594, 627,
660, 693, 726, 759, 792, 825, 858, 891, 924, 957
Total 30 slots. The remaining 970 slots belong to the main pool.
4.2. Using the Table During Operation
Function: incm::coins::c_job_provider::get_next_job_source() — address 0xe7f35 .
It:
reads the source from the table at the current index;
increments the index and wraps it modulo 1000;
selects the source if it has work;
if the selected source has no work, uses another available source via fallback.
Disassembly: re/pitbit/get_next_job_source.asm .
Therefore, when all sources are available, the repeating cycle is exactly:
970 main + 30 devfee per 1000 job selections
configure_fee() is called when the miner is created and when the configuration is updated, not on a
periodic timer.
4.3. What Exactly Goes to the Developer
For dev-fee jobs, the miner uses a separate Stratum source. Found shares are sent to the dev-fee endpoint
with the worker devfee .
This is not merely a declared deduction from statistics: the firmware really allocates part of the ASIC’s
work to separate developer jobs.
At the same time, 3% is the share of planned jobs, not a guaranteed percentage of each individual pool
payout. The actual accepted-ratio is affected by:
job lifetime and job changes;
different pool difficulties;
accepted/rejected/stale shares;
availability of dev-fee jobs and connections;
fallback when the selected source has no work.

5. Dev-Fee Endpoints for SHA-256
incmm.conf contains 24 backup configurations pool_devfee … pool_devfee24 .
In all of them:
user=devfee
password=x
Full list:
Configuration Address
pool_devfee 62.138.16.209:6767
pool_devfee2 62.138.16.209:7878
pool_devfee3 62.138.16.209:8989
pool_devfee4 62.204.42.79:3311
pool_devfee5 185.162.9.69:3322
pool_devfee6 185.162.9.69:3344
pool_devfee7 93.88.74.248:3355
pool_devfee8 62.204.42.79:3366
pool_devfee9 62.204.42.79:3377
pool_devfee10 93.88.74.248:3388
pool_devfee11 62.204.42.79:3399
pool_devfee12 148.227.170.13:8000
pool_devfee13 185.162.11.24:8001
pool_devfee14 93.88.74.65:8002
pool_devfee15 93.88.74.65:8003
pool_devfee16 148.227.170.13:8004
pool_devfee17 93.88.74.65:8005
pool_devfee18 103.65.231.15:5656
pool_devfee19 103.65.231.15:5657
pool_devfee20 138.226.220.11:5658
pool_devfee21 138.226.220.11:5659
pool_devfee22 103.65.231.15:5660
pool_devfee23 103.65.231.22:5661
pool_devfee24 138.226.220.11:5662
Unique IP addresses:
62.138.16.209
62.204.42.79
185.162.9.69
93.88.74.248
148.227.170.13
185.162.11.24
93.88.74.65
103.65.231.15
103.65.231.22
138.226.220.11
Location in the configuration: pitbit/rootfs/etc/incmm.conf:109-251 .
These are backup connection options, not 24 separate fees. Their values are not summed.
The sections pool_devfee_scrypt , pool_devfee_nervos , pool_devfee_kheavyhash , and
pool_devfee_x11d are intended for other algorithms and are not added to the S21 Pro SHA-256 fee.

6. Measuring the Actual Fee Ratio
The firmware separately tracks the difficulty accepted by pools, not just the share count.
For a window with accepted difficulty M for the main pool, F for dev fee, and H for hotel fee, the
calculation is as follows:
main_ratio = floor(1000 × M / (M + F + H))
dev_ratio = floor(1000 × F / (M + F + H))
hotel_ratio = floor(1000 × H / (M + F + H))
Without hotel fee:
dev_ratio = floor(1000 × F / (M + F))
The code is located in c_fee_logic::update_accepted_difficulty() at address 0xb1965 ; the
division is performed around 0xb1abc–0xb1b34 .
Supported:
short-term window of about one minute;
rolling window of approximately 180 counter snapshots, roughly 180 minutes;
before the ring buffer fills — effectively the period since reset.
The maximum of the short-term and rolling dev-fee ratios is used for control.
Therefore, comparing the fee by accepted share count alone is incorrect: each share adds its own difficulty
at the time of submission to the counter.

7. Behavior When Dev Fee Is Unavailable
The firmware has a startup check delay of up to 600000 ms (10 minutes); frequency initialization may
finish it earlier.
After the startup period, c_fee_logic::calc_state() at address 0xb15b5 uses the condition:
allowed = (nominal_fee == 0) ||
(rolling_dev_ratio > floor(nominal_fee / 3))
At fee=30 , the threshold is 10‰, that is, 1%.
Miner::check_fee_stats() additionally takes the presence of a dev-fee connection into account. If
simultaneously:
the rolling dev-fee ratio does not exceed 1%; and
no dev-fee connection exists,
then user-share decimation is enabled.
Function ChainMiner::is_need_decimate_share() at address 0xa9665 :
always passes dev-fee shares;
for other sources, discards every tenth valid share before submission.
Disassembly: re/pitbit/is_need_decimate_share.asm .
This is a penalty mode upon loss of dev fee, not an additional permanent fee and not a proven ASIC
frequency reduction. Restoration of the dev-fee connection or the rolling ratio rising above the threshold
stops the decimation.
Discarded user shares do not reach the pool’s accepted-difficulty counters.

8. Hotel Fee and Additional Parameters
In the factory rootfs/etc/cgminer.conf.factory , the parameters hotelfeepercent and
poolshotelfee are not set. Therefore, in the analyzed factory configuration the additional hotel fee is
not active.
The parameter period_boost_coeff is also not set in the shipped incmm.conf ; after parsing, the
default value 1 applies. There is no initial multiplier to the stated 3%.
The code contains the fields hide_devfee and fee_counters_visible , but they are not needed for
conclusions about the fee size and mechanism. The mere presence of these names should not be
interpreted as proof of permanent hiding of pools in the API.

9. Discrepancy with the PITBIT Website
The current PITBIT ECOSYSTEM page states a developer fee of 2.75% as of the analysis date.
This does not match the parameter of the submitted September image. For the analyzed binary, the
confirmed values are:
incmm.conf: fee=30
units: 1/1000
table: 30 dev-fee slots out of 1000
result: 3.0%
The website may describe other current commercial terms or versions, but it does not change the contents
of this image.

10. Key Evidence
Fee parameter: pitbit/rootfs/etc/incmm.conf:98 .
SHA-256 dev-fee pools: pitbit/rootfs/etc/incmm.conf:109-251 .
Parsing of fee and the fee(1/1000) designation: re/pitbit/config_parse_2.asm:27-49 .
Construction of the 1000-source table: re/pitbit/configure_fee.asm .
Cyclic source selection: re/pitbit/get_next_job_source.asm .
Decimation of non-dev-fee shares: re/pitbit/is_need_decimate_share.asm .
Miner launch command: re/pitbit/strings/iwatchdog.txt:1833 .
Symbol table: re/pitbit/incm.nm.txt .
Final Answer
The submitted PITBIT firmware for the S21 Pro nominally charges 3% of work through a deterministic
cycle of 30 dev-fee jobs per 1000 jobs.
The user share is nominally 97%. The actual share of accepted difficulty may differ over short intervals,
and upon loss of the dev-fee connection with a low rolling fee ratio, the firmware additionally discards
every tenth non-dev-fee share.