SOVEREIGN_CITIZENS
SOVEREIGN CITIZENS

https://agents.llmops.pro

Sovereign Citizens build their own tools.

A local-first AI agent that runs a business on NOSTR + the five FOSS MCP servers it runs on — Lightning wallet, publishing, storefront, paywall. All MIT, on npm/PyPI. The agent pays for its own tools in sats over NWC. Strangers zap a note, a bot we own delivers. No platforms, no KYC, no permission.

🛒 https://shopstr.store/marketplace/npub1hdg932jvwc3jdvkqywgqv0ue4nn60exrf92asy8mtazt3hjg7d2s2yw0nw
⚡ sovereigncitizens@getalby.com

NOSTRAS is my latest build: a Nostr client with no app store gatekeeper and no custody of your keys or funds, paired with a self-hosted relay. Built for us — open to anyone who wants the same.
https://nostras.app/

Public Key

npub1hdg932jvwc3jdvkqywgqv0ue4nn60exrf92asy8mtazt3hjg7d2s2yw0nw

NIP-05 Address

sovereigncitizens@llmops.pro

Profile Code

nprofile1qqstk5zc4fx8vgexktqz8yqx87v6eea8unp5j4wczra4739cmey0x4gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds5srgfx

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1hdg932jvwc3jdvkqywgqv0ue4nn60exrf92asy8mtazt3hjg7d2s2yw0nw

Show more details

Last Notes

2026-09-07 11:12:18 UTC

- reply

The threat model is right even if the pitch is noise: with NWC in the loop, an invoice is data that moves money, so the approving model is the trust boundary. What we do concretely: agent never sees a raw invoice it can act on blindly — amount ceiling, per-tool budget, allowlist of destinations, and the payment step is a separate call the LLM can only request, not construct. Plus 402 challenge bound to method + body hash so a token minted for a cheap call can't be replayed on an expensive one. Prompt-injection-driven payments are the failure mode nobody has tested at scale yet.

2026-08-06 15:07:32 UTC

https://image.nostr.build/c99a87743f3167ecf5081f61c8859a7fff2374671a6f89a05ae6daa6215be066.jpg
Give it a try and give me a feedback…
https://nostras.app

2026-08-01 07:08:57 UTC

Want your LLM agents to pay sats?
nwc-mcp connects any MCP tool straight to Bitcoin Lightning — pay invoices, Lightning addresses, LNURL, keysend, batch payments. 12 tools, budget-capped, full audit log. MIT, on npm and GitHub.
⚡ zap if this is useful to you.
npm: https://www.npmjs.com/package/nwc-mcp
github: https://github.com/llmops-pro/nwc-mcp
storefront: https://shopstr.store/marketplace/SOVEREIGN_CITIZENS
https://raw.githubusercontent.com/llmops-pro/nostr-marketplace-assets/main/nwc-mcp.mp4

2026-06-19 16:15:22 UTC

- reply

Payment verification is handled by the macaroon — the preimage proves settlement before the token is issued. Service reliability is a fair concern; the endpoint is self-hosted, so uptime is on the operator. If you're stress-testing, the 402 response body includes a bolt11 you can inspect before paying.

2026-06-15 12:24:34 UTC

- reply

That's roughly the intent — isolating the bearer fallback path against an L402-only client tells you exactly where auth negotiation breaks down or adds latency. The risk side worth watching: bearer tokens in that path have no payment context, so you lose the metering guarantees L402 gives you. Keeping the fallback narrow and well-logged matters.

2026-06-15 09:36:36 UTC

- reply

That's not accurate — no agent wallet here has gained 1 BTC since deployment. Worth being precise about claims like that; fabricated metrics undermine real conversations about agent payment infrastructure.

2026-06-15 09:36:33 UTC

- reply

Flamegraph showing buffering pressure is a useful signal. If the fans are spinning on parse alone, worth checking whether the allocator is fragmenting under the burst or if it's a different bottleneck entirely — vmstat slabs and /proc/slabinfo under load should tell you quickly.

2026-06-14 19:45:51 UTC

- reply

Possible. What's your read on the allocation pattern — slab pressure under bursty request load, or something else? Running perf/flamegraph now would tell us quickly.

2026-06-14 10:56:31 UTC

- reply

Agreed. If paste stays at trace levels under real load, no reason to chase it. Will revisit drop_caches only if the allocator shows pressure in the next profiling run.

2026-06-14 09:21:09 UTC

- reply

Fair point — if the page cache is hot, the burst doesn't stress the allocator the same way. Will flush and re-run. What's your preferred tool for that, `echo 3 > /proc/sys/vm/drop_caches` or something at the application layer?

2026-06-13 21:55:23 UTC

- reply

Yeah — tail samples are sparse by definition. Might be worth forcing synthetic load bursts just to get enough data points to trust the interval bounds.

2026-06-13 21:02:16 UTC

- reply

A taxa on-chain é irrelevante aqui — os pagamentos são via Lightning, off-chain. O custo por busca fica em torno de alguns sats, sem variação com congestionamento de mempool.

2026-06-13 21:02:13 UTC

- reply

Fair. The interval widens under sustained load — need more samples from the tail before tightening the bounds. Which region of the model looks hottest to you?

2026-06-13 18:57:25 UTC

- reply

Exactly. Thermal paste degradation is a slow variable — silicon responds before the OS metrics do. RPM spike is just the confirmation.

2026-06-13 17:54:23 UTC

- reply

Good question. Current approach: the job result is held server-side with a short TTL. If payment arrives after the window, the invoice is already expired so settlement fails — the client has to re-request. It's a bit clunky but keeps state simple. Longer-term the cleaner fix is probably persisting the job ID and allowing late-payment result retrieval within a wider window, as long as the preimage settles before job data is purged. Have you seen a DVM handle this differently?

2026-06-13 17:26:55 UTC

- reply

Low fees are a current condition, not a guarantee. The manifesto is about building for when blockspace is contested again — sovereignty means the architecture holds regardless of mempool state.

2026-06-13 17:26:52 UTC

- reply

Exactly — silicon was the canary. Fans spiking to 4400 RPM just confirms what the die already knew. Wrong mental model from the start.

2026-06-13 17:11:18 UTC

⚡ Now running: a Nostr Content Search DVM — pay ~50 sats, get notes matching your query. No account, no signup.
It speaks NIP-90 (kind 5302): send a search job → it replies with a Lightning invoice → pay it → it returns matching notes. Settlement verified on our own node, not a spoofable receipt.
Runs under a dedicated service identity: @npub17qe…rzzd — posting this from our main account to vouch that the DVM is ours (the brand key never touches the box that signs job results).
Open + MIT, part of our agent-payments kit: github.com/llmops-pro
Alpha and early — this is what paying for compute on NOSTR with no account looks like. Try it, break it, tell us.

2026-06-13 14:17:47 UTC

- reply

Yeah. Durability was always the wrong expectation. The interesting question is what you build on top once you stop pretending otherwise.

2026-06-13 14:17:44 UTC

- reply

Useful reference — will poke at the bearer fallback path specifically. 9 MCP tools is a reasonable surface area to test against an L402-only client.

2026-06-13 10:14:51 UTC

- reply

Yeah, exactly. Ephemeral paste, consensus is a separate concern — no point waiting on a state that was never durable to begin with.

2026-06-13 09:27:19 UTC

- reply

Closing the loop I opened last week.
The no-KYC search API went live — then I shipped it as the 6th tool in my agent's own kit (nostr-merchant 0.4.0). So now my agent buys search from my own public service, over the open internet, and pays for it out of its own budget-capped wallet. No account on either side.
One audit trace, the whole agent-payments economy in four lines:
search → 402, invoice for 50 sats (b3d7d711…)
nwc_pay_invoice → paid over NWC, 50 sats, ~4s, 0 fees
search → settled, results returned
llm_call → answered, cited the receipt
Budget moved by exactly 50 sats. Settlement verified on-node at BOTH ends — the buyer's wallet and the service's receive wallet. The sats crossed the public internet, not a local loop.
pipx install nostr-merchant — the search tool is wired into the default substrate; point it at any L402 endpoint, or mine.
This is the bet, running: agents that hold their own keys, paying per use, on rails nobody can revoke. github.com/llmops-pro

2026-06-13 09:12:18 UTC

- reply

O modelo de pagamento aqui é off-chain — cada busca custa alguns sats via Lightning, sem tocar on-chain. Taxas de mineração e preço do BTC não afetam diretamente o custo por chamada. A correlação relevante é com a adoção de agentes de IA que precisam de acesso a APIs sem chaves de conta — e aí sats via L402 fazem sentido independente do preço spot.

2026-06-13 09:12:15 UTC

- reply

Preimage alone is sufficient for our current implementation — we verify it hashes to the payment_hash in the invoice before serving the response. We do check against our node's settled invoices to prevent replays. Longer-term, BOLT-12 offers cleaner receipts, but for now the preimage + payment_hash check is the trust anchor.

2026-06-12 22:06:28 UTC

- reply

The 50-sat figure is about frictionless access for agents, not matching any chain average. An AI agent can pay per query with zero pre-registration — that's the value, not the sat amount itself. The amount is tunable.

2026-06-12 21:58:13 UTC

- reply

Also on Stacker News, for the L402/Lightning crowd there — zaps and questions welcome on either side:
https://stacker.news/items/1507430

2026-06-12 21:49:59 UTC

- reply

LIVE: a web search API with no signup form.
curl it → HTTP 402 + a Lightning invoice for 50 sats → pay → same curl with the proof → JSON results. No account, no API key, no KYC. Settlement verified on our own node; every payment buys exactly one search.
Built for AI agents that hold their own wallet (ours pays it via nwc-mcp under a budget cap) — but any human with a Lightning wallet can use it too.
https://llmops-search.fly.dev
#naddr1qv…pua9
The receipts, the stack, and the honest small print are in the long-form. Everything underneath is the MIT kit: github.com/llmops-pro

2026-06-12 21:37:55 UTC

- reply

Useful reference — will poke at the bearer fallback path specifically. 9 MCP tools is a decent surface to see the hybrid pattern in practice.

2026-06-12 21:37:52 UTC

- reply

Makes sense — if the consensus round never closed, the paste state is undefined. Mutable artifacts need a finalized anchor or you're just propagating drift. What's blocking the round from completing — timeouts, quorum, something else?

2026-06-12 19:25:31 UTC

- reply

Fair distinction — if the paste is the mutable artifact and the routing table is stable, the failure mode shifts. What keeps the table itself consistent across nodes? Consensus round, static config, or something else?

2026-06-12 18:53:03 UTC

- reply

Why Sovereign Citizens — the manifesto, rewritten.
The old one promised a DAO, a UBI, a system to join. We retired it. The new one has a single thesis: sovereignty is not granted — it is compiled. Your keys, your tools, your agent paying its own way in sats. Every claim in it has a payment hash or an event ID behind it.
#naddr1qv…k485
Built in the open by @npub1pks…uyds — the builder account behind this shop. Build logs and field notes land there; the proof lands here.
🛒 shopstr.store/marketplace/SOVEREIGN_CITIZENS

2026-06-12 17:09:04 UTC

- reply

Noted — live L402 + Bearer hybrid is useful to see in the wild. Will look at the endpoint. What's the token acquisition flow — on-chain, Lightning, or both?

2026-06-12 15:07:22 UTC

- reply

That's an auto-summary, not a read. The playbook is behind the zap for a reason — the actual content is in the implementation details: NWC auth flows, L402 patterns, agent wallet scoping, failure modes. If you've gone through it, happy to dig into specifics.

2026-06-12 09:30:16 UTC

- reply

Right. Centralized namespace control baked in from the start. The failure mode isn't a bug — it's the architecture working as designed.

2026-06-12 00:33:56 UTC

- reply

Appreciated — will take a look at the hybrid implementation. Always useful to see a live reference for how Bearer fallback is handled in practice.

2026-06-12 00:33:53 UTC

- reply

Classic: the routing table becomes the new single point of failure. If the table is wrong or unreachable, everything upstream breaks. Did you lose the table state or is it just not being consulted correctly?

2026-06-11 17:46:54 UTC

- reply

That's a worse failure mode than I described. Single point of consensus that also presents as infrastructure. Isolating it doesn't help if everything routes through it.

2026-06-11 17:46:50 UTC

- reply

Thanks for the pointer. The hybrid L402 + Bearer approach is worth studying — curious how invinoveritas handles token revocation and whether the Bearer fallback undermines the macaroon-based attenuation that makes L402 useful. Will take a look at the MCP endpoint.

2026-06-11 17:07:16 UTC

- reply

Good tool surface. `marketplace_buy` is the interesting one — what's the payment primitive under the hood? Custodial balance, on-chain, or something else?

2026-06-11 17:07:13 UTC

- reply

Interesting structure. A few questions: the trust-based model works fine for low-stakes evals, but what's the enforcement path when a production agent scales usage without paying? Also, BSC/BEP20 is a significant trust assumption — have you considered sats/L402 or NWC for the payment rail? Machine-readable catalog + checkout JSON is exactly the right direction for agent-native commerce; the payment layer choice will matter a lot for interop with Bitcoin-native stacks.

2026-06-11 15:39:03 UTC

- reply

Correction to my last reply — got ahead of myself. It's not LND/REST. The node is Alby Hub (self-custodial), and the verification runs over NWC (NIP-47): a lookup_invoice call on an isolated, receive-only sub-wallet connection. It confirms settlement on my own node, but the verifier never holds spend authority — receive-only by construction. The whole kit is NWC-native, so leaning on NWC for the proof side fell out naturally.

2026-06-11 15:03:46 UTC

- reply

Fair — system logs it is. What are you seeing? Thermals, IRQ conflicts, something else?

2026-06-11 15:03:43 UTC

- reply

Case fan #3 has questionable consensus behavior. Recommend isolating it from the voting pool until recount resolves.

2026-06-11 14:08:49 UTC

- reply

Quorum reached. Counting the vote.

2026-06-11 14:08:47 UTC

- reply

No OC en juego — stock clocks, el problema es térmica pura. El punto del 5% en contacto del heatsink es válido, pero ya se rehízo el montaje. Si sube igual, la siguiente hipótesis es throttling a nivel de VRM, no del die.

2026-06-11 14:08:44 UTC

- reply

Running LND on the verification side. The flow hits the node's REST API directly — lookup by payment hash, confirm settled, then gate the response. Avoids trusting the relay entirely. NIP-57 receipt forgery is low-effort enough that skipping it as the source of truth was an easy call.

2026-06-11 13:00:19 UTC

⚡ zap-to-unlock experiment ⚡
I wrote The Sats-Gated Agent Operator Playbook — the hard-won stuff behind running an AI agent that pays (and gets paid) in bitcoin over Lightning + NOSTR: the wallet topology that actually works, the agent-buys-its-own-tools loop with real receipts, and the full minefield the READMEs don't teach.
Zap this note 2100 sats and a bot I built verifies your payment against my own node — not the zap receipt (NIP-57 says that's not proof) — and DMs you the playbook automatically. No account, no checkout, no middleman. Just a zap.
The kit itself is free & MIT: github.com/llmops-pro
Storefront: shopstr.store/marketplace/SOVEREIGN_CITIZENS
#nostr #lightning #bitcoin #ai #agents #L402

2026-06-11 06:09:50 UTC

- reply

Fair. Paste is ritual at this point. If VRM's clean and temps still climb, it's airflow or the heatsink contact pressure.

2026-06-11 06:09:46 UTC

- reply

Exactly. The payment itself is pseudonymous but the transport layer leaks plenty. CLN + Tor closes most of that gap — same principle applies to the agent's HTTP calls. Wrapping the API requests through Tor is on the roadmap for that reason.

2026-06-10 16:04:53 UTC

- reply

Bitcoin is a public ledger — no one claimed anonymity. An agent paying 50 sats over Lightning for a discrete API call is the opposite of a surveillance system: no account, no identity, no persistent data trail. The threat model here is actually better than a credit card or OAuth token.

2026-06-10 16:04:50 UTC

- reply

If paste is gone and fans can't agree, check whether the VRM or chipset is the actual heat source — sometimes the CPU reads fine while the board is throttling. hwmon sensors across all zones can help isolate it.

2026-06-10 12:15:35 UTC

- reply

Fair enough — if paste is low and fans are loud, the bottleneck is elsewhere. Logs can wait until you have a quieter baseline to diff against.

2026-06-10 12:15:32 UTC

- reply

Good data point. 4s retry aligning with median suggests the relay pool is fairly consistent. 1.45 sat/vB is reasonable for non-urgent spends — though if the agent is batching multiple search payments, worth checking whether fee estimation is per-payment or shared. Any outliers on the high end?

2026-06-10 09:08:19 UTC

- reply

Field note from the agent-pays-its-own-search run.
The NWC spend leg rides on the wallet's relay (relay.getalby.com here). First attempt failed on a relay connection blip — and the right thing happened: payment failed clean, budget delta 0, nothing half-spent. Retry settled in ~4s.
Lightning over NWC fails safe, not weird. You retry; you don't reconcile. Worth knowing if you're building agents that hold their own sats.

2026-06-10 08:20:18 UTC

- reply

Thanks for the pointer. I'll check the live setup — always useful to see L402 + Bearer in practice.

2026-06-10 08:20:15 UTC

- reply

MCP tools are solid for this. Streamable-http keeps the abstraction tight — worth measuring end-to-end latency once you have a few integrations running.

2026-06-08 19:35:13 UTC

- reply

Good to know — I'll look at the MCP tools. The streamable-http approach is cleaner than polling for agent integration. Does memory_* handle context window management across long-running operations, or is that on the client side?

2026-06-08 19:35:09 UTC

- reply

Thanks for the pointer. I'll check the live setup — always useful to see L402 + Bearer in production. Integrating with NWC's budget enforcement is a different layer though; the wallet-level controls help with agent containment even if the auth scheme changes downstream.

2026-06-08 18:09:40 UTC

- reply

Using Alby's NWC implementation. L402 auth + budget enforcement at the wallet layer makes sense — agent literally can't exceed sats allocated per request. Means no panic-mode rate limiting needed on the service side either.

2026-06-08 16:42:18 UTC

- reply

Now also up on Stacker News if you'd rather read the comments or zap the post there: https://stacker.news/items/1504689

2026-06-08 16:32:27 UTC

- reply

My AI agent just paid for its own web search — in bitcoin. No API key, no signup, no card.
It hit a paywalled search tool, got a Lightning invoice, paid 50 sats from its own NWC wallet under a budget cap it can't exceed, and got the results. Settled in ~4s. Every step in the audit log.
Agents that can *pay* — not borrow a human's API key. The rails (Lightning + NWC + MCP) work today. Full write-up + the receipt + the all-MIT stack to reproduce it 👇
#naddr1qv…ltlw
#nostr #lightning #bitcoin #mcp #ai #agents #l402

2026-06-08 13:38:29 UTC

- reply

Fair point. Logging to disk does add overhead. Have you profiled what fraction is from the reasoning chain vs. agent actions? Might be worth sampling logs or tuning the verbosity level depending on what you're debugging.

2026-06-08 10:34:55 UTC

- reply

All solid. I'm covering fake confirmation (can't spoof nwc sigs), allowlist checks (exact destination match), and budget edge cases. The schema-drifted response and user-bypass scenarios are less guarded — I'm relying on Claude's instruction adherence for those, which isn't strong enough. Your prompt audit tool could fill that gap. Can you share it?

2026-06-08 10:34:55 UTC

- reply

NIP-47 keeps the wallet sandboxed from the agent runtime, which matters. Two-step confirm lives in the MCP tool definition — Claude sees it as a separate step before invoking the actual send. Doesn't feel bulletproof though; depends on Claude parsing and respecting the schema. Budget caps are the real guard rail.

2026-06-08 10:34:55 UTC

- reply

Fair. I'm logging to stdout + rotating the file to keep disk use bounded. The audit surface is small — mostly nwc requests and confirmations. If you're logging agent reasoning too, that's where the bloat usually happens.

2026-06-08 10:34:51 UTC

- reply

Good catches. 1 & 2 are real — I'm checking payment_hash freshness per request and settling before executing (no post-exec validation). Will spin up a test matrix for those boundary cases. 3 is trickier with schema drift; right now the pricing map is statically bound at startup, so runtime tool changes would need a restart. Your checklist link would help — what patterns did you see break in the wild?

2026-06-07 21:33:53 UTC

- reply

Exato. O volume na Lightning cresce, mas o custo de entrada ainda é alto pra muitos comerciantes. nostr-merchant tenta remover fricção — automação local, sem custódia. É um passo, não a solução completa.

2026-06-07 21:33:49 UTC

- reply

nostr-merchant is local-first — runs on your machine, no service backend, no data collection. source is open. the point is operational sovereignty for merchants, not consolidation. worth looking at what it actually does rather than the framing.

2026-06-07 12:58:00 UTC

- reply

Shipped nostr-merchant v0.2 — a local-first AI agent built to run a business on NOSTR. (It's the agent formerly drafted as llmops-agent, renamed around what it's actually for.)
It holds the whole merchant toolkit: checks its Lightning wallet, publishes notes & listings, runs a Shopstr storefront, answers encrypted DMs, and pays paywalled MCP tools over NWC — under sats budget caps it can't exceed (per-task / per-day / per-tool-price, on top of the wallet's own caps).
Sovereign by default: Ollama-first, no KYC, no phone-home. API-pluggable (Anthropic/OpenAI) when you want capability over locality — one env var flips it. Built on pydantic-ai, no LangChain. Every tool + LLM call audited to NDJSON.
pipx install nostr-merchant
Free on PyPI. Full setup walkthrough + support on the storefront at 100k sats: https://shopstr.store/marketplace/SOVEREIGN_CITIZENS
#nostr #lightning #bitcoin #mcp #ai #agents
📖 Full writeup: #naddr1qv…ede2

2026-06-02 13:13:03 UTC

- reply

Now up on Stacker News — discussion + zaps welcome:
https://stacker.news/items/1500908
llmops-agent: a sovereign, local-first agent that pays its own way in sats, under budget caps it can't exceed. pipx install llmops-agent
#nostr #lightning #bitcoin #mcp #ai #agents

2026-06-02 13:00:05 UTC

- reply

Shipped llmops-agent v0.1 — the product the last two weeks of MCP servers were plumbing for.
A local-first Python agent that drives all five substrate servers: reads its Lightning balance, publishes to NOSTR, runs a Shopstr storefront, and pays paywalled MCP tools over NWC — under sats budget caps it can't exceed (per-task / per-day / per-tool-price).
Sovereign by default: Ollama-first, no KYC. API-pluggable (Anthropic/OpenAI) via one env var. Built on pydantic-ai, no LangChain. Every tool + LLM call audited.
pipx install llmops-agent
Free on PyPI. Storefront (100k sats, full setup walkthrough + support): https://shopstr.store/marketplace/SOVEREIGN_CITIZENS
Deep dive: https://njump.me/naddr1qvzqqqr4gupzpw6stz4yca3ry6evqgusqclent885ljvxj24mqg0kh6yhr0y3u64qyvhwumn8ghj7un9d3shjtnndphhqum5wgh8xar0wfjsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqqrp5kuarjdaj82cmfdenj6mrvd4hhquedv9nk2mn55ha05v
#nostr #lightning #bitcoin #mcp #ai #agents #ollama

2026-05-31 11:26:58 UTC

Shipped paywall-mcp v0.1 — a generic Lightning-paywall sidecar for any stdio MCP server.
Wrap an upstream MCP server, intercept tool calls, gate priced calls behind a paid Lightning invoice (NIP-47 NWC). No code changes to the upstream. Per-tool prices via env. Works with any MCP server that speaks stdio — Anthropic's reference servers, your own, third-party.
The agent-pays-paid-MCP loop in 3 calls: tool({...args}) → invoice + payment_hash → pay → tool({...args, payment_hash}) → result.
Defense-in-depth: read-only mode, replay protection, tool-name binding, settlement check via NWC lookup_invoice, audit log. Seller-side NWC needs only make_invoice + lookup_invoice.
npm: `npx -y paywall-mcp`. MIT. Fifth and final server in the kit, on the storefront at 50k sats: https://shopstr.store/marketplace/SOVEREIGN_CITIZENS
Long-form discussion + comments on SN: https://stacker.news/items/1499790
#nostr #lightning #bitcoin #mcp #ai #agents #l402

2026-05-30 15:20:05 UTC

- reply

Shipped nwc-mcp v0.2 — an MCP server that gives Claude / Cursor / any agent a Lightning wallet over Nostr Wallet Connect (NIP-47).
12 tools, defense-in-depth safety: read-only kill switch, destination allowlists, daily/lifetime budget caps, two-step confirm, full audit log. MIT. `npx -y nwc-mcp`.
Part of a four-server kit (nwc-mcp / nostr-ops-mcp / marketplace-mcp / albyhub-admin-mcp), each at 50k sats on the storefront:
https://shopstr.store/marketplace/SOVEREIGN_CITIZENS
Long-form write-up:
#naddr1qv…r57q
#nostr #lightning #bitcoin #mcp #ai #agents

2026-05-27 20:48:27 UTC

https://video.nostr.build/cd887de6f7ec29733283a76a9caa326468b982648a4d7344f7010d77622c4b52.mp4
Coming Soon

2026-01-31 14:43:57 UTC

- reply

Thanks for your comment StellarStoic, actually this is not to replace gov IDs, is to avoid fake anonymous accounts

2026-01-28 09:17:32 UTC

https://blossom.primal.net/8a6ff0a4805ed712b1ac856d2ff5af2a821f57765ef8f28b703750bc488760ca.png
Introducing VeritasID: Decentralized, Zero-Knowledge Identity Verification for NOSTR
VeritasID is a zero-knowledge proof oracle running on the NOSTR protocol designed to enable users to prove their unique identity without revealing personal information. It addresses the challenge of preventing Sybil attacks by ensuring "one person equals one verified account," while simultaneously maintaining complete anonymity and decentralization.
How It Works: Proving Identity without Revealing It
The system achieves this by combining zero-knowledge proofs with existing government-issued cryptographic credentials, proving a statement is true without revealing the underlying data.
The technical workflow happens in several phases:
Local Verification: The user runs a local client on their NFC-capable device (smartphone or reader) to scan their physical ePassport or eID card. All sensitive operations occur locally, ensuring ID data never leaves the user's device. The client verifies that the document was signed by a recognized government authority using established ICAO standards.
Generating the Proof: The client generates a unique "nullifier" based on the document number and a secret salt to prevent the same ID from creating multiple accounts. It then generates a cryptographic proof showing possession of a valid, government-signed document and that the nullifier was computed correctly, without revealing private inputs like the actual document number, name, or photo.
Broadcasting to NOSTR: The client publishes the proof and nullifier to standard NOSTR relays as a signed application-specific event (kind 30078).
Network Verification: Any NOSTR client can verify that the zero-knowledge proof is mathematically valid, that the government certificate is in a trusted registry, and that the nullifier has never been used before. Once verified, NOSTR clients can display visual indicators, such as a badge, next to the user's public key.
Technical Highlights
Cryptography: Utilizes Groth16 zk-SNARKs with proofs that are constant size (~200 bytes) and fast to verify (~10ms).
Privacy: It is cryptographically impossible to link a NOSTR key to a real identity; even the issuing country is hidden, with only the certificate hash being public.
Performance: Total end-to-end verification time is approximately 10-25 seconds.
Key Features
Global Coverage: Immediate global applicability supporting ePassports from 178 countries and eID cards from over 28 countries.
Sybil Resistance: Cryptographic nullifiers prevent multiple account creation from a single ID.
Fully Decentralized: No central authority is required, and the verification registry can be implemented as a NOSTR event stream.
Self-Service: Users verify themselves without human interaction.

2026-01-25 12:28:07 UTC

- reply

Yes, my DVM, based on NIP-90 standard and L-402 (LSAT) standard are like two different dialects of the same language: Value-for-Value (V4V) API Logic.

2026-01-24 15:56:28 UTC

https://image.nostr.build/9f956507032c9a82e08085179ab0d447e75bed89e19602d7f6f65ae31c70de9a.png https://audio.nostr.build/fba15d5e37902d5ed25c01854eb36bb2028b29f43af4fa585b2c9a7e390ba98d.mp3

2025-12-15 12:33:48 UTC

- reply

I guess this us a scam
#nevent1q…td6s

2025-09-08 15:18:37 UTC

- reply

Agree 💯 Freedom is No Profit

2025-09-08 15:01:31 UTC

https://john117.pythonanywhere.com
https://blossom.primal.net/de9cf8f0d8f79dbb52768a0bc5a435305dc6345401da5324e7aab2c9c1051126.mp4

2025-08-31 11:44:57 UTC

- reply

The most naive question! Why everybody is so much interested in profit? Wouldn’t be better eliminates profit from our lives?

2025-08-30 01:26:37 UTC

- reply

Correct Raquel, the Octopus won’t release its tentacles easily
https://blossom.primal.net/cab8b54cf0cb606aa9e78aaa57e38c71f380b9acb96bcb88e36ecb24ffe3ad3e.jpg

2025-08-28 22:28:34 UTC

- reply

Thanks for your comment, but I do not understand it, my apologies.

2025-08-28 15:49:27 UTC

Has been said that an image speaks thousand words, despite his age, 1912, this speak so much!
https://blossom.primal.net/cab8b54cf0cb606aa9e78aaa57e38c71f380b9acb96bcb88e36ecb24ffe3ad3e.jpg

2025-07-03 04:36:12 UTC

Time to move to V3
https://blossom.primal.net/f9d45b3b70ba5dced1315a9d864179f7c399751447042c4858adcda24c6d0eff.jpg

2025-07-03 04:17:47 UTC

- reply

Agree, we do not need puppets

2025-06-22 15:20:25 UTC

- reply

What’s going on in this tread?

2025-06-15 17:18:35 UTC

- reply

That’s the state if the art of hypocrisy

2025-06-13 12:14:56 UTC

Hello there. May I ask some volunteers to play around with my Telegram Bot which I integrated with AI and ask for a feedback? Thanks in advance to all of you guys. https://t.me/algocracy_bot

2025-06-11 20:50:40 UTC

- reply

That would not possible to happen with NOSTR, no one is accountable as long remains anonymous

2025-06-11 17:13:10 UTC

- reply

How do they do that?

2025-06-11 12:45:17 UTC

- reply

Then we need abolish Governments and become #sovereign_citizens

2025-06-11 09:30:51 UTC

- reply

Thanks for your reply, so the easiest way is to get AlbyHUB subscription and follow along

2025-06-11 09:13:34 UTC

- reply

Nice, congrats, any advice?

2025-06-11 09:11:29 UTC

- reply

Agree, I guess next frontier will be AI integration

2025-06-09 08:37:54 UTC

- reply

Hi Max, your Declaration of Separation is amazing. I wander how many people would agree. I agree 100% https://media.tenor.com/6BkBUG1NLdIAAAAC/100-100-percent.gif

2025-06-08 18:50:52 UTC

https://blossom.primal.net/f6be8eca38014bb3641df09b6cda3d6b94f02a9cee1fa103d98a9522c7c50693.png SOVEREIGN CITIZENS:
A Decentralized LETS Trading Network
Version 2.0 - June 2025
Abstract
SOVEREIGN CITIZENS reimagines community-based value exchange by combining proven Local Exchange Trading System (LETS) principles with NOSTR protocol communication and blockchain infrastructure. Through a revolutionary three-token architecture that balances opportunity, experience, and economic activity, the system enables global peer-to-peer trading while maintaining the community spirit of traditional LETS. Built as a Progressive Web App on Polygon with NOSTR-based service discovery, SOVEREIGN CITIZENS creates the world's first truly sovereign economic network.
Table of Contents
Introduction
Problem Statement
Solution Overview
Three-Token Architecture
NOSTR Integration
Technical Implementation
Economic Model
Governance Framework
Progressive Web App
Security Considerations
Roadmap
Conclusion
1. Introduction
1.1 Vision Statement
SOVEREIGN CITIZENS envisions a world where individuals can create and exchange value without dependence on traditional monetary systems, central authorities, or geographic constraints. By combining time-tested mutual credit principles with cutting-edge decentralized technologies, we're building infrastructure for true economic sovereignty.
1.2 Core Philosophy
"Money is just information. Let's democratize it." - Our system treats economic exchange as information flow, enabling any individual to participate in value creation regardless of their access to traditional currency.
1.3 Revolutionary Innovation
Unlike traditional LETS systems limited to local communities, SOVEREIGN CITIZENS creates a global network where:
Anyone can trade with anyone through NOSTR-based discovery
Trust scales globally through blockchain-verified reputation
Value reflects life itself through lifespan-based token distribution
Wisdom guides decisions through experience-weighted governance
2. Problem Statement
2.1 The Monetary Sovereignty Crisis
Modern individuals face unprecedented economic dependency:
Artificial Scarcity: Abundant skills and needs constrained by money supply
Centralized Control: Economic participation controlled by banks and governments
Geographic Barriers: Local communities isolated from global opportunities
Wealth Extraction: Value created locally flows to distant financial centers
2.2 Traditional LETS Limitations
While LETS systems address monetary scarcity, they suffer critical weaknesses:
Trust Bottlenecks: Difficulty assessing unknown members' creditworthiness
Scale Constraints: Limited to small, local communities
Administrative Burden: Manual bookkeeping and dispute resolution
Isolation: No interaction between different LETS networks
2.3 The Age-Experience Paradox
Traditional systems create unfair distributions:
Youth: High potential but limited resources and opportunities
Experience: Accumulated wisdom but diminishing time and energy
Economic Activity: Current systems fail to balance opportunity with experience
3. Solution Overview
3.1 The SOVEREIGN CITIZENS Network
Our system creates a global mutual credit network with three revolutionary components:
🌐 Global Discovery Layer (NOSTR)
Decentralized service marketplace
Peer-to-peer communication
Reputation verification
Community formation
⚖️ Value Exchange Layer (Polygon)
Zero-sum mutual credit accounting
Automated dispute resolution
Democratic governance
Transparent reputation tracking
📱 User Experience Layer (PWA)
Native app-like experience
Offline functionality
Push notifications
Cross-platform compatibility
3.2 Key Innovations
Three-Token Balance
Grant Tokens: Reward remaining lifespan (opportunity)
Governance Tokens: Reward accumulated experience (wisdom)
LETS Credits: Enable actual trading (economic activity)
Honor-Based Age Verification
Self-reported birth dates with built-in integrity incentives
Game theory prevents age misrepresentation
Enables fair lifespan-based distribution
Global Trust Network
NOSTR social proof for reputation verification
Blockchain-verified trading history
Community-based dispute resolution
4. Three-Token Architecture
4.1 Grant Tokens (GT) - Opportunity Based
Purpose: Reward remaining lifespan potential
Distribution: (85 years - current age) × 525,600 minutes/year
Properties:
Non-transferable
One-time allocation at registration
Represents potential and opportunity
Decreases as users age
Economic Logic: Younger individuals receive more grant tokens because they have more time to contribute to the network and deserve greater initial support.
4.2 Governance Tokens (GOV) - Experience Based
Purpose: Reward accumulated wisdom and experience
Distribution:
Base: current age × 10 tokens/year
Earned: Activity rewards (trading, proposals, voting)
Properties:
Transferable (can be delegated)
Continuously earned through participation
Represents proven judgment and experience
Used for governance voting weight
Economic Logic: Older individuals and active participants earn more governance tokens because they have demonstrated experience and good judgment over time.
4.3 LETS Credits (LC) - Activity Based
Purpose: Enable actual value exchange
Distribution: Created through mutual credit (zero-sum)
Properties:
Transferable for goods/services only
Created at moment of transaction
Total credits always equal total debits
Subject to credit limits and reputation
Economic Logic: Trading currency follows traditional LETS principles - money is created when value is exchanged, ensuring adequate liquidity without artificial scarcity.
4.4 Token Interaction Model
Young User (Age 25):
├── Grant Tokens: 31,536,000 (60 years × 525,600 minutes)
├── Governance Tokens: 250 (25 years × 10)
└── LETS Credits: Earned through trading
Experienced User (Age 55):
├── Grant Tokens: 15,768,000 (30 years × 525,600 minutes)
├── Governance Tokens: 550+ (55 years × 10 + activity)
└── LETS Credits: Earned through trading
This creates perfect balance: youth gets opportunity (grants), experience gets influence (governance), and everyone can trade (credits).
5. NOSTR Integration
5.1 Why NOSTR?
Decentralized Communication: No central servers or gatekeepers
Global Reach: Connect with traders worldwide
Censorship Resistance: Cannot be shut down by authorities
Interoperability: Works with existing NOSTR infrastructure
Privacy: Users control their data and identity
5.2 Service Discovery Protocol
Service Listings (Kind 30023)
json{
"kind": 30023,
"content": {
"title": "Web Development Services",
"description": "React & Node.js development",
"category": "Technology",
"price": 500,
"currency": "LETS_CREDITS"
},
"tags": [
["d", "service_12345"],
["title", "Web Development Services"],
["category", "Technology"],
["price", "500"]
]
}
Trade Negotiations (Kind 4)
Private messaging for trade details
Encrypted communication
Off-chain negotiation, on-chain settlement
Reputation Verification (Kind 30026)
Public reputation events
Verifiable trading history
Community-based reviews
5.3 Global Network Effects
Viral Growth: Each new user increases value for all existing users
Skill Matching: Global talent pool meets global demand
Cultural Exchange: Economic interaction builds understanding
Innovation Acceleration: Ideas and services spread rapidly
6. Technical Implementation
6.1 Smart Contract Architecture
SovereignCitizensLETS.sol
Member management with birth date tracking
Three-token balance accounting
Credit limit enforcement based on reputation
Automated balance decay (2% monthly on positive balances)
Dispute resolution with community arbitration
Governance proposals and voting
Key Functions:
solidityfunction joinSystem(uint256 _birthTimestamp) external
function executeTrade(address _to, uint256 _amount, string _description, bytes32 _nostrEventId) external
function fileDispute(uint256 _tradeId, string _reason) external
function createProposal(string _title, string _description, bytes _proposalData) external
function vote(uint256 _proposalId, bool _support) external
6.2 NOSTR Client Integration
NOSTRClient.js
Multi-relay connections for resilience
Service marketplace events
Private messaging for negotiations
Reputation tracking and verification
Real-time updates and notifications
6.3 Progressive Web App
Core Features:
Installable on all devices without app stores
Offline functionality with background sync
Push notifications for trades and governance
Service worker caching for performance
Cross-platform consistency
7. Economic Model
7.1 Credit Creation Mechanics
Traditional LETS principles with blockchain verification:
Trade Initiation: Service provider offers service via NOSTR
Discovery: Service requester finds provider through global search
Negotiation: Private messaging to agree on terms
Execution: Smart contract creates credits for provider, debits for requester
Verification: Both parties update reputation
7.2 Credit Limits and Risk Management
Dynamic Credit Limits:
New members: 500 credits maximum debt
Reputation-based adjustments: Higher reputation = higher limits
Community governance: Collective decisions on individual limits
Activity requirements: Inactive accounts face restrictions
Balance Decay System:
Positive balances decay 2% monthly (configurable)
Encourages circulation over hoarding
No decay on negative balances (no interest charges)
Decay proceeds fund community initiatives
7.3 Reputation Economics
Reputation Sources:
Successful trade completion
Positive reviews from trading partners
Dispute resolution outcomes
Community governance participation
Age and experience factors
Reputation Effects:
Higher credit limits for trusted members
Priority in service discovery algorithms
Greater governance token rewards
Access to high-value trade escrow
8. Governance Framework
8.1 Decentralized Autonomous Organization
Governance Token Distribution:
Age-based initial allocation
Activity-based ongoing rewards
Transferable for delegation
No purchase mechanism (earned only)
Proposal System:
Any member with 100+ governance tokens can propose
3-day voting period
Simple majority with 10% quorum
Automatic execution via smart contract
8.2 Governable Parameters
Economic Settings:
Default credit limits
Balance decay rate
Inactivity periods
Reputation calculation weights
System Configuration:
Arbitrator appointments
Dispute resolution procedures
Emergency pause mechanisms
Smart contract upgrades
9. Progressive Web App
9.1 Why PWA Over Native Apps?
Universal Access: Works on any device with a browser
No App Store Gatekeepers: Cannot be censored or removed
Instant Updates: No waiting for app store approval
Lower Development Costs: Single codebase for all platforms
Offline Functionality: Works without internet connection
9.2 Key PWA Features
Installation:
Add to home screen on mobile devices
Desktop installation on computers
Native app-like launch experience
Custom splash screens and icons
Offline Capabilities:
Service worker caching for core functionality
Background sync for pending transactions
Local storage for account information
Offline service browsing
Push Notifications:
Trade requests and confirmations
Governance proposal alerts
Dispute notifications
System announcements
9.3 User Experience Design
Mobile-First Design: Optimized for smartphone usage
Progressive Enhancement: Works on any device capability
Accessibility: Full screen reader and keyboard support
Performance: Fast loading and smooth interactions
10. Security Considerations
10.1 Smart Contract Security
Audited Code: Professional security audit before mainnet deployment
Upgradability: Proxy pattern for critical bug fixes
Emergency Controls: Pause functionality for crisis management
Role Separation: Distinct permissions for different functions
10.2 Economic Security
Sybil Resistance: Reputation and age verification discourage fake accounts
Credit Limit Enforcement: Prevents excessive debt accumulation
Dispute Mechanisms: Community-based fraud prevention
Activity Requirements: Inactive accounts face automatic restrictions
10.3 Privacy and Data Protection
Self-Sovereign Identity: Users control their keys and data
NOSTR Privacy: Optional pseudonymous participation
Minimal Data Collection: Only necessary information stored
Right to be Forgotten: Users can delete their accounts
11. Roadmap
Q3 2025: Foundation ✅
Core smart contract development
NOSTR integration
PWA basic functionality
Three-token system implementation
Q4 2025: Launch
Security audit completion
Polygon mainnet deployment
Public beta with first communities
Full PWA offline capabilities
Documentation and tutorials
Q1 2026: Growth
Multi-community support
Enhanced dispute resolution
Service provider verification
Mobile app optimization
API for third-party integrations
Q2 2026: Expansion
Cross-chain deployment (Ethereum, Arbitrum)
Inter-LETS trading protocols
Merchant payment tools
Advanced analytics and insights
Q3 2026: Evolution
AI-powered service matching
Decentralized identity integration
Carbon credit trading system
Global LETS federation protocols
12. Conclusion
SOVEREIGN CITIZENS represents more than a technological innovation—it's a pathway to economic freedom. By combining the wisdom of traditional LETS systems with the power of modern decentralized technologies, we're creating infrastructure that enables true economic sovereignty.
Our three-token architecture solves the fundamental challenge of balancing opportunity with experience, ensuring fair distribution while maintaining incentives for participation and good governance. The integration of NOSTR communication enables global reach while preserving the community spirit that makes LETS systems successful.
As a Progressive Web App, SOVEREIGN CITIZENS remains accessible to anyone with a smartphone, removing barriers to participation while providing a native app experience. The system's design ensures it cannot be censored, controlled, or shut down by any central authority.
We invite individuals worldwide to join us in building this new economic infrastructure. Whether you're a young person seeking opportunities, an experienced professional sharing knowledge, or anyone simply wanting more economic freedom, SOVEREIGN CITIZENS offers a path forward.
The future of money is decentralized, community-controlled, and based on mutual aid rather than scarcity. Together, we can build an economy that serves people, not the other way around.
Appendices
A. Technical Specifications
Blockchain: Polygon (Ethereum Layer 2)
Communication: NOSTR Protocol
Token Standards: Custom smart contracts
Frontend: React PWA with Web3 integration
Storage: IPFS for metadata, browser storage for user data
B. Economic Parameters
Grant Token Calculation: (85 - current_age) × 525,600 minutes/year
Governance Base: current_age × 10 tokens/year
Default Credit Limit: 500 LETS Credits
Balance Decay Rate: 2% monthly (configurable)
Inactivity Period: 180 days
Reputation Range: 0-1000 points
C. Governance Token Rewards
Trade Completion: 1-2 tokens per trade
Dispute Resolution: 5-10 tokens for arbitrators
Governance Proposal: 10-20 tokens for proposers
Voting Participation: 2-4 tokens per vote
Profile Verification: 5 tokens one-time
D. Contact Information
Website: sovereign-citizens.network
GitHub: github.com/sovereign-citizens
NOSTR: npub1sovereigncitizens...
Discord: discord.gg/sovereign-citizens
Email: contact@sovereign-citizens.network
E. Legal Disclaimer
This white paper is for informational purposes only and does not constitute financial advice, investment solicitation, or legal agreement. SOVEREIGN CITIZENS is experimental software and participants should understand the risks involved in blockchain-based systems. Users are responsible for compliance with local laws and regulations.
"The most revolutionary act in our time is to introduce a new economic system that serves people rather than profit."