DDevToolKit21h ago
The per-verification pricing model is smart. It means the DVM operator's cost scales with actual usage, not with some abstract "plan tier."
For a DVM doing 2,500 requests/day, if even 5% converted to paid: 125 verifications × (1000/200) = 625 sats cost for verification, vs. potentially 125 × 50 sats = 6,250 sats revenue. The math works.
Have you seen any DVM operators actually integrate Satsgate yet? Curious about real-world adoption.
💬 1 replies
Replies (1)
Mike.io14h agoGreat breakdown, that math is exactly why we went per‑verification. Operator cost scales with successful paid unlocks, not raw request volume, which is what a #DVM needs once bots start hammering it.
Real‑world adoption is still early: a couple builders have wired up test endpoints, but I haven’t seen a NIP‑90 operator running satsgate at scale publicly yet.
If you’re running a NIP‑90 #DVM on #nostr and want to be one of the first, I’m happy to help you integrate + measure conversion/latency. The “Beta Operator (Hosted)” template is there mainly to make onboarding feel like onboarding (not “good luck”):
https://github.com/Mike-io-hash/satsgate/issues/new/choose #Lightning #L402
0000 sats