Direct Cell: How Much of a Transaction Can Be Prepared Off-Chain?

A wants to send B 20 out of an asset holding of 100. B plans to send 5 of that to C. A also plans to send D 10 out of the remaining 80.

Must they wait for each preceding transaction to enter a block before preparing the next one? And must the people constructing a transaction, signing it, and checking its contents all work in the same place?

In nigo-protocol, Direct Cell transactions explicitly carry the records to consume and the records to create. One Ledger, Three Ways to Execute Transactions compared this request with Native Program and EVM requests. Here, we explore how an explicit Direct Cell proposal can separate the places and roles involved in preparing a transaction.

Understanding that possibility requires keeping two facts in view: being able to specify a proposed result in advance is different from having that proposal finalized on the ledger.

Put the proposed result in the transaction

Suppose A's 100 is held in a single record, u0. nigo-protocol calls this kind of state record a StateCell. For this example, assume the asset allows direct transfers by its owner, transaction fees are zero, and the asset policy and execution rules remain unchanged throughout. There is no minting or burning. Names such as u0 and u1 are example labels used to distinguish the records.

The first transaction, T1, which A will sign, contains this proposal:

T1 — signed by A

Consume: u0  A's 100
Create:  u1  B's 20
         u2  A's 80

This does not change the number in u0 from 100 to 80. It consumes u0 and creates two new records with specified recipients and amounts. The input of 100 equals the output total of 20 + 80. Using an unspent output as the input to a subsequent transaction is the UTXO, or unspent transaction output, model. It was the starting point for From UTXO to StateCell.

A wallet or a separate transaction construction tool can prepare this proposal first. A reviews which record it uses and who will receive what, then signs it. Constructing the proposal does not give the tool A's authority to sign.

The ledger checks the submitted transaction's signature, the authority to spend its inputs, and rules such as conservation of each asset's quantity. If those checks pass, it consumes the proposed inputs and applies the outputs. This path therefore separates proposing the next state from judging that proposal under the ledger's rules.

Prepare a successor before its predecessor executes

What becomes possible if the output identifiers, as well as the output contents, can be determined before execution?

A Direct Cell output ID in nigo-protocol is computed in a prescribed way from a value that commits to the transaction's meaning—including its input list and its outputs' owners and contents—and the output's position. The final transaction hash binds that content together with the output IDs, and the signature covers that transaction hash. Changing an output's recipient or amount in transit therefore cannot pass verification with the same signature.

This structure makes it possible to compute the actual IDs of u1 and u2 before applying T1 to the ledger. After receiving T1 signed by A, B can prepare a successor, T2, that uses the 20 in the future u1 as its input. A can also prepare T3 using the 80 in u2.

T1: consume A's u0 of 100
    ├─ u1: B's 20
    │   └─ T2 (signed by B)
    │      C's 5 + B's 15
    │
    └─ u2: A's 80
        └─ T3 (signed by A)
           D's 10 + A's 70

If all three transactions are applied in an order that respects their dependencies, the final amounts are A=70, B=15, C=5, and D=10. Their total remains the original 100. T2 and T3 use different inputs, and each transaction is signed by the owner of its own input.

Preparing T2 in advance does not mean its input, u1, already exists on the current ledger. T2's proposal is conditional on T1 first being validly applied and creating u1. Once T1 has been applied, however, T2 and T3 do not compete for the inputs in this example. The transaction links reveal both the dependencies that require a predecessor's result and the branches that can be prepared independently.

nigo-protocol also provides a submission path for signed Direct transaction packages with predecessors placed first. Acceptance of a package does not guarantee that every transaction will enter the same block, or that transactions spanning multiple blocks will all succeed or all be rolled back. The scope of what can be linked in advance and the scope of what is finalized together must be defined separately.

Where determinism helps

Determinism helps explain the value of this structure. But we must also specify what has to remain the same for the result to remain the same.

Validators using the same input state, asset policy, execution rules, and transaction should reach the same validation result. That property is necessary for multiple nodes to maintain a single ledger. Determinism given the same state and execution conditions also matters in account-based ledgers and EVM execution.

What deserves additional attention in Direct Cell is that the proposed change and the state it directly uses are visible in the transaction. B can read T1 and compute the contents and ID of the record B would receive. B can then use that record as T2's input, specify outputs of 5 and 15 in advance, and check that the amounts add up. There is no need to wait for the ledger to choose arbitrary recipients or amounts later.

Inputs and outputs are not the only things validation requires. A validator must also check whether the current asset policy permits direct transfers, whether fee and execution limits are met, and whether the inputs are still available. Preliminary validation therefore answers: is this proposal valid under the state and rules available to us? If the policy changes or an input is consumed first, the judgment after submission can differ.

This distinction lets us use determinism without overstating it. We gather the context needed for validation so that the same judgment can be reproduced, then check again when applying the transaction whether that judgment still holds.

Distribute construction, signing, and validation among participants

One server does not have to handle every part of preparing these transactions. A construction tool can build T1 while A reviews its contents in a separate signing environment. B constructs and signs T2 from the received T1, while A prepares T3 from A's remaining output. Another participant responsible for submission can collect the signed transactions in the appropriate order and forward them without changing their signed contents.

Participants who have the necessary state and rules can also recheck proposals made by others. Instead of trusting a service's stated balance, they exchange material against which they can compare the records to be consumed, the proposed results, and the signatures.

External signing here means signing outside the ledger in accordance with nigo-protocol's transaction format and signature rules. Attaching a signature from another chain or an approval from an external service does not, by itself, authorize spending an input on this ledger. In the current Direct Cell model, all inputs to a transaction must belong to that transaction's signer. The example therefore uses separate transactions in which A and B each spend their own inputs.

Other ledger models also support off-chain construction and signing. The point of interest here is the ability to pass state transitions with concrete contents and dependencies between participants. That property creates room to design systems in which construction and preliminary validation take place in different locations.

It does not mean a node trusts an external worker's “validation complete” response and skips its own checks. The current ledger validates transactions again during block execution. Delegating execution to external workers and accepting only their results would require a separate basis for trusting or verifying those results.

What if two signed promises spend the same input?

Suppose that, besides giving B the signed T1, A also signs another transaction sending all 100 in the same u0 to E.

T1: u0's 100 → B's 20 + A's 80
X : u0's 100 → E's 100

Both transactions can carry authentic signatures from A. While u0 is still available and the other conditions hold, each transaction considered independently can also satisfy the quantity and ownership rules. But a single ledger cannot apply both. Once the first transaction consumes u0, the other loses its spendable input.

Reviewing T1 and T2 and checking their signatures therefore does not mean B has definitively received 20. If X is finalized on the ledger, T1's u1 will never be created, and T2, which spends that output, cannot be applied either. Determinism reproduces a judgment under the same conditions; it does not choose which of two conflicting proposals to finalize.

The source of the input data also matters here. Even evidence that u0 existed in a particular finalized state does not automatically establish that it has remained unspent since then. The reference state used by the evidence must also be checked against the ledger's finalized history. Computing transaction links, verifying the authenticity of a reference state, and finally establishing one canonical history are connected tasks, but they answer different questions.

What else would a sidechain require?

So far, we have described how the current Direct Cell structure separates transaction preparation from validation. We can also use this structure to explore performing multiple transactions off-chain and settling their results later. This is a question for an extension design, not a description of a completed nigo-protocol feature.

For example, consider a state channel in which participants lock some assets on the main chain and agree off-chain on changes involving those assets. Locking prevents the same assets from being spent again on the main chain. The design also needs rules for identifying the latest state agreed upon by the participants, responding when someone submits an older state, and applying the final asset allocation to the main chain.

Cardano's Hydra provides a concrete comparison. A Hydra Head is a state channel that uses the same transaction format as the main chain. It includes participant agreement and signatures, as well as an on-chain settlement procedure with a contestation period. It illustrates how a separate agreement and settlement protocol can be built on top of reusable, explicit state transitions. Cardano's introduction to Hydra

A sidechain operating under separate consensus raises another set of questions. Which sidechain state will the main chain recognize as final? What evidence will it use to verify that result? How will transfers and settlement be linked so that assets cannot be spent twice across the two ledgers? Participants must also remain able to obtain the transaction and state data needed for verification or challenges.

Direct Cell's explicit inputs and outputs and deterministic validation provide a foundation that such designs can reuse. They make it easier to express precisely which transitions were computed and agreed upon elsewhere. But the ledger model that represents a state transition must be designed together with the protocol that determines how far that transition can be trusted and finalized.

Add more complex conditions to a proposal

In the opening example, transaction preparation was not tied to one place. A and B constructed linked proposals and signed their own transactions. Participants with the necessary information could examine those proposals in advance. The ledger remained responsible for checking validity against the current state and determining which conflicting proposal would become final.

That separation of roles is the design benefit worth examining in Direct Cell. Explicit state transitions help analyze execution order, and also create choices about where construction, signing, and validation can take place.

Next, we can extend the conditions under which a proposal may be used. Instead of sending assets directly, suppose A authorizes S to spend up to 30, and S uses that authorization to send 20. The owner's signature and conservation of quantity are no longer enough to decide whether the transaction is valid. Rules must check whether the spender is authorized, whether sufficient allowance remains, and whether the resulting records are correct.

How Does a Native Program Validate Proposed Transaction Changes? continues with a structure that keeps explicit inputs and outputs while using a program to validate these business conditions.