Show and tell: OMIKAMI WALLET — a strictly read-only wagmi/viem dashboard (feedback on the read-only invariant welcome)

[Reprisal369]

Hi wevm community 👋

I built OMIKAMI WALLET, a non-custodial, read-only Ethereum wallet & DeFi
dashboard on the Sepolia testnet, using wagmi 3.7.4 + viem 2.55.10 (Next.js
static export). It reads balances, tokens, recent activity, and allowances, and
shows a transfer preview — there is deliberately no signing, no transactions,
and no first-party contracts yet. That comes only after review.

How the read-only invariant is enforced (would love a sanity check on this):

• transports are explicitly pinned in wagmi config so a viem default change can't
  move egress; connect-src (CSP) + a build-time bundle allowlist enforce the same
  two hosts.
• a build gate fails the build if any write/sign/switch hook or action appears in
  source (useSendTransaction, useWriteContract, writeContract, sendTransaction,
  signMessage, signTypedData, switchChain, prepareTransactionRequest, …).
• transactionsEnabled is false everywhere; signing is disabled build-wide.

What I'd love feedback on:

• Does the read-only invariant truly hold — any reachable path through wagmi/viem
  that could sign or move funds?
• Correct/idiomatic wagmi/viem usage (connectors, transports, useReadContract,
  getLogs paging) and any client-side pitfalls I've missed.
• Input handling (address poisoning, RPC-URL validation) and rendering of
  untrusted on-chain data.

Details, scope, threat model, test evidence, and one-page reproduction:

• Repo: https://github.com/Reprisal369/OMIKAMI-WALLET
• Tag to review: v0.5.5 (commit 1b1bbc2)
• Start here: docs/reviews/AUDIT_PACKAGE_v0.5.4.md

Small typed pnpm monorepo, pure unit-tested security logic (unit 94 / e2e 38),
full CI, A+ security headers, CodeQL 0 open, pnpm audit 0. Any pointers welcome —
thanks for wagmi + viem! — Reprisal