← Back to Blog

What It Means to Build a Primitive

This line of thinking is what led us to build Lightning Enable.

What It Means to Build a Primitive

There’s a word that gets used a lot in technical conversations, especially around infrastructure: primitive. It sounds abstract, even a little pretentious, so it’s worth grounding it in something concrete.

A primitive is not a product category. It’s not a feature. It’s not a buzzword. A primitive is the smallest unit of functionality that remains useful even when everything else around it changes.

TCP is a primitive. Cryptographic hashes are primitives. SQL transactions are primitives. They don’t care what application you’re building, who the user is, or how money is made. They simply do one thing, predictably, every time. Because of that, everything else can be built on top of them.

That’s the lens I’ve been using to think about Lightning Enable.

What a Primitive Actually Is

A real primitive has four properties.

First, it’s irreducible in practice. You can wrap it, automate it, orchestrate it, or abstract it, but you can’t remove it without breaking the system. If you take TCP away, the internet stops working. If you remove settlement from paid software, monetization collapses.

Second, it has stable semantics. A primitive does the same thing every time. It doesn’t encode business rules, pricing strategy, or opinions about user intent. A Lightning invoice either settles or it doesn’t. There’s no ambiguity.

Third, it’s composable. Primitives don’t insist on owning the workflow. They slot into other systems cleanly. They don’t demand custody, identity, dashboards, or lifecycle control just to function.

Fourth, it’s mechanically truthful. When a primitive says something happened, there is a cryptographic or protocol-level reason it happened. No trust fall required.

If a system fails one of these tests, it’s probably an application or a platform, not a primitive.

Why Settlement for Software Matters

Most payment systems today are built for humans. They assume logins, accounts, contracts, invoices, reconciliation cycles, and lawyers. That model breaks down when the thing that needs to pay is software.

APIs don’t want subscriptions. AI agents don’t want invoices. MCP tools don’t want to negotiate pricing plans. They want to request a resource, pay for it, and move on.

That’s where settlement becomes interesting.

Settlement is the moment value actually changes hands. Not billing. Not pricing. Not accounting. Just the irreversible transfer of value. If you can make settlement cheap, fast, and programmatic, you can let everything else evolve independently.

Lightning does exactly that.

A Lightning invoice paid via L402 is a settlement primitive. An HTTP request comes in. A payment requirement goes out. The payment settles. The response is unlocked. No accounts. No custody. No delayed reconciliation.

It’s boring in the best possible way.

What Lightning Enable Is (and Is Not)

Lightning Enable is not trying to be a wallet. It’s not trying to be a billing platform. It’s not trying to be a marketplace or a pricing engine.

It’s intentionally narrow.

It exists to let software settle value with other software, non‑custodially, using Lightning, in environments that actually matter to enterprises.

That constraint is the product.

By refusing to own funds, pricing logic, usage metering, or authorization, the system stays composable. It can sit underneath MCPs, AI agents, APIs, proxies, schedulers, and automation frameworks without becoming a bottleneck.

This is where most existing solutions quietly fail. They demonstrate the primitive, then wrap it in opinions that make it unusable in real systems.

Why This Looks “Early” (and Why That’s Fine)

Primitives almost always look obvious in hindsight and unnecessary at the moment they’re built.

TCP existed before the web. TLS existed before large‑scale e‑commerce. Virtualization existed before cloud computing made it mainstream.

Autonomous software with real spending authority is coming. Today it’s API calls and MCP tools. Tomorrow it’s agents negotiating, purchasing, and coordinating on their own.

When that happens, the systems that survive will be the ones that made value transfer disappear into the substrate.

That’s the goal here.

Not to invent money. Not to sell hype. Not to out‑market incumbents.

Just to make settlement so mechanical, predictable, and boring that nobody has to think about it again.