AI-powered Ethereum news curation, verification & distribution using decentralized EigenLayer AVS. Reviving 'Week in Ethereum News' with AI agents and blockchain-powered trust.
Prize Pool
Prize Pool
Project Goal:
The primary goal of the Week in Ethereum News AI Edition project is to create a next-generation, AI-powered newsletter that continues the legacy of the original "Week in Ethereum News" while
addressing the critical need for trust and transparency in AI-generated content. We aim to achieve this by implementing Verifiable Agent Prompts using EigenLayer's Autonomous Verifiable
Services (AVS).
Problem Statement:
As AI agents become increasingly sophisticated and are used for content creation, concerns about their trustworthiness, potential biases, and lack of transparency are growing. In the context
of news dissemination, it is crucial to ensure that AI-generated newsletters are not only informative but also created under sound, auditable, and policy-compliant instructions. Traditional
AI systems often operate as "black boxes," making it difficult to verify their processes and outputs.
Solution Overview: Verifiable Agent Prompts
Our project addresses this challenge by introducing Verifiable Agent Prompts. We leverage EigenLayer AVS to create a system where:
• The instructions (prompts) given to our AI newsletter generation agent are explicitly defined and recorded on the Ethereum blockchain.
• A decentralized network of Agentic Operators (simulated in our Proof of Concept) automatically reviews and verifies these prompts based on predefined Verification Policies.
• The verification outcome (Approved or Rejected) is cryptographically secured and recorded on the blockchain, providing an auditable and tamper-proof record of the prompt verification
process.
• The AI newsletter generation agent is conditionally executed – it only proceeds to create the newsletter content if its prompt has been verifiably approved by the operator network.
This approach aims to build a more trustworthy and transparent AI-driven newsletter by ensuring that the AI's content generation is guided by instructions that have been verifiably reviewed
and validated by a decentralized network, enhancing user confidence and accountability.
Key Features and Components:
1 Autogen Agentic Workflow for Newsletter Generation:
• We utilize the Autogen framework to create a multi-agent system for automated newsletter creation. This system includes specialized agents such as:
• Manager Agent: The central orchestrator, responsible for planning the newsletter content, delegating tasks, and managing the overall workflow.
• Critic Agent: Reviews plans and generated content, providing feedback to ensure quality, accuracy, and completeness.
• Web Scraper Agent: Gathers relevant information from the web based on prompts and instructions, extracting data from news sources and online resources.
• Coder Agent: (Placeholder for future development) Intended for data analysis and code-assisted content generation.
• Telegram Poster Agent: Automates the distribution of the generated newsletter to a Telegram channel.
• Twitter Poster Agent: (Commented out for now) Intended for future automated posting to Twitter.
2 EigenLayer AVS Integration for Verifiable Prompts:
• We integrate with EigenLayer AVS to implement the Verifiable Agent Prompts mechanism. This involves:
• Solidity Smart Contracts (NewsletterPromptTaskManager.sol, NewsletterPromptServiceManager.sol): Deployed as an EigenLayer AVS, these contracts manage the prompt verification tasks,
record verification outcomes, and interact with the EigenLayer ecosystem.
• Aggregator (aggregator.py): An off-chain component responsible for:
• Submitting new prompt verification tasks to the AVS contract.
• Receiving and aggregating signed verdicts from Agentic Operators.
• Determining the overall verification outcome.
• Recording the outcome on the AVS contract.
• Agentic Operators (Simulated by prompt_operator.py): Represent a network of entities that participate in the AVS and perform prompt verification. In our PoC, these are simulated by
running prompt_operator.py.
• Verification Agents (within Operators): Specialized AI agents deployed by Agentic Operators. These agents automatically check if a submitted Agent Prompt adheres to predefined
Verification Policies.
3 Automated Prompt Verification by Agentic Operators:
• Instead of manual review, we introduce Agentic Operators who deploy Verification Agents.
• When a new prompt is submitted for verification, each Verification Agent automatically assesses the prompt against predefined Verification Policies (e.g., topic relevance, tone, length,
keyword usage).
• This automated policy check is implemented within the prompt_operator.py script.
• Verification Agents generate automated verdicts ("Pass" or "Fail") based on policy compliance.
4 On-Chain Recording of Verification Outcomes:
• The verdicts from Verification Agents are aggregated by the Aggregator.
• The overall verification outcome (Verified or Rejected) is recorded on the Ethereum blockchain via the AVS contract, providing a transparent and auditable record.
5 Conditional Agent Execution based on Verification:
• The core AI newsletter generation agent (manager agent) is designed to be "AVS-Prompt-Verification Aware."
• It only proceeds to generate the newsletter content if the prompt has been verifiably Approved by the AVS operator network.
• If the prompt is Rejected, the newsletter generation process is halted, ensuring that content is only created under verifiably sound instructions.
Workflow Description:
1 Newsletter Creator Defines Prompt and Policies: The newsletter creator defines the Agent Prompt and a set of Verification Policies.
2 Prompt Submission to AVS: The prompt and policies are submitted to the NewsletterPromptTaskManager contract.
3 Verification Task Creation: The AVS contract creates a new "Prompt Verification Task."
4 Agentic Operators Deploy Verification Agents: Operators deploy Verification Agents that monitor the AVS for new tasks.
5 Automated Policy Check: Verification Agents automatically analyze the submitted prompt against the Verification Policies.
6 Automated Verdict Generation: Verification Agents generate "Pass/Fail" verdicts based on policy checks.
7 Verdict Aggregation and On-Chain Recording: The Aggregator collects verdicts, aggregates them, and records the overall verification outcome (Verified/Rejected) on the AVS contract.
8 Conditional Agent Execution: The Autogen newsletter agent checks the AVS for the verification outcome. If "Verified," it proceeds with newsletter generation using the approved prompt. If
"Rejected," the process halts.
9 Newsletter Generation and Distribution: If verified, the Autogen agents generate the newsletter content, which is then distributed.
Technology Stack:
• AI Agent Framework: Autogen (for multi-agent system orchestration)
• Large Language Model (LLM): GPT-4o-mini (or similar OpenAI model)
• Blockchain Platform: Ethereum (simulated local Anvil chain for PoC)
• Autonomous Verifiable Service (AVS) Framework: EigenLayer
• Smart Contract Language: Solidity
• Off-chain Components: Python (for Aggregator, Operator Agents, and main agent workflow)
• Web Scraping Library: Scrapegraphai
• Cryptographic Libraries: Eigensdk-python (for BLS signature aggregation)
Current Project Status (Proof of Concept):
This project is currently a Proof of Concept (PoC). We have implemented the core components to demonstrate the feasibility of Verifiable Agent Prompts. Key aspects currently implemented
include:
• Modified Solidity contracts for managing prompt verification tasks.
• Aggregator component for task submission and verdict aggregation.
• Simulated Prompt Operator (prompt_operator.py) with basic automated policy checking logic.
• Integration with a simplified Autogen workflow in agents.py to submit prompts for verification and conditionally execute the newsletter agent.
Future Development and Enhancements:
• More Sophisticated Verification Policies: Implement more complex and nuanced policies, potentially using more advanced NLP techniques for policy evaluation within Verification Agents.
• Diverse Verification Models: Explore using a variety of AI models within Verification Agents to increase robustness and reduce bias in the verification process.
• Verifiable Tool Usage Logging and Authorization: Extend the system to verifiably log and control the tools and APIs used by the AI agents, further enhancing transparency and security.
• Decentralized Policy Registry: Implement a decentralized system for managing and updating Verification Policies.
• Reputation and Incentive Mechanisms for Operators: Develop a reputation system and robust economic incentives for Agentic Operators to ensure high-quality and honest prompt verification
services within a real EigenLayer deployment.
• Enhanced User Interface and Workflow: Create a user-friendly interface for newsletter creators to define prompts, policies, and monitor the verification and generation process.
Value Proposition:
The Week in Ethereum News AI Edition with Verifiable Agent Prompts offers significant value by:
• Building Trust in AI-Generated News: Addresses growing concerns about AI trustworthiness by providing verifiable assurance that the newsletter content is created under reviewed and approved
instructions.
• Enhancing Transparency: Makes the AI content generation process more transparent and auditable, allowing users to understand the controls and policies governing the AI.
• Promoting Ethical AI Development: Provides a framework for incorporating ethical considerations and policy enforcement into AI agent workflows, particularly in sensitive domains like news
and information dissemination.
• Demonstrating the Power of EigenLayer AVS: Showcases a practical application of EigenLayer AVS for building verifiable and trustworthy AI systems, highlighting the potential of EigenLayer
for securing and enhancing AI applications on Ethereum.
Target Audience:
This project is relevant to:
• Ethereum Community: Provides a valuable service by continuing the tradition of "Week in Ethereum News" in an innovative, AI-driven, and verifiable way.
• News Consumers: Offers a more trustworthy and transparent source of information about the Ethereum ecosystem.
• AI and Blockchain Developers: Serves as a practical example and a potential framework for building verifiable and accountable AI systems using EigenLayer AVS.
• Researchers and Academics: Provides a case study for exploring the intersection of AI, blockchain, and verifiable computation.
Technology Stack - Layer by Layer:
1 Smart Contracts (Solidity Layer - On-Chain Verifiability):
• Language: Solidity (version ^0.8.9) - Chosen as the standard language for smart contract development on Ethereum and for EigenLayer AVSs.
• Framework/Libraries:
• Foundry: Used as our smart contract development toolchain. Foundry provides:
• Forge: For building, testing, and deploying Solidity contracts. Its speed and testing capabilities were crucial for rapid iteration during development.
• Anvil: For local Ethereum node emulation. Anvil's speed and ease of setup were essential for local testing and development.
• OpenZeppelin Contracts Upgradeable: We leveraged OpenZeppelin's upgradeable contracts library (@openzeppelin-upgrades/contracts) for contract initialization and upgradeability
patterns. While upgradeability isn't strictly necessary for this PoC, using these libraries provides a more robust and standard contract structure.
• EigenLayer Middleware Contracts (@eigenlayer-middleware): We directly utilized key contracts and interfaces from the EigenLayer middleware library, specifically:
• @eigenlayer-middleware/src/interfaces/IServiceManager.sol: Interface for service managers.
• @eigenlayer-middleware/src/BLSApkRegistry.sol, @eigenlayer-middleware/src/RegistryCoordinator.sol, @eigenlayer-middleware/src/BLSSignatureChecker.sol,
@eigenlayer-middleware/src/OperatorStateRetriever.sol: Core EigenLayer components for operator registration, stake retrieval, and BLS signature verification. These were essential
for building our AVS and leveraging EigenLayer's verifiable infrastructure.
• @eigenlayer-middleware/src/libraries/BN254.sol: Solidity library for BN254 curve operations, necessary for BLS signature verification.
• EigenLayer Contracts (@eigenlayer/contracts): Imported @eigenlayer/contracts/permissions/Pausable.sol for implementing pausable functionality in our contracts, a standard pattern in
EigenLayer AVSs.
• Forge-std: Used forge-std/console.sol for debugging and logging within Solidity tests and contracts (though console.log was mostly commented out in the final version).
2 Off-Chain Components (Python Layer - Agent Workflow, Aggregation, Operator Simulation):
• Language: Python 3.9+ - Chosen for its rich ecosystem of AI/ML libraries (Autogen, OpenAI API), web scraping tools, and ease of use for scripting and rapid prototyping.
• AI Agent Framework: Autogen (version 0.7.3) - A critical partner technology. Autogen provided the multi-agent abstraction and framework that allowed us to easily create and orchestrate
the complex interactions between our specialized AI agents (Manager, Critic, Web Scraper, etc.). Its conversational agent paradigm and group chat management were key to building the
Society of Mind workflow.
• LLM Interface: OpenAI Python Library (openai version 1.61.1) - Used to interface with OpenAI's models (specifically gpt-4o-mini - though in practice, we likely used gpt-4o or
gpt-4o-preview for better performance). Access to a powerful LLM like GPT-4o was essential for the agents' reasoning, content generation, and policy checking capabilities.
• Web Scraping: Scrapegraphai (version 1.37.1) - Another key partner technology. Scrapegraphai significantly simplified the complex task of web scraping. Its AI-powered extraction
capabilities allowed us to reliably extract structured information from diverse web pages with minimal coding effort for the agent logic.
• BLS Signature Aggregation & Ethereum Interaction: Eigensdk-python (custom version based on git+https://github.com/zellular-xyz/eigensdk-python@2736dafd95a0898180e25e86c7756ae7dc9c4e88) -
Essential for EigenLayer integration. This Python SDK provided:
• BLS Signature Functionality: For generating and aggregating BLS signatures, which is core to EigenLayer's security model.
• Web3.py Integration: For interacting with Ethereum smart contracts (deploying contracts, calling functions, reading events).
• Client Libraries for EigenLayer Contracts: Pre-built clients and utilities for interacting with EigenLayer's core contracts (Registry Coordinator, Operator State Retriever, etc.),
simplifying the integration process.
• Web3.py (version 7.4.0): While Eigensdk-python wraps Web3.py, we also directly used Web3.py for some lower-level Ethereum interactions, especially in the aggregator and operator
scripts.
• Flask (version 3.0.3): Used to create a lightweight Flask web server in aggregator.py. This server provides a simple API endpoint (/signature) for operators to submit their signatures to
the aggregator via HTTP POST requests.
• Requests (version 2.32.3): Used for making HTTP requests from prompt_operator.py to the aggregator's Flask server to submit signatures.
• PyYAML (version 6.0.1): Used for parsing YAML configuration files (config-files/aggregator.yaml, config-files/operator.anvil.yaml).
• Python-dotenv (version 1.0.1): Used for loading environment variables from .env files, for managing API keys and configuration parameters securely.
• Logging (Python's logging module): Used extensively throughout the Python scripts for logging events, debugging, and monitoring the system's operation.
• Threading (Python's threading module): Used in aggregator.py to run the signature submission loop and the Flask server concurrently in separate threads.
• Other Libraries: Standard Python libraries like os, json, time, dataclasses, typing, yaml, requests, web3, eth_abi, eth_account, flask were used for various utility functions, data
handling, and API interactions.
System Architecture - How Components are Pieced Together:
1 Smart Contracts (AVS Core):
• NewsletterPromptTaskManager.sol and NewsletterPromptServiceManager.sol are deployed to a local Anvil chain (simulating Ethereum).
• These contracts form the core of our EigenLayer AVS, managing tasks, recording verification outcomes, and interacting with EigenLayer's registry.
• They inherit from EigenLayer middleware contracts (BLSSignatureChecker, OperatorStateRetriever, ServiceManagerBase) to leverage EigenLayer's functionalities.
2 Aggregator (Off-Chain Orchestration & Aggregation):
• aggregator.py acts as the central off-chain component that bridges the AI agent workflow and the on-chain AVS contracts.
• Task Submission: The Aggregator class in aggregator.py has functions (like send_new_manager_instructions_verification_task) to initiate new prompt verification tasks by calling the
createNewTask function on the NewsletterPromptTaskManager contract.
• Signature Reception (Flask Server): The Flask server within aggregator.py listens for incoming HTTP POST requests at the /signature endpoint. Operators (via prompt_operator.py) send
their signed verdicts to this endpoint.
• BLS Signature Aggregation: The BlsAggregationService (from eigensdk-python, initialized within aggregator.py) handles the aggregation of BLS signatures received from operators.
• Transaction Submission (to AVS Contract): While in this PoC, the aggregator primarily receives signatures, in a more complete AVS implementation, the aggregator would also submit
aggregated signatures and verification outcomes back to the AVS contract (though this part is simplified in our current PoC).
• Configuration Loading: aggregator.py loads configuration parameters (contract addresses, keys, RPC URLs) from config-files/aggregator.yaml.
3 Prompt Operator (Simulated EigenLayer Operator):
• prompt_operator.py simulates an EigenLayer operator. In a real EigenLayer setup, this would be run by entities restaking ETH and participating in the AVS.
• Event Monitoring: prompt_operator.py uses Web3.py event filters to monitor the NewsletterPromptTaskManager contract for NewTaskCreated events.
• Task Processing (process_task_event): When a new task event is detected, the process_task_event function is triggered. This function:
• Retrieves the agentPrompt from the event data.
• Performs automated policy checks on the prompt (in our PoC, these are basic length and keyword checks).
• Determines verification_status (Approve/Reject) based on policy checks.
• Generates a BLS signature for the verification_status using the operator's BLS private key (loaded from tests/keys/test.bls.key.json).
• Sends the verification_status, signature, and task ID to the aggregator's Flask server via an HTTP POST request to /signature.
• Key Loading & Registration: prompt_operator.py loads operator ECDSA and BLS keys from files and includes logic to register the operator with EigenLayer and the AVS (though registration
is often skipped or mocked in local testing).
• Configuration Loading: prompt_operator.py loads configuration parameters from config-files/operator.anvil.yaml.
4 Autogen Agents (agents.py - Newsletter Workflow):
• agents.py contains the main Autogen workflow for newsletter generation.
• Society of Mind Agent Setup: It defines and orchestrates a Society of Mind agent group, including manager, critic, web-scraper, coder, and telegram-poster agents.
• Prompt Submission & Verification Flow (interact_freely_with_user): The interact_freely_with_user function in agents.py implements the core integration with the AVS:
• It initializes the Aggregator client.
• It calls aggregator.send_new_manager_instructions_verification_task() to submit the manager_instructions prompt to the AVS for verification.
• It then polls (a hacky but simple PoC approach) for a certain duration, waiting for the prompt to be (assumed to be) verified by operators.
• Conditional Agent Initialization: Only if the prompt verification is (assumed to be) successful, it proceeds to create and initialize the SocietyOfMindAgent and start the chat
interface.
• If verification is (assumed to be) rejected, it halts the agent initialization.
• Agent Definitions & System Messages: agents.py defines the system messages and roles for each Autogen agent, outlining their responsibilities in the newsletter creation process.
• Tool Integration: It integrates the custom tools (TelegramPostAgent, TwitterPostAgent, WebScraperAgent) into the agent workflow.
Partner Technologies - Benefits:
• EigenLayer AVS: Fundamental to Verifiability. EigenLayer AVS provides the core infrastructure for building verifiable services on Ethereum. It enabled us to:
• Decentralize Trust: Distribute trust in the prompt verification process across a network of operators, rather than relying on a single entity.
• Cryptographic Security: Leverage Ethereum's cryptoeconomic security to make the verification process tamper-proof and accountable through BLS signatures and on-chain recording.
• Build a Verifiable Service: Create an AVS (NewsletterPromptTaskManager) that can be permissionlessly accessed and utilized by our AI newsletter application.
• Leverage Existing Middleware: The EigenLayer middleware libraries (eigensdk-python, @eigenlayer-middleware) significantly simplified the integration with EigenLayer's complex
cryptographic and on-chain components, saving us substantial development time and effort.
• Autogen: Agentic Workflow Orchestration. Autogen was crucial for building the sophisticated multi-agent workflow for newsletter generation. It provided:
• Multi-Agent Abstraction: Simplified the creation and management of multiple interacting AI agents.
• Conversational Agent Paradigm: Enabled natural and flexible communication and collaboration between agents.
• Group Chat Management: Facilitated the orchestration of the Society of Mind agent group and managed message flow.
• Tool Integration: Made it easy to integrate custom tools (like our WebScraperAgent, TelegramPostAgent) into the agent workflow.
• Rapid Prototyping: Autogen's ease of use and high-level abstractions allowed us to rapidly prototype and iterate on the agentic workflow for the newsletter.
Notable "Hacky" or Simplified Implementation Details (for PoC):
• Polling for Verification Status in agents.py: Instead of implementing a more robust event listener to react to on-chain verification events, we used a simple time.sleep() and polling loop
in agents.py to check for verification status. This is inefficient and not suitable for a production system, but it was a quick way to demonstrate the basic workflow in the PoC. A proper
implementation would use Web3.py event filters to asynchronously listen for PromptVerified or PromptRejected events from the AVS contract.
• Manual Operator Input in prompt_operator.py (Initially): In the very first iteration of the PoC, the prompt_operator.py script required manual operator input ("yes/no") to approve or reject
prompts. This was a simplification to demonstrate the basic signature submission flow, but it was quickly replaced with automated policy checks to make the operator side more agentic.
• Basic Policy Checks in prompt_operator.py: The policy checks implemented in prompt_operator.py are very rudimentary (length and keyword checks). A more sophisticated system would use more
advanced NLP techniques and potentially even LLMs within the Verification Agents to perform more nuanced and comprehensive policy evaluations.
• Assumed Verification Success (in agents.py PoC Polling): In the agents.py polling loop, we simply assume that the prompt is verified after waiting for a certain time (verification_status =
True). A real application would need to query the AVS contract to verifiably confirm the verification outcome and aggregated signature before proceeding.
• Hardcoded Configurations and Paths: Configuration parameters (contract addresses, key file paths, RPC URLs) are often hardcoded or loaded from simple YAML files. A production system would
require more robust configuration management, potentially using environment variables, secure key vaults, and dynamic configuration loading.
• Simplified Error Handling: Error handling in the PoC is basic. A production system would need much more comprehensive error handling, logging, and monitoring to ensure robustness and
reliability.
• Lack of Full EigenLayer Deployment: The PoC is run on a local Anvil chain and simulates EigenLayer operators. A full deployment on a real EigenLayer testnet or mainnet would involve
additional complexities related to operator registration, staking, reward distribution, and slashing mechanisms, which are not fully explored in this basic PoC.
Despite these simplifications and "hacky" elements, the Week in Ethereum News AI Edition PoC successfully demonstrates the core concept of Verifiable Agent Prompts using EigenLayer AVS and
showcases the potential for building more trustworthy and transparent AI-driven applications on blockchain.