lambda-prize/prizes/LP-0011.md

LP-0011: Program development tooling: minimal Rust SDK for programs + CPI [DRAFT]

Status: Draft - To review with overlap with LEZ framework Logos Circle: N/A

Overview

This prize is for a minimal Rust SDK layer that makes it materially easier to write LEZ programs while keeping program execution semantics explicit and auditable. The goal is to remove repetitive plumbing (entrypoints, instruction routing, byte parsing, basic account validation, CPI construction) so builders can focus on program logic.

Unlike heavyweight frameworks, this SDK should stay close to idiomatic Rust: small surface area and predictable generated code. Attribute macros are acceptable if they only generate the unavoidable wiring and remain easy to inspect (e.g., via cargo expand). Rust supports attribute-like procedural macros for this kind of compile-time code generation.

Motivation

Even trivial programs require a lot of manual boilerplate: entrypoint definitions, instruction enums, instruction decoding from raw bytes, CPI instruction construction, and repetitive validation patterns. This increases time-to-first-program, produces inconsistent conventions across repos, and introduces avoidable parsing/validation bugs.

A competitive prize is a good mechanism here because multiple teams can propose different minimal designs and ergonomics trade-offs (how explicit the generated router is, how CPI is represented, how validation helpers are composed) and the ecosystem can adopt the cleanest, most maintainable approach without prematurely locking into a monolithic framework. (As a point of contrast, Solana’s Anchor demonstrates macro-based boilerplate reduction, but this prize explicitly targets a lighter, more explicit approach.)

Example

#[LEZ_sdk::program]
mod counter {

    #[LEZ_sdk::function]
    pub fn increment(account: AccountWithMetadata, amount: u64) -> Result<()> {
        ...
    }
}

Success Criteria

Functionality

• “Hello-world” program ergonomics: A reference counter program can be written with:
  • a single program module annotation (e.g., #[LEZ_sdk::program]), and
  • per-instruction function annotations (e.g., #[LEZ_sdk::function]),
  • and compiles on stable Rust.
• Generated entrypoint + routing: The SDK generates a deterministic instruction router that:
  • maps instruction discriminants to handler fns,
  • performs byte decoding for handler arguments,
  • returns consistent error codes/messages on malformed input. The generated code must be inspectable/documented (include cargo expand output in docs/ or examples/).
• CPI abstraction: Provide a small CPI API that supports:
  • building an instruction targeting another program,
  • passing accounts + metadata explicitly,
  • serialising arguments deterministically,
  • invoking the runtime CPI entry (or equivalent) with clear error propagation.
• No heavyweight “magic”: The SDK must not introduce a framework-style DSL. Specifically:
  • no auto-generated account schemas/IDL,
  • no hidden reflection-based dispatch,
  • no implicit account fetching,
  • no implicit mutation/authorisation rules.
• Testing + examples: Include:
  • unit tests for encoding/decoding and router correctness,
  • at least two example programs, one demonstrating CPI (Program A calls Program B),
  • negative tests for malformed instruction bytes / wrong account sets.
• Documentation: A concise “Getting Started” plus a “Design” doc explaining:
  • instruction encoding format,
  • how routing is generated,
  • CPI construction,
  • extension points (how future features would be added without bloat),
  • explicit non-goals.

Reliability

• The SDK returns deterministic, documented error codes for all malformed-input and wrong-account-set scenarios.
• The generated router handles all invalid instruction discriminants with a documented error rather than a panic.

Performance

• Document the compile-time overhead introduced by the SDK macros (e.g., via cargo build --timings) to confirm it does not materially slow incremental builds.

Supportability

• End-to-end integration tests for the SDK (encoding/decoding, routing, CPI) run via cargo test and are included in CI.
• CI must be green on the default branch.
• A README documents end-to-end usage: how to add the SDK as a dependency, write a program using it, expand macros for inspection, and run the included examples.
• A reproducible end-to-end demo script running the example programs is provided and works against a real local sequencer with RISC0_DEV_MODE=0.
• A recorded video demo showing the example programs running on-chain is included in the submission; the recording must show terminal output (including proof generation) to confirm RISC0_DEV_MODE=0 was active.

Scope

In Scope

• Minimal Rust crates (e.g., LEZ-sdk + optional LEZ-sdk-macros) that:
  • reduce entrypoint boilerplate,
  • provide explicit instruction routing and argument decoding,
  • provide CPI helpers with explicit account lists,
  • provide light validation helpers (e.g., common checks expressed as library functions, not “framework rules”).
• Clear, deterministic instruction encoding and decoding utilities.
• Developer tooling guidance (e.g., recommended cargo expand workflow and debug logging conventions).

Out of Scope

• Full frameworks comparable to Anchor (e.g., account derive systems, auto validation rule engines, IDL generation, client codegen).
• Complex macro DSLs that substantially change how Rust code is written.
• Wallet/client SDKs (TypeScript, Python, etc.) and off-chain tooling.
• Runtime changes to LEZ (this prize is strictly a Rust SDK layer).

Prize Structure

• Total Prize: $TBD
• Effort: Medium

Eligibility

Open to any individual or team. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT or Apache-2.0.

Submission Requirements

• A public repository containing:
  • the SDK crate(s),
  • examples (counter, plus a CPI example),
  • documentation (README.md + docs/design.md or equivalent),
  • tests (CI runnable via cargo test).
• Clear versioning and a minimal changelog.
• If any macros are used, include a section documenting what each macro expands into and why it is necessary (Rust procedural macros execute at compile time and should be treated with the same care as build scripts)
• A narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full end-to-end flow. A silent screencast is not sufficient (see demo requirements).

Evaluation Process

By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins.

Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation.

The following policies apply to all prizes (see evaluation policies):

• Submissions: each builder (or team) is allowed a maximum of 3 submissions per prize, with at most one submission/review per week.
• Feedback: initial evaluation feedback is limited to a pass/fail indication against the success criteria.

Resources

• LEZ Github repository

Potential for Subsequent λPrizes

TBD