Signing is the moment a wallet earns or loses trust. Eoonia's signing screen was rebuilt during its September 2026 audit around three questions a user should be able to answer before approving: what exactly will happen, what will it cost, and when is it done?
What will happen
Eoonia decodes every call from the chain's runtime metadata and renders it in words: Transfer 10 DMS to vx…, Bond 1,000 DMS and nominate …, Mint dynamic NFT in collection 7. A call it cannot decode — because the metadata is stale or the call is unknown — is refused, not shown as hex and approved blind. Metadata is refreshed after every runtime upgrade; the wallet detected and adapted to the three calls whose signatures changed in runtime 208 (registerDomain, addSessionKey, createVault).
What it will cost
The fee shown is real. Eoonia calls payment_queryInfo with the actual extrinsic — signed with 64 zero bytes as a placeholder, no nonce — and displays the chain's own estimate. On the testnet a transfer estimates at 0.000025 DMS. Earlier builds showed a fixed placeholder; that was one of the audit findings.
When it is done
After approval, the screen tracks the chain's three states:
- Submitted — accepted by the RPC node's pool.
- Included — in a block; balances updated; not yet irreversible.
- Finalized — GRANDPA has finalized; irreversible for practical purposes.
On the testnet these arrive at roughly 1 s, 3.5 s and 17 s. Eoonia never labels an included transaction as complete, and the consensus documentation requires every ecosystem client to keep the distinction.
What was found and fixed
- "Stake" wrote to local storage and reported success — an early audit finding. Correction: staking does reach the chain via
empStaking.bond; what was missing was the end-to-end test, now added. - Importing a wallet stored the seed unencrypted. Fixed; a test fails without the encryption.
- A background connection crashed (
Bad state: No elementfrom a secondWalletService). Fixed by guarding the shared chain service. - Governance voting was thought missing — it was implemented; the audit was wrong and says so.
Local history
Transactions are recorded locally (dms_historial) with their final state, so the history screen works offline and does not depend on an indexer — EmpooScan's indexer has been intermittently behind, and a wallet should not inherit that.
On the phone
All of this was exercised on a physical device (a POCO F8 PRO) with a funded CI account on the live testnet, not only in an emulator. One finding from that session was not a wallet bug at all: the device refuses screenshots and installs when locked, which is why the test runbook now says unlock the phone first.
Based on the Eoonia audit blocks 1–3 (2026-09-07) and the device test session.