Skip to main content

Security

Wallet permissions​

Cat Wallet never requests custody of funds and never asks for a private key or seed phrase. Every action that moves funds or writes to a contract is signed by the connected wallet directly – Privy's embedded wallet or an external wallet like MetaMask/Rabby and the wallet, not Cat Wallet, is the final gate on whether a transaction goes through.

Two categories of wallet interaction happen:

  • Signature requests (personal_sign) – used only to prove wallet ownership for session auth and for deriving a chat encryption key (see below). These never touch the blockchain and cost no gas.
  • Transaction requests (eth_sendTransaction) – used for anything that changes on-chain state: swaps, staking, sending tokens, registering a username, minting an NFT. Each one shows the user their own wallet's confirmation screen before anything is broadcast.

Signature flow​

Session authentication works like this:

  1. The client asks the wallet to sign a short message containing the wallet's own address and a timestamp.
  2. That signature is sent to the backend, which recovers the signing address from the signature and checks it matches the claimed address and that the timestamp is recent (protects against replaying an old signature).
  3. On success, the server issues a short lived bearer token bound to that address. The client attaches it to subsequent authenticated requests.

The token proves "this request came from whoever controls this address" without the server ever seeing a private key, and without the token itself being usable to sign transactions or move funds – it only unlocks read/write access to that address's own chat messages and synced tx history.

Encrypted messaging​

Chat messages are end-to-end encrypted and each wallet derives a stable keypair from a one time signed message (the signature itself is used as key material – deterministic, so the same wallet always recovers the same keypair and it's cached locally after the first time so the signature prompt only happens once). The public key is published and the private key never leaves the device.

When you send a message, it's encrypted client side twice; once with the recipient's public key, once with your own – before it's sent to the server. The server (and the Redis store behind it) only ever sees ciphertext. Media attachments (images, voice notes) are the one exception today: they're uploaded to IPFS via Pinata and are not currently encrypted, since IPFS content is inherently public by design. Don't send anything through the image/voice attachment that you wouldn't want publicly retrievable by CID.

If a recipient has never opened the app and has no published key yet, then a message falls back to being sent as plaintext through the relay rather than failing to send and this trades confidentiality for deliverability in that one case, and only that case.

Data handling​

  • On-chain data (balances, contract state, .ritual profiles) is public by definition – that's true of any blockchain, not something specific to Cat Wallet.
  • Chat messages and synced transaction history are stored in Redis, addressed by wallet address, and (for messages) encrypted as described above. There's no separate user account system, your wallet address is your identity.
  • Uploaded media (avatars, NFT images, chat photos/voice notes) goes to IPFS via Pinata and is content-addressed and public.
  • AI assistant conversations are proxied through our backend to a secure third-party LLM provider to generate responses and the request includes wallet context (balances, recent transaction summary) needed for the assistant to answer questions about your wallet, no private key or signing material is ever included.

Transaction safety​

Before executing a swap, send, stake, or any other value moving action, Cat Wallet:

  • Re-quotes the transaction against live chain state immediately before sending and rejects if the price/amount has moved past your slippage tolerance since you last saw it on screen.
  • Shows a price impact warning (and requires explicit acknowledgment) for trades that would move a pool's price by more than 15%.
  • Never auto-submits a transaction without a wallet confirmation because the "AI executes complex actions automatically" framing in the app's marketing means the AI proposes an action and pre-fills the transaction, you still confirm it in your wallet like any other action.

Phishing protection​

  • Cat Wallet only ever asks for a signature or transaction confirmation inside your own wallet's UI but if a prompt to enter a seed phrase or private key appears anywhere in the flow that means it did not come from the Cat Wallet.
  • The app is deployed to a fixed, known domain. So bookmark it rather than following links and verify the URL before connecting a wallet.
  • Ritual chain ID (1979) is checked and enforced before any transaction is signed, if incase your wallet is on the wrong network, then the Cat Wallet prompts a network switch rather than silently sending on the wrong chain.

Ritual zkML transaction risk gate​

Every send is scored by an AI risk model before the signature prompt appears. The scan runs against the recipient address as soon as it resolves, and the result is shown inline under the recipient field – so you see the verdict while you're still filling in the amount, not after you've committed to anything.

  • Where it runs: the model executes inside a Ritual TEE (Trusted Execution Environment) rather than on a server we could quietly swap out. The verdict comes back with a signed commitment, so the score can be independently verified after the fact via the on-chain verifiable-inference endpoint rather than simply trusted.
  • What it checks: the recipient against known phishing/drainer patterns, contract bytecode static analysis (SELFDESTRUCT, dangerous approval patterns), and LLM-based behavioural matching through Infernet.
  • Three outcomes:
    • Safe – green indicator, the flow continues normally.
    • Warning – amber indicator with an expandable reasoning trace. You can still send, but you've been told why.
    • Critical – red indicator and the Send button is disabled. This is a hard block, not a dismissible modal.
  • Explainability: every verdict expands to show the individual signals that produced it, the model's confidence score, and whether the result carries a TEE signature. A risk score with no explanation is just a number, so the reasoning trace is always available.
  • Debounce and caching: the scan fires 600ms after the address stops changing (so it isn't re-run on every keystroke) and results are cached per address for 60 seconds.
  • Fails closed, not open: if the security API is unreachable, the result degrades to Warning rather than silently passing. A scan that didn't happen is never reported as a scan that passed.

This is the difference between a wallet that warns you after a drain and one that refuses to sign in the first place.

Key generation entropy​

Most wallets derive keys from the operating system's random number generator alone. That's a single point of failure with real precedent – the 2013 Android SecureRandom bug silently produced predictable keys and cost users roughly $5.7M in Bitcoin. Nobody noticed until the coins were gone.

Cat Wallet mixes additional physical entropy into key generation from sources that depend on the device's environment at the moment of creation:

  • Timing jitter – sub-microsecond variance in scheduler and execution timing, which is influenced by cache state, thermal noise, and WiFi radio interrupt activity.
  • Network conditions – RTT and downlink variance from the Network Information API, which fluctuates with physical WiFi channel state.
  • Audio clock – AudioContext sample timing, which is unique to the device's hardware clock.
  • Device fingerprint – screen geometry and pixel ratio characteristics.

These are XOR-folded into a 32-byte buffer, mixed with the OS CSPRNG output, and conditioned through SHA-256.

The OS generator is never replaced – only augmented. If the added entropy contributed nothing at all, key strength would be exactly what it is in any other wallet. If the OS generator is ever compromised the way Android's was, the environmental entropy is what stands between a user and a predictable key. The measured min-entropy is surfaced in the UI during wallet creation (target: ≥5.5 bits/byte, validated against the NIST SP 800-90B methodology).

Autonomous Security Sentinel​

Beyond the on-demand Infernet phishing check (above), Cat Wallet runs a background AI agent that continuously watches for new activity and proactively protects users without requiring any manual check.

  • Continuous scanning: a scheduled job (roughly every 15 minutes) scans newly recorded transactions for counterparty addresses no one has checked yet.
  • Automatic risk analysis: each new address is run through the same Infernet risk-analysis model used by the manual recipient check — automatically, in the background.
  • Known-safe skip list: Cat Wallet's own contracts (tokens, staking, swap router, etc.) are never scanned — always trusted.
  • Caching: any given address is re-scanned at most once every 24 hours, so the Infernet inference budget isn't wasted re-checking the same counterparties repeatedly.
  • Proactive delivery: if an address comes back Warning or Critical, the affected user gets a notification in their personal feed and a toast + bell alert the next time they open the app — before they'd ever think to check that address themselves. The same (user, address) pair is only alerted once per 7 days to avoid repeat spam.

This turns Infernet from a click-to-scan tool into a genuinely autonomous protection layer that runs whether or not a user remembers to check.

Future security audits​

There's no third-party smart contract or application security audit has been completed yet – this is a testnet product under active development and a formal audit is planned before any mainnet deployment; this page will be updated with the report once is completed.

Passkey authentication​

Key isolation​

When you register a passkey, the device generates a P-256 key pair inside its secure enclave (Apple Secure Enclave, Android StrongBox, or Windows TPM). The private key cannot be exported. Cat Wallet stores only the public key coordinates and the credential ID.

Transaction binding​

Each signing challenge is derived from the full transaction parameters:

SHA-256(abi.encode(chainId, nonce, to, value, sha256(data)))

A signature cannot be replayed against a different transaction or a different chain.

On-chain verification​

Transaction signature verification is performed by the SECP256R1 precompile at 0x0100. No trusted relay or backend is involved in approving a transaction.

Challenge expiry​

Challenges issued by /api/passkey/challenge expire after 90 seconds and are invalidated after first use.

MEV protection​

The Send and Swap pages score every transaction for sandwich-attack risk before submission. Risk is computed from slippage tolerance, trade size, token pair activity, and time of day. Ritual's Infernet AI refines the score when available. Suggested mitigations include reducing slippage, splitting the trade, and using a private relay.

See MEV protection for details.