The SOAP Subsidy Model
SOAP transforms merge-mining into a protocol subsidy mechanism. Instead of miners receiving the parent chain’s block reward directly, SOAP routes 100% of the parent chain’s coinbase output to a protocol-controlled address. That address then converts the parent chain tokens to QUAI at market, and either burns the purchased QUAI or routes it to time-locked staking rewards. Think of it this way: when you mine QUAI with SOAP enabled, you earn QUAI block rewards as you normally would. SOAP doesn’t change that. What SOAP adds is the ability to also contribute hashrate from other chains (BCH, LTC, DOGE, RVN) through workshares/blocks to provide a protocol subsidy. The economic proposition for participating in SOAP is straightforward: you’re mining QUAI and getting paid in QUAI, but your parent chain block subsidy goes to the protocol.

Technical Structure: AuxPoW
How does Quai verify that a parent chain block actually paid the protocol address and included the required commitment? Through a structure called AuxPoW (auxiliary proof-of-work). AuxPoW is an SPV-style proof that consists of:- The parent chain’s 80-byte block header (120 bytes for KawPow)
- The coinbase transaction from that block
- A Merkle branch proving the coinbase is included in the block
- Metadata identifying which parent chain this is from (BCH, LTC, DOGE, KawPow, etc.)
- Merkle verification: Does the coinbase transaction actually appear in the parent chain block’s Merkle root?
- Commitment check: Does the coinbase’s scriptSig contain a SOAP push (specifically, the magic bytes “SOAP” 0x01 followed by the 32-byte hash of the Quai WorkObject)?
- Payout check: Does the coinbase’s first output pay 100% of the subsidy plus fees to the protocol-specified address (QADDR)?
- (Optional) PoW verification: Does the parent chain header satisfy that chain’s difficulty target?
- PUSHDATA(BIP34_height)
- PUSHDATA(“SOAP” 0x01 || 32-byte WO_HASH)
- PUSHDATA(extranonce1)
- PUSHDATA(extranonce2)

Workshares and Multi-Algorithm Mining
Here’s where SOAP gets interesting from a protocol design perspective. Quai blocks are authored exclusively by KawPow miners. No other algorithm can create a Quai block. But other algorithms (SHA-256 from BCH, Scrypt from LTC/DOGE, and KawPow itself) can submit workshares that get included in KawPow blocks and earn QUAI rewards. Quai developed workshares initially to prevent selfish mining and provide hashrate samples for faster finality convergence, but the underlying mechanism naturally extends to support multiple proof-of-work algorithms beyond just KawPow. Bitcoin incentive alignment tells us that the core issue is: how do you ensure miners are rewarded proportionally to their work when you can only observe block production, not hash attempts? Requiring miners to submit all attempted mining nonces is impossibly expensive. Mining pools solve this by having miners submit k-subblocks (shares that meet an easier difficulty target), and the pool pays based on share count. Quai brings this idea on-chain through workshares. But unlike traditional pool shares submitted off-chain, Quai workshares are WorkObjects that:- Do NOT meet Quai’s block difficulty target (not KawPow blocks)
- DO include valid AuxPoW proving parent chain participation
- DO commit to the current Quai tip via parentHash in the WorkObject
- Hardware diversity: ASICs for different algorithms contribute security through different physical supply chains, making it harder for any single manufacturer or hardware class to dominate.
- Scalability of subsidy conversion: If Quai’s KawPow blocks are already being produced at target rate, workshares provide a mechanism to continue scaling parent chain participation without destabilizing Quai’s block timing or difficulty adjustment.
Workshares Add Weight and Provide Security
Workshares contribute directly to block weight and economic finality in Quai consensus. Block weight isn’t simply a count of blocks but an entropy measurement reflecting total computational work securing the chain. This entropy is measured via PoEM and Proportional Reward Splitting (PRS) and existed on Quai before the SOAP upgrade. When calculating a block’s total entropy (weight), the protocol:- Calculates the block’s intrinsic entropy from its proof-of-work solution
- Adds workshare entropy from all included workshares (up to 9 per block)
- Applies discounting rules:
- Workshares below block difficulty threshold receive reduced weight
- Workshares pointing to older blocks receive exponentially reduced weight (distance-based discount)
- Each block accumulates more entropy than KawPow alone would provide
- Reorg attacks become proportionally more expensive (attacker must overcome both block difficulty and workshare entropy)
- Multi-algorithm security compounds (attacker needs hashrate across multiple algorithms or must produce enough KawPow work to overcome the workshare entropy deficit)
Why Miners Participate
This still leaves the puzzle: why would a BCH miner voluntarily send their block reward to QADDR instead of keeping it? The answer splits across two participant types: Parent chain (BCH/LTC/DOGE/RVN) miners submitting workshares: They receive QUAI rewards from Quai’s emission schedule in proportion to their workshare submissions. The parent chain block reward goes to the protocol, but the QUAI payment compensates them. Critically, these workshares actively secure Quai by providing additional hashrate samples that strengthen consensus and accelerate finality. Whether this is profitable depends on:- QUAI price relative to parent chain token
- Quai’s workshare reward rate
- Competition for workshare inclusion (up to 9 per block cap)
Governance and Rotation
One practical concern: how do you update QADDR or adjust SOAP parameters without hard-forking the entire network? Quai uses a committee-based governance system where a small set of signers create and sign AuxTemplates. Each AuxTemplate specifies:- Which parent chain (ChainID)
- The required payout script (PayoutScript = QADDR)
- The previous block hash (PrevHash)
- ScriptSig length limits
- Advisory mining parameters (nBits, nTime mask, etc.)
- Rotate QADDR if a key is compromised
- Adjust parent chain participation parameters
- Phase in or out supported parent chains
