Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Inline ZK

What it is

Inline ZK are the specialist path for per-action verification and settlement.

Use it when the interesting part of the product is the proof attached to each action: privacy, custom validity rules, or a custom account model.

Unlike Based Apps, you do not inherit a built-in account model from a managed app environment. This path is for products that revolve around proving one action at a time.

Mental model

sequenceDiagram
    participant W as Wallet
    participant S as Proof Service
    participant K as Kaspa

    W->>S: Ask to verify an action
    S->>S: Compute the action result and proof
    S->>K: Submit the verified action
    K->>K: Verify the proof
    K-->>W: One action settles

Pick this when

  • Each action needs custom validity checks before it settles.
  • Each action should be verified and settled independently.
  • Privacy is part of the product.
  • You need a custom account model instead of the built-in account model from a managed app environment.
  • You want Kaspa to verify the result without putting all of the computation on-chain.

Good fits

  • Privacy-preserving actions
  • Custom verified workflows
  • Actions that should stay independent instead of living inside one managed app environment

Developer experience

This path gives you the most control over how one action is validated and settled, but it asks more from you. You own more of the proof design, system architecture, and operational setup than in Based Apps.

When not to use it

  • Your logic is mostly about asset rules and flows.
  • You want a managed app environment with a built-in account model and ongoing shared state.
  • You want many actions to live inside one app environment rather than settle independently.

Current expectations

This is a specialist path. It usually requires more proof-system design and operational infrastructure than Covenants or Based Apps.

In deeper technical material, the component that generates the proof is often called the prover. That detail matters later. On a first read, the important idea is simpler: one action is proved, then that one action settles.