- Added SequencerClient class to handle asynchronous account reads and transaction queries.
- Updated NewPositionRuntime to integrate SequencerClient, allowing for improved wallet account management.
- Modified existing tests to accommodate changes in the new position schema from v1 to v2.
- Enhanced QML tests to validate new position form behavior with updated holding selections and context handling.
- Refactored code to ensure compatibility with the new SequencerClient functionalities.
Keep wallet assets as token choices without automatically selecting a pair. Keep pool-probe amounts internal so active-pool quotes do not populate the form before user input.
Expose typed Rust request contracts and transport-independent operations for application clients. Keep the existing C ABI as a thin adapter so the AMM UI continues to use the same symbols.
Implement one create-pool and add-liquidity workflow. Add searchable token resolution, direct opening-price and deposit editing, optimistic pool activation, and base58 transaction IDs.
Isolate network, wallet, AMM client, and runtime boundaries. Stabilize quote, submission, refresh, and pool-probe state while consolidating liquidity tests and removing obsolete liquidity paths.
Replace prototype data and floating-point quotes with live wallet and
chain reads, exact Rust quote planning, and optimistic external-wallet
submission.
Add canonical display-order mapping, responsive QML states,
network-scoped program configuration, and packaged Rust client support.
The Logos.Wallet QML plugin was installed with an ELF "$ORIGIN" rpath.
macOS dyld does not expand "$ORIGIN", so loading the plugin failed with
Cannot load library liblogos_wallet_qmlplugin.dylib:
Library not loaded: @rpath/liblogos_wallet_qml.dylib
even though liblogos_wallet_qml.dylib sits in the same directory. Select
the rpath per platform: @loader_path on Apple, $ORIGIN elsewhere, so
@rpath/liblogos_wallet_qml.dylib resolves to the sibling library.
Move wallet lifecycle, account-model synchronization, settings, and reachability behind a composition-based WalletController. Keep AmmUiBackend as the QtRO forwarding adapter while retaining direct WalletProvider ownership for program-specific reads and transaction submission.
Adopt the thin-consumer direction demonstrated by PR #230 without coupling the shared module to generated QtRO base classes.
Refs #227
Refs #230
Replace AMM-local wallet access, account state, controls, and confirmation-dialog mechanics with the reusable wallet targets. Keep AMM-specific transaction summaries and actions in the AMM UI.\n\nRefs #227
Move the spel-framework dependency from the 0x-r4bbit/spel fork
(v0.5.0 @ 91023c9, the refactor/lez-v020-compat branch) to the released
logos-co/spel tag v0.6.0.
spel v0.6.0 is built against the final logos-execution-zone v0.2.0, not
the v0.2.0-rc6 this repo pinned. The two must match: with rc6, the guest
ELF build fails because spel's lee_core::program::ValidityWindow and the
repo's own copy are distinct types the #[lez_program] macro can't unify.
So this also bumps every logos-execution-zone pin (lee/lee_core aliased
as nssa/nssa_core, plus clock_core) from v0.2.0-rc6 to the final v0.2.0.
- 10 Cargo.toml switched to logos-co/spel tag v0.6.0
- 24 logos-execution-zone pins across 18 Cargo.toml moved rc6 -> v0.2.0
- All 7 Cargo.lock files re-resolved (root + 5 guest workspaces +
benchmark); pulls in lee_core v0.1.0 (v0.2.0) as a spel transitive dep
Guest ImageIDs change as a result: the ID hashes the whole guest ELF,
which links the updated spel-framework and lee_core object code, even
though the program sources are unchanged. Update any ImageID-derived
values (deployed program IDs, PDA addresses, AMM/ATA program-id inputs)
before submitting transactions.
The AMM guest lockfile had drifted to enum-ordinalize 4.4.1 (and
enum-ordinalize-derive 4.4.1), both of which require rustc 1.89. The
RISC Zero guest toolchain is 1.88.0-dev, so `cargo +risc0 build
--locked` failed the "build programs" CI task:
error: rustc 1.88.0-dev is not supported by the following packages:
enum-ordinalize@4.4.1 requires rustc 1.89
enum-ordinalize-derive@4.4.1 requires rustc 1.89
enum-ordinalize is pulled in transitively via educe 0.6.0 (^4.3), so
4.3.2 satisfies the requirement and matches what every other guest
lockfile already resolves to. Pin both crates back to 4.3.2.
The host workspace Cargo.lock keeps 4.4.1 — it builds on 1.94.0 per
rust-toolchain.toml and is unaffected.
Add an optional mint authority to fungible tokens for controlled supply:
create with a designated minter, mint additional supply, rotate the
authority to a new key, or permanently revoke it to fix the supply.
The authority is stored inline on `TokenDefinition::Fungible` as
`authority: Option<AccountId>` (`Some(id)` = mintable by `id`, `None` =
fixed supply). Keeping it a plain `Option<AccountId>` rather than a custom
wrapper type leaves account state decodable by `spel inspect`; the
require/rotate/revoke guard logic lives inline in the handlers.
LEZ rejects a transaction that lists the same account id twice, so one
instruction cannot statically express both "the definition account is the
authority and signs" (self/PDA authority) and "a distinct rotated account
signs" (external authority) — they need opposite signer markers. Each
privileged operation is therefore split into a self and an external
variant:
- `Mint` / `SetAuthority` — the definition account is the signer.
- `MintWithAuthority` / `SetAuthorityWithAuthority` — a distinct authority
account is the signer; the definition account does not sign.
Creation via `NewFungibleDefinition { mint_authority, .. }`; an all-zero
authority id is rejected. The AMM's LP token uses self/PDA authority — its
stored authority is the LP definition PDA, minted only by the pool via
chained calls.
Covered by token unit tests and zkVM integration tests: creation with and
without an authority, self- and external-authority mint, rotation, and
external rotate/revoke. IDLs regenerated.
Turns the dummy-data AMM UI into a real client of the on-chain LEZ wallet.
Adds a hand-written ui_qml C++ backend (src/AmmUi*) over the core
logos_execution_zone module: create/open a local wallet, create and list
public/private accounts, and a navbar Connect / Connected + account-selector
+ Disconnect flow. Onboarding is password-only (no path picking) with a
per-app wallet at ~/.lee/amm-wallet (override: AMM_WALLET_HOME_DIR);
standalone gets its own wallet, Basecamp shares accounts via adopt-on-start.
Requires Nix with flakes; macOS also needs `sandbox = false` (the default).
The logos_execution_zone input is pinned to a module rev whose LEZ (lssa)
already includes the macOS Metal-build fix, so no `--override-input` is
needed — plain `nix run .` works:
cd apps/amm
nix run .
- create_new now returns the new wallet's BIP39 mnemonic (not an int status);
the app currently discards it, so the wallet can't yet be recovered. Surfacing
it in onboarding (+ restore_storage) is a follow-up.
- The wallet password is currently a no-op upstream (storage.rs: "TODO: use
password for storage encryption"); storage.json is plaintext. So Disconnect
is a UI-level lock and reconnect does not (cannot yet) re-prompt for it.
- wallet-ffi requires explicit config/storage paths; a *_default() FFI would
let the app drop its path handling.
- Bundled network config: connects to whatever WalletConfig::default() points
at; real testnet endpoints still TBD.
The AMM multiplied amounts in u128 — `token_a * token_b` for the initial
LP in `new_definition`, `reserve * amount` in swaps, and the mul/div steps
in add/remove liquidity. For realistic 18-decimal token amounts the
intermediate product exceeds `u128::MAX` (~3.4e38): opening a pool with
100/200 tokens is `1e20 * 2e20 = 2e40`, which panicked and caused the
sequencer to skip the transaction.
Widen the intermediate arithmetic, not the stored types. Add
`mul_div_floor`, `mul_div_ceil`, and `isqrt_product` to `amm_core` (using
`alloy_primitives::U256`, as `spot_price_q64_64` already does): they
compute the product/division/sqrt in U256 and downcast the result back to
u128. Route `new_definition`, `swap_exact_input`/`swap_exact_output`,
`add_liquidity`, and `remove_liquidity` through them. `swap_exact_output`
keeps its ceil rounding (required input rounded up, in the pool's favour)
via `mul_div_ceil`.
Balances, reserves, and LP supply stay u128, so account data formats,
IDLs, and the token/ata/stablecoin programs are unchanged. This lifts the
usable amount range to the full u128.