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).
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.
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.
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) |
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) |
| Field | Type | Description |
|---|---|---|
targetIndex |
ULEB128 |
Index into the addresses vector (0-based) |
instructions |
VECTOR |
Instruction bytecode intended for the target address |
| Field | Type | Description |
|---|---|---|
ed25519Signature |
VECTOR (64 bytes) |
Ed25519 signature over the hash |
sphincs256sSignature |
VECTOR (29792 bytes) |
SPHINCS-256s signature for PQC security |
[] = Repeating block (zero or more)VECTOR = Length-prefixed byte arrayAddresses (addresses):
VECTOR containing all 32-byte addresses involved in the transaction.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.addresses vector MUST NOT contain duplicate entries.Invocations:
Invocation blocks.Invocation consists of a targetIndex (ULEB128) followed by an instructions field (VECTOR).targetIndex MUST be a valid, 0-based index into the addresses vector.instructions field contains the application-specific instruction bytecode to be executed in the context of the targeted address.Signature Set:
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.SignaturePair corresponds one-to-one with the signers in the addresses vector by index.SignaturePair contains two VECTORs:
ed25519Signature: A 64-byte Ed25519 signature.sphincs256sSignature: A 29,792-byte SPHINCS-256s signature.Termination:
0x0F).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.SignaturePair must be provided. The Ed25519 and SPHINCS-256s signatures are calculated over the transaction hash.SignaturePair to the corresponding address in the addresses vector, starting from index 0.SignaturePair blocks simplifies parsing and removes the need for a separate field to declare the signer count.addresses vector simplifies address management and indexing for invocations.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.
SignatureSet in the hash would invalidate all signatures.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.targetIndex in an invocation is a valid index within the addresses vector. An invalid index must cause the transaction to be rejected.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.addresses vector is the fee payer. Logic for deducting fees must correctly and exclusively identify this address.This LIP is licensed under the MIT License, in alignment with the main LEA Project License.