[PROPOSAL] RFP-0016 — Privacy-Preserving Token Launchpad: LBP

[syafiqeil]

RFP ID

RFP-016

---

Your Project Name

NullPad

---

Team or Organization Name

Evice Labs

---

Primary Contact

Discord: @bristinborah.sol, @syafiqeil, @mmlado

---

Team Members

Member 1

• Name: Syafiq Nabil Assirhindi
• Social links: https://www.linkedin.com/in/syafiq-nabil-assirhindi/ | https://github.com/syafiqeil
• Role: On-chain LBP program (SPEL), ZK allowlist circuits (RISC Zero), Rust SDK with C-ABI FFI, and integration test suite.
• LEZ Track Record: Delivered LP-0016 — Anonymous Forum with Threshold Moderation (awarded to a different participant, now continues as an independent personal project): a full-stack privacy-preserving protocol spanning SPEL on-chain programs, RISC Zero ZK circuits, a forum-agnostic Rust SDK with C-ABI FFI, and native Logos Basecamp module integration.
• Status: Independent Developer Team.

Member 2

• Name: Bristin Borah
• Social links: https://www.linkedin.com/in/bristin-borah-739b63179/ | https://github.com/bristinWild
• Role: LEZ event integration, token program interactions (mint authority, ATA), CLI, analytics backend, and testnet/mainnet deployment pipeline.
• LEZ Track Record: Delivered LP-0012 — Structured Event System for LEZ Programs (Winner, Merged). Delivered LP-0013 — Token Program Improvements: Authorities (Winner, Merged as lez-programs#213). SPEL framework contributor (spel#212, #[require_admin] macro).
• Status: Independent Developer Team.

Member 3

• Name: Mladen Milankovic
• Social links: https://www.linkedin.com/in/mladenmilankovic/ | https://github.com/mmlado
• Role: Basecamp mini-app development: core module (universal interface, C++ backend) and QML UI module (participant and creator views), including sale analytics frontend.
• LEZ Track Record: RFP-001 — Admin Authority Library (Accepted, Final Milestone). RFP-002 — Freeze Authority Library (Accepted, Final Milestone). SPEL extension-architecture contributor. SPEL framework contributor (spel#233, #Generic Extension Scanner).
• Status: Independent Developer Team.

Team Commitment: NullPad is Evice Labs sole active proposal, our capacity across this 18-week window is allocated to this delivery, not split across parallel RFP submissions.

---

Project Summary

Token launches are the entry point for new projects into any blockchain ecosystem. On transparent chains, every participant in a token sale is immediately linkable to a wallet address and, by extension, to the buyer's full on-chain history. Early investors can be identified, profiled, or front-run at unlock — a structural privacy failure that no existing launchpad platform (Fjord Foundry, DAO Maker, Polkastarter) addresses.

NullPad builds a Liquidity Bootstrapping Pool (LBP) launchpad natively on LEZ, combining Balancer-style weight-shifting price discovery with the optional deshield→buy→re-shield privacy pattern. The LBP mechanism starts price above estimated fair value and lets it decline over time unless buying pressure counteracts it — naturally deterring bot sniping and removing the need for teams to pre-set a valuation. When buyers interact from a private account, their identity, total position, and token destination are completely unlinked from the on-chain sale, with each purchase routed through a fresh ephemeral account. An optional ZK allowlist gate enables projects to restrict participation without exposing the eligibility set on-chain, preserving the zone-wide anonymity set regardless of list size.

Our team brings direct, proven experience with the exact LEZ primitives this RFP requires: LP-0016 delivered Merkle-tree ZK membership proofs and privacy-preserving protocol design on RISC Zero; LP-0012 delivered the structured event system that the RFP depends on for analytics; and LP-0013 delivered the token authority model required for mint and custody operations.

---

Evidence at a Glance

Every credential below is public and independently verifiable, click through before reading the technical approach.

Contributor	Delivery	Status	NullPad (RFP-016) Relevance
Bristin Borah	LP-0012 — Structured Event System	Winner, merged upstream into LEZ	Powers the sale analytics view (U8) — reuses emit_event() / EventRecord for buy, weight-update, and lifecycle events
Bristin Borah	LP-0013 — Token Program Authorities	Winner, merged (lez-programs#213)	Powers collateral/token custody (F5, F9) via the same PDA-authority pattern and mint-authority tooling used for the protocol-fee transfer
Mladen Milankovic	RFP-001 — Admin Authority Library	Delivered, M3 submitted — awaiting final acceptance	Underpins the LBP sale creator authority model and program-level admin controls
Mladen Milankovic	RFP-002 — Freeze Authority Library	Delivered, M3 submitted — awaiting final acceptance	Directly implements the pause/resume mechanism (F6)
Mladen Milankovic	SPEL Generic Extension Scanner	In review	Framework-level plumbing that lets RFP-001/002's authority extensions plug into any consuming program — including NullPad's LBP program
Syafiq Nabil Assirhindi	SPEL → LEZ v0.2.4 migration	Merged, 39/39 tests passing	De-risks NullPad's core dependency: correct VPK-aware private PDA derivation and the async WalletCore API are exactly what the LBP program's PDA-derived sale accounts and ephemeral private-account flow require on current LEZ

---

Technical Approach

The LBP program will be built in Rust using the SPEL framework, compiled to RISC-V and executed inside the RISC Zero ZKVM on the Logos Execution Zone.

• LBP Pricing Engine (Balancer Weighted Pool Math): Implementing the weight-shifting AMM derived from the Balancer weighted pool formula. Pool weights are linearly interpolated between start and end values over the sale duration using the on-chain block timestamp. The buy formula computes token output as: tokens_out = reserve_token × (1 - (reserve_collateral / (reserve_collateral + C_in)) ^ (w_collateral / w_token)). All arithmetic uses fixed-point integer operations (no floating point in ZKVM) — the power function x^(a/b) is implemented via a Rust fixed-point math library using natural logarithm and exponentiation approximations with sufficient precision for weight ratios between 1/99 and 99/1. Weight computation is lazy: the program evaluates weights from the block timestamp at each transaction, ensuring correct pricing without depending on external poke calls.

• Sale Lifecycle & Pool State: Each sale is a PDA-derived account storing: token pair, start/end weights, start/end timestamps, reserves, cumulative collateral raised, per-block token ceiling (optional), allowlist root (optional), pause flag, creator authority, and protocol fee configuration. The creator deposits project tokens at sale creation. After the end timestamp, the creator can withdraw collateral (net of protocol fee, deducted atomically) and unsold tokens. Pausing halts buys but does not affect weight progression — the weight schedule continues during a pause.

• ZK Allowlist Gate: When enabled, the creator commits a Merkle root of the eligible participant set at sale creation. Buyers prove inclusion via a RISC Zero ZK circuit that verifies Merkle path membership without revealing the full set on-chain. This directly reuses the ZK set membership architecture from LP-0016 (Anonymous Forum), where the same pattern (Merkle tree commitment + ZK inclusion proof) was used for anonymous membership verification. On LEZ, the effective anonymity set is all private accounts in the zone, not the allowlist size — the allowlist gate does not degrade privacy. This fully satisfies F7: Merkle root commitment, RISC Zero ZK inclusion proof, and zone-wide anonymity set preservation are delivered as core scope in M3 — not a partial, deferred, or bolt-on implementation.

• Atomic Privacy Pattern (SDK Level): The SDK orchestrates the deshield→buy→re-shield flow as a single, indivisible operation, following the interaction model defined in RFP-008. The atomic deshield transfers both collateral and gas to a freshly generated ephemeral account; the buy executes against the LBP pool; the purchased tokens are re-shielded to the buyer's validated private account. If any step fails, the entire transaction reverts. The SDK enforces that the re-shield target is a private (shielded) account and hard-blocks any transaction where the shielded balance cannot cover both collateral and gas.

• Event Integration & Analytics: Sale events (buy executed, weights updated, sale created, sale closed) are emitted using the structured event system delivered in LP-0012 (emit_event() with Borsh-encoded EventRecord). The analytics backend consumes events via the getTransactionReceipt RPC to provide aggregate sale metrics (total raised, price over time, buy count) without exposing individual participant identities.

• Token Program Integration: The LBP program interacts with the LEZ Token Program for all token custody operations (transfer collateral in, transfer project tokens out, deposit/withdraw). Token definitions with mint authority (LP-0013) enable the protocol fee transfer to the treasury account. ATA derivation per (owner, mint) is used for all user-facing token accounts; the program also accepts any valid SPL token account owned by the caller.

• Logos Basecamp Mini-App: The mini-app follows the current Logos module architecture (tutorial-v3):

  • A core module (type: core, interface: universal) built with mkLogosModule, wrapping the NullPad Rust SDK via C-ABI FFI. All sale lifecycle methods are exposed as public methods on the impl class, auto-generated by logos-cpp-generator.
  • A UI module (type: ui_qml with C++ backend) built with mkLogosQmlModule. Two views: Participant view (browse active sales with live price curve, weight visualization, time remaining; execute buy with pre-confirmation summary) and Creator view (create sale with all parameters including allowlist, monitor active sale, pause/resume, close, withdraw). Privacy disclosure rendered before each buy from a private account.
  • Both modules distributed as .lgx packages, installable via lgpm.

---

RFP-016 Hard Requirements Coverage

Functionality

#	Requirement	Milestone	Notes
F1	LBP program: weight-shifting AMM with Balancer weighted pool formula	M2	Fixed-point integer math; lazy weight computation from block timestamp
F2	Sale creation with all configurable parameters (token pair, weights, timestamps, deposit, per-block cap, allowlist)	M2	PDA-derived sale accounts; all parameters immutable after creation
F3	Buy from public account or via deshield→buy→re-shield for private accounts	M3	Atomic privacy pattern enforced at SDK level
F4	Permissionless weight poke; correct weight at transaction time regardless of last poke	M2	Lazy computation — weights evaluated from block timestamp at each tx
F5	Creator withdraw: collateral net of protocol fee + unsold tokens after end timestamp	M2	Fee deducted atomically in withdrawal transaction
F6	Pause/resume buying; weight schedule continues during pause	M2	Pause flag checked on buy; weight interpolation ignores pause state
F7	Optional ZK allowlist gate (Merkle root commitment + ZK inclusion proof)	M3	RISC Zero ZK circuit; reuses LP-0016 Merkle membership proof architecture
F8	Slippage protection: minimum token output, revert if exceeded	M2	Enforced at program level before state mutation
F9	ATA compatibility per LP-0014; accept any valid SPL token account	M2	ATAs accepted but never forced; sale vaults use PDAs

Usability

#	Requirement	Milestone	Notes
U1	SDK: full lifecycle for participants and creators; atomic deshield (collateral + gas)	M3	Both public and private account paths supported
U2	Logos mini-app GUI: participant view + creator view	M4	Core module (universal interface) + UI module (ui_qml with C++ backend), .lgx packages
U3	CLI: core functionality for participants and creators	M4	Pool creation, buy, pause/resume, close, withdraw, query price/status
U4	Pre-buy confirmation: current price, estimated tokens, price impact, collateral spent	M4	Rendered in mini-app before user confirms
U5	Privacy disclosure before each private-account buy	M4	Split-view: what is public vs private on-chain
U6	Atomic deshield enforcement (no external funding of ephemeral account)	M3	Hard-blocked at SDK level
U7	Shielded balance validation (collateral + gas) before deshield	M3, M4	SDK validates; mini-app shows actionable error if insufficient
U8	Sale analytics view (collateral raised, price chart, buy count, pool composition)	M4	Aggregate-only; consumes LP-0012 structured events via RPC
U9	IDL via SPEL framework	M2	Generated alongside program deployment
U10	Actionable error messages (insufficient balance, sale not started, ended, allowlist rejected, slippage exceeded)	M3, M4	SDK surfaces typed errors; mini-app renders human-readable messages

Reliability

#	Requirement	Milestone	Notes
R1	Consistent pool state under concurrent buys; no double-spend	M2	Invariant checks enforced on every state transition
R2	Failed buy reverts atomically: no collateral consumed, no state change	M2	All checks performed before any state mutation
R3	Weight pokes are idempotent: multiple pokes per block do not corrupt state	M2	Lazy computation from timestamp; stored weights are a cache, not source of truth

Performance

#	Requirement	Milestone	Notes
P1	Single-tx buy	M2	Confirmed — single atomic instruction
P2	Single-tx weight poke	M2	Confirmed — single atomic instruction
P3	CU cost documented per operation; LEZ testnet version noted	M2	Covers: create, buy, poke, pause/resume, close, withdraw

Supportability

#	Requirement	Milestone	Notes
S1	Deployed and tested on LEZ testnet 0.2	M4	Initial on-chain deployment
S2	E2E integration tests against LEZ sequencer standalone mode; CI green	M4	Happy-path buy, slippage revert, allowlist accept/reject, sale close, weight poke schedule
S3	Every hard requirement has at least one corresponding test	M4	Full coverage mapped to requirements
S4	README with deployment steps, program addresses, step-by-step usage	M5	Covers both creator and participant journeys via CLI and mini-app
S5	Privacy and anonymisation properties document	M3	Covers: visible on-chain data, private data, trust assumptions, bypass scenarios
S6	Program updated and verified on LEZ testnet 0.3	M6	Re-deployment + re-verification
S7	Program deployed to LEZ mainnet	M7	Production deployment

Privacy

#	Requirement	Milestone	Notes
PV1	SDK and mini-app support both public and deshield→buy→re-shield paths	M3, M4	Both paths fully supported
PV2	Re-shield step not skippable from private account	M3	Hard-enforced at SDK level
PV3	Pre-confirmation privacy summary before each private buy	M4	Split-view rendered in mini-app
PV4	SDK validates re-shield target is a private account	M3	Rejects with explicit error if not
PV5	Ephemeral account never reused across operations	M3	Fresh account per operation; reuse architecturally impossible

Soft Requirements

#	Requirement	Milestone	Notes
Soft1	Fixed-price sale mode (no weight shift; constant price)	M2	Implemented as degenerate case: start weight = end weight

Out of Scope — Acknowledged

Item	Reason
Per-wallet buy limits	Fundamentally incompatible with private account path (RFP explicitly acknowledges this)
Fully private pool state	Open research problem; public pool state is required for LBP price discovery
Smart contract audit	Outside RFP-016 scope by design, not by omission — every M2–M4 deliverable is engineered audit-ready (full invariant test coverage, Rustdoc across the SDK, CI-gated E2E suite per S2/S3). We can scope a dedicated audit engagement with Logos as a follow-up, with coordination already accounted for on our side.

---

Milestones, Payout and Timeline

Milestone	Payout	Duration	Owner	Deliverables
M1 — Design and Specification	$10,000	2 weeks	All	System architecture document; Balancer weighted math specification with fixed-point precision analysis; ZK allowlist circuit design; Sale lifecycle state machine; Mini-app UX wireframes (Figma); Privacy and anonymisation properties draft
M2 — Core LBP Program	$22,000	4 weeks	Syafiq (program), Bristin (token integration), Mladen (module scaffolding)	LBP program deployed on devnet: weighted pool math, sale creation, buy, weight poke, pause/resume, close/withdraw, protocol fee, per-block cap, slippage protection; SPEL IDL; CU usage report per operation
M3 — ZK Allowlist, Privacy SDK & Docs	$22,000	4 weeks	Syafiq (ZK circuits, SDK), Bristin (event integration, CLI foundation), Mladen (mini-app core module)	ZK allowlist gate (RISC Zero Merkle membership circuit); deshield→buy→re-shield atomic pattern; Fully functional SDK with pre-buy simulation; SDK API documentation; Privacy and anonymisation properties document (final); Developer integration doc packet
M4 — Client Interfaces, Analytics & Testnet 0.2	$22,000	4 weeks	Mladen (mini-app UI), Bristin (CLI, analytics, deployment), Syafiq (E2E tests)	Basecamp mini-app: core module (universal interface) + UI module (ui_qml with C++ backend), .lgx packages; CLI with CLI doc packet; Sale analytics view (LP-0012 event consumption); Figma mockups; E2E test suite; CI green; LEZ testnet 0.2 deployment
M5 — Documentation & Finalization	$8,000	2 weeks	All	Final README with deployment steps and program addresses; Setup guides for creators and participants; Code formatting/linting
M6 — Testnet 0.3 Verification	$8,000	1 week	Bristin	Program updated and verified on LEZ testnet 0.3; Regression test pass; Migration notes if API changes
M7 — Mainnet Deployment	$8,000	1 week	Bristin	Production deployment to LEZ mainnet; Deployment verification; Final program addresses documented
Total	$100,000	18 weeks

On the 18-week total: M1–M5 — full design-through-testnet-0.2 delivery — total 16 weeks, at the upper bound of the requested 14–16 week window. The remaining 2 weeks (M6, M7) are appended verification and mainnet-deployment milestones gated by LEZ's own testnet 0.3 and mainnet release cadence, not by our delivery capacity. M6 and M7 timelines depend on LEZ testnet 0.3 and mainnet readiness respectively. If platform releases are delayed, these milestones will be delivered promptly after the corresponding network becomes available, without affecting the preceding milestone schedule.

---

Total Requested Budget (USD)

$100,000

---

Why $100,000

Three factors keep this budget efficient relative to scope, and two extend it beyond what a narrower bid would need to cover:

• Zero R&D risk on the critical path. The event system (analytics, U8), token custody model (F5, F9), ZK Merkle allowlist architecture (F7), and pause/resume authority model (F6) are not being designed from scratch — they are direct extensions of code our team has already built and had merged into LEZ (see Evidence at a Glance). This budget covers integration and hardening of proven components, not discovery.

• A real ZK allowlist, not an optional bolt-on. F7 is implemented as a first-class RISC Zero circuit reusing a Merkle-membership design already built and tested, priced into M3 as core scope — not deferred, stubbed, or treated as a stretch goal.

• Full commitment through mainnet. M6 (testnet 0.3 re-verification) and M7 (mainnet deployment) are dedicated, budgeted milestones — not an implicit "we'll figure it out after the RFP closes." Their timing depends only on LEZ's own testnet/mainnet release cadence, not on our willingness to see the work through.

• Minimal integration risk. The three hardest external dependencies this RFP requires — token authorities, admin authority, and freeze authority — are deliveries our own team members authored. There is no handoff, no waiting on a third party's API to stabilize, and no risk of building against documentation that turns out to be wrong.

This is a full-lifecycle bid, design through mainnet, priced against work we have substantially already proven we can deliver.

---

Relevant Experience

Syafiq Nabil Assirhindi — hands-on experience building privacy-preserving cryptographic systems natively on the Logos Execution Zone. Built a full-stack submission for the LP-0016 Lambda Prize (awarded to a different participant), demonstrating end-to-end capability across the full Logos stack.

• LP-0016 — Anonymous Forum with Threshold Moderation (Logos):

  • On-chain programs + SDK: https://github.com/syafiqeil/logos-anonymous-forum
  • Basecamp Core Module: https://github.com/syafiqeil/anonymous_forum_core
  • Basecamp UI Module: https://github.com/syafiqeil/anonymous_forum_ui
  • Delivered a complete privacy-preserving forum protocol:
    • SPEL framework guest program with 4 instructions and per-instance PDA accounts
    • Forum-agnostic Rust SDK compiled as both WASM and C-ABI shared library (cbindgen) — directly applicable to the headless core module architecture required by RFP-016 Basecamp mini-app
    • Native Logos Basecamp integration: core module + QML UI module
    • Full deshield→interact→re-shield privacy pattern — directly reusable for NullPad's deshield→buy→re-shield SDK path

• SPEL → LEZ v0.2.4 Migration (spel#256):

  • PR: feat: migrate SPEL to LEZ v0.2.4 - WalletCore async API + ViewingPublicKey PDA derivation spel#256
  • Migrated the entire SPEL ecosystem across the breaking API surface introduced by LEZ's multi-sequencer architecture and ML-KEM-768 ViewingPublicKey integration in private PDA derivation:
    • Async WalletCore::from_env() migration and replacement of direct sequencer_client field access with helm_owned() / poller_helm() / get_account_public() abstractions
    • Added ViewingPublicKey-aware private PDA derivation (compute_private_pda(), new vpk macro attribute for #[spel_program], CLI --vpk flag) — the exact derivation path NullPad's PDA-derived sale accounts and ephemeral private-account flow depend on
    • All 39 fixture-program tests updated and passing against LEZ v0.2.4, zero workspace errors
    • Directly de-risks NullPad's core on-chain dependency — the LBP program's sale accounts and the SDK's deshield→buy→re-shield flow are built against this exact wallet/PDA API surface

• ZK-AppChain: https://github.com/evice-labs/e-zkappchain
  A sovereign ZK rollup integrating an intent-centric execution engine with a CLOB matching engine (Velocity-DEX) and MEV protection infrastructure (Rust-MEV-Builder). Architecture: ZK prover (Winterfell AIR), sequencer node, settlement engine (Alloy-rs), and user client — demonstrating full-stack blockchain and DeFi engineering from L1 settlement to ZK proof generation.

Bristin Borah — hands-on experience building core LEZ infrastructure primitives. Winner of LP-0012 and LP-0013, covering the exact event system and token authority model that this RFP depends on. SPEL framework contributor.

• LP-0012 — Structured Event System for LEZ Programs (Winner, Merged):

  • Repo: https://github.com/bristinWild/logos-execution-zone
  • PR: Solution: LP-0012 — Structured event system for LEZ programs lambda-prize#14
  • Delivered the complete event system now used by all LEZ programs:
    • Guest SDK (emit_event(), EventRecord, Borsh-encoded payloads) in the lez-events crate
    • Event persistence on both success and failure paths (via FAILURE_SENTINEL pattern)
    • getTransactionReceipt RPC method for event retrieval
    • 167 tests passing across all crates; merged into upstream LEZ
    • Direct dependency of RFP-016 — the sale analytics view (Usability *8) consumes exactly this event system for buy, weight-update, and sale-lifecycle events

• LP-0013 — Token Program Improvements: Authorities (Winner, Merged as lez-programs#213):

  • Repo: https://github.com/bristinWild/logos-execution-zone
  • PR: Solution: LP-0013 — Token Program Improvements: Authorities lambda-prize#56
  • Demo: https://www.youtube.com/watch?v=fJWbhobNIFM
  • Delivered mint authority model for the LEZ Token Program:
    • AuthoritySlot — reusable authority primitive in standalone lez-authority crate
    • Self/external authority-variant instruction shape (Mint/MintWithAuthority, SetAuthority/SetAuthorityWithAuthority)
    • Deep experience with LEZ executor constraints: InconsistentAccountPreState on mid-transaction PDA state changes, duplicate-account-id rejection, authorization scope mismatches
    • Direct dependency of RFP-016 — the LBP program custodies collateral and project tokens via the exact PDA-authority pattern PR #213 established, and uses its mint-authority tooling for the protocol-fee transfer to the treasury account

• SPEL Framework — #[require_admin] macro contribution spel#212:
  Active participation in the extension-architecture direction in builder-hub.

Mladen Milankovic — 19 years of professional software development experience, with recent focus on Logos ecosystem infrastructure and cryptographic protocol engineering.

• RFP-001 — Admin Authority Library (Accepted, Final Milestone):

  • Repo: https://github.com/mmlado/spel-admin-authority
  • Docs: admin-authority guide
  • Standardised admin authority library for LEZ programs. Implements authority assignment (admin_initialize), transfer (admin_transfer), and revocation (admin_renounce) as first-class SPEL annotations (#[admin_authority], #[require_admin]). Directly applicable to the LBP sale creator authority model and program-level admin controls. As the author, Mladen ensures zero-friction integration. End-to-end tested against LEZ v0.2.0.

• RFP-002 — Freeze Authority Library (Accepted, Final Milestone):

  • Repo: https://github.com/mmlado/spel-freeze-authority
  • Docs: freeze-authority guide
  • Emergency circuit breaker library for LEZ programs: program-wide freeze, per-account freeze, and a replaceable freeze authority appointed by the admin. Directly applicable to the LBP sale pause/resume mechanism (Functionality requirement F6). End-to-end tested against LEZ v0.2.0.

• SPEL Framework — Generic Extension Scanner (in review):

  • Docs: Build a SPEL Extension Library
  • Framework-side enabling change for the SPEL extension architecture: a metadata-driven discovery mechanism ([package.metadata.spel]) that lets path-dep extension libraries ship #[instruction] fns auto-discovered by the framework and merged into a consuming program's dispatcher + IDL. The framework carries zero hardcoded knowledge of any specific extension — RFP-001's admin-authority is the first consumer, RFP-002's freeze-authority the second, and any future extension plugs in by declaring the same metadata with no further framework changes required. This decouples extension libraries from the framework's release cadence.

• LP-0009 — Keycard NIP-46 Nostr Signer Proxy (Logos Ecosystem):

  • Repo: https://github.com/mmlado/nip46-keycard
    • NIP-44 v2 encryption implemented from scratch with full spec vector test coverage
    • Demonstrates cryptographic protocol engineering and daemon architecture

• LP-0010 — Shell dApp Integration Proof of Concept (Logos Ecosystem):

  • Repo: https://github.com/mmlado/shell_dapp_prototype
  • Live demo: https://shelldappprototype.vercel.app/
    • Full ERC-4527 / Uniform Resources protocol implementation; 56 unit tests
    • Demonstrates frontend development and UI/UX design for the NullPad mini-app (participant and creator views)

(Note: LP-0009 and LP-0010 are contributions to the broader Logos ecosystem. RFP-001, RFP-002, and the SPEL extension scanner represent Mladen's current active development on LEZ-native infrastructure.)

---

Post-Delivery Plan

Post-delivery, Evice Labs will maintain the repository asynchronously. This includes monitoring the open-source codebase, reviewing community Pull Requests, patching potential bugs, and ensuring ongoing compatibility with future updates to the Logos Basecamp and LEZ environment.

Engineering Standards & Continuity: NullPad enforces strict engineering standards: comprehensive test coverage for all program invariants, thorough Rustdoc documentation for the SDK, and automated CI/CD pipelines for E2E integration tests against the standalone LEZ sequencer. The three-person team structure ensures knowledge is shared across all components from day one — no single point of failure in the on-chain program, client interfaces, or deployment pipeline.

---

Permissions and Consent

• I confirm Logos may contact me using the primary contact information provided above for follow-ups and next steps.
• I consent to Logos using information from this proposal publicly such as blogs case studies social posts or analytical reporting. Redactions can be requested at any time.

Program Requirements

• We understand this project must be open-sourced under the MIT and Apache 2.0 Licenses unless explicitly approved otherwise.
• We are prepared to deliver milestone-based outcomes.

[syafiqeil]

Updated NullPad's LEZ Track Record / Relevant Experience: LP-0013 and RFP-001/002 now reflect their current status (merged / final milestone), and LP-0016 is correctly framed as originally submitted to the Lambda Prize (awarded to a different participant), now continued as an independent project.

[syafiqeil]

Update: NullPad (RFP-016) proposal revised

We've updated our submission based on team review. Summary of changes:

• Added an Evidence at a Glance table right after the Project Summary, consolidating every verifiable delivery (LP-0012, LP-0013, RFP-001, RFP-002, spel#257, spel#256) with direct links.
• Added an explicit Team Commitment statement after Team Members.
• Strengthened the audit note in Out of Scope.
• Added an explicit line under the ZK Allowlist Gate section confirming it fully satisfies F7 as core M3 scope.
• Clarified RFP-001/002 status to reflect their current state accurately (delivered, M3 submitted, awaiting final acceptance).
• Added a "Why $100,000" section addressing budget efficiency, integration risk, and full-lifecycle commitment through mainnet directly.
• Added a note under the Milestones table explaining the 18-week total: M1–M5 (full delivery through testnet 0.2) lands at 16 weeks, the upper bound of the requested window, with M6/M7 appended and gated by LEZ's own testnet 0.3/mainnet release cadence, not our delivery capacity.

Happy to answer any questions on the updated sections.