Modules as the unit of automation

A Priime module does one thing. It watches one signal, runs deterministic logic when that signal moves, and writes one transaction only when it must. Most ticks it returns nothing. That restraint is the design, not a limitation of it.

The claim, stated so you can falsify it: every Priime product is a composition of the same small modules on one shared verifier-and-operator rail, which means a new strategy is an assembly job, not a rebuild. If that holds, two live products and one in private preview should decompose into a handful of recurring bricks sharing one settlement path, and the next product should reuse most of them. If a new strategy instead required a new operator set, a new verifier, or a new keeper, the thesis is wrong. The rest of this post lays the bricks on the table so you can check.

Why now: the unit of automation has been wrong

On-chain strategies have mostly shipped as monoliths, a single strategy contract bolted to a keeper bot, with risk logic, hedging, and rebalancing tangled into one deployment. Each new strategy means a new monolith: new code holding funds, a new privileged automation key, a new thing to audit end to end. The cost of shipping the second strategy is roughly the cost of the first, because nothing is reused below the strategy line.

The module flips the unit. Instead of the strategy being the smallest shippable thing, the smallest thing is a single Observe-Reason-Act loop scoped to one concern. Products become arrangements of those loops on infrastructure that is already built and already verifiable. The cost of the second product is the cost of its new arrangement, not its new plumbing, and that is where shipping speed compounds.

Mechanism: one module is one Observe-Reason-Act loop

Observe is the read. A module fetches one signal at block time, on-chain or off-chain: a health factor, a pool's current tick, an oracle's last update, a funding rate, a bridge's liveness. The read can pull from anywhere, which matters, because the data that should move a position often lives on a different chain than the position itself.

Reason is the compute, and it runs as sandboxed WebAssembly, deterministic by construction: same inputs, same output, every time. This is where the strategy actually lives, the thresholds, the sizing math, the decision about whether anything needs to change. Determinism is not a style choice. It is the property that lets independent machines run the same code and arrive at the same answer, which is what makes the result checkable later.

Act is the write, and it is conditional. A module emits a transaction only when its logic says one is required. A hedge module that finds the position already flat does nothing. A risk module that finds the position inside its bounds does nothing. The action is the exception, not the heartbeat. A position can be monitored every block and touched rarely, that is the intended behavior, because every needless transaction is cost and attack surface a builder did not ask for.

Read the table as a parts bin, not a feature list. Two of these, Endogenous and Exogenous Risk, are the same risk discipline split by where the threat comes from. Endogenous Risk watches the position's own state and trims it through a graduated cascade rather than a single liquidation cliff. Exogenous Risk watches everything the position depends on, the oracle that prices it, the venue that holds it, the bridge that feeds it, the stablecoin it is denominated in, and de-risks the moment any of those degrade, before the degradation reaches the position. Different signal, same restraint: act only when you must.

The rail: why a module's output is provable

A module's logic does not run on a server. It runs on the processor, the shared rail that separates a Priime module from a cron script. The processor executes the same WebAssembly across a set of independent operators. Each operator runs the code, signs its result, and an aggregator proceeds only when a quorum produces matching signatures. An on-chain verifier checks those signatures against the operator set before anything settles.

The consequence for a builder is specific: every action a module takes is provable, not trusted. The deterministic WASM from the Reason step is exactly why this works, if the logic were nondeterministic, independent operators could not agree, and there would be nothing to verify. The module's restraint and the processor's restraint are the same restraint at two layers: the module decides nothing needs doing, and the processor settles nothing. When the module does decide, the result that lands on-chain carries proof that a quorum computed it the same way.

Evidence: the live products are the same bricks, arranged differently

An app is a set of modules arranged on the processor. Three exist today, and the overlap between them is the whole argument.

Priime Pools (live) turns a liquidity pool into a delta-neutral execution product: it collects concentrated LP fees while hedging out the price exposure, managed at block time. Read as modules, Auto Center keeps the range collecting fees, Dynamic Hedge holds the directional exposure flat, and the Endogenous and Exogenous Risk modules watch the position and its dependencies. The yield is fees, not emissions; the decomposition of that yield is its own post.

Priime Loop (live) is a leveraged lending loop hedged dollar-for-dollar by a matching short, delta-neutral, with a block-level cascade that deleverages before liquidation and levers up when there is room. Read as modules, Dynamic Leverage runs the loop, Dynamic Hedge holds the matching short, Endogenous Risk runs the cascade, Exogenous Risk watches the venues underneath.

The next products are further arrangements on the identical rail, same operators, same verifier, same module vocabulary, a different configuration on top.

What this buys: shipping speed that compounds

This is the part that changes how a builder plans. A new Priime product is a new arrangement of modules, it is not new infrastructure. The processor already runs WASM across operators and verifies the result on-chain. The risk modules already watch the position and its dependencies. The hedge, leverage, and centering modules already exist and already settle. A builder composing a new strategy is choosing which modules to arrange and how to wire them, not standing up an operator set, not writing a verifier, not building a keeper, not reimplementing a hedge.

Because each module owns exactly one concern and acts only when it must, the arrangements stay legible. You can reason about a Pools app or a Loop app one module at a time, and you can reason about a new arrangement the same way before it ever touches a chain. The infrastructure is the constant; the arrangement is the variable. That is why the second product is cheaper than the first, and the third cheaper than the second, the constant is already paid for. Shipping speed compounds because the denominator stops growing.

Risk & failure modes: what the lego framing does not remove

Composition reduces build risk. It does not remove market risk, and the design does not pretend otherwise. A few failure modes are explicit:

• The hedge has a cost. Dynamic Hedge resizes a short that pays or receives funding. In a high-funding regime the hedge can erode the fee or carry residual it is protecting, flat delta is not free delta.
• Rebalancing costs gas and slippage. Auto Center and Dynamic Leverage write transactions; each write is cost. The modules' restraint mitigates this but cannot zero it, and a choppy market drives more writes.
• Endogenous Risk trims, it does not guarantee. A graduated cascade is gentler than a liquidation cliff, but a fast enough move can still outrun the steps. "Before liquidation" is a target, not a promise.
• Exogenous Risk depends on detection. It de-risks when a dependency degrades observably. A dependency that fails instantly and silently is the residual it cannot fully cover.
• Shared rail, shared blast radius. One verifier and one operator set across all products is the source of the reuse, and a correlated failure point. A liveness or quorum fault on the rail affects every product on it at once.

The composition model concentrates risk into a small number of audited, reused parts. That is a feature for legibility and a thing to watch for correlation, in the same breath.

Verification: how to check the claim

The thesis is checkable without trusting this post. Each module's action settles through the on-chain verifier, so the transactions a Pools or Loop position emits are readable on-chain, you can confirm that a hedge resize or a deleverage step carries a quorum-signed result, not a single key's say-so. The reuse claim is checkable structurally: the same operator set and the same verifier contract back Pools and Loop, so the rail addresses are shared across products rather than duplicated per strategy. And because the Reason step is deterministic WASM, the published component is the thing the operators run, same inputs, same output, reproducible by anyone who runs the same code.

The honest open question is the one the bars chart only illustrates: how small the marginal build of the next product actually is when a third arrangement is attempted. The architecture says it should be mostly wiring. That is the number worth watching.

The takeaway

The unit of automation in a Priime product is the module: one signal observed, deterministic logic, one conditional action, provable when it fires. Apps are arrangements of those modules on a single verifier-and-operator rail that is already built and already verifiable. Pools and Loop are two arrangements of the same five-brick set. Because the rail is the constant and the arrangement is the variable, a new strategy is assembly, not a rebuild, a hedge module, a risk stack, and one new piece of logic, snapped onto a board that already settles, with keys that stay yours, across EVM, SVM, and Move. You do not build the next product. You arrange it. The open question we are testing in the open is exactly how cheap that arrangement gets.