lea-improvement-proposals

• LIP: 5
• Layer: Core Encoding
• Title: Generalize Vectors with Explicit Entry Sizes
• Author: Allwin Ketnawang
• Created: 2025-07-03
• Replaces: 2
• Superseded-By: 6
• Status: Replaced

Abstract

This LIP proposes a fundamental, breaking change to the CTE specification. It renames Public Key List and Signature List to Public Key Vector and Signature Vector, and renames Legacy Index Reference to Vector Index.

Crucially, it replaces the concept of a crypto-specific type code (as defined in LIP-2) with a generic entry size code. The TT bits in the vector headers will now explicitly define the byte size of each element in the vector's data payload. This simplifies the core CTE parsing logic by decoupling it from cryptographic scheme specifics, making the format more flexible and forward-compatible. This proposal renders LIP-2 obsolete.

Motivation

LIP-2 coupled the TT type code directly to a cryptographic algorithm (e.g., TT=00 for Ed25519). While this provided semantic meaning at the parsing layer, it also made the core format rigid. Adding a new algorithm or a variant with the same key size would require a new TT code and a specification update.

This proposal simplifies the parser's responsibility to a purely structural one: read a vector of N items, where each item is X bytes long. The TT code now simply defines 'X'. The semantic interpretation of what those bytes represent (e.g., an Ed25519 key vs. an SLH-DSA key) is moved to the application layer, where it ultimately matters. This makes the base CTE format more generic and extensible. The renaming to "Vector" and "Vector Index" reflects this more generic, structural nature.

Specification

This LIP replaces the specifications for Tag 00 and Tag 01 as defined in LIP-2 and renames the IxData Sub-Type 00.

---

4.1. Public Key Vector (Tag 00) - Updated

• Tag: 00
• Purpose: Encodes a vector of one or more public keys. The size of each key is determined by the header byte's Entry Size Code.
• Header Byte:

  Bits	Field	Description
  7-6	Tag (00)	Identifies this as a Public Key Vector.
  5-2	Length (N)	Number of keys in the vector (1-15).
  1-0	Entry Size Code (TT)	Specifies the size of each key (see table below).

• Entry Size Codes (TT):

  TT (Bin)	Key Size (Bytes)
  00	32
  01	64
  10	128
  11	Unused

---

4.2. Signature Vector (Tag 01) - Updated

• Tag: 01
• Purpose: Encodes a vector of one or more cryptographic signatures or signature hashes. The size of each item is determined by the header byte's Entry Size Code.
• Header Byte:

  Bits	Field	Description
  7-6	Tag (01)	Identifies this as a Signature Vector.
  5-2	Length (N)	Number of items in the vector (1-15).
  1-0	Entry Size Code (TT)	Specifies the size of each item (see table below).

• Entry Size Codes (TT):

  TT (Bin)	Item Size (Bytes)
  00	32
  01	64
  10	128
  11	29792

---

4.3.1. Vector Index (IxData Sub-Type 00) - Updated

• Name: The field previously known as Legacy Index Reference is renamed to Vector Index.
• Purpose: Provides a zero-based index into a Public Key Vector or Signature Vector. The responsibility for determining which vector is being referenced lies with the application layer, as per LIP-4.

---

Rationale

• Decoupling: This change decouples the core CTE parser from the complexities of cryptographic validation. The parser's job is to validate structure, not semantics.
• Flexibility: The application layer can now define the meaning of a given entry size (e.g., a 32-byte public key is Ed25519 for one transaction type, and PQC for another). This requires no changes to the base protocol.
• Forward Compatibility: New cryptographic schemes can be adopted without requiring new TT codes, as long as their key or signature sizes fit one of the existing size slots.

Backwards Compatibility

This proposal is a breaking change and is not backwards compatible with implementations based on LIP-2.

• Parsers compliant with LIP-2 expect the TT code to define a specific cryptographic scheme. They will misinterpret the data if they receive a stream based on this new specification.
• For example, under LIP-2, a Signature field with TT=00 implies a 64-byte Ed25519 signature. Under this proposal, TT=00 for a Signature Vector implies a 32-byte item.
• Adoption of this LIP requires a coordinated update of all CTE processors and defines a new, incompatible version of the CTE protocol.

Security Considerations

The primary security consideration is that the responsibility for correctly interpreting the cryptographic context of the data is now entirely on the application layer.

• Application logic MUST unambiguously determine the cryptographic algorithm to be used based on the transaction type or other contextual information.
• Failure to do so could lead to severe vulnerabilities, such as attempting to validate a signature with the wrong algorithm or against a key of a different type. The system's security now relies on the application layer being correct.

Copyright

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