Spend an afternoon exploring how Newton actually wants a new builder to get started, and you run into two contradictory instructions almost immediately. The public facing site invites you to book a call, promising the team will help you get a first policy live with support running from architecture through integration and launch. The newt-foundation GitHub organization, meanwhile, hosts nine public repositories including a Rego interpreter, a forked EigenLayer SDK, and a mockestrator demo built specifically so a developer can run policies locally without talking to anyone at all. Same protocol, two completely different first impressions depending on which door you walk through.
The concierge path
A book a call funnel is standard practice for enterprise infrastructure selling into institutions, and Newton's target customers, vault curators managing real capital, stablecoin issuers, RWA platforms, are exactly the kind of buyer who expects that motion. Nobody running a nine figure vault wants to debug a Rust interpreter themselves. They want a team that will hold their hand through architecture decisions, help them pick the right prebuilt policy from the catalog, and be reachable when something breaks in production. This path optimizes for trust transferred person to person, closing deals the way enterprise software has always closed deals.
The self-serve path
The GitHub side of Newton tells a different story about who the project is for. Regorus, the team's own Rust interpreter for Rego, sits in a public repo alongside quickstart-policies and mockestrator, tools built so a curious developer can clone a repo, run a mock operator network locally, and watch a policy evaluate and reject a test transaction without ever creating an account or scheduling a meeting. That is the classic open source infrastructure playbook, the one that built trust for tools like Kubernetes and OPA itself, the same Rego language Newton borrowed rather than inventing from scratch. It optimizes for a different kind of trust, the kind earned by letting a skeptical engineer verify claims on their own machine before ever engaging commercially.
Why both exist and what tension that creates
Most successful infrastructure companies eventually run both channels simultaneously, a self serve tier for smaller or more technical users and a white glove tier for larger accounts, and there is nothing unusual about Newton doing the same. The interesting question is not whether both paths should exist, it is what a person actually learns about Newton depending on which one they encounter first.
A developer who starts with mockestrator gets a bottom up education: they see the Policy Client, the Calling Address, and a rejection reason printed in plain text from code running on their own laptop. Their mental model of Newton starts concrete and mechanical. A prospect who starts with a booked call gets a top down education: they hear about the four enforcement domains, the institutional backing, the audit history, framed as a pitch rather than discovered as code. Their mental model of Newton starts abstract and narrative.
Neither education is wrong, but they are not the same education, and they can produce two different populations of Newton advocates who would explain the protocol to a third party in noticeably different ways, one reaching for code and receipts, the other reaching for the pitch deck's framing.
The unresolved part
What is genuinely unclear from the outside is how much these two funnels actually overlap in practice. Does the enterprise prospect who books a call ever end up reading the GitHub repos afterward, closing the gap between the pitch and the mechanics underneath it? Does the self taught developer running mockestrator locally ever get pulled into the concierge relationship once their use case scales past a demo? If the two paths stay mostly separate, Newton risks having two different publics with two different levels of technical grounding in what the protocol actually does, which matters more for a security and compliance product than it would for almost any other category of software, since the whole value proposition rests on people trusting the mechanics, not just the pitch.
I tested this myself in a small way, running mockestrator one evening and then reading the call to action copy on the main site the following day, back to back. The gap between the two experiences was large enough that they barely felt like the same product, and I already knew what Newton was supposed to be before starting either one. A first time visitor arriving cold through only one of those two doors would come away with a meaningfully narrower picture than either path alone can offer, and there is no obvious signpost on either page directing someone toward the other.
@NewtonProtocol $NEWT #Newt $LAB $VELVET
