docs(ai): spec a fidelity audit of every signing surface

[AntonioVentilii]

Motivation

Eight externally reported defects landed in a short period, across three chains and two entry points. They look unrelated, and they are not: in every one of them the approval screen described something other than what the wallet actually signed. A hidden Solana prioritisation fee, an authority change and a burn riding behind a dust transfer, a signing scheme picked from what a payload parsed as instead of from the requested method, undeclared EIP-712 keys steering a summary while a different value was hashed, ERC-20 transfer calldata rendered as a zero-value native send, counterparty markup reaching the consent dialog as a control, a transaction message accepted on the message-signing path, and a PSBT field the review reads that the signer does not use.

Fixing these one at a time is losing a race against someone walking this surface systematically. This spec defines an audit that enumerates the surface ourselves, so the remaining instances are found by us rather than reported to us.

Changes

Adds docs/ai/spec-driven-development/specs/2026-08-12-chore-signing-surface-fidelity-audit.md, which:

• names the six recurring shapes behind the eight defects, so the audit hunts the class and not the instances;
• inventories every signing surface, established from the code: the WalletConnect reviews for BTC, ETH and SOL, the session proposal, the ICRC signer consent flow, OISY's own send, swap, convert, approval, trade, stake, Liquidium, Open Crypto Pay and AI assistant flows, plus signature-producing paths that render no approval screen at all;
• defines a fixed eight-point per-surface checklist, a finding format, a severity rubric, and the wave order surfaces are examined in, so the work is resumable and the result is auditable;
• states that it covers the audit and not the fixes, and that each finding becomes its own atomic change;
• records open questions rather than resolving them, including whether the activity list and transaction history are in scope, and whether internally built transactions are in scope or only counterparty-supplied ones.

No file under src/ is touched.

Tests

Spec-only PR: there is no code to test. format and lint --max-warnings 0 pass.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to fb833a1.

Security Overview

• 🔎 Scanned files: 1 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/00881019-f162-4503-9567-953b0be667d7?scanId=7523ef91-97b8-4cb9-ba74-6a66a57005bb&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Other relevant categories	► docs/ai/spec-driven-development/specs/2026-08-12-chore-signing-surface-fidelity-audit.md     Add new Signing-surface fidelity audit specification document

[Copilot]

Pull request overview

Adds a spec document to drive a systematic audit of every signing/approval surface in the frontend, aiming to prevent mismatches between what OISY displays for consent and what it actually signs.

Changes:

• Introduces a new spec defining the motivation, scope, inventory, per-surface checklist, severity rubric, and audit wave order for a “signing-surface fidelity” audit.
• Defines a standardized finding format and acceptance criteria so results are resumable and auditable.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.