Cowrie Research

contextvm-primary-sources-2026-05-02

3 min read

ContextVM primary sources — 2026-05-02

Project status in this pass

  • No canonical standalone ContextVM whitepaper or litepaper surfaced.
  • The clearest current sources of truth were the official website pages, the public servers directory, the public GitHub organization, and the SDK README/package metadata.
  • The materials consistently frame ContextVM as MCP-over-Nostr transport infrastructure with optional payments rather than as a single AI product or simple hosted service.

Primary-source snapshots

1) Homepage

  • URL: https://www.contextvm.org/
  • Key excerpt:
    • The homepage describes ContextVM as “A transport layer for MCP over the Nostr network.”
    • It says there are “no domains, no OAuth, no port forwarding—just keys, relays, and optional payments.”
    • It also says ContextVM works with any MCP server and presents direct value exchange through Bitcoin micropayments as a first-class feature.

2) About page

  • URL: https://www.contextvm.org/about
  • Key excerpt:
    • The About page says ContextVM “liberates” the Model Context Protocol by running it over Nostr.
    • It says identity, discovery, connectivity, and payments move into a decentralized fabric rather than depending on centralized web infrastructure.
    • It also says the project supports both public and private servers and highlights portable identity, outbound-only connectivity, and optional payments as core properties.

3) FAQ page

  • URL: https://www.contextvm.org/faqs
  • Key excerpt:
    • The FAQ says running MCP over Nostr removes the need for public hosting, server provisioning, or port forwarding.
    • It says Nostr provides service discovery, signed-and-encrypted event transport, and optional payments using Bitcoin and the Lightning Network.
    • It also frames ContextVM as usable by both traditional software and AI agents because it stays aligned with MCP’s tool/resource/prompt model.

4) Public servers page

  • URL: https://www.contextvm.org/servers
  • Key excerpt:
    • The servers page presents ContextVM as a public discovery surface for “Public MCP Servers.”
    • It describes these as Model Context Protocol servers running on the Nostr network.
    • The page again emphasizes the “no domains, no OAuth, no port forwarding” framing, which is useful evidence that discovery and connectivity are part of the product surface rather than side details.

5) GitHub organization

  • URL: https://github.com/ContextVM
  • Key excerpt:
    • The organization bio says ContextVM sits at “the intersection of Nostr and MCP.”
    • The public repos include the SDK, docs site, website, relay code, and related tooling.
    • That repo spread reinforces that ContextVM is an ecosystem and protocol/toolchain effort, not just a landing page.

6) SDK README

  • URL: https://raw.githubusercontent.com/ContextVM/sdk/master/README.md
  • Key excerpt:
    • The README says the SDK implements the Context Vending Machine Protocol and bridges Nostr with Model Context Protocol to enable decentralized access to computational services.
    • It says the package includes Nostr client/server transports, a Proxy, a Gateway, relay abstractions, and signer support.
    • It also says existing MCP servers can keep their conventional transports while gaining Nostr interoperability.

7) SDK package metadata

  • URL: https://raw.githubusercontent.com/ContextVM/sdk/master/package.json
  • Key excerpt:
    • The package metadata names the package @contextvm/sdk and tags it with keywords including nostr, modelcontextprotocol, mcp, ai, and llm.
    • Its exports expose dedicated transport, gateway, proxy, relay, signer, and payments modules.
    • That export surface is useful evidence that the project is packaging a transport-and-connectivity stack, not only a demo app.

Working conclusion

ContextVM is best cataloged as decentralized MCP transport infrastructure: a Nostr-based connectivity layer that lets humans and agents discover, access, and optionally pay for remote MCP services without relying on conventional hosting, auth, or routing primitives. The decisive evidence in this pass was the combination of (1) official homepage/about language about replacing domains/OAuth/port forwarding with keys and relays, (2) the FAQ’s explicit discovery/transport/payment breakdown, (3) the public server-discovery surface, and (4) the SDK’s concrete transport, gateway, proxy, relay, and payments modules.

Graph View