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.

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.