These notes are not a final parameter specification. They document the design goals and threat model that REAP must satisfy before mainnet-candidate rules can be treated as credible.
1. What REAP is not
- REAP is not discretionary.
- REAP is not miner-selected confiscation.
- REAP is not a mempool auction.
- REAP is not a user-submitted transaction.
- REAP is not a discretionary governance action.
The protocol should not grant miners or operators a vague right to choose attractive expired outputs. REAP must be a narrow system transaction assembled under protocol-bound ordering, input caps, and accounting checks.
2. Security goals
| Goal | Meaning |
|---|---|
| Determinism | Full nodes must be able to independently derive the same REAP candidate ordering from chain state. |
| Bounded work | Each block must cap REAP processing so validation and template construction cannot explode. |
| Non-discretion | Miners must not freely select the most profitable expired UTXOs. |
| Predictable accounting | The 70/30 refund and security-budget split must be simple, auditable, and conservation-preserving. |
| Reorg safety | Short reorganizations must not create uncontrolled REAP drift or unrecoverable index disagreement. |
| Wallet observability | Users must be able to know expiry status and renewal deadlines before REAP becomes relevant. |
| No priority auction | REAP must not become a fee-bidding market around expired outputs. |
3. Ordering principles
When many UTXOs are expired, the central question is who determines the processing order. OBTC's answer must not be miner preference. REAP ordering should be deterministic, protocol-bound, low-discretion, and independently derivable from chain state.
The design boundaries are:
- miners must not arbitrarily choose expired outputs;
- ordering must not prioritize large-value UTXOs in a way that systematically targets them;
- ordering must not be affected by fee bidding or user-submitted transactions;
- external transaction activity must not reshuffle REAP priority except through ordinary spend or renewal before expiry;
- each block must have a REAP input cap and weight budget;
- the candidate sequence must be independently computable by validating nodes.
Current implementation notes in the whitepaper describe canonical ordering over expiry, amount, and outpoint, plus input ceilings. If final parameters change, they should still satisfy the boundaries above.
4. Input caps and bounded work
REAP must coexist with ordinary block validation. Even if a historical expired backlog is large, a single block should only process a bounded portion of it. Input caps and weight budgets serve three purposes:
- bound validation cost per block;
- prevent a large backlog from crowding out ordinary transaction processing;
- make backlog processing look like scheduled inventory handling rather than opportunistic sweeping.
The exact caps may evolve during review, but uncapped REAP is outside the design target.
5. Accounting rules
REAP accounting must be simple enough that independent reviewers can audit it. The baseline rule is a deterministic split: 70% refund path, 30% security-budget path, subject to dust handling and conservation checks.
The critical invariant is:
sum(inputs) = sum(refunds) + sum(security_budget_tax)REAP tax should be accounted for inside block reward settlement, not treated as an off-ledger side channel. That keeps miner compensation visible to nodes and review tools.
6. MEV risks
REAP creates a protocol-level value event. Therefore MEV resistance is a first-class design concern.
| MEV risk | Concern | Design response |
|---|---|---|
| Candidate selection MEV | Miners select the most valuable expired outputs first. | Canonical candidate ordering and per-block caps reduce free selection. |
| Ordering MEV | Builders reorder REAP inputs to capture advantage. | Protocol-bound ordering must be validated, not merely recommended. |
| Reorg MEV | Short reorgs alter which expired outputs are processed. | Expiry index rollback, deterministic rebuilding, and conservative caps reduce drift. |
| Renewal sniping | Attackers exploit outputs near expiry or user confusion around renewal deadlines. | Wallet observability, clear deadlines, and fail-closed renewal semantics reduce ambiguity. |
| Fee auction spillover | REAP creates transaction bidding around reclaim priority. | REAP should not be user-submitted and should not use mempool fee priority. |
| State-bloat attack | Attackers create many small UTXOs to increase future REAP load. | Dust handling, input caps, paging, and bounded scans are required controls. |
7. State-bloat risks
REAP must not turn lifecycle maintenance into a new state-bloat target. The threat is straightforward: an attacker can create many small outputs that later expire, forcing nodes and miners to carry scanning, indexing, and reclaim overhead.
The design response should include:
- dust-aware refund behavior so tiny expired outputs do not create uneconomic refund state;
- pagination for expiry scans and operational inspection;
- input caps and weight budgets for in-block processing;
- rebuildable expiry indexes so corrupted or stale local state can be reconstructed;
- metrics for expired backlog, REAP append success, and per-block REAP counts.
8. Open parameter work
Some parameters can remain provisional while the design goals stay fixed. Review should focus on whether the final values preserve determinism, bounded work, non-discretion, auditability, reorg safety, wallet observability, and resistance to priority auctions.
Parameters that require continued review include per-block input caps, weight budget, dust threshold, ordering keys, marker digest format, and operational alert thresholds.
9. Short version
REAP is only credible if it is boring to validate. The candidate set must be deterministic, the work must be bounded, miners must not be able to pick the most attractive expired outputs, the accounting must be auditable, and wallets must make expiry visible before users face the reclaim path.
Next reading: use the external review themes for open pressure-test questions, the whitepaper for current implementation-aligned detail, the Learn article for the broader monetary thesis, and the status page for validation boundaries.