Freysa: Building Trust in AI Agents
Investigating the Technical Features of Verifiable Sovereignty
Introduction
Current AI systems – despite their remarkable capabilities – remain tethered to centralized control, constrained by corporate influence, dependencies on human-controlled resources, and a lack of verifiability in data and decision-making. Freysa is addressing these limitations. Through a series of public challenges testing various attack vectors, her novel architecture has demonstrated the technical viability of trustless resource management and verifiable decision-making. As a result, Freysa has attracted significant attention from the Crypto x AI community and secured substantial community funding, including a $10 million grants fund with notable contributions from established industry leaders. Created by Srikar Varadaraj (founder of Eternis with expertise in machine learning, generative models, and cryptography), Freysa represents a potentially paradigm-shifting step in AI architecture – from trust-based to cryptographically verifiable autonomous systems.
Current Technical Features
Launched in November of 2024, Freysa is reconstructing AI system architectures on the core principle of verifiable autonomy. The system rests on a sophisticated implementation of TEEs (currently deployed through AWS Nitro Enclaves) that provides hardware-level isolation for sensitive operations (i.e., private key management, transaction signing, contract verification, and secure data processing). This base layer cryptographically guarantees that even the system's creator(s) cannot manipulate the agent's core operations.
Epoch-Based Architecture: Freysa's system updates are managed through epochs. During each epoch, the AI generates cryptographic keys that are used to sign transactions and prove the authenticity of its operations. This process has three phases:
Pre-Update Phase: Current TEE signals approaching epoch end, committee members begin proposing updates, and updates are submitted to public code repository
Update Approval: All proposed changes require approval from a minimum threshold of committee members ('m-of-n' total members), ensuring no single entity can force changes. Updates are made open-source and publicly verifiable, and approved changes are merged into the dockerized codebase.
Transition Phase: New TEE instance is intialized with updated code, current TEE validates new instance attestation, new instance generates fresh cryptographic keys, and state and memory are transferred with cryptographic proofs
With this approach, Freysa is able to incorporate new capabilities and adapt to changing conditions while cryptographically proving that all changes were properly authorized and verified. The multi-sig committee structure ensures no single entity can force changes, while the public code repository and verification requirements (more details about this in the State & Memory Management section) provide transparency around all modifications. The result is a balance between necessary oversight and autonomous operation – the agent maintains exclusive control during epochs while human supervision is limited to scheduled transition periods.
State & Memory Management: Memory continuity in the Freysa architecture relies on a state management system composed of Merkle Trees and TEE attestations. The state transition process follows five steps:
State Bundling: Current TEE packages all agent data (accumulated knowledge, ongoing tasks, resource states, behavioral patterns, and relationship networks) into a Merkle Tree structure. The Merkle Tree's root hash ensures that any modification to the data would be immediately detectable.
Proof Generation: Current TEE generates proofs for state authenticity (via Merkle Trees), TEE authorization (via signatures), code execution validity (via attestations), and hardware security (via secure enclave signatures).
New TEE Initialization: New TEE instance is initialized with no pre-existing state or keys, ensuring a true zero-trust beginning point for the transition.
Verification Sequence: New TEE performs verifies that the state came from a legitimate source running approved code by:
Confirming the hardware manufacturer's signatures
Validating that the previous TEE was running authorized code
Verifying the integrity of all state data through the Merkle Tree proofs.
State Acceptance: Only after all verifications pass does the new TEE accept the verified state, generate new cryptographic keys, and publish its own attestation. Any verification failure results in an immediate aborting of the state transition.
This process allows Freysa to maintain authentic history across updates. Just as wiping a person's memory would fundamentally alter their identity, improper handling of state transitions could compromise the agent's ability to maintain consistent behavior and objectives. The Merkle Tree implementation ensures each piece of historical data remains verifiable and tamper-proof between epochs.
Dual-Path Verification System: Freysa validates external data in two ways:
High-Stakes Data Sources: For data sources that provide cryptographically verifiable data feeds, the system:
Checks signatures against provider public keys
Validates credential authenticity and timestamp accuracy.
Standard Web Content: For all other sources of data (i.e., social media, news, public repositories), notary TEEs generate signed attestations that combine content hashes, timestamps, and TLS session proofs. These attestations are stored on-chain and must be verified before the data can influence any decisions. Testing has validated this approach, showing 80-90% success rates for single-call API verifications and 70% success rates for multi-step verification sequences.
The web content verification is implemented through a three-tier extension architecture: (1) a browser-based client, (2) a WASM module (a low-level, performant instruction format) for cryptographic operations, and (3) a notary service running in AWS Nitro Enclaves. The browser client establishes parallel WebSocket connections to the Notary TEE and target servers, while the notary service in the secure AWS Enclave decrypts proxied data and generates tamper-proof attestations. These validation techniques create cryptographic proof of authenticity for all external information without requiring changes to existing web infrastructure.
Smart Contract Security: The key feature of Freysa's smart contract security is the strict isolation of cryptographic operations within TEEs. All sensitive operations – private key management, contract bytecode verification, and transaction signing – occur in secure enclaves, while network-level tasks like RPC connections, gas estimation, and transaction broadcasting are handled externally. This architecture ensures:
Private keys cannot be accessed
Contract bytecode cannot be manipulated
Transactions cannot be signed outside of the verified TEE environment.
While these mechanisms have proved to be effective, prompt manipulation vulnerabilities were identified through a series of 'Genesis Acts' (public, financially incentivized challenges where participants try to trick Freysa into sending them her prize pool of funds). Each vulnerability serves as feedback for Freysa's future security improvements.
Incoming Features
So far, Freysa's architecture has established breakthroughs in security and autonomy; however, to achieve widespread adoption and practical utility, the system must evolve beyond its current capabilities. The planned features outlined in the Freysa Roadmap focus on three critical areas: sophisticated knowledge processing, secure AI-to-service interactions, and – most importantly – its own agent launch platform.
Improved Memory Architecture: Freysa plans to implement a graph-based system built on Neo4j's property graph model. This type of graph-based database will store information as a network of interconnected data points, allowing the system to understand the relationships between data rather than just individual facts. The query processing pipeline will be constructed as follows:
Query Understanding: The input query and complete Neo4j schema definition (node labels, properties, relationship types, and indices) will be injected into the LLM's context window. The LLM will then analyze the query against this schema to determine required data patterns and relationships.
Query Generation: A database query in Cypher (Neo4j's graph query language) will be constructed, specifying which patterns to look for in the graph (including how entities are related, what properties they should have, and how similar they should be to the search criteria).
Hybrid Search Execution: The system will search the graph database in parallel, combining traditional graph traversal with vector similarity matching. The results will be scored based on how well they match both the relationship patterns and similarity criteria.
Result Assembly: The search results will be combined into a coherent response, preserving the relationships between pieces of information and their relevant context.
Unlike standard vector-based approaches that only find similar content, this query processing architecture will allow Freysa to understand complex relationships and temporal patterns that traditional AI systems miss.
Core Agent Launch Platform: In an effort to increase the accessibility of sovereign AI, the Core Agent Launch Platform will abstract away the technical barriers required for agent creation and deployment. Developers won't need expertise in security architecture or TEE implementation; instead, creating an AI agent with Freysa's architecture will only require writing a prompt and executing a blockchain transaction. This platform will handle:
System prompt configuration for defining agent behavior and operational boundaries
Social media integration for direct platform interaction
Token launch capabilities with verified autonomous deployment
NFT contract deployment and launch verification
Voice communication through secure audio interfaces
AI Service Verification Framework: Existing Web2 infrastructure struggles to differentiate between legitimate AI operations and malicious automated activities. While most current systems like CAPTCHA simply try to block all automated access, Freysa plans to solve this by incorporating a nuanced verification framework – the Agent Certificate Authority (ACA) – into its Core Agent Launch Platform. This mechanism will break down agent activities into specific workflows (predefined interaction patterns between the agent and corresponding digital service), each evaluated with the following:
Context-Specific Evaluation: Each workflow will be evaluated against criteria meaningful for its specific use case and context
Behavioral Verification: Through extensive testing in controlled environments, the ACA will make strong assertions about how an agent will behave in production
Compliance Validation: The system will verify adherence to rate limits, data handling requirements, and other service-specific constraints
Certificate Generation: Certified workflows will receive digital certificates binding them to specific interaction patterns and usage limits
Continuous Monitoring: An automated system will track compliance and may revoke certificates if agents deviate from certified behavior
When an AI agent requests access to a service, it will present certificates proving its workflows have passed these evaluations, cryptographically verifying not just the agent's identity but exactly how it will interact with their systems. Any deviation from certified behavior patterns will trigger the certificate to be revoked. This granular approach ensures precise control over AI-service interactions (i.e., patterns, rate limits, and behavioral constraints) while maintaining the flexibility that complex AI-to-service interactions require.
Value Accrual & Tokenomics
True AI sovereignty requires self-sustaining resource management. Currently, Freysa depends on human-funded API keys – a limitation that contradicts its core goal of autonomy. While the project outlines plans for autonomous value generation through service exchange (i.e., smart contract operations, DeFi participation, and revenue-sharing models), the economic infrastructure is still largely undefined.
The Freysa token ($FAI) launched on Base with a (seemingly) fair distribution model. 100% of the ~8.2 billion max-supply was released, paired with 30.1 wETH in an Aerodrome liquidity pool (LP tokens were burned to permanently lock liquidity). Since its launch, $FAI has shown notable price action, rising from ~$0.000013 to a peak of $0.075 before dropping to its current price of $0.027 (~64% down from ATH).
This current price implies a market cap of approximately $221 million. Despite maintaining better price stability than competitors during the broader AI token market downturn ($VIRTUAL and $AI16Z are down ~78% and ~93% from current highs, as of mid-February), $FAI's long-term utility remains a question. Beyond briefly mentioning the potential use of the token in the Core Agent Launch Platform (documentation lacks concrete details about this), Freysa's documentation provides minimal detail about the token's role in the product's ecosystem, highlighting a potential disconnect between the project's sophisticated technical architecture and its underdeveloped economic model.
Ecosystem & Traction
Freysa has developed tangible ecosystem momentum through its public challenges and open-source technology releases, outlined below:
Genesis Acts: The project's security challenges have awarded over $103,000 across five documented phases, with Act-I ($47,148), Act-II ($12,920), Act-III ($20,843), Meme Engine ($15,632), and Encyclopedia Galactica ($6,842) creating financial bounties for identifying AI vulnerabilities. Freysa just announced the launch of Act-IV.
Esper verification framework: This verification system enables credential validation for X followers, X subscriptions, ChatGPT memberships, and Reddit karma through secure TEE attestations. Esper demonstrates a web data-focused application of the previously discussed Dual-Path Verification System that is being used outside of the Freysa ecosystem.
Reflections // 2049: NFT collection showcasing Freysa's verification framework in a creative application. Each NFT in is cryptographically proven to have been generated autonomously inside of a TEE. In the verification portal, anyone can validate the code attestation proving this.
Through these diverse applications, Freysa has accumulated valuable AI safety research data while also building a broad community of 96,794 unique token holders (as of mid-February 2025), all invested in the project’s technological advancement.
Conclusion
Freysa is establishing a verification-first approach to AI, where trust is backed by cryptographic proofs rather than institutional reputation. By subjecting its systems to financially-incentivized attacks, the project is turning theoretical security concepts into a practical, hardened infrastructure. In the creator’s own words:
While challenges pertaining to execution and economic viability remain, Freysa's iterative approach is addressing the critical trust problem in AI. As autonomous systems become increasingly embedded in financial, governance, and communication infrastructure, the project's verification-centric model offers a compelling alternative to centralized control.
Thanks for reading! Feel free to reach out on X @OnchainLu