Deniability by construction, not by paragraph.
Most "deniability" features are a line on a marketing page. A decoy wallet exists, says the page, so under coercion you open the decoy and your real funds stay hidden. The paragraph does all the work; the code does very little. Here is what it takes to make deniability a property of the system.
What a decoy session is
A decoy is not a second wallet that lives alongside your real one in a shared backend. It is a separate session — a distinct on-device runtime state with its own key material, balance view, and transaction history. When you set up a duress PIN, you provision a second session on the device, not a "decoy account" on a server. The real session and the decoy session never co-exist in a place the backend can query.
What "zero backend calls" means
A decoy session makes zero backend calls — not fewer, not calls that look the same. The decoy reads balances from public blockchain infrastructure (data anyone can read for any address) and signs transactions locally. It never authenticates to Veyrnox's infrastructure, because there is no session token to send and no user identifier to send. The backend, by design, is never told that two sessions exist.
How it is enforced in code
Deniability that depends on every future engineer remembering not to add a network call in the decoy path is deniability with an expiry date. The enforcement lives at the network layer: the decoy session runs against a surface with no authenticated channel to Veyrnox's infrastructure — there is no code reachable from the decoy session that would construct an authenticated request. It is a constraint, not a policy. The wallet's native code has not shipped yet; until it does, this page links to the design deep-dive rather than a specific file. See the current verification status on the feature status page.