-
Notifications
You must be signed in to change notification settings - Fork 3
LEZ Lambda prize proposal from "Zones team" #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
77c269d
LP-0011 prize details and requirements
moudyellaz 8d88552
Add LP-0012 prize details for structured event system
moudyellaz 25919c7
Add LP-0013 prize details for token program improvements
moudyellaz aadd718
Add Solana resource links to LP-0013.md
moudyellaz 6f00102
Add LP-0014 prize details for general cross-program calls via tail calls
moudyellaz b082e9a
Revise LP-0015 for bug bounty on protocol vulnerabilities
moudyellaz 9c6f40c
Introduce LP-0016: Adversarial testing and fuzzing prize
moudyellaz 4eddf00
Update title in LP-0011.md for clarity
moudyellaz 0660ce3
Add new prize entries to README
moudyellaz 1a955d1
Fix formatting in LP-0016 markdown header
moudyellaz 8657529
Apply suggestion from @schouhy
moudyellaz 5107a30
Revise LP-0013 prize details for token program improvements
moudyellaz 299509d
Revise LP-0013 prize details for ATAs and tooling
moudyellaz c36c348
Revise prize entries in README
moudyellaz af3b9c8
Update prizes/LP-0014.md
moudyellaz 9901682
Update prizes/LP-0016.md
moudyellaz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,104 @@ | ||
| # LP-0011: Program development tooling: minimal Rust SDK for programs + CPI | ||
|
|
||
| **`Logos Circle: <N/A>`** | ||
|
|
||
| ## Overview | ||
|
|
||
| This prize funds 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 | ||
| ```rust | ||
| #[LEZ_sdk::program] | ||
| mod counter { | ||
|
|
||
| #[LEZ_sdk::function] | ||
| pub fn increment(account: AccountWithMetadata, amount: u64) -> Result<()> { | ||
| ... | ||
| } | ||
| } | ||
| ``` | ||
| ## Success Criteria | ||
|
|
||
| - [ ] “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. | ||
|
|
||
| ## 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 | ||
| - **Next Planned Revision Date:** TBD | ||
|
|
||
|
|
||
| ## 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) | ||
| ## Evaluation Process | ||
|
|
||
| By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins. | ||
|
|
||
| ## Resources | ||
|
|
||
| - [LEZ Github repository](https://github.com/logos-blockchain/lssa) | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,103 @@ | ||
| # LP-0012: Event/Log mechanism: Structured events for LEZ program execution | ||
|
|
||
| **`Logos Circle: <N/A>`** | ||
|
|
||
| ## Overview | ||
| This prize is for designing and implementing a *structured event system* that lets LEZ programs emit events describing what happened during execution in a way that is both *human-interpretable* (debugging, wallet UX) and *machine-readable* (indexers, explorers, apps). Events must be retrievable by clients after execution and must still be emitted even when a transaction fails. | ||
|
|
||
| Other ecosystems demonstrate the value of making execution metadata available to clients: Solana exposes per-transaction `meta.logMessages` (alongside `meta.err`) via RPC, which is widely used for debugging. Cosmos SDK treats events as a first-class client interface for explorers and wallets, returning structured type/attribute events in ABCI results rather than storing them in state. | ||
|
|
||
| ## Motivation | ||
| Currently, program-level feedback is too limited for good UX and tooling: developers and users struggle to understand *why* execution failed, indexers cannot reliably classify activity, and explorers/wallets cannot provide meaningful post-transaction narratives. | ||
|
|
||
| A prize is appropriate because there are multiple plausible designs with important trade-offs (format/encoding, namespacing, ordering, size limits, failure semantics, privacy considerations). We want builders to propose and implement competing approaches, then adopt the one that is simplest, robust, and most indexer-friendly. | ||
|
|
||
| ## Example | ||
| ```rust | ||
| fn main() { | ||
| let ( | ||
| ProgramInput { | ||
| pre_states, | ||
| instruction: Withdraw { amount }, | ||
| }, | ||
| instruction_data, | ||
| ) = read_nssa_inputs::<Instruction>(); | ||
|
|
||
| let [pre_state] = pre_states.try_into().unwrap(); | ||
|
|
||
| let balance = read_balance(&pre_state.account); | ||
|
|
||
| if balance < amount { | ||
| // <<<<<< EVENT HERE | ||
| emit_event(InsufficientFunds { | ||
| account: pre_state.account.address, | ||
| requested: amount, | ||
| available: balance, | ||
| }); | ||
|
|
||
| panic!("Insufficient funds"); | ||
| } | ||
|
|
||
| write_nssa_outputs(instruction_data, vec![pre_state], vec![post_state]); | ||
| } | ||
| ``` | ||
|
|
||
| ## Success Criteria | ||
|
|
||
| - [ ] Event API for programs: Provide a Rust-facing API usable inside LEZ programs, e.g. `emit_event(MyEvent { ... })`, that supports emitting typed events with structured fields. | ||
| - [ ] Machine-readable format: Events are encoded deterministically with: | ||
| - stable versioning, | ||
| - stable ordering, | ||
| - explicit program attribution (e.g., `program_id` included or enforced by runtime), | ||
| - and a documented schema strategy (e.g., discriminant + bytes payload; or key-value attributes with ordering). | ||
| - [ ] Human-friendly rendering: Provide a reference decoder/formatter that renders events into a readable form (CLI output or JSON) for debugging. | ||
| - [ ] Available post-execution: After transaction execution, clients can retrieve emitted events via a documented interface (e.g., tx receipt / RPC / block data access). | ||
| - [ ] Emittable on failure: If a transaction fails (program aborts / returns error), events emitted prior to failure are still available to clients (i.e., not discarded with state reversion). | ||
| - [ ] Testing: Include tests covering: | ||
| - deterministic encoding/decoding, | ||
| - event ordering, | ||
| - size-limit behaviour, | ||
| - failure-path persistence (“emit then fail” still returns events). | ||
|
|
||
| ## Scope | ||
|
|
||
| ### In Scope | ||
| - A clear event model (record structure, attribution rules, encoding). | ||
| - Rust SDK hooks for emitting events from programs (public and, where relevant, privacy-preserving execution environments). | ||
| - Runtime/sequencer integration sufficient to make events retrievable after execution and to preserve them in failure cases. | ||
| - Decoder tooling and documentation for clients/indexers. | ||
|
|
||
|
|
||
| ### Out of Scope | ||
| - A full hosted explorer, production indexer stack, or managed data service. | ||
| - Heavy, framework-wide “magic” (auto-generated IDLs, large macro DSLs) not necessary for event emission. | ||
| - Privacy-leaking defaults: designs must be explicit about what is emitted and what is safe to emit (especially for private execution), but this prize does not require solving private analytics beyond sensible defaults. | ||
|
|
||
|
|
||
| ## Prize Structure | ||
|
|
||
| - **Total Prize:** $TBD | ||
| - **Next Planned Revision Date:** TBD | ||
|
|
||
|
|
||
| ## 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 | ||
| - Public repository containing: | ||
| - implementation (SDK + any runtime/sequencer glue), | ||
| - event format specification (`docs/event-format.md`), | ||
| - decoder/formatter tool (CLI or library), | ||
| - at least one example program demonstrating: | ||
| - success-path events, | ||
| - failure-path events (emit then fail), | ||
| - reference indexer example (can be minimal). | ||
|
|
||
| ## Evaluation Process | ||
|
|
||
| By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins. | ||
|
|
||
| ## Resources | ||
|
|
||
| - [LEZ Github repository](https://github.com/logos-blockchain/lssa) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| # LP-0013: Token program improvements: authorities | ||
|
|
||
| **`Logos Circle: <N/A>`** | ||
|
|
||
| ## Overview | ||
| This prize targets practical, production-oriented improvements to the LEZ Token program to support controlled, real-world token issuance. The current example is intentionally minimal; this challenge focuses on adding a mint authority model that enables variable supply, revocable control, and common issuance patterns expected by wallets and applications. | ||
|
|
||
| [Solana’s SPL Token ecosystem](https://solana.com/docs/tokens/basics/create-token-account) is a useful reference point: it supports authority-controlled minting, enabling fixed supply, capped supply, permissioned minting, and revocation. | ||
|
|
||
| ## Motivation | ||
| Without minting authorities,token issuers cannot implement widely used supply models: | ||
| - fixed supply tokens (mint authority revoked), | ||
| - variable or inflationary supply, | ||
| - permissioned issuance, | ||
| - governance-controlled minting. | ||
|
|
||
| Adding a clean authority model enables the ecosystem to support real economic use cases while preserving minimalism and auditability. | ||
|
|
||
|
|
||
| ## Success Criteria | ||
| - [ ] Variable-size Tokens through minting authority: Implement a mint authority model for LEZ tokens that supports: | ||
| - mint authority set at token initialization, | ||
| - minting by the authority, | ||
| - authority rotation and/or revocation (e.g., set to `None` to make supply fixed). | ||
| - [ ] Documentation and examples: Provide: | ||
| - at least *two* example integrations (e.g., “fixed supply token with revoked authority” and “variable supply token with mint authority”). | ||
|
|
||
| ## Scope | ||
|
|
||
|
|
||
| ### In Scope | ||
| - Mint authority (and optionally freeze authority if proposed, but not required). | ||
| - Clear specifications for authority semantics. | ||
| - Minimal, auditable implementation with strong tests. | ||
|
|
||
| ### Out of Scope | ||
| - A full-featured token standard with numerous optional extensions. | ||
| - Complex compliance systems, fee mechanics, or DEX integration. | ||
|
|
||
| ## Prize Structure | ||
|
|
||
| - **Total Prize:** $TBD | ||
| - **Next Planned Revision Date:** TBD | ||
|
|
||
|
|
||
| ## 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 | ||
| - Public repository containing: | ||
| - code changes to the token program, | ||
| - `README` + design docs (authority model and lifecycle), | ||
| - tests and example programmes/scripts. | ||
|
|
||
| ## Evaluation Process | ||
|
|
||
| By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins. | ||
|
|
||
| ## Resources | ||
|
|
||
| - [LEZ Github repository](https://github.com/logos-blockchain/lssa) | ||
| - [Solana - Create a Token Account](https://solana.com/docs/tokens/basics/create-token-account) | ||
| - [Solana - Token Extensions](https://solana.com/docs/tokens/extensions) | ||
| - [Solana - Set Authority](https://solana.com/docs/tokens/basics/set-authority) |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.