SDKs#

The LEA SDKs provide programmatic access to the LEA blockchain for building applications, services, and tooling.

They abstract over protocol details while exposing the architectural concepts that matter to developers, such as PODs, accounts, transactions, and execution boundaries.

The SDKs are designed to remain stable as the underlying system evolves.

Purpose of the SDKs#

The primary goal of the LEA SDKs is to allow developers to interact with the network in a predictable and explicit way.

The SDKs handle:

• connection to LEA nodes,
• transaction construction and signing,
• account and identity handling,
• interaction with PODs and smart contracts,
• and submission and monitoring of execution results.

Where architectural boundaries exist in the protocol, the SDKs aim to reflect them rather than hide them.

Architectural alignment#

The SDKs are aligned with LEA’s system architecture.

Base Chain interaction#

The SDKs interact with the LEA Base Chain for:

• submitting transactions,
• observing ordering and finality,
• and retrieving data required for execution verification.

Consensus and data availability are treated as protocol-level concerns and are not embedded into application logic.

BasePOD as the default execution context#

The BasePOD acts as the default execution environment for the LEA network.

All smart contracts are ultimately registered against the BasePOD, even when developers do not explicitly interact with it. This ensures a consistent baseline for:

• security assumptions,
• account handling,
• and transaction validation.

The SDKs handle BasePOD registration and interaction implicitly unless a developer chooses to work with Custom PODs.

Execution model and POD scope#

Interaction with LEA through the SDKs is always executed within a well-defined execution context. However, explicit POD management is optional for developers.

By default, smart contracts are executed within the BasePOD. Contracts deployed this way:

• are implicitly registered to the BasePOD,
• use the BasePOD’s cryptographic primitives,
• rely on the default LEA fee and gas model,
• and do not require explicit interaction with POD-specific interfaces.

For many applications, this default model is sufficient. Developers can write and deploy smart contracts without handling POD concepts directly.

Explicit POD usage becomes relevant when developers want to define sovereign execution environments.

Custom PODs are required only if an application needs:

• its own native coin or token model,
• a custom fee or incentive structure,
• custom cryptographic schemes,
• or domain-specific governance rules.

In these cases, the SDKs expose POD-level primitives that allow developers to create, configure, and interact with Custom PODs explicitly.

Account and cryptography abstraction#

The SDKs expose account and signing interfaces that are compatible with:

• post-quantum–secure schemes provided by the BasePOD,
• and custom cryptographic models defined by individual PODs.

This allows applications to evolve their security posture without rewriting application logic.

When do I need a POD?#

You do not need to work with PODs explicitly if:

• you are deploying standard smart contracts,
• you are fine with the default LEA fee model,
• you do not require custom cryptography.

You do need a Custom POD if:

• you want to issue and control a native coin,

• you want to define your own fee or gas logic,

• you want to use non-default cryptographic schemes,

• or you require domain-specific governance or compliance rules.

Supported SDKs#

LEA provides SDKs for multiple programming environments.

Currently supported and planned SDKs include:

• JavaScript / TypeScript
• C (planned)
• Rust (planned)

Each SDK follows the same conceptual model and exposes equivalent functionality, adapted to language conventions.

What the SDKs do not do#

The SDKs intentionally do not:

• embed application-specific business logic,
• enforce governance or compliance decisions beyond what the protocol defines,
• or abstract away architectural boundaries such as POD isolation.

This keeps responsibility and trust boundaries explicit.

Getting started#

To start using an SDK, choose your language environment:

• LEA Web3 SDK → Installation and Quick Start
• more SDKs coming later 2026

Each SDK section provides:

• installation instructions,
• minimal working examples,
• and references to core APIs.

Relationship to other sections#

• Concepts explain the architectural ideas exposed by the SDKs.
• Architecture describes how SDK interactions map to system layers.
• Tools cover command-line and operational tooling.
• Operate explains how nodes and infrastructure expose SDK endpoints.