- 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
