• LIP: 9
• Layer: Consensus
• Title: Programmable Transaction Format
• Author: Allwin Ketnawang
• Created: 2025-07-12
• Status: Draft

Abstract#

This LIP proposes a universal transaction format for the LEA protocol. The format consists of a minimal, two-part structure: a DecoderID and a Payload. The DecoderID is a 32-byte identifier for an on-chain contract responsible for interpreting the transaction. The Payload is an opaque byte stream passed to this contract. This design delegates all transaction validation, serialization, and execution logic to the contract layer, making the base protocol itself simpler and more extensible.

Motivation#

Traditional blockchain protocols enforce a single, rigid transaction structure. This creates significant friction when introducing new features, such as novel signature schemes, privacy-preserving technologies, or account abstraction logic. Implementing such upgrades typically requires a network-wide consensus change (hard fork), which is a slow, contentious, and complex process.

The motivation for this proposal is to create a flexible and future-proof foundation for the protocol. By abstracting transaction interpretation away from the base consensus rules, the network can adopt new functionalities dynamically, without requiring core protocol modifications. This shifts the responsibility for innovation to the execution layer, allowing for faster, permissionless evolution.

Specification#

The base protocol shall recognize a single transaction structure, referred to as the "Transaction Envelope."

1. Transaction Envelope Definition: The Transaction Envelope is the raw byte array submitted to the network for processing. It is composed of two distinct fields:

   • DecoderID [bytes 32]: The first 32 bytes of the envelope. This field contains the address of a smart contract, hereafter referred to as the "Decoder."
   • Payload [bytes N]: All bytes of the envelope following the DecoderID. The protocol treats this field as an opaque byte stream.

2. Base Protocol Execution Rule: The consensus layer will enforce a single, immutable rule for initiating transaction processing:

   a. Upon receiving a Transaction Envelope, the node reads the first 32 bytes to identify the DecoderID. b. The node invokes the contract located at the DecoderID address. c. The node passes the Payload to the Decoder contract for all subsequent processing.

3. Decoder Responsibilities: The Decoder contract is responsible for all logic related to the transaction, including, but not limited to:

   • Parsing the Payload.
   • Validating signatures and authorizing the transaction.
   • Implementing replay protection (e.g., via a nonce).
   • Defining and processing fee payments.
   • Executing the state transition.

Rationale#

The design is based on the principle of a minimal, robust core protocol with maximal flexibility at the edges.

• Forward Compatibility: This is the primary rationale. New cryptographic standards (e.g., post-quantum signatures) or transaction features (e.g., calldata compression, ZK-proof verification) can be introduced by deploying a new Decoder contract. This avoids the need for hard forks for a wide class of upgrades.
• Native Account Abstraction: This model provides account abstraction at the protocol's most fundamental level. The logic for what constitutes a valid transaction (e.g., multi-sig, social recovery, fee payment in arbitrary tokens) is not defined by the protocol but by the Decoder, which is chosen by the user or wallet.
• Architectural Simplicity: By delegating complexity to the execution layer, the consensus engine is simplified significantly. Its sole responsibility is to dispatch the payload to the correct interpreter. This reduces the surface area for potential consensus-level bugs. This layered architecture is analogous to the Internet Protocol (IP), where the core network layer is responsible for routing packets, while higher-level protocols (TCP, HTTP) handle interpretation and structure.

Backwards Compatibility#

This LIP defines the foundational transaction format for the LEA protocol. As such, it does not have backwards compatibility considerations with a prior state. It establishes the framework upon which all future transaction types will be built.

Security Considerations#

The security model is shifted from the protocol to the execution layer.

• Decoder Security: The integrity and security of any given transaction are entirely dependent on the implementation of its specified Decoder contract. Users must trust the Decoders they use. A buggy or malicious Decoder could result in a permanent loss of funds.
• Gas Metering: To prevent Denial-of-Service attacks from computationally intensive or non-terminating Decoders, their execution must be strictly metered (i.e., via a gas mechanism).
• Replay Protection: The base protocol does not provide replay protection. Each Decoder must implement its own nonce or other replay prevention mechanism. Failure to do so would make transactions vulnerable to replay attacks.

Copyright#

This LIP is licensed under the MIT License.