State models, history, auditability, and privacy
How a DAG represents the waiting required between transactions, how WAVE, READY_QUEUE, and WORK_FIRST_CONTINUATION schedule the same dependencies, and where these strategies apply to nigo-protocol's Direct Cell and Native Program paths.
A split-and-join example with 100 units of an asset explains how transaction independence, isolated execution, and ordered result application produce the same ledger as sequential execution.
Follow a flow verified with the same token contract and ethers, viem, and Web3j, from deployment to transaction results, to see which code and tools can be reused in nigo-protocol and which integration settings need adjustment.
Starting with verification data shared by several states, nigo-protocol's load tests show why stopping safely and completing automatic cleanup are different outcomes.
An allowance of 10 illustrates state preservation across revisions and RESET on program replacement, and why isolating records and preserving their meaning are different guarantees.
Follow a token transfer function from EVM state reads and calculations to StateCell changes, then examine how its execution responsibilities differ from Native Program validation and where parallel execution stops.
An approved asset transfer illustrates the validation data and results exchanged with a Native Program, and how Core checks those results against the actual ledger changes.
Follow explicit inputs and outputs, and output IDs computed before execution, to see how Direct Cell separates off-chain construction, signing, and preliminary validation from consensus finality.
Comparing asset transfers expressed as Direct Cell, Native Program, and EVM requests shows who constructs the next state, who validates it, and how the results reach a shared ledger.
A transfer of 100 units shows how absence from historical state differs from uncaptured or unretained data, what a single Cell proof establishes, and who must keep that data available.