diff --git a/README.md b/README.md index b5b6328..1a3efcb 100644 --- a/README.md +++ b/README.md @@ -7,19 +7,26 @@ A competitive prize framework for the Logos ecosystem. **λ**Prize targets contr All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown file following the `LP-XXXX` naming convention. -| File | Description | -| ---------------------------- | -------------------------------------------------------- | -| [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | -| [LP-0001](prizes/LP-0001.md) | Private NFT Ownership Proof | -| [LP-0002](prizes/LP-0002.md) | Private M-of-N Multisig | -| [LP-0003](prizes/LP-0003.md) | Private Allowlist / Airdrop Distributor | -| [LP-0004](prizes/LP-0004.md) | Sealed-Bid Auction Using Shielded Balances | -| [LP-0005](prizes/LP-0005.md) | Private Token Balance Attestation | -| [LP-0006](prizes/LP-0006.md) | Bitcoin–LEZ Atomic Swap Using Adaptor Signatures | -| [LP-0007](prizes/LP-0007.md) | Monero–LEZ Atomic Swap | -| [LP-0008](prizes/LP-0008.md) | Autonomous AI Module with Wallet, Storage, and Messaging | -| [LP-0009](prizes/LP-0009.md) | Keycard NIP-46 Nostr Signer Proxy | -| [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | +| File | Description | +| ---------------------------- | -------------------------------------------------------- | +| [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | +| [LP-0001](prizes/LP-0001.md) | Private NFT Ownership Proof | +| [LP-0002](prizes/LP-0002.md) | Private M-of-N Multisig | +| [LP-0003](prizes/LP-0003.md) | Private Allowlist / Airdrop Distributor | +| [LP-0004](prizes/LP-0004.md) | Sealed-Bid Auction Using Shielded Balances | +| [LP-0005](prizes/LP-0005.md) | Private Token Balance Attestation | +| [LP-0006](prizes/LP-0006.md) | Bitcoin–LEZ Atomic Swap Using Adaptor Signatures | +| [LP-0007](prizes/LP-0007.md) | Monero–LEZ Atomic Swap | +| [LP-0008](prizes/LP-0008.md) | Autonomous AI Module with Wallet, Storage, and Messaging | +| [LP-0009](prizes/LP-0009.md) | Keycard NIP-46 Nostr Signer Proxy | +| [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | +| [LP-0011](prizes/LP-0011.md) | Program development tooling | +| [LP-0012](prizes/LP-0012.md) | Event/Log mechanism | +| [LP-0013A](prizes/LP-0013A.md) | Token program improvements (authorities) | +| [LP-0013B](prizes/LP-0013B.md) | Token program improvements (ATAs + wallet tooling) | +| [LP-0014](prizes/LP-0014.md) | General cross-program calls via tail calls | +| [LP-0015](prizes/LP-0015.md) | Bug bounty: Protocol vulnerabilities | +| [LP-0016](prizes/LP-0016.md) | Adversarial testing/ uzzing infrastructure | ### Proposing a New Prize @@ -62,4 +69,4 @@ at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be -dual licensed as above, without any additional terms or conditions. \ No newline at end of file +dual licensed as above, without any additional terms or conditions. diff --git a/prizes/LP-0011.md b/prizes/LP-0011.md new file mode 100644 index 0000000..4f5ec79 --- /dev/null +++ b/prizes/LP-0011.md @@ -0,0 +1,104 @@ +# LP-0011: Program development tooling: minimal Rust SDK for programs + CPI + +**`Logos Circle: `** + +## 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) diff --git a/prizes/LP-0012.md b/prizes/LP-0012.md new file mode 100644 index 0000000..0bbac6e --- /dev/null +++ b/prizes/LP-0012.md @@ -0,0 +1,103 @@ +# LP-0012: Event/Log mechanism: Structured events for LEZ program execution + +**`Logos Circle: `** + +## 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::(); + + 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) diff --git a/prizes/LP-0013A.md b/prizes/LP-0013A.md new file mode 100644 index 0000000..3b1413d --- /dev/null +++ b/prizes/LP-0013A.md @@ -0,0 +1,65 @@ +# LP-0013: Token program improvements: authorities + +**`Logos Circle: `** + +## 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) diff --git a/prizes/LP-0013B.md b/prizes/LP-0013B.md new file mode 100644 index 0000000..e27d74b --- /dev/null +++ b/prizes/LP-0013B.md @@ -0,0 +1,75 @@ +# LP-0013: Token program improvements: Associated Token Accounts (ATAs) + wallet tooling + +**`Logos Circle: `** + +## Overview +This prize targets practical improvements that make LEZ tokens usable in real wallets and applications by introducing deterministic Associated Token Accounts (ATAs) and minimal tooling to manage them. + +[Solana’s SPL Token ecosystem](https://solana.com/docs/tokens/basics/create-token-account) provides a useful reference: it separates *mints* from *token accounts* and commonly uses ATAs as a canonical token account per wallet+mint pair, simplifying balance discovery and improving UX. + +## Motivation +Without deterministic token accounts: + - wallets cannot reliably discover a user’s balances, + - users must manually create and select accounts, + - integrations become brittle and error-prone, + - UX degrades significantly. + +A standardized ATA mechanism provides predictable account locations, idempotent creation, and wallet-friendly defaults. + +## Success Criteria +- [ ] Associated Token Account (ATA) mechanism: Implement an ATA program/pattern such that: + - there is a deterministic token account address for a given `(owner, mint)` pair, + - the derivation is documented and stable, + - creation of an ATA is idempotent (safe to call repeatedly), + - token accounts created via the ATA mechanism are clearly identifiable as “associated token accounts”. +- [ ] Wallet/CLI command support: Provide user-facing commands (or a minimal wallet-facing library + CLI) for: + - creating an ATA for a given mint, + - querying the derived ATA address, + - listing a wallet’s ATAs for known mints (at minimum via explicit mint list input), + - transferring tokens using ATAs as defaults when available. +- [ ] Backwards-compatible baseline: Existing simple transfers (one sender/one recipient), mint/burn, and NFTs continue to work (or have a clear migration story and compatibility layer). +- [ ] Documentation and examples: Provide: + - a short “Wallet integration guide” describing how to derive/create/use ATAs. + +## Scope + +### In Scope +- ATA programme/pattern for deterministic token accounts. +- Minimal wallet/CLI tooling for the ATA lifecycle. +- Clear specifications for: + - ATA derivation and ownership rules, + - expected UX defaults (e.g., “use ATA if present; otherwise prompt/create”). +- Minimal, auditable implementation with strong tests. + +### Out of Scope +- Authority models for minting (covered in a separate prize). +- A full production wallet UI or hosted explorer. +- 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 and any ATA program, + - CLI tooling and/or wallet-facing library, + - `README` + design docs (ATA derivation and UX guidance), + - 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 - ATA](https://github.com/solana-labs/solana-program-library/blob/master/docs/src/associated-token-account.md) diff --git a/prizes/LP-0014.md b/prizes/LP-0014.md new file mode 100644 index 0000000..ee30fdb --- /dev/null +++ b/prizes/LP-0014.md @@ -0,0 +1,89 @@ +# LP-0014: General cross-program calls via tail calls: public vs internal entrypoints + tooling + +**`Logos Circle: `** + +## Overview +This prize is for designing and implementing *general cross-program calls* (call mid-execution, then continue) while keeping *tail calls as the only execution primitive*. The system should let a program tail-call another program, have control return later via another tail call, and then continue execution in an *internal-only function* that cannot be invoked directly by users. + +Conceptually, this is about making chained execution feel like a normal “call/return” experience for developers, while preserving the simplicity of a tail-call-only model. This aligns with well-known compilation techniques like *continuation-passing style (CPS)*, where control flow is made explicit and all calls are tail calls. + +## Motivation +Modelling general calls using tail calls requires awkward patterns because all functions are effectively externally callable. That prevents encapsulation, makes interfaces hard to reason about, and creates security footguns (users can jump into “continuation” handlers directly). + +We want a principled mechanism to distinguish *public entrypoints* from *internal continuation steps*, ideally using an unforgeable authority mechanism (e.g., a call capability/ticket) so only legitimate chained execution can reach internal functions. Capability-based security literature motivates why unforgeable references/capabilities are useful for enforcing least privilege and interface boundaries. + +## Success Criteria +- [ ] External vs internal functions: Programs can explicitly declare: + - public entrypoints callable by users, and + - internal-only functions callable only during chained execution. +- [ ] Non-forgeable internal access: Provide a mechanism (e.g., a runtime-issued call-capability / ticket / proof) such that: + - internal functions require this capability, + - users cannot fabricate it, + - and direct user invocation of internal functions fails deterministically. +- [ ] General calls compile down to tail calls: Demonstrate an execution model where “call B then return to A and continue” is expressed purely with tail calls, consistent with CPS-style compilation intuition. +- [ ] Ergonomic developer tooling: Provide tooling (preferably Rust SDK support) so developers can write general calls naturally, e.g.: + - `call_program!(B::do_thing(args) => then A::continue_internal(ctx))`, + - or an equivalent explicit API that remains readable and auditable. +- [ ] End-to-end demo: Provide a working example with two programs: + 1. User calls `A::public_entry()` + 2. A tail-calls `B::public_entry()` (or similar) + 3. B tail-calls back to `A::internal_continue()` + 4. A continues and finalises + Plus a negative test: user tries to call `A::internal_continue()` directly and it is rejected. +- [ ] Clear interface rules: A concise spec describing: + - how entrypoints are enumerated/encoded, + - how internal-only routing is enforced, + - ordering and determinism guarantees, + - error semantics. +- [ ] Test coverage: Unit/integration tests for: + - capability validity checks, + - replay/duplication handling (if relevant), + - direct-call prevention, + - nested/multi-step chains (at least one multi-hop scenario). + + +## Scope + +### In Scope +- Mechanism to mark function visibility (external vs internal-only). +- Runtime/sequencer verification rules to enforce internal-only access. +- Tooling / SDK support to author general-call patterns that compile to tail-call chains. +- Example programs and tests demonstrating correctness and UX. + + +### Out of Scope +- Introducing mid-execution synchronous calls as a new runtime primitive (tail calls must remain the only primitive). +- A full framework rewrite; this should be a focused extension to enable safe composition. +- Solving every possible cross-program security policy (e.g., global allowlists). The goal is encapsulation + safe chaining. + + +## 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 (runtime/sequencer checks if required + SDK/tooling), + - specification document (`docs/general-calls-via-tail-c-calls.md`), + - example programs (A and B) + scripts to run the demo, + - tests runnable in CI. +- A short walkthrough (README or video) showing: + - the developer-facing API for general calls, + - the tail-call chain produced at runtime, + - failure when a user attempts to invoke an internal function directly. + +## 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) +- [Cross Program Invocation](https://solana.com/docs/core/cpi) +- [Tail calls](https://github.com/WebAssembly/tail-call/blob/main/proposals/tail-call/Overview.md) diff --git a/prizes/LP-0015.md b/prizes/LP-0015.md new file mode 100644 index 0000000..73850bd --- /dev/null +++ b/prizes/LP-0015.md @@ -0,0 +1,85 @@ +# LP-0015: Bug bounty: Protocol vulnerabilities (correctness, security, DoS) + +**`Logos Circle: `** + +## Overview +This prize rewards security researchers and builders who find and responsibly report vulnerabilities in the protocol implementation: anything that could cause incorrect execution, state corruption, denial of service, or violations of protocol rules. Findings should be reported with enough detail to reproduce, assess impact, and fix. + +## Motivation +Protocols at this stage are especially prone to deep correctness and security bugs (parsing edge cases, authorisation bypasses, verification inconsistencies, resource exhaustion). These issues are hard to uncover through unit tests alone and often require adversarial thinking and targeted fuzzing. + +A competitive bug bounty encourages broad, parallel review by experienced researchers and provides a fast feedback loop for hardening the implementation before wider adoption. Coordinated disclosure is a recognised approach for reducing real-world risk while enabling fixes. + +## Success Criteria +- [ ] Valid vulnerability affecting protocol correctness, security, or availability (examples include: invalid state transitions accepted, authorisation bypass, verification inconsistencies, crash/panic via malformed inputs, resource exhaustion/DoS, consensus/sequencer divergence). +- [ ] Reproducible proof-of-concept (PoC) with step-by-step instructions (inputs, environment, commands) such that the Logos team can reproduce reliably. +- [ ] Impact analysis clearly explaining: + - what breaks (rules/invariants violated), + - who can exploit it (attacker capabilities), + - worst-case outcomes. +- [ ] Severity assessment provided using a standard framework or a clearly reasoned equivalent. +- [ ] Suggested mitigation (a patch, design change, or concrete fix direction), even if partial. +- [ ] Responsible disclosure: reported privately, with no public disclosure until the Logos team approves. + +## Scope + + +### In Scope +- Protocol implementation issues that could lead to: + - incorrect execution or acceptance of invalid transitions, + - state corruption or root/digest inconsistencies, + - signature / authorisation bypasses, + - ZK proof verification inconsistencies or acceptance of malformed proofs, + * transaction decoding / validation weaknesses, + - sequencer/replay verification mismatches, + - resource exhaustion / denial of service (CPU, memory, storage, queue growth, pathological inputs). + +### Out of Scope +- Social engineering, phishing, or attacks requiring compromising developers/validators/users. +- Purely theoretical issues without a plausible exploit path or without a reproducible PoC. +- Issues that depend on undefined behaviour outside the protocol (e.g., OS compromise). +- “Best practice” suggestions that are not vulnerabilities (unless they demonstrably enable exploit). + +## 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 submission must include: + +- Title + summary (one paragraph). +- Affected component(s) (e.g., tx parsing, state transition verification, proof verification, sequencer logic). +- Severity (CVSS v4.0 vector/score preferred) plus justification. +- Reproduction steps: + - environment setup, + - exact inputs (or a generator), + - exact commands/scripts. +- PoC (code or minimal payloads) demonstrating exploitation. +- Impact (what invariant is broken; practical consequences). +- Mitigation (patch PR, diff, or clear fix guidance). +- Disclosure safety: redact secrets/keys; do not include exploit code that meaningfully endangers live systems unless explicitly requested for verification. + +## Evaluation Process + +This prize *deviates from first-come-first-served*. +- Reports are *triaged* for validity and severity. +- Rewards (and whether multiple reports are awarded) are determined by: + - severity/impact, + - reproducibility quality, + - exploit plausibility, + - novelty (non-duplicate). +- Duplicates: typically the first complete, reproducible report wins; later duplicates may receive acknowledgement only. + +## Resources + +- [LEZ Github repository](https://github.com/logos-blockchain/lssa) +- [ISO/IEC 29147:2018 - Information technology](https://www.iso.org/standard/72311.html) +- [CVSS v4.0 Specification Document](https://www.first.org/cvss/specification-document) +- [Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) +- [Vulnerability Disclosure Guidelines](https://www.hackerone.com/terms/disclosure-guidelines) diff --git a/prizes/LP-0016.md b/prizes/LP-0016.md new file mode 100644 index 0000000..181fed3 --- /dev/null +++ b/prizes/LP-0016.md @@ -0,0 +1,75 @@ +# LP-0016: Adversarial testing/fuzzing infrastructure: stress-test the protocol under hostile inputs + +**`Logos Circle: `** + +## Overview +This prize is for building a *repeatable adversarial testing + fuzzing framework* that continuously stress-tests the protocol implementation to uncover edge cases: crashes/panics, invariant violations, inconsistent state transitions, and (where applicable) sequencer vs replayer divergences. + +The deliverable should make it easy for contributors to add new fuzz targets, generate hostile inputs, reproduce failures deterministically, and minimise failing cases into small regression tests. Coverage-guided fuzzing tools such as *libFuzzer* (commonly used via *cargo-fuzz* in Rust) are well-suited to automatically explore large input spaces and evolve a corpus to maximise code coverage. + +## Motivation +Manual testing cannot reasonably cover the full input space of a protocol: transaction decoding, boundary sizes, invalid state combinations, ordering/pathological sequences, and resource exhaustion behaviours. A dedicated fuzzing and adversarial testing harness finds bugs that conventional unit tests miss—especially those caused by malformed inputs and weird state transitions. + +A competitive prize is appropriate because different teams can optimise for different strengths (coverage vs performance, stateful vs stateless fuzzing, differential testing, minimisation quality), and the ecosystem benefits from adopting the most robust, maintainable approach. + +## Success Criteria +- [ ] Turn-key fuzz runner: A single entrypoint (e.g., `make fuzz` / `cargo fuzz run …`) that runs fuzz targets locally with clear instructions and expected dependencies. `cargo-fuzz` is an accepted approach. +- [ ] Multiple fuzz targets (minimum 4): Provide distinct targets covering, at minimum: + 1. transaction decoding / instruction parsing, + 2. stateless verification checks, + 3. state transition / execution engine, + 4. block verification / replayer logic (or the closest equivalent in the current codebase). +- [ ] Invariant detection: Implement a shared invariant framework that asserts protocol rules (e.g., no invalid transitions accepted, nullifier/commitment uniqueness constraints, authorisation checks, deterministic roots/hashes, etc.) and fails fast with actionable diagnostics. +- [ ] Crash + panic capture with minimisation: Demonstrate automatic minimisation of failing inputs (smallest reproducer) and a workflow to convert findings into regression tests. Property-testing shrinkers (e.g., `proptest`) are acceptable for structured inputs; coverage-guided fuzzers should also be supported. +- [ ] CI integration: Add a CI job that: + - runs fuzzing for a fixed time budget (e.g., short smoke fuzz), + - runs regression reproducer tests from the saved corpus, + - and clearly reports failures. +- [ ] Performance baseline: Document achieved throughput for key targets (e.g., exec/sec for parsing and for execution) and the recommended local settings. + +## Scope + + +### In Scope +- Fuzz targets: TBD. +- Coverage-guided fuzzing harnesses (libFuzzer via cargo-fuzz recommended) and/or complementary property-based adversarial generators for structured inputs. +- Input generators for: + - malformed and boundary-value transactions, + - invalid account/state combinations, + - re-ordered / duplicated inputs, + - pathological sequences intended to violate protocol rules. +- Invariant-checking utilities and differential-testing hooks (where applicable). +- Failure minimisation, reproduction, and regression workflows. + +### Out of Scope +- Manual audits or “one-off” bug reports without reusable infrastructure (those belong in the bug bounty prize). +- Fuzzing unrelated third-party libraries unless required to reach protocol code paths. +- Non-deterministic tests that can’t be reliably reproduced. + +## 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: + - fuzz targets + harnesses, + - seed corpus (and dictionaries if relevant), + - invariant framework + examples of invariants, + - CI integration (smoke fuzz + regression runs), + - documentation: `docs/fuzzing.md` with “how to run”, “how to add a fuzz target”, and “how to minimise + reproduce”. + +## 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) +- [Fuzzing with cargo-fuzz - Rust Fuzz Book](https://rust-fuzz.github.io/book/cargo-fuzz.html) +- [libFuzzer and AFL++ | ClusterFuzz](https://google.github.io/clusterfuzz/setting-up-fuzzing/libfuzzer-and-afl) +- [libFuzzer – a library for coverage-guided fuzz testing](https://llvm.org/docs/LibFuzzer.html)