The problem Mining Pools solves

The problem it solves

When two or more people pool mining hardware, the month ends with a spreadsheet and an argument: who used more electricity, who actually contributed, and what happens when one rig was off for two days. Someone has to do the math, and everyone else has to trust it.

HashPool turns that argument into verifiable arithmetic. Small groups (friends, home-hosting collectives, small teams co-owning rigs) can split revenue, electricity costs and a maintenance fund fairly, without trusting any single person or server.

How it makes the task easier and safer

• Fair by construction: the split weighs effective hashrate × uptime, not declared hardware. A partner whose rig is off 2 of 7 days drops from 33.33% to 26.31% of the revenue, and does not pay for electricity they did not use.
• Verified on-chain, not just calculated: the PoolSplitter contract refuses to pay unless the payout lines add up to the exact wei sent, every recipient is on an allowlist, and the maintenance floor is met.
• A compromised server cannot steal: funds live in a Gnosis Safe multisig, so even an attacker with full control of the calculation server cannot redirect a single wei to their own address.
• Auditable by anyone: each settlement anchors the hash of the raw telemetry on-chain, so any partner can recompute the split and check they were paid what they were owed.
• One flow: compute, preview, sign with your wallet, and settle in a single atomic transaction.

Status: live on HSKChain Testnet. Hardware telemetry is simulated; the split engine, EIP-712 multisig signing and the contracts are real and tested (93 contract tests, 142 engine tests).

Challenges we ran into

Challenges I ran into

1. The wallet would not switch to HSKChain ("could not coalesce error").
Connecting a wallet failed on the very first step. The chain-switch code already handled error 4902 ("unknown chain"), but ethers wraps provider errors, so the original code ended up nested instead of at the root and the check never fired. We now search for the code in every place different wallets leave it, try to add the chain on any failure that is not the user rejecting the request, re-request the switch (some wallets register a chain but stay put), and poll eth_chainId instead of trusting ethers' cached network. Then we covered all of it with simulated wallet providers so it is a test, not something we only catch with a real wallet in hand.

2. Partners signing a hash the Safe would not recognize.
Safe's own app does not cover every chain, so we built the transaction and EIP-712 signing ourselves. A single wrong field order or unsorted signatures gives a valid-looking signature that only fails at execution. We generated a fixture from the real Safe deployed on HSKChain, compare our hash against it in tests, and the UI compares it against the contract's getTransactionHash before letting anyone sign.

3. One wei of rounding can revert an entire settlement.
The contract requires the payouts to sum exactly to the value sent, and the maintenance reserve to reach a rounded-down floor. Floating point was out of the question, so the whole engine uses bigint, replicates the contract's rounding exactly, and assigns the division remainder by largest remainder, deterministically.

4. x402 with no facilitator on HSKChain.
There is no public facilitator, so our server verifies and settles payments itself. That meant checking every field of each authorization, blocking replays, and checking the payer's balance first, because anyone could otherwise sign valid payments from empty accounts and make us burn gas on failed settlements.

5. A demo that was correct but misleading.
With a tariff sized for a larger gross, electricity swallowed the whole period and partners received zero. That is a valid result, but a bad demo. We recalibrated the defaults against the treasury's real balance so the split stays readable.