What began as a way to recover context across coding-agent sessions became a proposal for portable computers with cryptographic identities, content-addressed state, and an auditable path through every action they take.
The short version
- Skein is a sandboxed virtual computer whose inputs arrive as signed messages or Bitcoin proofs and whose state is stored as a content-addressed graph.
- Each application writes to its own branch of state while the whole instance can read shared content by hash.
- Deterministic programs, transaction dependencies, and Merkle proofs make past states replayable and let unresolved work pause until evidence arrives.
- A BRC-100 wallet gives each instance an identity and budget, while private keys remain behind the host wallet interface.
- The same pieces could support agents that pay for inference and compute, but David emphasized that the project was still at the kernel and refinement stage.
- The meetup closed with a preview of the BitGenius developer API and a request for builders to spend more time testing and improving one another’s applications.
Utility still needs a market
The opening connected application adoption to market access. Interoperable wallets and BRC-100 applications are becoming easier to combine, but people still need a practical way to acquire BSV before they can use it for payments, data services, games, or compute. The group treated access, credibility, and useful applications as mutually reinforcing parts of the same adoption problem.
This theme returned later in a long discussion about publicity and proof. One view called for clearer public messaging and easier exchange access. Another argued that the strongest marketing is working infrastructure: systems that fulfill the network’s claims under real use. The common ground was concrete—help more people obtain BSV, then give them applications worth using it in.
Skein starts with a sandbox and one signed door
David described a skein—pronounced “skane”—as a small virtual computer with deliberately narrow interfaces. It can exchange signed messages through a message box, authenticated HTTP, or libp2p. The instance has a BRC-100 wallet identity, so outbound messages can be tied to its keys and inbound messages can be checked against the identities that sent them.
Inside the boundary, every file, message, process step, and state change becomes part of a content-addressed graph. Skein borrows from IPLD: content is named by its hash, and links between objects preserve the route through prior state. A current “head” identifies the computer’s present view while earlier versions remain available to replay, branch, or merge.
State can wait for proof
The graph is more than an activity log. A process can depend on a transaction whose final status is still unknown. Instead of flattening that uncertainty into a premature success or failure, the thread can stop at the dependency. When a Merkle proof arrives, Skein can continue from that point; if the proof changes after a reorganization, the dependent state can be replayed from the new evidence.
Programs run as WASI modules, giving the runtime a path to support familiar tools and languages while preserving the sandbox. David said he had already loaded shell tools, Git, Python, and JSON utilities. Each installed application owns its writable section of the graph, while content that is known by hash can be read across the instance.
That model also makes deployment portable. A fully configured instance can begin from a known Git commit or an on-chain transaction bundle. Because the starting content is hash-addressed, two hosts can reconstruct the same software and state instead of trusting a mutable download location.
An overlay can emerge from signed peers
David used token overlays to show how the pieces fit together. A Skein instance can subscribe to a libp2p topic, learn about submitted or accepted transactions, request the missing parts of their dependency graph, and update its view as proofs arrive. Peer identities derive from the instance identity, so the messages that move the graph forward remain attributable.
This does not require one central operator to distribute the current database. Peers with an economic reason to maintain a marketplace or token inventory can synchronize the information among themselves. David proposed Pixel Fox collection tracking as an early example, while noting that the deployable overlay demo was still a near-term goal rather than a finished product.
A wallet turns the runtime into an economic agent
The agentic version of Skein joins the runtime to paid services. An instance could use its own BSV balance to buy inference or compute, record every request and response, and expose the resulting execution graph for audit. Tool calls remain constrained by the applications and interfaces installed inside the sandbox.
The wallet is also a security boundary. David clarified that private keys do not need to live inside the Skein. Signing and wallet operations route through the host’s BRC-100 interface, allowing the same runtime to operate on a server, laptop, or browser while the host controls custody.
The discussion pushed the idea toward self-funding agents that might pay for hosting, inference, or even additional instances. That possibility made auditability feel less optional, but David repeatedly separated the architecture from the current implementation: at the time of the meetup, Skein had its kernel and core wiring, not a production system autonomously spending funds.
The original problem was lost agent context
Skein’s starting problem was practical: David used several coding agents across multiple computers and could no longer remember where a session or piece of work had been left. Git preserved source history, but it did not preserve the complete path of prompts, tool calls, inference responses, and external events that led to each change.
Folding those interactions into the same graph gives an agent a searchable memory of its work. Rather than checking out one branch and losing sight of the rest, it can walk the relationships among sessions, files, decisions, transactions, and outcomes. The runtime wakes for an event, advances the relevant thread, and can return to rest while it waits for the next signed message or proof.
BitGenius opens an API, and builders need feedback
The final product update previewed the BitGenius developer API. Its public documentation describes OpenAI-shaped Responses and Chat Completions endpoints for source-grounded BSV applications, with client-executed function tools and locally managed conversation history. The meetup described BSV payment per call as a direction; the published compatibility table currently marks the BRC-105 payment adapter as planned.
The closing request was social rather than technical. Builders were encouraged to spend a meaningful share of their time trying other people’s applications and leaving useful feedback. Products built quickly with AI still need human judgment, and feedback submitted to an automated agent needs review before it can trigger consequential changes.
Explore the projects mentioned
- Full meetup replay
- Skein project overview
- BitGenius developer API
- BitGenius
- BSV Blockchain Standards repository
- B-Open BSV skills for coding agents
This recap was prepared from a complete local transcript of the October 2, 2026 recording. Project status and product boundaries were checked against the official Skein and BitGenius sites on the publication date.