Software That Can Survive Its Builder

Ross Campbell has a demanding test for software: can the builder walk away and leave something that still works?

That question runs through the open-source blockchain software he is releasing now. Accounts, payments, organizations, domains, and exchange tools appear as distinct projects, but the design instinct is consistent. Put more of the application onchain. Keep the parts simple enough to inspect and recombine. Reduce the number of services that must stay alive behind the scenes.

It is less a product launch than a working argument about what Ethereum software can be.

The current build

In a recent public thread, Ross mapped the work across five areas: a timelocked multisig for accounts, timelocked sends for payments, Moloch Majeur as organization software powering zOrg and zFi DAICOs, Wei Name Service for domains, and ZSwap for exchange.

The immediate objective is not to funnel every use case into one large platform. It is to release small, composable pieces that people can run, inspect, and build on. ZSwap demonstrates the approach by composing multiple exchange contracts behind a simpler interface. Elsewhere, Ross experiments with HTML stored in contract bytecode and token-list graphics and metadata associated with contract addresses.

These are released tools and demonstrations, not a blanket claim that every component is audited, immutable, or ready for production. The useful signal is the direction: onchain settlement paired with interfaces and metadata that depend less on conventional hosting.

The builder's perspective

Ross describes the goal as repeat-use software he can walk away from while it continues to work. That “walkaway test” is a sharp filter. It pushes against software that quietly relies on its original team, a hosted frontend, or a company server to remain useful.

His view of agent-assisted development has a similar boundary. Agents can do more of the implementation, but humans must keep the ability to “say no.” At the smart-contract layer, speed without judgment can harden a shortcut into deployed code. Autonomy is useful; veto power still matters.

The RaidGuild connection

This line of work did not begin with ZSwap.

In 2020, Ross contributed to RaidGuild's alpha Simple Code Deference Agreement repository, or SCoDA. The experiment connected written contract terms to an Ethereum smart contract. GitHub records one contribution from Ross, so the right credit is precise: he was a contributor to a RaidGuild team experiment, not its sole author.

RaidGuild later worked with Ross on guild-focused changes to LexLocker and LexGuildLocker. An archived retrospective documents automated spoils and a working mainnet result, along with unresolved problems around privacy, testing, rounding, and coordination. It is a useful receipt because it records both what shipped and where the work fell short.

By 2022, RaidGuild meeting notes pointed members toward Ross as someone worth consulting during a discussion about what belonged on paper in a legal-wrapper structure. The notes show trust in his legal-engineering perspective; they do not claim he took on that work or gave specific advice.

Together, those records show the relevant continuity. Ross has spent years working at the boundary between agreements and execution: deciding what code should enforce, what people should retain, and how the two fit together.

Proof in the open

The current work is visible in a public release thread linking the timelocked account and payment tools, Moloch Majeur, zOrg, zFi, Wei Name Service, and ZSwap. A public slop.computer interview goes deeper, showing how Ross thinks about onchain HTML, contract-linked token metadata, exchange composition, and agent-assisted development.

The older trail is public too. The SCoDA repository records Ross's contribution to the agreement experiment. RaidGuild's Escrow RIP retrospective records the LexLocker collaboration and its mainnet outcome. His public GitHub history connects the legal-engineering work to years of Solidity experimentation.

None of that needs résumé polish. The throughline is in the artifacts.

What comes next

The open question is whether the walkaway test can hold as these tools meet other users. Software can be self-hosting and composable while still needing clear documentation, careful review, sensible defaults, and people willing to test the edges.

That is where readers can help. Try one of the live demonstrations. Review a contract or interface. Test an integration. Improve the documentation. If you have built account, DAO, naming, or exchange infrastructure, compare assumptions with Ross and report where the pieces compose cleanly—or do not.

Durable software earns that description after other people can understand it, use it, and keep it moving.

Primary links

• Ross's current release thread

• Public interview

• Ross Campbell on GitHub

• RaidGuild SCoDA repository