Holder staking
Stake $ZKMOSQ in MosquitoStockVault and you earn every stream it runs, in proportion to your share of the total staked. There is no lockup: withdraw whenever you like, and what you have earned stays claimable.
Example: three stakers and a stream of 1 NVDA per day. Each earns the stream in proportion to their share of all $ZKMOSQ staked, second by second, for every reward token the vault lists.
In-product accounting
Inside the product every job is priced in credits. The worker keeps 70% of it, or 85% if the worker has $ZKMOSQ staked. Of the margin left over, 80% goes to the holder pool.
job_price = credits_spent worker_share = 0.85 if worker_has_stake else 0.7 worker_reward = job_price * worker_share protocol_margin = job_price - worker_reward holder_pool += protocol_margin * 0.8
That margin is credits today. It reaches the on-chain vault only when the treasury sends stock tokens to the vault and someone calls sync. Trading fees reach the vault on-chain without anyone’s help.
Worker bonding
Verification is the main difference between a distributed service and a trustless compute protocol. ZK Mosquitoes does not need full verification for the initial launch, but the system is designed so it can be added without replacing the worker model. Bonding, where workers post collateral that can be slashed, is one of these mechanisms and is not built yet.
| Mechanism | Purpose | Cost |
|---|---|---|
| Spot checks | Rerun a random sample of jobs or test jobs to detect invalid workers. | Moderate. Good default for early verification. |
| Redundancy | Send the same job to multiple workers and compare outputs or traces. | High. Useful for sensitive tiers or audits. |
| Bonding and slashing | Make invalid work economically costly for providers. | Requires careful policy, disputes, and governance. |
| Reputation | Route more traffic to reliable workers over time. | Lower cost, but not sufficient by itself. |