Transaction Model
Nigo Protocol does not place every operation into one general-purpose transaction. Transactions whose state-transition, signature, and wire semantics differ use separate canonical kinds and hash domains.
This separation allows Native Cell transitions and Ethereum raw transactions to coexist in one block while preserving the identity and validation rules of each format.
Common envelope
Every Nigo transaction includes the following common information.
| Field | Meaning |
|---|---|
txHash | Domain-separated canonical hash for the transaction kind |
creator | Normalized 20-byte creator address |
signature | Signature evidence for the NIGO or ETH scheme |
timestamp | Nigo transaction timestamp or canonical raw-carrier value |
signatureScheme | NIGO(0) or ETH(1) |
gasLimit | Execution gas limit for the transaction |
| Ethereum metadata | Original signing-hash and fee data retained for the ETH-signature flow |
The kind-specific body and hash calculation cannot be reduced to the common fields alone. In particular, Ethereum type-2 and type-4 transactions preserve signed raw bytes as the authoritative body.
Canonical transaction kinds
| Kind | Code | Role |
|---|---|---|
DIRECT_CELL | 0 | Declarative Cell transition validated by Core ownership and conservation rules |
PROGRAM_VALIDATED_CELL | 1 | Cell transition whose business validation is delegated to a Native Program |
EVM | 2 | Nigo-native EVM call/create or legacy EIP-155 carrier |
EVM_SET_CODE | 3 | Signed EIP-7702 type-4 raw transaction carrier |
EVM_TYPE2 | 4 | Signed EIP-1559 type-2 raw transaction carrier |
Codes and canonical encodings are consensus data. Adding a transaction kind or changing an existing encoding is a protocol revision, not an ordinary API change.
Cell transactions
A Cell transaction declares input StateCell IDs and output StateCells in its body.
CellTransaction
inputs[] StateCellId
outputs[] StateCell
Before execution, Core validates input existence, ownership, domain access, output shape, and hashes. Success spends the inputs and creates the outputs.
Direct Cell
For DIRECT_CELL, Core validates shared ownership and conservation rules directly. It is used for explicit state transitions that require no separate program execution, such as ordinary Native Asset transfers and protocol-neutral Direct outputs.
Deriving an output ID directly from the final transaction hash would create a circular dependency: each value would require the other first. Nigo separates this into intent and final-transaction-hash stages.
An output semantic descriptor includes owner, schema hash, data type, value, and required asset identity, but excludes the ID. A producer can therefore calculate output IDs before signing and reference them from a later transaction in the same block, while output semantics cannot be changed after signing.
Program-validated Cell
PROGRAM_VALIDATED_CELL delegates business-rule validation for a declared state transition to a Native Program. In addition to inputs and outputs, the transaction commits this invocation:
ProgramInvocation V1
programId
expectedRevision
expectedDescriptorHash
methodSelector
assetScopes[]
arguments
The invocation signs not only the stable program identity but also its expected revision and descriptor hash. This prevents a transaction from silently switching to unintended code when a new runtime revision exists under the same programId.
Core validates common protocol invariants, and the VM runs the selected Native validator in constrained EVM mode. A success receipt contains the actual program ID, revision, and descriptor hash that executed.
EVM transactions
EVM
EVM(2) represents contract calls and deployments.
- No target means deployment.
- A target means a call.
valueis an unsigned 256-bit NIGO value.- Calldata and gas limit bind into the canonical hash.
- NIGO signatures and validated legacy EIP-155 ETH carriers are supported.
The legacy ETH flow reconstructs and exactly validates the Ethereum signing hash, raw transaction hash, nonce, gas price, and signature fields. Because an Ethereum transaction has no timestamp, the carrier timestamp is deterministically derived from the authoritative Ethereum hash.
EVM_TYPE2
EVM_TYPE2(4) preserves a signed raw 0x02 EIP-1559 envelope containing:
- chain ID and nonce;
- priority and maximum fee;
- gas limit;
- destination and value;
- calldata and access list; and
yParity,r, ands.
After decoding raw bytes, the decoder verifies that they re-encode to the same canonical bytes. It recalculates the Ethereum signing hash and transaction hash from the raw value and binds the Nigo-specific fee-funding identity into a separate carrier area.
Supporting the type-2 envelope does not imply support for Ethereum's entire base-fee market. Current fee admission and settlement follow the active Nigo fee-profile rules.
EVM_SET_CODE
EVM_SET_CODE(3) preserves a signed raw 0x04 EIP-7702 envelope and authorization list. Raw Ethereum fields and the outer signature are authoritative; only Nigo fee funding binds through a separate extension.
Whether an SDK can author and sign type-4 transactions is distinct from protocol execution support. Developer guides and the compatibility matrix will report the validated scope for each SDK separately.
Signatures and identity
Nigo distinguishes NIGO and ETH signature schemes.
| Scheme | Validation basis |
|---|---|
NIGO | Signature over the Nigo transaction intent/hash domain and recovered creator |
ETH | Ethereum signing payload/RLP, chain ID, nonce, fields, and recovered sender |
An ETH-signed transaction can retain its original Ethereum identity while also receiving a Nigo-ledger transaction hash and canonical carrier. Do not assume these two hashes are equal. Mapping and RPC projection explicitly connect the original Ethereum hash to the finalized Nigo transaction identity.
Execution lifecycle
A transaction validated at admission is validated again against consensus state during block execution. Nonces, inputs, program revisions, or protocol profiles may have changed between admission and execution.
Rejection and execution failure
An invalid transaction differs from a valid transaction whose execution fails.
| Result | Receipt | Included in block |
|---|---|---|
| Malformed canonical bytes | None | No |
| Signature or chain-ID mismatch | None | No |
| Input, domain, nonce, or protocol-invariant violation | None | No |
| Direct Cell success | Success | Yes |
| Native validator success | Success | Yes |
| Native validator revert or out-of-gas | Failure with defined fee transition | Yes |
| EVM success | Success | Yes |
EVM REVERT or out-of-gas | Failure; VM state rollback followed by fee settlement | Yes |
| Validator-result or capability protocol violation | None | No |
Including an execution failure in a block does not commit the failed message's state changes. Its revertible overlay is discarded, leaving only the receipt and transitions allowed by fee policy.
Receipts
A canonical receipt preserves:
- the Nigo transaction hash and a separate receipt hash;
- input StateCells observed during execution;
- output StateCells created;
- spent StateCell IDs;
- contract and Native events;
- gas limit, gas used, and gas schedule;
- fee policy, effective gas price, charged amount, and settlement mode;
- success or failure status;
- contract deployment address; and
- Native Program identity and revision metadata when required.
Receipt inputs, outputs, and spent IDs form StateCell lineage. A different fee-policy revision or actual settlement mode can change the canonical receipt hash even when the visible execution result is similar.
Block execution and parallelism
The block pipeline fixes transactions at canonical indexes. Sequential mode executes in that order. Parallel mode builds a graph and waves from explicit StateCell access relationships.
- Execute independent transactions against the same frozen state view.
- Verify that actual access remains within the declared range.
- Merge results only in canonical transaction-index order.
- Execute EVM or broad transactions whose access range cannot be proven sequentially as barriers.
- Fall back to the sequential path on errors or uncertainty.
The parallel strategy is not recorded in the block. Validators with different worker configurations must produce identical transactions, receipts, and state roots.