Write your program in Rust, AssemblyScript or C and compile it to deterministic WebAssembly for wasm32-unknown-unknown. Each SDK ships its own determinism lint and the same paid-counter reference with identical exports, storage keys and status numbers. The Rust lint reuses the node's own deterministic-subset validator, so a program the chain would reject fails on your machine first. Porting kits map an existing EVM, Solana or CosmWasm contract onto the programs ABI and name what does not carry over.

What it does

Three guest SDKs bind the LayerX programs ABI so a program compiles to deterministic WebAssembly for wasm32-unknown-unknown. Each language ships its own determinism lint, its own pinned toolchain description, and the same worked paid-counter reference with identical exports, storage keys, event layouts and status numbers. Three porting kits (EVM, Solana and CosmWasm) map an existing contract's vocabulary onto the programs ABI and name the constructs that do not carry over instead of emulating them. A port is a rewrite against the programs ABI, not bytecode compatibility; EVM bytecode runs on the Paxeer chain, which is a separate surface.

Key capabilities

• Rust no_std bindings that never allocate, with caller-owned buffers and checked 128-bit amounts.
• AssemblyScript bindings with a source gate that refuses non-deterministic builtins before compilation.
• C bindings built freestanding with -nostdlib, so no clock, socket or thread symbol links.
• EVM, Solana and CosmWasm porting crates, each with a migration guide and an executable reference.
• One shared capability fixture read by all three languages' test suites.
• layerx new scaffolds a program project; layerx program build enforces the determinism policy locally.

Differentiators

The EVM kit keeps keccak256(key . slot) storage slot addresses, event topic0 values and 4-byte function selectors unchanged after the port, computed with a real keccak256. A single fixture, programs/sdk/vectors/capability-boundary.kvx, is read by the Rust, AssemblyScript and C tests, so all three languages are held to the same encoded bytes. The Rust determinism lint reuses the runtime's own deterministic-subset validator and compares the SDK's frozen surface against layerx_programs_runtime, so the toolchain and the node cannot disagree.

Outcomes

• Fail a non-deterministic build on your machine before the chain rejects it.
• Keep storage slot addresses, event topics and function selectors unchanged after an EVM port.
• Hold all three languages to one shared capability fixture.

Technical notes

• Toolchain floors: cargo and rustc 1.91.1, Node.js 22 or newer with AssemblyScript pinned at 0.27.31, clang 15.0 or newer for the C bindings. The programs workspace pins edition 2021 and denies unwrap_used, expect_used, float_arithmetic and lossy_float_literal.
• All three guest toolchains declare abi_version 1 against the layerx_v1 import module. The runtime's frozen manifest also carries layerx_v2 and a layerx_v3 oracle_read, and the lint accepts --abi-version 1 or 2, so the v2 host surface is not yet described by a guest toolchain file.
• New ports target ABI v2 through the reference-v2 guest in each kit. make programs-porting-v2-references builds all three for release, lints each at --abi-version 2, then runs them through programs_call_activity; execution and receipt qualification need the production C transition and that gate is recorded in qualification.kvx rather than met locally.
• Two ABI v2 gaps are recorded, not papered over: Solana ports get no enumerable authenticated instruction account list, and CosmWasm's MessageInfo.funds is unavailable rather than empty, so monetary input stays an explicit 402LXP capability.
• Guest execution is dispatched under kernel module ID 9 (LXP_MODULE_PROGRAMS) as part of a LayerX activity, which costs 1/10 of a cent; a program writes no balances of its own.
• layerx new <name> scaffolds a Rust program only. The AssemblyScript and C paths start from their examples/paid-counter templates.

#![no_std]

use layerx_program_sdk::{program, trap_on_panic, ProgramError};

trap_on_panic!();

program!(handle);

fn handle(value: i64) -> Result<i64, ProgramError> {
    Ok(value)
}

More in Developers