• LIP: 6
• Layer: Core Encoding
• Title: Replace Core Transaction Encoding (CTE) with Simple Compact Transaction Protocol (SCTP)
• Author: Allwin Ketnawang
• Created: 2025-07-07
• Replaces: 1, 2, 4, 5
• Status: Proposed

Abstract#

This LIP officially deprecates the Core Transaction Encoding (CTE) and all associated improvement proposals (LIPs 1, 2, 4, 5). It is replaced by a new, streamlined encoding standard known as the "Simple Compact Transaction Protocol" (SCTP). This proposal formalizes the transition and contains the complete technical specification for SCTP, marking a fundamental shift in the project's approach to data serialization.

Motivation#

The Core Transaction Encoding (CTE) was becoming increasingly complex. A series of proposed extensions (LIPs 1, 2, 4, 5) highlighted that incremental patches were leading to a fragmented and overly complicated design. Rather than continuing to amend the original specification, a decision was made to develop a new encoding from the ground up. The Simple Compact Transaction Protocol (SCTP) was designed to be simpler, more performant, and more extensible than CTE. This LIP serves to formally ratify the switch, providing a clean break from the legacy system and establishing a more robust foundation for future development.

Specification#

The Core Transaction Encoding (CTE) is deprecated. All LEA-compliant systems will adopt the Simple Compact Transaction Protocol (SCTP) for all transaction encoding purposes.

The following is the complete technical specification for SCTP.

Overview#

A SCTP stream is a sequence of typed data fields. Each field is prefixed with a 1-byte header that defines its type and provides metadata. All multi-byte integer and floating-point values are encoded in little-endian byte order.

Header Byte#

Every data field begins with a header byte, structured as follows:

MMMM TTTT

• TTTT (lower 4 bits): The Type Identifier. This specifies the data type of the field.
• MMMM (upper 4 bits): Metadata. Its meaning depends on the TTTT value.

---

Type Identifiers#

The TTTT bits map to the following data types.

Type ID	Name	Description
0	INT8	Signed 8-bit integer.
1	UINT8	Unsigned 8-bit integer.
2	INT16	Signed 16-bit integer.
3	UINT16	Unsigned 16-bit integer.
4	INT32	Signed 32-bit integer.
5	UINT32	Unsigned 32-bit integer.
6	INT64	Signed 64-bit integer.
7	UINT64	Unsigned 64-bit integer.
8	ULEB128	Unsigned LEB128-encoded integer.
9	SLEB128	Signed LEB128-encoded integer.
10	FLOAT32	32-bit floating-point number.
11	FLOAT64	64-bit floating-point number.
12	SHORT	A small integer (0-15) in a single byte.
13	VECTOR	A generic byte array.
14		(Reserved for future use)
15	EOF	End of Stream marker.

---

Type Encoding Details#

Fixed-Size & Variable-Size Numerics#

• Types: INT8 - UINT64, ULEB128, SLEB128, FLOAT32, FLOAT64
• Encoding: The header's MMMM bits are unused and should be 0000. The binary data of the specified type immediately follows the header byte.

SHORT#

• Description: Encodes a small, unsigned integer value from 0 to 15.
• Encoding: The entire field is a single byte.
  • The TTTT bits identify the type as SHORT.
  • The MMMM bits contain the actual integer value.

VECTOR#

• Description: Encodes a variable-length array of bytes.

• Encoding: The MMMM bits in the header determine how the size is encoded.

  • Case 1: Small Vector (0-14 bytes)

    • The MMMM bits hold the length of the vector (0000 to 1110).
    • The vector's byte data immediately follows the header.

  • Case 2: Large Vector (>= 15 bytes)

    • The MMMM bits are set to 1111.
    • This signals that a ULEB128-encoded integer representing the vector's true length follows the header.
    • The vector's byte data follows the ULEB128 length.

EOF#

• Description: Marks the end of the data stream.
• Encoding: A single byte where the TTTT bits are 1111. The MMMM bits should be 0000.

---

Rationale#

A new, unified encoding standard is preferable to a heavily patched legacy system. By replacing CTE with SCTP, we avoid the accumulated complexity of multiple LIPs and introduce a more coherent design. Embedding the specification directly into the LIP ensures that the proposal and its technical details are reviewed and approved as a single, atomic unit.

Backwards Compatibility#

This is a fundamental breaking change. Transactions encoded using the legacy CTE format are not compatible with the new SCTP standard and will be invalid. This change necessitates a coordinated network upgrade. A specific block height or "flag day" will be designated for the switchover from CTE to SCTP. All node operators and developers must upgrade their software to a version that supports SCTP before this activation point to remain on the network.

Security Considerations#

The security of the LEA protocol now depends entirely on the correctness and robustness of the SCTP specification and its implementations. Implementers must be diligent in creating parsers that are robust against malformed or malicious data to prevent potential vulnerabilities, especially when decoding variable-length structures like VECTOR, ULEB128, and SLEB128. The deprecation of CTE removes any security concerns associated with its previous complexity and patches.

Copyright#

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