Mobile Application Analysis Statement

Application Analysis

The Veilon mobile client is a React Native (Expo) wallet that integrates with the Veilon privacy-pool smart contracts on Sepolia. It supports public ERC20 transfers, zero-knowledge shielded deposits and withdrawals, and private intra-pool transfers. Proof generation is delegated to a backend relayer; the device handles wallet custody, secret storage, transport encryption, public-input validation, and on-chain submission. The team has now remediated twenty-three of the issues raised across both audit cycles - eleven of them in this remediation round, including every Medium-class finding and the previously-High TLS pinning misconfiguration - and the codebase has matured significantly. There are no remaining Critical or High findings. The items that stay open have been formally acknowledged by the team with documented compensating controls and a remediation roadmap:

• The relayer still receives cleartext shielding secrets server-side, so a compromise of the relayer operator de-anonymises every shielded operation. The team has acknowledged this as the dominant architectural trust assumption of the current design and accepted the residual risk on the basis of the layered compensating controls (ECDH+AES authenticated transport, application-layer relayer ECDH public-key pinning, TLS SPKI pinning, and client-side publicInputs validation) and a roadmap commitment to on-device proof generation as the long-term mitigation. The finding has been re-rated from Critical to Medium in this cycle to reflect that the realistic attack surface is now reduced to relayer-operator compromise rather than an exploitable implementation flaw; Medium is the lower bound of what the residual architectural risk supports.
• Proof-level chain binding is implemented in the contract but disabled at deployment because the production circuits do not yet embed the chain identifier as a public input. The always-on deployment-chain modifier in PrivacyPoolV2 blocks cross-deployment replay unconditionally, and the team has acknowledged this contract-level mitigation as sufficient for launch; the circuit-regeneration work is tied to the same roadmap milestone as on-device proof generation so that the circuits are touched only once.
• A set of Optimization and Informational items remain open and have been formally acknowledged by the team as deferred to post-production: absence of automated test coverage for the hardened cryptographic paths, absence of crash-reporting telemetry, an unused SDK wrapper layer retained as the attachment point for the future on-device proof path, a deprecated shield() delegating stub, a hardcoded developer-only relayer URL, a leafIndex placeholder that is not consumed by the current relayer-driven proof path, an AppState listener subscription that is never released, and an imported resetHandshake helper that is never invoked on wallet switch, delete, network switch, or disconnect.

Trust Model and Privileged Components

The mobile client's security boundary is shaped by a small set of privileged components, each with explicit responsibilities and constraints:

• SecureStore holds per-wallet private keys and per-address commitment-encryption keys; access is gated by the operating-system keystore and the application-layer PIN.
• The off-chain relayer holds cleartext shielding secrets for the duration of proof generation and is authenticated both by a pinned ECDH public key at the application layer and by SHA-256 SPKI pinning at the TLS layer in production builds.
• The deployed PrivacyPoolV2 contract authorises operations through ZK-proof verification and an always-on deployment-chain modifier that blocks cross-chain replay; the client additionally validates the relayer's returned publicInputs against the circuit specification before submitting on-chain, so a malicious or buggy relayer cannot quietly swap field positions.
• PIN and biometric authentication gate wallet operations and emergency withdrawal; emergency withdrawal cannot proceed without an explicit PIN.
• The relayer is currently a single point of trust for transactional privacy and must be operated under that assumption until on-device proof generation is implemented; the team has formally acknowledged this constraint.
• Transport-layer TLS public-key pinning is now correctly configured against react-native-ssl-pinning v1.6.0 (pkPinning: true, mandatory sha256/ prefix, multiple pins to survive certificate rotation), and production builds fail closed when no pins are configured.
• Proof-level chain binding is implemented in the contract but disabled at deployment because the production circuits do not yet include the chain identifier as a public input; the contract-level deployment-chain modifier covers the launch-time threat model.
• The PIN itself is hashed with a memory-hard KDF; legacy weak hashes are migrated transparently and force-wiped at the documented migration deadline.

Security Features

The two remediation cycles introduced or hardened a substantial set of positive controls:

• PIN hashing uses scrypt (N=2¹⁴, r=8, p=1) with constant-time comparison and persisted brute-force counters that survive application restarts.
• All cryptographic randomness paths fail closed when the platform CSPRNG is unavailable; the previous Math.random fallbacks have been removed across the polyfill chain and the SDK utilities.
• ECDH transport encryption between mobile and relayer is mandatory and the plaintext fallback has been removed; payloads are protected with authenticated AES-CBC + HMAC-SHA-256 over an explicit random IV (replacing the previous CryptoJS passphrase-mode construction), and the relayer's ECDH public key is pinned at the application layer in production builds.
• TLS SPKI pinning is wired into the relayer transport with mandatory sha256/-prefixed pins, support for multiple pins to survive certificate rotation, and a fail-closed production path that refuses to ship without pins configured.
• Commitment secrets, nullifiers, and randomness are AES-encrypted at rest with per-address keys held in SecureStore using the same authenticated wire format as the transport layer; legacy plaintext rows remain readable through a backward-compatibility flag, and a versioned ciphertext prefix lets the decoder distinguish new from legacy records.
• The RPC endpoint and privacy-pool contract address are no longer hardcoded: the SDK resolves the RPC URL through an explicit argument, then a build-time environment variable, then a per-chain registry, and resolves the pool address from the active network rather than the literal “sepolia”.
• A single shared toContractProof helper performs the snarkjs-to-Solidity mapping and validates the relayer-returned publicInputs against a per-circuit specification (length, positional fields, locally-known values) before any transaction is submitted, eliminating the previous duplicate inline mapping and catching field-swap attacks client-side.
• Token decimals are now captured from ERC20.decimals() at commitment-save time and persisted on the commitment, so balance display and emergency-withdraw amounts are correct for any token (WBTC = 8, USDC = 6, ETH = 18, …) instead of relying on hardcoded symbol-based assumptions.
• On-chain commitment sync now queries spentNullifiers with the Poseidon-derived nullifierHash rather than the random preimage, with BN254 field-modulus range validation, so recovery and reconciliation flows correctly mark spent commitments.
• PIN removal forwards the PIN that was just verified by the UI to the underlying service instead of submitting a hardcoded literal, restoring the intended user flow.
• The pinned-fetch wrapper no longer defaults missing response statuses to 200; malformed responses surface as errors instead of being silently treated as success.
• The previously-committed third-party block-explorer API key has been removed from eas.json; rotation of the leaked key with the provider and scrubbing the literal from version-control history are operational follow-ups outside the code-review scope, but remain necessary because the literal otherwise stays recoverable from history.
• Production logging is centralised behind a build-flag-gated logger, sensitive interpolations have been redacted, and emergency withdrawal cannot bypass PIN verification.

Auditor's Closing Remarks

The team's response across the two audit cycles has been substantive: twenty-three findings - including all four issues originally rated critical on the cryptographic and storage layers, the previously-open TLS pinning misconfiguration, and every Medium-class finding - have been properly closed. No Critical or High items remain open. The remaining ten open findings have been formally acknowledged by the team with documented compensating controls and a remediation roadmap: one Medium (the relayer trust assumption, re-rated from Critical in this cycle to reflect the layered compensating controls), one Low (proof-level chain binding, accepted on the basis of the contract-level deployment-chain modifier and tied to the same roadmap milestone as on-device proving), two Informational (a developer-only relayer URL and a leafIndex placeholder that is not consumed by the current proof path), and six Optimization items deferred to post-production. Notwithstanding the formal acknowledgments, the audit team flags two of the deferred Optimization items as warranting pre-release attention because both are single-digit-line-count fixes with disproportionate operational impact: wiring resetHandshake into the wallet-switch, delete, network-switch, and disconnect paths so a single transient ECDH handshake failure does not silently latch the relayer into a throwing state for the remainder of the session, and capturing the AppState subscription in securityStore.initialize with a teardown to prevent listener stacking. The absence of automated test coverage for the now-fail-closed cryptographic paths and the absence of crash-reporting telemetry are likewise no longer optional in spirit even where they remain optional in scope: without observability, regressions in those paths will be invisible to operators.

Note — This audit report consists of a security analysis of the Veilon mobile application source code at the revision provided for re-review. The analysis did not include dynamic penetration testing of compiled builds, in-device verification of the now-corrected TLS-pinning behaviour against a deliberately misconfigured pin in a release build, confirmation that the previously-committed API key has been rotated with the provider or scrubbed from version-control history, or formal review of the off-chain relayer service and underlying ZK circuits, which fall outside the scope of this engagement and were audited separately. We recommend the team complete the listed operational verification steps, action the two pre-release fixes flagged in the closing remarks (resetHandshake wiring and AppState teardown), integrate crash-reporting telemetry to surface any production regressions in the hardened cryptographic paths once feasible, and that users perform their own security review before transacting significant value through the application.