Marvin JonesandClaude Sonnet 5
ed61107f1c
Programs dispatch at the address seeded via with_programs/a live Deploy (loader_core::immutable_deploy_account_id), not the bijection AccountId::from(program_id) used by the legacy ProgramDeploymentTransaction storage shape. This sweep threads the correct address through lee/lez/integration_tests/wallet-ffi call sites and fixes 7 dispatch-address bugs the mismatch was masking: bijection-vs-real-PDA mismatches in lez/wallet's native_token_transfer facade, integration_tests' auth_transfer/private and private_pda suites, wallet-ffi's generic_transaction FFI boundary, a stale assertion in program_deployment.rs, and a stale expected-error string in cross_zone_state_machine.rs. Also includes a full clippy/fmt pass: doc-comment reflow, #[expect(...)] attribute additions, redundant type-annotation/unused-import removal, and two assert!s added purely for bounds-check elision on already-guarded slices — no logic changes. Both CI clippy invocations and cargo fmt --check are clean. Verified: RISC0_DEV_MODE=1 cargo test -p lee --lib (214 passed) and the broader sanity set across lee/wallet/bridge_lock_core/ping_core/ cross_zone_outbox_core/sequencer_core (mock features) both green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Programs
This crate serves two purposes at once:
- Provide one entrypoint for
cargo risczero buildto build guest binaries used in LEZ in one shot. - Provide access to the built binaries wrapped with
Programtype.
Binaries
This crate contains binaries taken from sub-directories: one per each program. This binaries are meant to be compiled with cargo risczero build. No other use is intended for them.
Library
You may import this crate as a library but it will only make sense if you enable artifacts feature flag.
Enabling this flag will make crate expect that binaries where already built and put in the right place (use just build-artifacts for that).
Why not just risc0_build::embed_methods() ?
Because this will either provide non-deterministic guest build or requires Docker. And forcing to use Docker to build the project is not an option for us especially because we also build Docker images for our services, which would mean we would have to call docker from docker (and this is not really feasible).
risc0_build::embed_methods() works well when you don't need deterministic build or Docker is not a problem. This is the case for our tests and we use it there.