demo

What this debugger can show

Each entry is one small Noir program. Open one to step through it — the source, the function names and the values are the program's own. The transaction it is published under is synthetic, like every other transaction on this chain.

values

Types and values

Every value kind the language has, brought into scope one line at a time. The subject is the Values pane: a reader stepping through should be able to name the type of every row they see.

valuesstepping 34 steps · 2 calls · transaction →

loops

Loops and iteration

Three loop shapes, chosen so the loop rail has iterations worth moving between and values that differ from one iteration to the next. A loop whose variables never change is a rail with nothing on it.

loop-railsteppingvalues 863 steps · 10 calls · transaction →

branches

Branches and conditions

Every `if` here is written so that both arms are reachable and the inputs decide, and each classifier is called more than once with values landing in different arms — so the same source line is marked taken on one visit and not-taken on another.

branch-markingstepping 54 steps · 9 calls · transaction →

calls

Calls and recursion

A call tree worth looking at rather than a flat list: direct recursion several frames deep, two functions calling each other, tree recursion that branches, and a helper reached from two different parents.

call-tracestepping 657 steps · 50 calls · transaction →

generics

Generics and traits

Source written once and executed several times over different types. A generic function has one body and many instantiations; a trait method has one name and many bodies. Both make "which code is running" a real question, and the call trace is where it is answered.

call-tracesteppingvalues 99 steps · 9 calls · transaction →

events

Program output and the event log

The stream of things the execution SAID, as distinct from the values it held. In this language that stream is `print`, `println` and format strings, and it is the only pane whose content a program author writes directly.

event-logloop-railstepping 124 steps · 7 calls · transaction →

constraints

Constraints, and an execution that fails one

What a recording looks like when the program does NOT finish. This is the case a zero-knowledge debugger exists for: a constraint did not hold, and the question is which one, on which values, reached from where. The recording ends at the failing assertion.

failureevent-logcall-tracestepping 71 steps · 5 calls · transaction →

limits

Bounds, limits and overflow

What happens at the EDGES of a type. In a circuit this is not a curiosity: an addition that overflows is a failed constraint, and the difference between wrapping and aborting is the difference between a proof and no proof.

valuessteppingloop-rail 101 steps · 6 calls · transaction →

mutation

Mutation over time

A value that CHANGES. Everything else in this tour shows values computed and bound once; this one shows the same binding holding a different value at a different time, which is the case a time-travelling debugger answers and a printout of the final state does not. The forms the recorder captures come first; the one it does not is last, alone and labelled.

valuessteppingbranch-marking 118 steps · 9 calls · transaction →

Latest blocks

All blocks →

Latest transactions

All transactions →

About this data

Synthetic demo data — Every block, transaction, address and hash on this chain is generated from a fixed seed. None of them exists on any network, and none of these values can be looked up anywhere else. The execution trace is real — it is a recorded Noir program — but it is not the execution of the transaction it is published under.