# Nibiru Engine Page Copy

## Hero

Eyebrow:

```text
Verifiable confidential compute
```

Headline:

```text
Private execution with public receipts.
```

Subheadline:

```text
Nibiru runs a committed program over encrypted material and emits a receipt
that anyone can verify without learning the private inputs, state, outputs, or
program contents.
```

## The Problem

Confidential computation and verifiable computation usually point in opposite
directions.

FHE lets an operator compute over ciphertext, but it does not prove the operator
ran the right program correctly. ZK proves a computation was correct, but a
normal prover usually sees the plaintext. MPC lets two parties compute jointly
without revealing their inputs to each other, but it produces no public evidence
and classically leans on a trusted dealer. Nibiru combines all three on the same
execution: for private-program/private-input sessions, the owners co-generate
the receipt witness over MPC — dealer-free, with no third-party prover — and the
co-generated witness is byte-exact the one the receipt proves.

## The Nibiru Shape

```text
data owner encrypts inputs
        |
        v
operator runs Nibiru over ciphertext
        |
        v
receipt proves committed execution
        |
        v
owner, auditor, app, or chain verifies
```

The verifier learns that the committed program ran correctly. The verifier does
not learn the private data, private program, private state, or private result.

This is also Nibiru's structural reaction-attack boundary. The operator and
public verifier do not get a plaintext answer oracle or a public branch trace to
query adaptively. They get encrypted outputs, salted commitments, and receipts.
Correctness is public; reactions from the private program and private input are
not.

## Why The Machine Is Small

Nibiru uses a compact SUBLEQ/MDVM execution law as the verifiable core. The
instruction shape is subtract, test, branch. That matters because exact machine
steps are easier to encrypt, audit, and prove than floating-point ML kernels.

For private inference, the long-term route is:

```text
ternary model -> executable VM image -> encrypted run -> public receipt
```

This is why Nibiru is not just an implementation detail. The machine law is the
bridge between ternary inference, confidential execution, and succinct public
verification.

## What Is Proven

Nibiru receipts bind:

- the committed program root;
- the committed initial and final state roots;
- the semantic transition trace;
- the public receipt root;
- the artifact identity used by the FHE-to-ZK bridge.

The receipt proves semantic validity of the committed VM transition. The current
prototype also cross-checks FHE-produced artifact roots against receipt roots.
Tighter end-to-end ciphertext binding remains part of the production hardening
path.

For bilateral privacy mode, the production pipeline can source the witness from
MPC while targeting the same semantic object. It does not MPC the full encrypted
VM or a floating-point model; it MPCs the compact MDVM witness surface: shared
carries, oblivious addressing, Poseidon commitments, and persistent shared
Merkle state, then runs the same receipt chain.

## Best Fit Use Cases

| Use case | Why Nibiru fits |
|---|---|
| Verifiable confidential auctions / RFQ clearing | Bids and intent stay private while the clearing rule produces a public receipt. |
| Regulated decisioning receipts | Apply approved policy or eligibility logic to sensitive records while auditors verify the receipt. |
| Compact fraud and risk scorecards | Let two parties check a risk rule without exposing all raw data or proprietary logic. |
| Provider benchmark and capacity receipts | Turn valid execution history into a reputation and reserved-capacity primitive. |
| Inference-provider trust layer | Prove a committed model or policy version ran while protecting user data and model-owner IP. |

For compute and inference markets, the Nibiru Engine is the trust runtime
underneath payment, reputation, and capacity accounting. It turns "trust this
operator" into "verify this receipt": committed job, sealed run, private result,
and public proof of correct execution.

That is what lets confidential work move across replaceable providers. The
operator becomes a capacity input; the receipt is the product the market can
verify and settle. Different providers can compete to produce the same kind of
proof-carrying confidential execution without becoming trusted counterparties.

## Maturity

What exists now:

- encrypted VM smoke execution over TFHE/Metal;
- decrypt-matched execution artifacts;
- semantic MDVM receipts;
- production-pipeline MPC witness source for bilateral privacy mode;
- fold, final, multi-wrap, and cycle-wrap receipt paths for the current smoke
  artifact;
- a redacted viewer JSON exporter and static viewer that surface MPC status
  gates without exposing shares or transcript bodies.

What remains:

- larger FHE runtime shapes;
- release-grade packaging;
- broader artifact regression coverage;
- stronger ciphertext-to-receipt binding;
- compiler path from ternary model or policy to VM image.