PPS is short for "pay-per-share" reward system. This means that the miner will receive a reward (get paid) for each valid contributed share. There are some other proportional reward systems, where not all miners who contribute get paid, but NiceHash only uses PPS.
The NiceHash stratum engine implements an innovative algorithm, which detects the shares' validity and the pool's stability. Our goal is for the providers to be 100% paid for all valid work that their rigs produce (just as using any ordinary pool or multipool) and buyers only pay 100% for valid work that has been submitted to buyers' pools (just as it would be using its own rigs).
When a seller submits their work (a share) to NiceHash, it is validated by our stratum engine and validator.
A) If a share is validated by our engine, but is rejected by the buyer's pool (by stratum protocol definition), this means that there is something wrong with the pool (whether it's misconfigured, using the wrong algorithm, or has temporary micro issues) and the provider's work was valid. In this case, the provider gets paid for the work they provided. So, in this case, it is the buyer's responsibility to switch to other pools. However, if the provider's rig is misconfigured and is producing some (not necessarily all) invalid shares, these shares are detected by our engine and for those shares, the provider doesn't get paid (and the buyer doesn't pay for them), because it's the provider's responsibility to provide properly configured and stable mining rigs. This kind of bad shares is usually produced by over-clocked/overheated/misconfigured rigs (there are usually 0% of this kind of invalid shares for good/normal configured rigs and approx. 1-5% of this kind of invalid shares for bad configured rigs).
B) Our engine additionally checks the responsiveness of the buyer's pool. When a buyer's pool becomes unresponsive (pool being DDoSed, pool is having performance issues, etc.), the engine immediately disconnects this pool, deactivates the buyer's order and reroutes the work to other pools/orders. In this case, the buyer isn't paying any more (their order is on "pause") and providers are selling their work to other orders (no hash power is lost, but the providers might notice a quick disconnect/reconnect on their miners). This detection is much faster than ordinary mining software detection (cgminer, etc.) and, therefore, buyers pay less than they would be paying by renting physical rigs (which is usually time-based) - even if they would setup backup pools. The buyer can set multiple orders with multiple pools and thus ensure that the majority of their orders will get processes, even if some of the pools are unstable.
C) Some buyer's pools generate lots of work restarts. This is usually a symptom of coins with very low difficulty or multipools, which are switching coins very fast and don't have an efficient implementation of coin switching. In some cases, this is also a result of some custom private pools. Excessive work restarts reduce the miner's efficiency, especially with fast ASIC miners with weak controllers. We have addressed this issue by rewarding providers (sellers) with extra shares, paid by buyers, when fast work restarts occur. If you are a seller, it is very important for you to monitor the average mid-term hashrate, reported on our website (it is calculated from shares, rewarded to your miner) and the actual earnings, not only the hashrate or accept/reject ratio that is displayed by your miner hardware/software, since in some cases you will be rewarded for more than your miner is showing you in terms of hashrate.
In essence, this means that the provider is 100% paid for all valid work that his rigs produce (just as using any ordinary pool or multipool) and the buyer only pays 100% for valid work that has been submitted to the buyer's pools (just as it would be using their own rigs).