The machinery

How it all chains showed how proofs tie the pieces together across L1 blocks. This chapter describes who runs what. Five roles cover the whole machine.

flowchart TB
    BR["Bridge: watches confirmed L1, feeds witnesses from lane and deposits"]
    EX["Executor: runs the program's rules over actions and deposits"]
    PR["Provers: transaction -> batch -> aggregate proofs"]
    ST["Settler: builds and submits settlement txs"]
    DA["DA / index: serves program state to apps"]
    BR --> EX --> PR --> ST
    BR --> DA

The bridge is the machine’s view of L1. It follows the Kaspa chain behind the confirmation window and turns confirmed lane entries and deposits into the inputs execution consumes. Users submit to the lane themselves; the bridge only reads. Every fact the machine holds about L1 arrives through it.

The executor applies the program’s rules, the guest code, to the witnessed actions. It is deterministic: same inputs, same state, same result. What it computes is defined by the program, not by the executor.

The provers produce proofs of the execution, in three stages, one guest program each: the transaction guest proves one transaction, the batch guest compounds a block of those proofs, and the aggregator compounds batches into the single proof a settlement carries (The zkVM, briefly details the pipeline). Batch proofs chain within a bundle, and bundles chain across settlements, so the pipeline is a chain by construction.

The settler builds the settlement transaction (state digest, lane tip, proof, continuation and permission outputs) and submits it to Kaspa.

The DA/index layer is the read side: an operator can serve the program’s current state over an API so apps can query it without replaying proofs. Building an app on it builds on it.

In tt’s deployment these roles are in-process components of the single ttd daemon (the framework’s reusable runner engine), plus the web app reading the DA APIs. The roles are independent of the packaging: a bigger deployment could scale each separately.

Who are you trusting, again?

With the roles named, the trust question from Based rollup on Kaspa gets concrete. The bridge can’t invent L1 facts; the proofs check everything against the real chain. The executor can’t cheat; its output is proven. The settler can’t settle a fabricated state; Kaspa verifies the proof before accepting the tx, and the settlement chain can’t fork without splitting real money on L1. What the operator can do is stop: stop executing, stop proving, stop settling, or keep settling against an old lane tip so your action is never processed. That is the liveness trust: safety needs no operator; liveness does, until someone else takes over.

Two properties make “someone else” possible. First, nothing in the machine is operator-keyed: the settlement script requires no signature, only a valid proof (a valid proof from anyone extends the chain), the bridge only reads public chain data, and the lane is public. So anyone can, in principle, stand up this same open stack against the same lane and continue where the last operator stopped. The limits of that claim: resuming means running a proving stack, real work at real cost (Building an app on it says who would pay), so it is a capability, not a service anyone promises. Second, exits already committed to the permission tree are claimable by their holders alone; no operator sits in that loop. The claim data travels the same way everything else does: the tree is rebuilt from public data, its leaves ride the proofs’ journals, and anyone running the stack reconstructs the identical tree, so withholding a branch means withholding L1 itself.

What is not shipped today is an escape hatch: a flow that lets a user force a settlement through without first running the machine. Until one exists, a balance that never became a committed exit waits for an operator. The practical advice: exit early if you plan to leave.