LP-0019: Tokenized Vault Standard for LEZ

[mart1n-xyz]

Summary

• Adds LP-0019, a tokenized vault standard for LEZ with ERC-4626-equivalent semantics adapted to LEZ's account model.
• Two privacy variants in scope: LVS-P (fully public) and LVS-SD (public pool, private depositor positions).
• Deliverables: standard spec, vault + factory LEZ programs, conformance test suite, SDK, SPEL IDLs, and Basecamp demo app.
• Hard dependencies on RFP-001 (admin authority library) and LP-0013 (mint authority in the LEZ token program).

[github-actions]

✅ Validation passed

A reviewer will assess against the prize criteria.
ℹ️ Prize proposal for LP-0019.

---

Automated check. See solution template and TERMS.

[fryorcraken]

Review: fold this into RFP-012 rather than landing as a standalone LP

First — the spec itself is well-written and the technical decisions (mandatory inflation defense via virtual offset, vault-favoring rounding table, the LVS-SD shielded-depositor variant) are solid. My concern is the vehicle, not the content.

Main concern: LP-0019 is a standard with no consumer in its own scope. As a standalone prize it sits idle until something is built on top of it — and the thing that would consume it, RFP-012 Curated Lending Vaults, isn't done. We'd be paying to define and reference-implement a standard that has no in-scope user, then waiting for a separate prize to actually exercise it.

Recommendation: add the tokenized vault standard to RFP-012's scope instead. RFP-012 already needs exactly this — it issues LEZ-token vault shares with a monotonic share price (its F2) — so folding the standard in means it ships defined, reference-implemented, and used out of the box, as one coherent deliverable. This matches the ERC-4626 precedent: the standard succeeded because it shipped with hungry consumers (Yearn, Morpho), not ahead of them.

Why fold-in beats keep-as-LP-and-sequence:

• No idle period — LP-0019 alone delivers nothing usable until RFP-012 lands.
• No divergence risk — RFP-012 currently re-specifies its own vault-share semantics in prose (F2) and does not depend on LP-0019; two definitions of "vault share" could drift. One scope = one definition.
• One artifact / one audit surface, not two prizes that must be coordinated.

Mechanics: don't merge this as a standalone LP; instead open a PR on logos-co/rfp expanding RFP-012 to include the vault-standard deliverables currently here (spec, conformance suite, share-accounting rules), and have RFP-012's shares conform by construction. The content in this PR is worth preserving — it just belongs inside RFP-012.

Other near-term vault-share consumers exist (Liquid Staking — though it has no live RFP yet — and the broader "Yield & Vaults" roadmap layer), but none rescue a standalone LP from sitting idle, so RFP-012 is the right home.

Secondary nit, only relevant if it stays a standalone LP: the declared dependencies (RFP-001, LP-0013) aren't reflected in the acceptance criteria with an explicit MUST/MAY — RFP-001 in particular is unenforceable as written.