Bliss
Bliss is the on-chain OS — the layer people and organizations actually operate through, and the first application built on Impactium's execution layer. Its job is to carry the influx of data and the automated pipelines subliminally, so the people using it stay in flow: focused on the work they came to do rather than on the machinery underneath.
The name is not decoration. On the 0SCALE, 0TRUE at +3 is BLISS — the peak state on the band the whole system measures against. An OS named for it is committing to the state it is supposed to produce.
impactOS — Impact Relationship Management
The clearest way to describe Bliss is by analogy to the software organizations already run on. A business runs on CRM and ERP: systems of record that carry customers, resources and operations. IRM — Impact Relationship Management — is the impact-native equivalent, and Bliss is the implementation.
The shape of the work is ingest → automated pipelines → settle:
- ingest — the influx: claims, evidence, documents, contributions, exchanges with other organizations
- automated pipelines — the steps that carry that influx through attestation, valuation and routing, without a person shepherding each one
- settle — the result lands on L1 as permanent, verified record
That last step is what makes this different from a workflow tool that happens to touch a blockchain. The pipeline does not report to the chain afterwards; its steps run on-chain and settle there.
The dApp Engine
Bliss is not only an application — it is the runtime other applications are served by. It renders and executes dApps in both directions: headless and UI, for humans and agents alike, with functionality layered and lazily loaded so that a request pulls in exactly what it needs and no more.
This is why Bliss is the first thing built on the execution layer rather than one app among many. An execution layer with a single hard-coded application is not proven; an execution layer whose first application serves other applications is. The deterministic Wasm executor that permissionless dApps will eventually need is folded in as Bliss's executor, not built as a separate stage beside it.
What is built today
Bliss v0 is a deterministic job queue, and it is real. A transaction appends a job; the node's end-block hook processes every job that has come due, in ordered state-key order — so every honest node performs the same work in the same sequence and arrives at the same state.
| The queue | |
|---|---|
| enqueue | MsgEnqueueJob { kind, payload_ref, run_at_height } |
| stored as | PipelineJob — id, kind, payload reference, status, enqueued height, due height |
| status | PENDING → DONE or FAILED |
| scheduling | by block height, not wall clock — the chain has no clock to trust |
| execution | the end-block hook, in deterministic key order |
Scheduling by height rather than time is what makes deferred work safe to put in consensus at all: "run at height N" means the same thing on every node, and "run at 14:00" does not.
Its execution is governed, not merely registered. Bliss reads its own manifest from x/app and refuses to work unless that manifest is ACTIVE. An app the registry has never heard of is refused outright, because absence is not permission. That matters concretely: before this was wired, Bliss had zero references to the registry, so deprecating it through governance would not have stopped it from running. Governance that cannot actually stop a thing is not governance.
The founding manifest is seeded ACTIVE rather than awaiting review, because Bliss is compiled into the node: a native app's presence in the binary is its admission. REGISTERED describes a third-party upload awaiting review — which nothing is yet.
What is NOT built. Everything above the queue. The IRM surface, the pipelines themselves, the dApp Engine, the renderer, the Wasm executor — all designed, none shipped. Bliss today schedules and runs deterministic jobs; it does not yet manage anyone's impact operations.
One gap is worth naming plainly: there is no compute metering. Nothing currently bounds what an application costs the chain. Impactium has no gas market by design, so the bound has to come from somewhere else — and until it exists, "thick on-chain execution" is a design intention rather than something the chain could safely be opened to.
Why Bliss gates the founding record
Bliss is one of the three conditions on Genesis — the point at which the record becomes permanent. The bar is a fuller IRM: multiple real pipelines, inter-organization impact exchange actually happening, and Bliss serving at least one other dApp.
The reasoning is that a permanent record should not be sealed before the thing people live in is real. A network can look healthy while every participant is still operating through spreadsheets and goodwill; what it records then is an artifact of how hard the tooling was, not of what people actually did. Waiting for the OS means the founding record reflects real practice.