Skip to main content

Security

Given the sector we operate in and the potential outcomes of specific scenarios, security is one of our top priorities. That's why we decided to launch the product with Smart Accounts instead of Vaults.

Smart Account Security​

By design, we opted for personalized Smart Accounts rather than a global vault for three main reasons:

  1. Non-custodial: Each user has their own Smart Account, which is more secure compared to having all funds in a single vault contract.
  2. Direct Interaction: Instead of rebalancing and curating positions through a vault, the Agent sends DeFi opportunities directly to all Smart Accounts, which then interact directly with the chosen protocols themselves.
  3. No front-end interactions: By design, your smart account will automatically interact with the contracts of protocols you have chosen. Even if a protocol's front-end is hacked, your funds remain safe.

Additionally, Smart Accounts are audited multiple times and battle-tested, reinforcing our decision to utilize this technology.

Session Key Security - An Home-Made Solution​

In line with the Smart Account architecture, the session keys are fully compatible and provide an additional layer of security concerning users' funds.

At Zyfai, we spent months researching and developing our own session key architecture without sacrificing UX or security.

By default, the strength of session keys lies in their ability to limit actions based on predefined permissions. However, asking users to sign a new session key each time we integrate a new pool is inefficient and leads to yield loss for Zyfai users. To solve this, we designed a hybrid method described below:

We built and audited two contracts to handle session keys more effectively:

function executeGuardedBatch(Execution[] calldata executions) external whenNotPaused {
    _execute(callData);
}

It exposes the function above, which is the only selector approved by the session key and is called by the Agent to execute DeFi position calldata. It uses a target registry contract to verify whether the calldata is allowed to be executed, as well as to control transfer selectors.

  • The target registry contract is a simple contract used to whitelist target contracts and selectors. The owner of this contract is a 3/5 multisig, or any curator/institutional partner, responsible for whitelisting new targets and selectors that users' session keys can interact with.

As you can see in the code above, even if the Agent sends incorrect requests to the Smart Account, the session keys are only authorized to interact with predefined protocols listed in the target registry contract.

This ensures that users maintain control over their assets while still enjoying a seamless experience.

Everything is open source and was audited by Sherlock in December 2025.

GitHub repository: Zyfai Executor Module & Target Registry

Audit report: Sherlock audit – December 2025