Offline Transaction Execution
This section describes how $KNX is transferred within the offline execution domain. The offline transaction execution protocol defines transaction structure, local validation rules, and optional witness attestations. The protocol is designed to enable private, local value transfer without continuous connectivity, while ensuring that all executed transactions remain reconcilable with the global ledger.
KnoxNet explicitly separates transaction execution from global settlement. Execution occurs locally between devices, while settlement occurs later through reconciliation with the global ledger. As a result, offline transactions can be valid at the moment of exchange, but they only become globally final after reconciliation.
7.1 Transaction Structure
An offline transaction transfers ownership of one or more offline notes. Each transaction consumes a set of existing notes and produces a new set of notes whose total value is conserved.
An offline transaction consists of:
Inputs
The notes being spent (existing notes)
Outputs
The new notes being created and assigned to the receiver
Authorization
A cryptographic signature from the sender proving approval of the transfer
Transaction Identifier
A transaction nonce or identifier
A valid transaction must always conserve value:
Total value in = Total value outEach output note specifies a new owner public key and a fixed denomination of $KNX. Output notes are newly created objects that replace the consumed input notes. For example, if a user spends 10 $KNX offline, the outputs must sum to exactly 10 $KNX.
7.2 Local Validation Rules
Before accepting an offline transaction, the receiver performs a set of local validation checks. These checks are lightweight and do not require internet connectivity.
The receiver verifies the following:
Note Authenticity
The receiver verifies that each input note was originally issued by KnoxNet and is not forged. This is confirmed through the Layer 1 ledger's cryptographic signature on each input note.
Ownership Authorization
The receiver verifies that the transaction is signed by the correct private key, proving that the sender is the legitimate owner of the notes being spent.
Value Conservation
The receiver verifies that the transaction does not create or destroy value. The total value of inputs must equal the total value of outputs.
Basic Integrity Checks
The receiver also verifies that:
The same note is not referenced multiple times within the same transaction
Output notes specify valid owners and valid values
If any of these checks fail, the transaction is rejected immediately.
7.3 Ownership Transfer and Authorization
Ownership of an offline note can only be transferred by its legitimate owner. The sender proves ownership by signing the transaction that consumes the note. The transaction then creates new output notes assigned to the receiver's public key.
This mechanism ensures that offline spending remains secure even in adversarial environments. Simply copying a note object is insufficient to spend it—spending requires cryptographic authorization from the owner's private key.
Because notes function as controlled bearer instruments, possession alone is insufficient for transfer. Authorization must be explicitly provided by the owner's private key. This prevents unauthorized reuse or reassignment of notes during offline execution.
7.4 Optional Witness Attestations
KnoxNet supports optional witness attestations for offline transactions. A witness is a nearby device that signs a statement confirming it observed a specific transaction execution event.
Witnesses do not validate transaction correctness and do not determine whether a transaction is accepted. Their role is purely evidentiary. During reconciliation, witness attestations can provide additional context in cases where conflicting histories are submitted or when participants dispute events that occurred during offline execution.
To discourage false attestations, witnesses may be required to stake $KNX, which can be slashed if contradictory attestations are proven during settlement. Participation as a witness is optional and incentive-driven.
7.5 Absence of Global Uniqueness Enforcement
KnoxNet does not enforce global uniqueness of note consumption during offline execution. In offline environments, the system does not check whether an input note has already been spent in another offline history.
This is an intentional design choice. Enforcing uniqueness in real time would require internet connectivity, global broadcast, or trusted infrastructure—reintroducing network-level observability and undermining the offline-first privacy model.
Instead, global uniqueness is enforced during reconciliation. If the same note identifier appears in multiple conflicting submissions, the contradiction is detected deterministically and penalties are applied through escrow-based enforcement. This approach preserves privacy during execution while still guaranteeing eventual correctness and bounded risk.