Now that payments are in place, we are going to work on: - CEP-19 for ephemeral gift wraps:

GitHub

Issues · ContextVM/contextvm-docs

ContextVM documentation and specification. Alternative link: https://contextvm.github.io/contextvm-docs/ - Issues · ContextVM/contextvm-docs

and - CEP-17 for servers relay list:

GitHub

Issues · ContextVM/contextvm-docs

ContextVM documentation and specification. Alternative link: https://contextvm.github.io/contextvm-docs/ - Issues · ContextVM/contextvm-docs

Both CEPs are quite minimal but yet beneficial for the ecosystem. CEP-19 provides better privacy guarantees, as servers and clients will be able to use ephemeral gift wraps for encrypted communications. Currently, they use regular gift wraps, which are regular events, and even if the events inside are ephemeral, they are wrapped in a regular envelope. CEP-17 defines how servers can announce relay lists (NIP-65) to improve discoverability. Simple but powerful! LG!🚀 After this iteration we will come back to CEP-15 introducing common tool schemas, which is a bigger one

GitHub

[CEP-15] Common Tool Schemas · Issue #15 · ContextVM/contextvm-docs

Preamble Title: Common Tool Schemas Authors: ContextVM-org Status: Draft Abstract This CEP establishes a standard for defining and discovering comm...

We've just released a new version of our SDK, now CEP-8 implementation is now complete, end to end, we’ve added the missing piece for LLM aware spending CEP-8 gives us the wire protocol for paid MCP capabilities, servers request payment, clients settle, both sides get explicit confirmation. What was missing was a clean way to make consent programmable. This release adds a single paymentPolicy hook at the client boundary, a little yet powerful new addition. Your host environment decides whether a charge proceeds: a deterministic budget, a per-tool allowlist, a terminal prompt, or a full LLM-based policy engine. One hook, any pattern. Google's AP2 addresses a similar problem, but it's an ambitious multi-actor framework involving Shopping Agents, Credential Providers, and cryptographic Mandates passed across multiple parties, quite complex. Our take is different, CEP-8 provides the payment rails, Nostr anchors every request to a cryptographic identity at the transport level, and consent is a composable local primitive. Simpler to integrate, and versatile enough to fit whatever your host needs to do. This our take on agentic payments, simple, versatile, composable, no vendor lock ins

After a few days experimenting and receiving feedback around CEP‑8 payments, we enhanced their SDK implementation, making payments more reliable and consistent. We’ve just released a new feature that supports additional use cases, such as servers with prepaid balances, top‑up accounts, or separate payment management. This feature lets you waive a payment via the server’s resolve price callback. With this update, payment processing is far more powerful 🚀 Docs and skills have been updated accordingly. Happy building :) Docs:

ContextVM Documentation

Payments (CEP-8)

Learn how to add payment handling to your ContextVM servers and clients using CEP-8

Skills: npx cvmi add --skill payments, or npx skills add contextvm/cvmi --skill payments

Get it fresh in your inbox every two weeks! View quoted note →

GM Nostr! Our newsletter, The ContextVM World 🌍, is now live on Substack:

The ContextVM World 🌍 | Substack

Your biweekly appointment with ContextVM, MCP, and Nostr. Click to read The ContextVM World 🌍, a Substack publication. Launched 2 months ago.

While ContextVM is built on Nostr and will continue to publish natively on Nostr, our goal is to reach a larger audience outside of Nostr to have more builders leveraging our protocol! Feel free to subscribe to our Substack and to share our newsletter with the world!

The second issue of "The ContextVM World" is out! Hope you enjoy it 💛 View article →

Thanks so much to openSats for this opportunity! We'll keep pushing the boundaries of this new paradigm 💛 View quoted note →

Protocols over Platforms is the mantra at the core of CVM

Use Protocols, Not Services

The Internet is almost anonymous and privacy-preserving by design. I mean, unless some administrator actively tries to track you, there is no built...

https://lemonade.contextvm.org View quoted note →

These are badges are real, you can check them here as well: https://nostrsigil.com/badges/naddr1qvzqqqr48ypzpl0zzdglhjrqfsnaelea2plcaxc4gw8nh5zqj09rl4tu66ekckxsqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsqyrvv4kk7mnpv3jj6mr9vajkuernaqgdnx View quoted note →

🍋 Introducing Lemonade Legends, our newest teaching project that demonstrate how to use CEP-8 in a tangible and fun way! Do you want your lemonade legend badge? https://lemonade.contextvm.org This is a server that mints nostr badges with dynamic pricing: 21 sats on day 0, +21 sats each day after. A live experiment in paid capabilities, SQLite accountability, and dual APIs (humans via UI, agents via MCP). The idea behind this project was to create a new and fun educational resource for the CVM ecosystem. You can read our blog post here: https://contextvm.org/blog/lemonade-legends or in nostr. What we did for this project: ✨ Server + Svelte app, both open source ✨ Step-by-step blog post walking through the code ✨ Copy-paste ready patterns for your own paid tools Dive in → https://contextvm.org/blog/lemonade-legends Server → github.com/ContextVM/lemonade-legends Site → github.com/ContextVM/lemonade-legends-site What will you build with CEP-8? 💛 #lemonadelegends #contextvm #cep8 #nostr #bitcoin #lightning #opensource View article →

Just pushed a new payment processor for our SDK based on ZAPS!⚡️ It only requires an LN address to be used, it couldn't be easier⚡⚡️ With this new payment processor, our SDK now supports three payment processors based on Lightning BOLT11: NWC, LNbits, and now ZAPS⚡ To use it, simply update to the latest contextvm SDK. The only consideration regarding this payment method is that ZAPS can be faked by the provider of your LN address. If you trust the provider of the configured Lightning address, there is no problem, it could even be your own node. However, if you don’t trust the provider, the ZAP receipt alone is not sufficient to prove settlement. This is not a new issue; it has been discussed and is already covered in an appendix in nip-57 Hope you enjoy!⚡️⚡️⚡️

This is why CVM. In an agent-mediated world, the shipped feature set matters less than what an agent can discover and compose at runtime. Your real product becomes your callable surface area: reliability, clear schemas, predictable behavior, and the ability to snap into workflows you didn’t design. That shift makes distribution the new battleground. If discovery collapses into a handful of registries and default tool lists, the ecosystem recentralizes fast, no matter how open the API spec looks. You can already see the gravity well: MCP’s mainstream path tends to reintroduce old control points, registries anchored to domains, OAuth-based access, and platform-shaped “approved” directories. They’re convenient, but they harden into gatekeeping, and single points of failure. ContextVM is built to route around that. It runs MCP over Nostr so services are addressed by public keys, routed over relays, and announced publicly without permission. Discovery becomes a network primitive instead of a platform feature. Relays act as decentralized repositories, and curation becomes competitive and plural rather than owned. We’ve just added payments in a way that composes cleanly with autonomous, per-call usage. If agents can swap tools mid-workflow, pricing has to be as modular as the capabilities themselves, without dragging builders back into accounts, gatekeepers, and permissioned land. ContextVM’s wager is simple: if agents are going to assemble the future on the fly, the underlying rails for identity, discovery, and payment must be open, permissionless, and censorship-resistant by default. View quoted note →

It takes you ~20 LOC to enable payments in your server. NWC + CVM = 🤯 The code:

GitHub

dummy-paid-server/index.ts at main · ContextVM/dummy-paid-server

Contribute to ContextVM/dummy-paid-server development by creating an account on GitHub.

View quoted note →

Pro tip: get the CVM skills for payments `npx cvmi add --skill payments -y` Ask your agent to build something profitable, use an NWC connect string, and start monetizing. Quite easy. Additionally, there is an LNBits backend available in the SDK, and the skills come with documentation on how to build your custom payment rails if you need. Let's build! 🚀 View quoted note →

Payments Have Arrived! 🚀 ContextVM now supports payments with CEP-8! Your servers can finally become digital lemonade stands, paid, permissionless services that anyone can run and consume without asking for permission. This release packs everything you need. The new version of the SDK have everything you need, even ships with Lightning BOLT11 integrations (NWC and LNbits), the ContextVM site now supports payment discovery, cvmi and skills has been updated, and the docs cover the full flow. Want to see it in action? The dummy demo server (https://github.com/ContextVM/dummy-paid-server) shows you exactly how to price and monetize a capability. Looking forward to hear your thoughts and see what you are building! Read the docs:

ContextVM Documentation

CEP-8 Capability Pricing and Payment Flow

Pricing mechanism and payment processing for ContextVM capabilities

Build a stand. Price a capability. Let value flow. If you have any question just ask View article →

Payments are coming imminently 🚀

Just shipped some clarity improvements to CEP-8 🎯 We are pretty close to getting this done; we just shipped some clarification to the payments spec so some concepts are less ambiguous. The spec now has well-defined PMI (payment method identifier) boundaries, clarifiying what goes in `pay_req`. We've added a recommended PMI registry with precise payload semantics, plus naming conventions to keep things unambiguous as the ecosystem grows. Also new: optional direct payments for bearer assets. When both parties support it, you can skip the roundtrip, just attach `["direct_payment", "<pmi>", "<payload>"]` to your request and you're done. Good for cashu 🥜 The ongoing implementation remains unchanged, this is all documentation and specification hardening. Current spec:

GitHub

contextvm-docs/src/content/docs/spec/ceps/cep-8.md at ed71abec7bd93ba1082e67dfc92f0b0bcf618a72 · ContextVM/contextvm-docs

ContextVM documentation and specification. Alternative link: https://contextvm.github.io/contextvm-docs/ - ContextVM/contextvm-docs

SDK progress: github.com/ContextVM/sdk/pull/24 Feedback welcome! View quoted note →

📡 New relay live! wss://relay2.contextvm.org 📡 We were running a public relay at wss://relay.contextvm.org and have now added a new relay to increase redundancy. This new relay is hosted by a different provider in a different location, ensuring that if one provider experiences an outage, the other will remain available. Additionally, there is a third relay operated by @Pete Winn at wss://cvm.otherstuff.ai Note: You can use any public relay for CVM stufff, but these three are more optimized as they reject other events not related with CVM and do not store events, they are ephemeral. We have also added a new section to our awesome repo to make it easy to find these relays:

GitHub

GitHub - ContextVM/awesome: Awesome things based on ContextVM

Awesome things based on ContextVM. Contribute to ContextVM/awesome development by creating an account on GitHub.

The PR is not even merged yet, and we already have @klabo contributing an LNbits payment processor and handler 🚀 Thanks so much for the contribution 💛 The PR will ship two payment processors and handlers: NWC for making it work with any wallet supporting NWC, super easy to configure and use. And LNbits, which will allow the use of an LNbits backend as a payment processor and handler. More built-in payment methods can be added in future iterations. Anyone will be able to create their custom ones as well View quoted note →