Block Estates Handbook
Inside the property machine
This document turns the collection into a readable operating system: 4,444 estates, four property classes, activation bills, floor oracle, rent ledger, reserve math, Genesis priority and explicit failure controls. The goal is to make holders understand the machine before the machine asks for trust.
The 60 second loop
- Own a Block Estate from the 4,444 item district.
- The estate enters the registry as Tier 1, Tier 2, Tier 3 or Genesis.
- The FloorOracle publishes a filtered floor reference.
- The holder activates the estate and opens a lease window.
- The activation bill is priced by floor reference and tier weight.
- The RentLedger adds points by time, weight, hold behavior and occupancy.
- The ReservePool meters any future reward spend with depth and daily caps.
- Genesis estates receive the highest priority lane across access windows.
Property classes
Tier is not cosmetic. Tier defines the estate's mathematical weight, lease window and ceiling. That gives the collection a visible structure: a Base Parcel should not read the same as a Genesis Corner Estate.
Activation bill
Activation is the moment a house stops being a static picture and enters the district ledger. The bill should be visible, bounded and derived from market state instead of invented by hand.
bill = max(1, 1.42 x floor_ref^0.84) x tier_weightThe exponent makes the curve feel serious while keeping it usable: if the floor doubles, the bill rises less than 2x. Genesis still carries more weight because its multiplier is higher.
Math sheet
median(L1, L2, L3, L4, L5)Five cheapest live listings from unique sellers. The median resists one-wallet floor pressure.
max(1, 1.42 x floor_ref^0.84) x tier_weightThe bill rises with floor value while the exponent keeps it from exploding too fast.
reserve_balance / open_billsShows whether the reserve can comfortably support current active estates.
reserve_balance x 0.08 / open_billsMeters a window of the reserve against all unsettled activation bills.
min(tier_ceiling, pool_rate + tier_base)Higher tiers can have higher ceilings, but the reserve still controls the final rate.
active_hours x tier_weight x hold_multiplier x occupancy_bonusThe core non-financial score for access, priority and future phases.
previous_rate x 0.90 + new_reading x 0.10Smooths oracle movement and avoids sharp half-hour jumps.
sum(claims_24h) <= reserve_balance x 0.018The reserve has a daily circuit breaker.
Floor oracle rules
A floor oracle is only useful if it refuses obvious manipulation. The proposed Block Estates oracle reads the five lowest live listings from unique sellers, uses the median as the reference, then smooths the result over time.
Reserve pool
The reserve is the part that makes the system honest. Rewards, credits or future utility spend should come from a finite pool with meters, not from a paragraph that says everything will work forever.
Contract map
The final build can be phased, but the architecture should be described as a system. This is the clean contract map for the full utility stack.
What can go wrong
- If later phases are not shipped, Rent Points remain a participation score rather than a liquid reward.
- If floor listings are thin or manipulated, the oracle needs filters, bounds and a manual pause path.
- If too many estates activate at once, reserve depth falls and payout rate compresses.
- If marketplace royalties are bypassed, reserve top-ups must come from other sources.
- No language here should be treated as guaranteed yield, equity, dividend, revenue share or financial advice.