Logos DEX UX review

BlockerThe testnet deployment the app points to is gone

Testnet has been reset and upgraded since 10 Sep. The AMM config, both token definitions, the vaults and the TKA/TKB pool now all return empty accounts. The v0.2.4 CLI can't even decode the sequencer's responses any more.

Yet DEPLOYMENTS.md, artifacts/amm-registry.testnet.json and the module's network config still describe the v0.2.4 deployment. The app turns this into the raw error amm_not_initialized plus “No pool / no liquidity”.

Fix: redeploy to the current testnet and update the registry and DEPLOYMENTS.md. Add a smoke check (CI or a cron job) that reads the registry's config account, so a reset is noticed the same day.

BlockerThe Basecamp catalog ships an outdated, incompatible build

The catalog's “Logos DEX App” installs DEX App v0.1.0 + DEX Core v0.1.0 (published 3 Sep), while the repo is at v0.3.0. It pairs them with LEZ Core v0.5.0.

• DEX Core v0.1.0 has no way to receive the registry's ammConfigId (no setConfigId), so it predates per-instance AMM configs entirely.
• Even after swapping in v0.3.0, LEZ Core v0.5.0 gives amm_ffi op failure: account read failed on every read. That's the incompatibility the repo's flake.nix warns about when it pins a 0.4.1 interim build instead.

The install itself is smooth: one button installs all three packages.

Fix: publish v0.3.0 to the catalog together with a compatible LEZ Core, and declare version constraints between the DEX Core and LEZ Core.

BlockerThe app starts with no tokens and no pools

Out of the box the registry URL in Settings is empty (“Leave empty to load none”). The token picker says “No tokens found”, Explore is empty, and nothing hints that a URL is needed or where to find one.

Pasting a token's definition ID into the swap picker's search doesn't help either. The Settings field also stays blank when a registry is active via AMM_REGISTRY_URL, so it never shows what's in use.

Fix: ship the official registry URL as the default; show the active source in Settings; add an empty-state message pointing to Settings.

BlockerWallet module version changes strand the user

• v0.4.1 can't open a wallet made by v0.5.0. Changing the module from v0.5.0 (catalog) to v0.4.1 (the repo's pin) made the existing wallet unopenable. The app says only “Wallet could not be opened”: no reason, no password prompt, no “restore from recovery phrase”, no “create new wallet”.
• v0.4.1 can't sync current testnet. Its sync fails with Unexpected variant tag: 247.
• The app hides the failed sync. It silently drops back to “Connect” with no message.

Fix: surface the real error and offer restore-from-phrase or create-new; tell the user when sync fails; migrate or version-check wallet storage.

MajorAmounts are raw base units, and decimals are swallowed

• The swap field silently drops . and ,. Typing 0.5 gives 05, and 1.5 gives 15, which the app then treats as 15.
• It's by design. SwapCard.qml:541 sends the field as raw base units (digitsOnly: true). With 18-decimal tokens, selling one token means typing 1000000000000000000.
• The Liquidity form behaves differently. It accepts the decimal, then rejects it with “Token amounts must use whole raw units.” That's clearer, but just as unusable.
• It isn't my input tool. The same key presses produce 1.5 2,5 in Basecamp's search box.

Fix: take human amounts everywhere. Add a decimals field to the registry and token metadata, convert at the boundary, and accept the locale's decimal separator.

MajorBalances are unformatted 21-digit strings, truncated in the middle

The holding selectors run an account ID straight into a raw balance (3b11459.....999990000). The truncation hides exactly the digits that change after a trade.

The Liquidity form shows Balance 999999999999999999990000, and LP amounts appear as “raw LP”. The same token is “TKA” in one place and “TOKEN A” in the next.

MajorThe add-liquidity summary implies spending your whole balance

Open “Add liquidity” with both amount fields at 0, and the summary reads “Expected spend 999999999999999990000 TOKEN A + 980396039603960386235 TOKEN B”, which is essentially the entire balance.

It corrects itself once you type an amount (100 → “99 TOKEN A + 98 TOKEN B”, which is what landed on-chain). The first impression is alarming, though.

MajorNo “confirmed” state, stale data afterwards, and forms that aren't reset

• Swap: a “Swap submitted” toast that disappears after a few seconds.
• Add liquidity: a persistent “Position submitted” box, but the form keeps its values (100 / 98) with the submit button still active, so a double submission is one click away.
• No result, either way. Neither says whether the transaction succeeded or failed.
• Remove liquidity: 25 seconds later the pool page still showed the pre-removal reserves (10,199 / 10,000), so a user would conclude it did nothing. On-chain it had landed exactly as quoted.

Fix: poll the tx or the account until it's included, then show success or failure and refresh balances, the pool and positions.

MajorA pool you create is invisible in the app

I created a TKA/TKC pool through the app (it landed; the wallet holds 9,000 LP). It appears in neither Explore nor Positions, because both lists come only from the registry file. The only way to see the position again is to edit a JSON file.

MajorError messages blame the wrong thing

• A raw code, amm_not_initialized, shown to users.
• “No pool / no liquidity” and “No funds” while the real cause is “wallet not connected” or “can't reach the chain”.
• The Pools list shows a fee of “—” when reads fail, with no hint why.

Fix: map error codes to plain language and distinguish “disconnected”, “network/read error” and “pool doesn't exist”.

MajorCreating a pool defaults to locking 99.9% of the deposit

The form pre-fills the bare minimum (1,001 + 1,001). Its own summary then reads “Expected LP 1 raw LP”, “Locked LP 1000 raw LP”: the creator would permanently give up 99.9% of the deposit's value. Nothing warns about this, and the confirmation dialog doesn't mention the locked amount.

Rows like “Deposit multiplier 1x minimum” and “Deposit scale 10000 basis points” are internal jargon.

MajorThe wallet unlocks without a password

On every relaunch the existing wallet opened and connected straight away, with no password prompt. The README presents this as a feature, but it means anyone at the machine gets a signing-capable wallet.

• Three names for one app: “Logos DEX App” (catalog, tab), “Logos AMM” (header), and the text “AMM” as its icon.
• Mixed number formats on one page: 0,01% and 10 100 next to 0.98039603 (the system's Czech number format leaking into some fields but not others).
• Wallet dialogs use unstyled default widgets (white fields, grey buttons). The “I have backed up my phrase” label is nearly invisible: dark grey on dark.
• Wallet creation shows a static “Creating…” for ~35 s (26 s of it syncing the chain) with no progress.
• Navigation overlaps: “Explore” opens a page titled “Pools / Pools”, while “Pool” is a dropdown (View positions / Create pool).
• Add liquidity is the create-pool wizard: on an existing pool it opens “New position” with a pointless step 1, “Select token pair and fees”, though fees aren't selectable any more.
• Two different token pickers: “Popular tokens / Tokens by 24H volume” (there is no volume data) versus “Quick select / All tokens”.
• Buttons out of reach: main buttons sit below the fold at 900 px, and editing an amount resets the scroll position.
• Wallet chip: it shows the address, the word “Connected”, or “Connect” at different times. The account menu shows only the native balance (0) and no token holdings.
• Swap confirmation: shows only the minimum (97), not the expected amount (98), and doesn't say which holding pays.
• Catalog details: the size label flips from 232.3 MB to 12.1 MB once a download starts, and the button text is cut off (“Downloadin…”).
• QML warning: RemoveLiquidityDialog.qml:443 logs “Detected recursive rearrange” on every load.

GoodWhen the chain is reachable, the numbers are right and the core screens are thoughtfully designed.

• Pool detail page: reserves, split bar, spot prices, LP supply, fee growth and all addresses.
• Remove sheet: 25/50/75/Max presets, a slider, and guaranteed minimums after slippage.
• Positions: combines multiple LP holdings correctly (90.10% share, floor-rounded claims).
• Wallet setup: a recovery-phrase backup step with explicit confirmation.
• Errors: an exact-output request beyond the reserve gives a clear “Not enough liquidity” and a disabled button.
• Catalog install: one button pulls in all three packages.

• setup-amm-testnet.sh reports success on failure: it exits 0 even when wallet restore-keys fails.
• It depends on one exact wallet CLI build: it assumes the v0.2.4 CLI's first-run prompt order. An older wallet on PATH asks for the phrase first, so the restore fails.
• Its header says to run make build-programs, but it reads binaries from the old per-guest Docker paths, not target/guest/.
• The amm module only logs when AMM_DEBUG=1; without it, failed reads leave no trace in Basecamp's log.

Local setup used for round 2: the v0.2.4 standalone sequencer built from the logos-execution-zone tag, the repo's release guest binaries (same AMM program ID as testnet, cf93244a…), and the deterministic test wallet. The local instance's swap fee is 1 bps.