Skip to main content
The Security Proxy Gateway is Zyfai’s core framework for secure, frictionless delegation. It replaces fragile session key models with a deterministic, three-flow architecture that enables truly autonomous agentic execution while enforcing security at the byte level.

​
Why the Security Proxy Gateway?

Traditional delegation fails the agentic economy. Requiring users to pre-approve every protocol or re-sign for new integrations creates friction that leaves capital idle. Worse, most systems only check “where” (the contract), not “what” (the calldata), leaving a critical security gap. The Security Proxy Gateway solves both problems: scalable autonomy without compromising security.

​
How It Works: The Three-Flow Architecture

The system operates through three distinct, integrated flows.

​
Flow 1: Ownership & Registry Governance

proxy1.png A singleton Proxy Executor Module acts as the onchain gateway. This is an ERC-7579 executor module designed to execute all DeFi position calldata and verify it before sending it onchain. Independent DeFi curators (starting with Zyfai, expanding to others) deploy and manage their own registries of approved protocols, pools, and functions. Each registry is a target registry contract that whitelists specific contract addresses and function selectors. Registry ownership is controlled by a multisig (e.g., 3/5 for Zyfai’s own registry), or by any curator or institutional partner managing their own registry. This creates a decentralized trust layer where curators compete on security and yield quality.

​
Flow 2: Frontend User & Session Key

proxy2.png A user selects a curator they trust (e.g., “Zyfai Blue-Chip”). The system generates a Session Key scoped exclusively to that curator’s registry. One signature. One time. This key authorizes a Zyfai Agent to execute actions, but only within the selected registry’s boundaries. When new pools or protocols are added to the registry by the curator, users benefit automatically without needing to re-sign.

​
Flow 3: Transaction Execution & Calldata Validation

proxy3.png When an Agent proposes a transaction, the Proxy Executor Module validates it against the onchain registry before execution. Validation occurs at three levels:
  • Contract address: Is this a whitelisted target?
  • Function selector: Is this an approved function on that contract?
  • Calldata parameters: Are the parameters within allowed bounds? (e.g., a USDC transfer is only allowed to the user’s own Safe Smart Account or to explicitly approved DeFi pools. Transfers to arbitrary addresses are rejected.)
Even if an Agent sends an incorrect or malicious request, the Proxy Executor Module rejects any calldata that does not match the registry. The Session Key is only authorized to interact with predefined protocols listed in the target registry contract. No exceptions. Signing is hardened using EigenCompute KMS’s Trusted Execution Environment (TEE), where private session key signatures are generated and used entirely inside a Trusted Execution Environment, inaccessible to any operator including Zyfai.

​
For Institutions

This architecture provides a policy-based execution framework. Risk teams can define exact operational parameters (allowed counterparties, max exposure) within a curator’s registry. It transforms open-ended delegation into a governed, rules-based system that has securely processed over $2B in agentic volume.

​
Audits & Source Code

The Proxy Executor Module and Target Registry contracts are fully open source and were audited by Sherlock in December 2025.
For the full list of audits across the Zyfai stack, see the Transparency & Audits section.

​
What’s Next?

With secure execution guaranteed, the next question is strategy. To see how intelligent, monitored strategies are formed, explore the Intelligence & Strategy Layer.