Skip to content
SAI Wallet

Security

A multichain wallet combines several risk sources: client level (keys and signatures), network level (fees, finality), protocol level (contracts and dependencies), and cross-chain infrastructure. This chapter describes the threat model for SAI Wallet in a neutral technical form and fixes which execution properties are considered critical.

Security Objectives

For SAI Wallet, key security objectives are expressed as:

  • prevent unauthorized asset withdrawal;
  • preserve operation parameter integrity between confirmation and execution;
  • prevent re-execution of cross-chain messages;
  • ensure operation status observability through transactions and events.

Client and Key Level Threats

Main threats on the user side are related to key material compromise and parameter substitution before signing:

  • device compromise and access to seed/keys;
  • phishing and destination address substitution;
  • substitution of amount, network, or token contract when confirming the operation.

In SAI Wallet, the model is non-custodial: keys are used for signing on the user side, and server components do not receive access to the seed. At the interface level, security is maintained by showing final transaction parameters before signing: network, asset, destination address, and execution constraints (e.g., execution price limit (minOut)).

Financial Protocol Level Risks

Yield strategies and exchanges rely on protocol smart contracts. At this level, risks include:

  • contract errors and vulnerabilities;
  • dependency on oracles and protocol parameters;
  • parameter changes through governance or admin keys;
  • liquidity risks (e.g., sudden deterioration of exit conditions).

For users, this means that “yield” is a function not only of the market but also of the properties of a specific protocol. In SAI Wallet, a strategy is described as a combination: network + asset + protocol + position type, so the user context is not reduced to a single ticker.

Cross-Chain Layer Threats

A cross-chain route adds a separate class of threats:

  • errors in cross-chain infrastructure and message delivery logic;
  • re-delivery and re-execution in the destination network;
  • status divergence between source and destination due to finality differences;
  • risks of asset representations (wrapped/bridged variants) and their liquidity.

In the SAI Wallet operation model, the cross-chain stage is tracked separately: artifacts of sending (txHash_source) and, if available, the cross-chain message identifier (messageId) are recorded. This separates “sent” and “executed” as different execution facts.

Data and Observability Threats

Even with correct contracts and networks, user experience depends on data quality:

  • RPC provider unavailability and discrepancies between providers;
  • indexer and explorer delays;
  • errors in quote sources and routing.

In SAI Wallet, operation statuses are tied to confirmed transactions and events, and quota calculations fix assumptions (e.g., execution price limit (minOut) and deadline). This reduces the impact of temporary instability of external sources on the operation outcome.

UX as Part of Security

In a multichain model, part of the risks is transferred to the interface level: the user confirms parameters that then become execution constraints. Two properties are critical:

  • operation parameters are readable and unambiguous (network, asset, contract, destination address);
  • execution constraints are fixed (deadline, minimum output), so that condition changes do not lead to unexpected results.

Below is a simplified risk dependency map:

Security Model