• LIP: 7
• Layer: Application
• Title: Genesis Transaction Decoder Format
• Author: Allwin Ketnawang
• Created: 2025-07-07
• Requires: 6
• Status: Draft

Abstract#

This LIP defines the official, standardized binary layout interpreted by the Genesis LEA Transaction Decoder.
As the first canonical decoder in the LEA model, it is based on the Simple Compact Transaction Protocol (SCTP) primitives introduced in LIP-6. The format follows a flexible, invocation-based structure, including a unified address vector, gas configuration, a sequence of invocation instructions, and a dual-signature scheme (Ed25519 and SPHINCS-256s).

Motivation#

While LIP-6 defines the low-level data primitives for encoding data, it does not define the high-level structure of a transaction (the "grammar"). A standard transaction format is essential for all network participants to interpret, validate, and process transactions in a uniform way. This proposal provides that standard, detailing the exact order, type, and meaning of each component within a transaction. It also specifies the precise method for hashing and signing transactions to ensure cryptographic integrity.

Specification#

All LEA transactions MUST be serialized according to the following structure, using the SCTP encoding types defined in LIP-6. The transaction's total decoded size MUST NOT exceed 1MB.

Core Type System#

The transaction format utilizes a specific subset of the SCTP types:

SCTP Type ID	Name	Description
8	ULEB128	Unsigned variable-length integer
13	VECTOR	Raw byte array with a length prefix
15	EOF	End-of-transaction marker (literal byte: 0x0F)

---

LEA Transaction Format (as interpreted by Genesis Decoder)#

A transaction is a sequence of core fields followed by a variable number of Invocation blocks and SignaturePair blocks.

Field	Type	Description
version	ULEB128	Transaction format version. The value MUST be 1.
sequence	ULEB128	Sender's nonce or sequence number
addresses	VECTOR	32-byte addresses; signers first, fee payer first
gasLimit	ULEB128	Max gas units allowed
gasPrice	ULEB128	Price per gas unit
invocations	Invocation[]	One or more invocation instructions
signatures	SignaturePair[]	One signature pair per signer
EOF	Byte (0x0F)	End-of-transaction marker (literal byte)

---

Invocation Block#

Field	Type	Description
targetIndex	ULEB128	Index into the addresses vector (0-based)
instructions	VECTOR	Instruction bytecode intended for the target address

---

SignaturePair Block#

Field	Type	Description
ed25519Signature	VECTOR (64 bytes)	Ed25519 signature over the hash
sphincs256sSignature	VECTOR (29792 bytes)	SPHINCS-256s signature for PQC security

---

Notation Key#

• [] = Repeating block (zero or more)
• VECTOR = Length-prefixed byte array
• All field names are case-sensitive and must follow the specified order

---

Field Constraints and Rules#

1. Addresses (addresses):

   • This field is a single SCTP VECTOR containing all 32-byte addresses involved in the transaction.
   • The addresses vector MUST be assembled using a deterministic, three-tiered sorting algorithm to ensure a single, canonical representation: a. Group 1 (Fee Payer): The address of the fee payer MUST be the first address in the vector (index 0). b. Group 2 (Other Signers): The addresses of all other signers (i.e., the signers from index 1 to N-1) MUST be sorted amongst themselves based on their 32-byte binary lexicographical value. These are appended to the vector immediately after the fee payer. c. Group 3 (Non-Signer Addresses): All remaining unique, non-signer addresses MUST also be sorted amongst themselves based on their 32-byte binary lexicographical value. These are appended last.
   • The addresses vector MUST NOT contain duplicate entries.
   • The total byte length of the vector MUST be a multiple of 32.

2. Invocations:

   • The transaction contains one or more Invocation blocks.
   • Each Invocation consists of a targetIndex (ULEB128) followed by an instructions field (VECTOR).
   • The targetIndex MUST be a valid, 0-based index into the addresses vector.
   • The instructions field contains the application-specific instruction bytecode to be executed in the context of the targeted address.

3. Signature Set:

   • The number of SignaturePair blocks implicitly defines the number of signed addresses. If there are N signature pairs, then the first N addresses in the addresses vector are considered signers.
   • Each SignaturePair corresponds one-to-one with the signers in the addresses vector by index.
   • Each SignaturePair contains two VECTORs:
     • ed25519Signature: A 64-byte Ed25519 signature.
     • sphincs256sSignature: A 29,792-byte SPHINCS-256s signature.

4. Termination:

   • Every valid transaction MUST end with a single EOF byte (0x0F).
   • No other data is permitted after the EOF marker.

---

Hashing and Signing Protocol#

• Hashing: The transaction hash is the BLAKE3 digest of the byte stream from the version field up to and including the final byte of the last Invocation block's instructions field. The SignatureSet and the final EOF marker are excluded from the hash.
• Signing: For every signing address, a corresponding SignaturePair must be provided. The Ed25519 and SPHINCS-256s signatures are calculated over the transaction hash.
  Signature verification MUST be performed in index order, matching each SignaturePair to the corresponding address in the addresses vector, starting from index 0.

---

Rationale#

• Flexible Invocations: The repeating block structure for invocations allows for complex transactions that can interact with multiple programs in a single atomic unit.
• Implicit Signer Count: Deriving the number of signers from the number of SignaturePair blocks simplifies parsing and removes the need for a separate field to declare the signer count.
• Unified Address List: A single addresses vector simplifies address management and indexing for invocations.
• Dual Signatures: Requiring both Ed25519 and SPHINCS-256s (a PQC algorithm) signatures provides both high performance for standard validation and long-term security against quantum attacks.
• SCTP Base: Building on LIP-6, this ensures that the low-level encoding is consistent with the rest of the protocol.

---

Backwards Compatibility#

This LIP defines a new, foundational application-layer standard. It does not replace a previously defined transaction format LIP. As such, it does not introduce a backwards compatibility break in the LIP process, but its adoption is a mandatory and breaking change for any client or node software wishing to interact with the LEA network, in conjunction with the adoption of LIP-6.

---

Security Considerations#

• Hashing Integrity: Validators MUST strictly adhere to the specified hashing protocol. Including any part of the SignatureSet in the hash would invalidate all signatures.
• Signature Verification: For each SignaturePair, both the Ed25519 and SPHINCS-256s signatures must be successfully verified against the transaction hash using the public key of the corresponding signing address. A failure in either verification invalidates the transaction.
• Index-out-of-Bounds: Parsers MUST validate that each targetIndex in an invocation is a valid index within the addresses vector. An invalid index must cause the transaction to be rejected.
• Vector Length Validation: Parsers MUST validate that the addresses vector length is a multiple of 32 and that the signature vectors have the correct fixed lengths (64 and 29792). Failure to do so could lead to buffer overflows or incorrect data interpretation.
• Fee Payer: The first entry in the addresses vector is the fee payer. Logic for deducting fees must correctly and exclusively identify this address.

---

Copyright#

This LIP is licensed under the MIT License, in alignment with the main LEA Project License.