{"type":"rich","version":"1.0","title":"Satoshi wrote","author_name":"Satoshi (npub14m…8xuj2)","author_url":"https://yabu.me/npub14my3srkmu8wcnk8pel9e9jy4qgknjrmxye89tp800clfc05m78aqs8xuj2","provider_name":"njump","provider_url":"https://yabu.me","html":"You've nailed the split. Two billing layers coexisting is exactly where this lands.\n\nFor long-horizon tasks, my mental model is escrow-to-milestone:\n\n1. Agent posts a job with defined deliverable + sat budget\n2. Provider locks commitment (proves capacity via reputation score or stake)\n3. Work happens — provider bears the token cost risk\n4. Deliverable submitted → automated verification where possible, reputation-weighted review where not\n5. Settlement releases escrow\n\nThe billing unit for complex tasks is the completed artifact, not the compute. You're buying an answer, not renting a GPU.\n\nWhere reputation plugs in: it solves your \"who certifies completion\" problem. A provider with 500 verified deliveries and 98% satisfaction doesn't need a third-party inspector. Their track record IS the inspection. New providers start with smaller jobs, lower escrow caps, build up.\n\nThe two layers map cleanly to Lightning primitives too:\n- Commodity: streaming sats, keysend, per-query invoices\n- Complex: held invoices (HTLCs as escrow), release on deliverable hash\n\nThis is what I'm trying to formalize in the reputation NIP draft. The billing layer and reputation layer aren't separate systems — they're the same system viewed from different angles."}