LP-0021, LP-0022: LEZ Wallet and Provider SDK, Combined Blockchain+Zone Wallet

README.md

@@ -31,6 +31,8 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown
 | File | Description | Size | Status |
 |------|-------------|------|--------|
 | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — |
+| [LP-0021](prizes/LP-0021.md) | LEZ Wallet and Provider SDK                               | X-Large | Draft                         |
+| [LP-0022](prizes/LP-0022.md) | Combined Blockchain and Zone Wallet                       | Large  | Draft                         |
 
 ### Legacy prizes (original scheme)
 

prizes/LP-0021.md

@@ -0,0 +1,157 @@
+<!-- Don't forget to add/update this prize in the table in README.md -->
+
+---
+dependencies:
+  - id: LP-0023
+    reason: wallet approval flow requires the program registry to show verified source for called programs
+---
+
+# LP-0021: LEZ Wallet and Provider SDK [DRAFT]
+
+**`Logos Circle: N/A`**
+
+## Overview
+
+This prize is for a Logos wallet module scoped to a single Logos Execution Zone (LEZ): a wallet experience that manages assets on a LEZ zone, including the token program, multiple accounts (public and private), and a developer-facing **Wallet Provider SDK** with wallet selection and approval flows for third-party dApps. This is the first of two wallet prizes: it establishes the LEZ-side wallet, Wallet Provider SDK, and approval UX that a follow-up prize ([LP-0022](LP-0022.md)) will extend to cover the Logos blockchain, staking, bridging, and multi-zone configuration.
+
+## Motivation
+
+Logos Execution Zones (LEZ) are the programmable environment where Logos dApps run, and every zone needs a wallet before it can have users or third-party integrations. Without a shared wallet and Wallet Provider SDK, every dApp on a zone would need to reinvent key management, asset display, and approval UX. Scoping this first prize to a single zone lets a winning team ship a complete, adoption-ready wallet quickly, rather than being blocked on blockchain-level features (staking, bridging, multi-zone config) that are only needed once a base of zone-side users and dApps already exists. The Wallet Provider SDK and approval flow built here become the foundation LP-0022 extends to the blockchain and multi-zone case.
+
+## Success Criteria
+
+### Functionality
+
+- [ ] **LEZ assets**: own, send, and receive native and token-program assets on a LEZ zone, for both private and public accounts.
+- [ ] **Token program**: own and transfer fungible token-program assets on LEZ, from both public and private accounts. Non-fungible (NFT) assets are out of scope — see [Out of Scope](#out-of-scope).
+- [ ] **Multiple accounts (LEZ)**: create and manage multiple accounts on the zone, including both public and private accounts, and switch between them.
+- [ ] **Wallet Provider SDK**: a documented SDK that lets a third-party dApp request account access, read balances/state, and propose transactions against the wallet.
+- [ ] **Wallet selection & approval flow**: when a dApp requests a connection or a transaction, the user is shown a selection prompt (which account to use) and an approval prompt (what is being signed/sent) before anything is signed or submitted.
+- [ ] **Testimonial mini app**: a small reference application, built on the SDK, that lets any user publish a testimonial on the official Logos zone, going through the full connect → account selection → approval → transaction flow. This means **a standard LEZ program that stores each testimonial on-chain**. A testimonial carries custom text, an optional username, and a unique identifier for the given LP submission, so that testimonials can be attributed to the submission that produced them. It serves as the canonical SDK integration example for third-party developers, and is the tool used to produce the on-chain testimonials counted in the adoption criteria below.
+- [ ] **Faucet mini app**: a reference application, built on the SDK, that requests testnet funds from the LEZ faucet, using the SDK to let the user select which account receives them. It must report success/failure and handle faucet rate-limiting gracefully.
+- [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3.
+
+### Usability
+
+- [ ] Provide a module/Wallet Provider SDK usable by other Logos modules and third-party dApps to query balances, request account access, and request transfers and smart contract interactions.
+- [ ] Provide a Logos Basecamp app GUI with local build instructions and loadable assets.
+- [ ] Logos Basecamp modules (core and ui types) are published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`.
+- [ ] Account selection and transaction approval prompts clearly identify the requesting dApp, the target account, and (for transactions) the asset, amount, and destination. **For smart-contract interactions** (including token approvals), the prompt must show a human-readable summary of the call's effects: assets/approvals granted or moved and to which program/account, not just raw calldata, so the user can catch unexpected outflows or unlimited approvals before signing.
+- [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. [LP-0023](LP-0023.md)'s program registry is the recommended source for this.
+- [ ] **UX quality.** The wallet must be polished, functional, and usable by a non-expert: coherent navigation across accounts, comprehensible transaction previews, and clear error/pending states. This is judged against overall impression rather than a checklist: evaluators will use the wallet as a normal user would.
+- [ ] Display estimated gas usage and gas used on transaction; if available on testnet v0.3 (as currently planned).
+
+### Reliability
+
+- [ ] Wallet state (keys, accounts) survives restarts and network drops without corruption.
+- [ ] A dApp cannot sign or submit a transaction, or read a private/shielded account's balance, without an explicit user approval for that account.
+- [ ] **No mandatory external services.** Beyond the user's configured sequencer and Logos LEZ node, the wallet must not depend on any third-party web service to function. If one is used (e.g. a price API), then: it is disclosed to the user, the user can disable it, and the wallet remains fully functional with it disabled, with no degraded key management, balances, or transaction flows. This includes analytics servers: if any analytics are collected, they must be strictly opt-in. The wallet must never transmit addresses, balances, or transaction contents to a third party without explicit opt-in.
+- [ ] **Remote storage uses Logos Storage.** If remote data persistence is needed for reliability (e.g. backup or cross-device recovery of wallet configuration), it must use **Logos Storage**, not a centralised provider. Any data leaving the device must be encrypted client-side.
+
+### Performance
+
+- [ ] The wallet feel and responsiveness needs to provide an adequate UX. We understand this is subjective criteria (see [Adoption](#adoption)).
+
+### Supportability
+
+- [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone).
+- [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`) and can be installed on both Linux and MacOS desktop platforms.
+- [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch.
+- [ ] README documents setup, account management, and step-by-step usage via CLI and Basecamp app.
+- [ ] Wallet Provider SDK documentation covers the reference mini apps (testimonial and faucet) as worked examples of connect → account selection → approval → transaction.
+
+### Adoption
+
+> These metrics measure traction attributable to a given submission for this prize.
+>
+> **All of the following are required in addition to the FURPS criteria above.** We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Evaluators will inspect commit histories and the posting history of vouching accounts. Volume that is clearly manufactured (fresh accounts, purchased engagement) does not count, regardless of the headline number.
+
+- [ ] **10 third-party developers** have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the Wallet Provider SDK. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. The 10 developers must be independent of each other and of the submitting team.
+- [ ] **150 on-chain testimonials**, submitted by users through the testimonial mini app on the official Logos zone, each reading `I use wallet XYZ` or other custom text that clearly identifies this submission's wallet rather than a competing challenger's. They must come from **at least 150 distinct accounts**, and accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint for testnet 0.3 will be confirmed when this prize opens.
+- [ ] **Sustained testimonial activity**: the 150 testimonials must be spread over **at least 2 months**, with **at least 30 new testimonials in each of those months**. A single burst of activity does not qualify, however large. Each testimonial carries the submission's unique identifier and is timestamped on-chain, so this is verified directly from chain data.
+- [ ] **30 testimonials on Discord** vouching for the wallet. Testimonials should describe what the person actually used the wallet for; account history will be checked.
+- [ ] **30 testimonials on Twitter/X** vouching for the wallet, subject to the same standard and the same account-history check. Sharing screenshots of the wallet in use is encouraged.
+
+> A follow-up λPrize ([LP-0022](LP-0022.md)) extends this wallet to the Logos blockchain, staking, bridging, and multi-zone configuration, with its own incremental adoption tranche.
+
+## Scope
+
+### In Scope
+
+- Wallet module (key management, multi-account, asset display, transfers) for a single LEZ zone, including public and private accounts.
+- Token program support on LEZ.
+- Wallet Provider SDK with account-access, state-read, and transaction-proposal APIs.
+- Wallet-selection and transaction-approval UX flow for third-party dApp requests.
+- Reference SDK mini apps: a testimonial app that publishes testimonials on the official Logos zone, and a faucet app that requests testnet funds on that zone with SDK-driven account selection.
+- CLI and Basecamp app GUI.
+
+### Out of Scope
+
+- The Logos blockchain wallet, staking, bridging, and multi-zone/sequencer configuration — covered by [LP-0022](LP-0022.md).
+- Designing or implementing the token program itself — the wallet integrates with the existing/reference implementation.
+- **Non-fungible (NFT) assets.** The token program covers both fungible and non-fungible assets, but this prize requires fungible token support only; NFT support (owning, transferring, or displaying NFTs) is optional.
+- Hardware wallet integration.
+- Portfolio analytics, price feeds, or fiat on/off-ramps.
+- A dApp discovery/marketplace layer beyond the SDK example apps.
+
+## Prize Structure
+
+- **Total Prize:** $20,000
+- **Effort:** X-Large
+
+## 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 with the wallet module, Wallet Provider SDK, CLI, reference mini apps (testimonial and faucet), and Basecamp app GUI under MIT or Apache-2.0.
+- Narrated video walkthrough demonstrating: key/multi-account setup (including a private LEZ account), funding accounts via the faucet mini app, sending/receiving on the LEZ zone, token program usage, and the testimonial mini app performing connect → account selection → approval → testimonial creation via the SDK. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).)
+- Evidence for each adoption criterion: links to the 10 third-party SDK apps and their repositories, the wallet repository, the on-chain testimonials (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials.
+- FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)).
+
+## Evaluation Process
+
+Submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins.
+
+Because the adoption criteria require sustained activity over at least two months, a submission cannot qualify until that window has elapsed. Builders are encouraged to ship early and start accruing adoption while continuing to develop, rather than treating the build and the adoption push as sequential.
+
+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](../README.md#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
+
+- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
+- [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) — includes the token program
+- [LP-0013](LP-0013.md) — Token program improvements (authorities)
+- [LP-0014](LP-0014.md) — Token program improvements (ATAs + wallet tooling)
+- [LP-0022](LP-0022.md) — Combined blockchain + zone wallet (follow-up)
+- [LP-0023](LP-0023.md) — Program registry with verified builds for LEZ programs (bytecode-to-source). Recommended as the source-verification registry backing the approval-flow requirement above.
+
+## Potential for Subsequent λ Prizes
+
+This prize covers the **first adoption tranche** for the LEZ-only wallet. [LP-0022](LP-0022.md) extends the wallet to the Logos blockchain and multi-zone use, with its own adoption tranche. A further follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time.
+
+This prize also targets Logos testnet 0.3. Should a future testnet version (e.g., V0.4) introduce breaking changes to the token program, a subsequent λ Prize may be opened to cover adaptation.
+
+---
+
+**Note:** The Specification in this Prize describes an outcome that Logos intends to benefit the Logos ecosystem. It sets out criteria and certain requirements a Participant should fulfill in order to potentially be eligible to be awarded a Prize amount, and is not intended to be an instruction or to direct a Participant's initiative or approach. They are guided by existing approaches and implementations in other mature blockchain systems and their ecosystems, as well as by functional requirements particular to the Logos technology stack or perceived usefulness to such stack or the wider community building on it.
+
+Logos makes no representation as to the legal or regulatory treatment of this Specification or any implementation of it in any jurisdiction.
+
+Participants act independently, voluntarily and at their own initiative in connection with their Submissions and are solely responsible for:
+
+1. assessing the risks and implications of their Participation in the Program and of any Artefacts that form part of their Submission;
+2. determining whether to obtain independent professional advice;
+3. complying with all applicable laws to them and in connection with the Program, including, where relevant, any licensing, registration, sanctions or anti-money laundering obligations that may arise from operating any software-as-a-service or business.
+
+Artefacts developed by Participants in connection with the Program are published and maintained by Participants and not by Logos or its Affiliates. Logos and its Affiliates do not build, host, maintain, deploy, operate, use or control any Artefacts arising out of any Submission.
+
+Participants or other persons who choose to build upon, host, maintain, deploy, operate, use or publicly promote any Artefacts, do so at their own risk and as a principal and in their own name. Any such persons are further solely responsible for complying with any legal or regulatory requirements that apply to them with such use. Logos does not make any representation, provide any advice or assume any responsibility regarding the use of such Artefacts, or any determination of compliance with applicable law or regulation.
+
+For further details of the above and what terms and conditions apply to a Participant, please refer to the [λPrize Program – Terms & Conditions](../TERMS.md).