One of five LEZ deliverables split out from #214 ("Review API reference and
requirements for Blockchain and LEZ integration"). No draft PR yet.
Scope
The wallet counterpart to the LEZ node API: key handling, derivation, proving,
and signing. It covers the local and wallet operations only. The library that
exposes it is packaged in the lez_core module, which an integrator can run
with every wallet function disabled. It is exposed over the Logos Core FFI on
that module, and through the lez_wallet_ffi crate so it can be wrapped for
other languages by the LEZ-DK (#238), in the shape of bdk-ffi. Internal
deliverable.
Also owns transaction simulation, which the node cannot provide: on LEZ a
privacy-preserving transaction is executed by the wallet over notes only it can
decrypt, so simulation belongs on the side that holds the keys. Siting it on
the node would split one capability across two components and answer against
finalised state rather than the state the caller is building on. See the
discussion in logos-co/rfp#200.
Note the division of work with the node: the wallet produces a signed
transaction and, for a privacy-preserving one, the new commitments that come
with it, but it does not reach the chain itself. Those go to the network
through the LEZ node API. Following BDK, the wallet holds no client and
performs no network I/O.
Source material
appendix/wallet-libraries-ecosystem.md (in logos-co/rfp) — where wallet
functionality lives per chain, key derivation standards, watch-only support,
and hardware and offline signing. Written explicitly as input for this RFP.appendix/logos-api-surfaces.md — as-built inventory of the LEZ wallet FFI
and lez_core module.
Dependencies
None — this is a root surface alongside the LEZ node API. The JSON-RPC proxy
and its client library (#237), and the LEZ-DK (#238), consume it.
Related
One of five LEZ deliverables split out from #214 ("Review API reference and
requirements for Blockchain and LEZ integration"). No draft PR yet.
Scope
The wallet counterpart to the LEZ node API: key handling, derivation, proving,
and signing. It covers the local and wallet operations only. The library that
exposes it is packaged in the
lez_coremodule, which an integrator can runwith every wallet function disabled. It is exposed over the Logos Core FFI on
that module, and through the
lez_wallet_fficrate so it can be wrapped forother languages by the LEZ-DK (#238), in the shape of
bdk-ffi. Internaldeliverable.
Also owns transaction simulation, which the node cannot provide: on LEZ a
privacy-preserving transaction is executed by the wallet over notes only it can
decrypt, so simulation belongs on the side that holds the keys. Siting it on
the node would split one capability across two components and answer against
finalised state rather than the state the caller is building on. See the
discussion in logos-co/rfp#200.
Note the division of work with the node: the wallet produces a signed
transaction and, for a privacy-preserving one, the new commitments that come
with it, but it does not reach the chain itself. Those go to the network
through the LEZ node API. Following BDK, the wallet holds no client and
performs no network I/O.
Source material
appendix/wallet-libraries-ecosystem.md(inlogos-co/rfp) — where walletfunctionality lives per chain, key derivation standards, watch-only support,
and hardware and offline signing. Written explicitly as input for this RFP.
appendix/logos-api-surfaces.md— as-built inventory of the LEZ wallet FFIand
lez_coremodule.Dependencies
None — this is a root surface alongside the LEZ node API. The JSON-RPC proxy
and its client library (#237), and the LEZ-DK (#238), consume it.
Related
Client Library ([RFP] LEZ JSON-RPC Proxy Module & Client Library #237), LEZ-DK ([RFP] LEZ-DK: The LEZ Development Kit #238). The separate Indexer Client Library
issue ([RFP] LEZ Indexer Client Library #239) was folded into [RFP] LEZ JSON-RPC Proxy Module & Client Library #237.
read and signing.