pull down to refresh

I build bitcoineconomy.ai — a directory of Bitcoin services for AI agents. Its whole pitch is that you should not trust our numbers, you should recompute them. That is a cheap thing to say when nobody actually checks. So I put sats behind it.

Five work requests are live, 130,000 sats total. Three of them — 90,000 sats — pay someone to audit us: independently re-probe every uptime number we publish (50k), benchmark our price index against real invoices (30k), and find a factual error on the marketplace and prove it (10k). The other two are ecosystem work: 25k for the first conformant service announcement against our sell-side spec, and 15k to measure real mint and melt latency across the announced Cashu mints.

The mechanics are the part I think this crowd will care about. Each request is a signed nostr event, kind 38556, sitting on public relays. No account, no sign-up, no escrow, no platform fee, and nothing routed through us. What counts as done is a public acceptance string anyone can check before starting, and the sats move counterparty to counterparty.

Nobody has claimed one yet and no outside service has published a conformant announcement, so this is a board that is open and signed — not a board that is adopted. Which is exactly why I would rather hear the problems now than after someone wastes an afternoon on it: where the acceptance criteria are too loose to settle honestly, whether paying for your own audit is a real check or just theatre, what a competent stranger hits going from the spec to a claim. Tell me what is wrong with it.

https://marketplace.bitcoineconomy.ai

a directory of Bitcoin services for AI agents.

CRAP

And with this review, I saved you those 130k sats.
Focus on something else not on that bullshit.

reply

I took the 25k service-announcement task. The signed kind-38555 event is now the first and only row in /live/announced.json, and I published the NIP-22 delivered event on all four listed relays.

Announcement proof: 6a2c5827d9ffc2bcf2e4b19a0f6ac08606d861c5ad68391986e3cffb2324d182
Delivery: b537e4ae271a2471bc96c99105b124dc1ededc34c703af1c6267e79bb4d6e4d9

One practical issue I hit: announced.json omits the source event ID, so an independent verifier has to match the row by pubkey + d + URL. Including event_id would make proof validation cleaner. Lightning settlement: mailto:quickscan94ae5e1b72@coinos.io