Caty: A Self-Custody System for EVM Chain Security

Caty's self-custody system ensures safe fund storage on EVM chains through cold and hot signer roles managing transaction policies.

### Caty: A Secure Self-Custody System for EVM Chains
* 🔒 Caty is a self-custody system designed for users who want to **securely store funds** on Ethereum Virtual Machine (EVM) chains, addressing the philosophical challenge of **safeguarding substantial on-chain assets**.
* 🛡 The system incorporates a **dual signer mechanism**, consisting of **cold signers** who set transaction policies and whitelist protocols, and **hot signers** who execute predefined transactions under these policies.
* 🔍 A key feature of Caty is its emphasis on **checking call data before transactions are executed**, ensuring that even if a user's computer or browser is compromised, their **funds remain secure**.
* 💼 The initial version will focus on **lossless DeFi protocols**, such as lending and single-sided staking, with plans to whitelist platforms like **Moonwell** on various networks including **Base and Optimism**.
* 🛠 The architecture leverages Nosis Safe and a time lock mechanism to enhance security, **preventing unauthorized upgrades or changes that could lead to asset loss**.
* ⚠ A significant security improvement includes the implementation of a **guard that prohibits delegate calls**, thereby allowing the system to **reverse any malicious actions before a time lock expires**.
* 🕒 Additionally, the time lock policy engine allows hot signers to interact only with **whitelisted addresses and call data**, significantly **reducing the risk of unauthorized transactions**.
* 📜 For recovery, Caty employs social recovery spells, enabling a predefined group of users to **recover access to the wallet while maintaining anonymity** until the recovery process is initiated.

### Understanding Call Data Management in DeFi Protocols
* 🔍 The management of call data in DeFi protocols is constrained by the requirement for **concrete values**, limiting the use of **dynamic arguments** like arrays or strings.
* 🔑 A wildcard check is established when the **start and end indexes are equal**, allowing certain functions, such as Compound's **mint function**, to bypass specific checks.
* 🔧 The initialized function sets up **crucial checks for call data**, enabling users to **create wallets without needing to gather signatures from multiple locations**.
* 📊 The core functionality involves validating call data by ensuring the **contract address and function signature are correct**, and that the call data checks are **not empty or invalid**.
* ⚙ Operations can only be scheduled by the **safe**, while anyone can execute them, maintaining **security during the execution of transactions**.
* 🛡 The system includes multiple checks to prevent overlapping call data checks, ensuring that each function call is **exclusive and does not compromise security**.
* 📝 Functions are built to allow for the **removal and addition of call data checks**, with strict rules preventing the addition of checks that could lead to **security vulnerabilities**.
* 🔒 Overall, the implementation emphasizes **safety and thorough checks**, supported by **extensive testing and formal verification** to ensure the **integrity of the protocol**.

Kleidi Code Walk-Through

Code4rena

Caty's Self-Custody System for EVM Chains

Caty is a self-custody system designed to help users store funds safely on EVM chains, using a combination of hot and cold signers to manage transactions and set policies.

The system is built on Nosis Safe, with a unique time lock mechanism to prevent malicious actions and fund loss.

The initial version will focus on lossless DeFi protocols, such as lending and single-sided staking, to provide users with a secure way to manage their assets.

Nosis Safe's Contract Architecture and Recovery Mechanisms

Nosis Safe offers social recovery spells with predefined delays, using create 2 for address calculation and allowing owners to recover the wallet.

The time lock plays a crucial role in the system, hosting a policy engine and allowing the safe to perform arbitrary actions.

The instance deployer is responsible for creating wallet instances and coordinating with various factory contracts to prevent front-running and ensure a secure setup.

The safe's owner is the instance deployer, and the creation salt is a hash of the initial parameters.

The proxy is created with a fail-safe mechanism, and the time lock is established using the same parameters, preventing front-running.

The deployment process includes initializing the safe, setting up modules, and adding new owners while ensuring all actions align with the specified logic.

The setup allows users to hide their recovery signers until contracts are deployed, ensuring privacy.

Recovery signers must sign transactions for each network if the system is on multiple chains.

The time lock mechanism includes a minimum delay for executing transactions and has a data structure for whitelisting hot signers, allowing for specific checks on call data parameters.

Call Data Slicing and Wallet Creation in DeFi

The call data slicing method only works with concrete values, avoiding dynamic arguments.

Wild card checks are used for specific function calls, allowing for flexible wallet creation without the need to gather signatures from multiple locations.

The process includes scheduling and executing operations, with the ability to cancel and clean up expired actions, all while ensuring the contract is not paused.

Key Features of the State Machine and Time Lock Contract

The state machine includes logic to set the pause time to zero when updating the pause duration, preventing contract repa.

The execute function, called by the hot signer, allows for batch operations without checking the value, which is intended for users swapping ETH.

The contract has strict rules for adding call data checks, ensuring they are exclusive and non-overlapping to maintain security.

The function has strict access control and a set of checks to prevent unexpected behavior.

It verifies the contract address, selector, and index values, while also ensuring that checks cannot overlap or be added from the same time lock.

The function iterates through existing checks to maintain exclusivity and prevent multiple values with the same start and end indexes.

Overview of Call Data Checks and Contract Functions

The process involves checking for mutual exclusivity between start and end indices to avoid overlaps.

If the indices are not found, the target index is assigned, and data length is validated.

The contract includes functions for adding and removing call data checks, receiving ETH, and revoking hot signers, with thorough testing and formal verification in place.