BWG Loonshots

Four validator nodes were maintaining a single ledger. Three finalized the first block, while one remained behind. The lagging node's process was alive, and it was still connected to the other three. Yet waiting did not bring it to the same block.

This was the behavior reproduced locally in nigo-protocol on September 8, 2026. The node had neither failed to read a block from storage nor lost its network connections. In fact, the lagging node was further ahead in its attempts to reach consensus. It had timed out first, moved to the next round, and was discarding messages from earlier rounds.

Rejecting old messages sounds like a reasonable rule. But what if a message is not asking for a new vote, and instead contains evidence that other nodes have already agreed? That distinction left one live node persistently behind.

As the article on observing consensus progress explains, a server responding to requests is different from a server finalizing transactions. Once we can observe where consensus is waiting, the next question is when that wait may safely end. If it is waiting for storage, moving on sooner is not always an improvement.

A consensus node sends other nodes signed messages supporting a block. Those nodes treat the signatures as votes. But suppose the sender abruptly stops and then restarts. What if it is the only node that cannot remember the vote it already sent?

To prevent this, nigo-protocol first records consensus actions in local storage before broadcasting them. The question was what “the save call returned successfully” actually included. In the implementation and verification work of September 2026, the key was to distinguish a write request, a database commit, and completion of the storage synchronization request, rather than treating all three as a single success.

A transaction has been submitted, but it has not finalized. The operations dashboard opens, and status queries succeed. The consensus engine reports running=true. If the server responds and the engine is running, is waiting a little longer all that is needed?

That information cannot answer the question yet. The node might be idle because there is no work to do, waiting for votes from other validators, or stuck inside a storage operation. The value still on the screen might even be the last response received before a failure.

The article on GC safety and progress distinguished stopping to protect data from finishing the cleanup. Observing consensus raises a similar question: How do we distinguish the absence of a visible failure from evidence that the work is getting done?

nigo-protocol does not leave that question to response status alone. It separates the path for reading minimal execution status, then assesses progress through distinct observations of pending transactions, votes, and local finalization. This article covers that design and the scope established by local validation in September 2026.

Running independent transactions together and dispatching dependent work as soon as its inputs are ready can reduce computation time and unnecessary waiting. nigo-protocol explored several ways to schedule that work, each with a different way of handling dependencies, while preserving the same results as sequential execution.

But a correct parallel engine did not reduce the node's total processing time by the same proportion. In one experiment on August 7, 2026, block execution for 1,000 transactions took about 18% less time, while the full local processing path measured in the experiment improved by only about 2.4%.

Where did the execution gains go? Revisiting the records requires separating three questions: what was measured, what work remained in the execution stage, and how the execution methods were compared. This article looks back at that experiment. It is not a new measurement of nigo-protocol's current throughput.

Suppose two transactions run together. One finishes quickly; the other takes longer. A third transaction needs only the result of the faster one to begin. Must it wait for the slower one too?

The conditions for preserving the same ledger result as sequential execution do not settle this question. Having the necessary results ready and assigning the next piece of work to a worker are separate decisions.

nigo-protocol represents dependencies between transactions as a graph called a DAG. It implements three ways to execute that graph: WAVE, READY_QUEUE, and WORK_FIRST_CONTINUATION. Before focusing on the names, let us look at the waiting each approach tries to reduce in the same set of transactions.

Suppose the starting ledger state, the transactions to execute, and their order are fixed. One node executes those transactions one at a time. Another divides the work into tasks and executes several at once. What must remain the same for both nodes to produce the same ledger?

Tasks that start together can finish in different orders. If a later transaction is applied to the ledger first simply because it finishes first, the transaction order or execution results may differ between nodes. But if every transaction must wait for the previous one to finish before it can start, even unrelated computations cannot run together.

The validation structure of Native Programs describes how a transaction makes the state it will use and its proposed changes explicit in advance. That information also helps determine which transactions can execute together. In an EVM function call, however, state access can be determined during execution. Deterministic results and the ability to establish transaction independence before execution are separate requirements. Here, we will look at how to produce the same result as executing transactions one by one in a fixed order, even when their computations finish in a different order.

Choosing a new ledger also means considering the code and tools you will use on it. If you already have contracts written in Solidity and an app that reads balances and signs transactions with familiar libraries, being able to keep using that work is a substantial benefit.

nigo-protocol provides this connection through an EVM execution path within its own ledger architecture. In SDK sample verification, the same Token bytecode and ABI were used with ethers, viem, and Web3j for deployment, queries, signed transaction submission, and result checks. The necessary changes were handled through SDK settings and transaction options without rewriting the business rules.

EVM function calls and state changes explained how contract execution is reflected in the ledger. This article examines what that structure offers developers. Let us follow a token transfer app to see what it means to keep using existing code and tools.

Proving a historical state requires keeping data from that time. Keeping all verification data indefinitely, however, makes storage harder to maintain as the ledger processes more transactions. Once we have decided what to retain, we also need a way to clean up what is no longer needed.

Historical state and proofs distinguished an answer saying that data cannot be provided from one saying that a record was absent at the time. This article asks about deleting that data. If cleanup protects everything that must survive, has it done its job?

nigo-protocol's local tests on September 18, 2026 produced two answers. While transactions kept arriving, the conditions for deletion changed and GC stopped safely. Yet it completed no cleanup cycles during those periods of load. We need to read that result for both what it protected and what it could not yet accomplish.

A owned 100 units of an asset and approved S to spend up to 30 of them. After S sent 20 to B, A held 80 and B held 20. S's remaining allowance was 10. The article on Native Program validation examined how the asset transfer and the allowance reduction are checked as a single transaction.

Now suppose that, after this transaction, the program that checks the asset's spending rules changes. Should the new program let S spend the remaining 10? If the asset uses another program for a while and then returns to the original one, should the old approval become valid again?

Currently, nigo-protocol preserves existing state when changing a program's execution version, or revision, and opens a new state namespace when replacing it with a different program. State is not reset on every upgrade. But preserving a record does not necessarily preserve the meaning of the user's approval, and starting fresh does not necessarily make every condition for spending stricter.

How much continuity can the ledger guarantee when the rules change? This article separates the state boundaries the ledger enforces from the business meaning that those authorizing a program change must review.

A wants to send B 20 out of a token balance of 100. A has authorized S to spend up to 30, and S submits this transaction. Afterward, A will hold 80, B will hold 20, and S will have 10 left to spend.

One way to perform this transfer is to write the result into the transaction in advance. The transaction specifies which records to use and which records to leave behind, then asks a program to check whether those changes are allowed. That is the approach we explored in Native Program proposal validation.

In a typical contract call, however, S does not specify the resulting balances and allowance as outputs. S asks the token contract to execute transferFrom(A, B, 20). Code running on a node reads the current values and computes the next ones.

Without a concrete proposal for the resulting changes, how does a function call become a state change in the same ledger? Let us look inside a single call through EVM, nigo-protocol's third execution path.