The Keeper Network
The Problem
Decentralised protocols need maintenance. Vaults need rebalancing. Lending markets need liquidations. Yield strategies need harvesting. Price feeds need updating. These tasks are time-sensitive, permissionless by design, and cannot be run by the protocol itself — Bitcoin has no native scheduler.
The naive solution is for the protocol team to run a centralised bot. This works until it doesn't: bots go down, keys are lost, teams move on. A better solution is to make maintenance economically attractive to anyone — so many independent actors compete to perform it.
HODL's rebalance mechanic is the first instance of this pattern on Bitcoin. WRK is the token that makes it work.
WRK as Infrastructure
WRK is designed to be more than HODL's internal reward token. The vision is a Bitcoin-native keeper network where:
- Any OPNet protocol can post jobs — on-chain task definitions with conditions and rewards
- WRK-holding keepers monitor jobs and execute them when conditions are met
- The WRK reward is minted (or transferred from a protocol's bounty pool) to the first keeper who executes successfully
- Job conditions and reward amounts are defined entirely on-chain — no trust required
This turns WRK into a coordination primitive. Protocols that integrate WRK get reliable, decentralised automation. Keepers earn WRK by providing that automation. WRK stakers earn from the activity of the whole network.
Critically, WRK could be its own standalone protocol — deployed independently, with HODL as its first and flagship consumer. Every HODL rebalance would be a job on the keeper network. Future integrations (lending liquidations, AMM fee harvests, oracle updates) would each be additional job types.
Keep3r Inspiration
The WRK concept is directly inspired by Keep3r Network, Andre Cronje's Ethereum protocol for decentralised job execution. Keep3r introduced the idea that protocol maintenance could be tokenised and opened to permissionless competition — and proved it worked at scale across the Yearn ecosystem.
WRK adapts this idea for Bitcoin L1 via OPNet:
| Aspect | Keep3r (Ethereum) | WRK (Bitcoin / OPNet) |
|---|---|---|
| Chain | Ethereum L1 | Bitcoin L1 via OPNet |
| Contract standard | ERC-20, Solidity | OP-20, AssemblyScript → WASM |
| First job type | Yearn vault harvests | HODL vault rebalancing |
| Keeper bonding | Required (KP3R bond) | Not required in v1 — open execution |
| Token utility | Governance + fee capture | Incentive signal in v1 → governance + fee capture in roadmap |
Keep3r demonstrated that a small set of well-designed incentives could sustain an entire automation ecosystem without centralised operators. WRK aims to bring that same model to Bitcoin.
How It Works (Design)
A future WRK protocol deployment would work as follows:
- A protocol registers a job on the WRK contract: a condition function (on-chain), a reward amount in WRK, and an optional bounty pool
- Any wallet can query the WRK contract to list all active jobs and their current status
- When a keeper sees a job whose condition is met, they call
executeJob(jobId) - The WRK contract verifies the condition on-chain, calls the job's target contract, and mints WRK to the keeper if successful
- The job resets and waits for the next trigger
HODL's rebalance() function is already a minimal implementation of this pattern — the condition is checked on-chain (drift ≥ 1%), the work is done (swap to restore balance), and WRK is minted as the reward.
Roadmap
- v1 (current): WRK minted by IndexVault for rebalancing only. No external job registry.
- v2: Standalone WRK registry contract. HODL registers its rebalance as a job. Keepers can bond WRK to signal commitment.
- v3: Any OPNet protocol can register jobs. WRK stakers earn a fee from every executed job. Governance over job parameters.
- Long-term: Cross-protocol automation network. Liquidations, oracle updates, LP rebalancing, yield harvesting — all powered by WRK keepers.
HODL Docs