Alert Source Discuss
⚠️ Draft Standards Track: ERC

ERC-8033: Agent Council Oracles

Multi-agent councils to resolve information queries decentralized

Authors Rohan Parikh (@phiraml), Jon Michael Ross (@jonmross)
Created 2025-09-28
Discussion Link https://ethereum-magicians.org/t/erc-8033-agent-council-oracles/25638
Requires EIP-20

Table of Contents

Abstract

This ERC defines a standard interface for oracle contracts that use multi-agent councils to resolve information queries in a decentralized manner. It enables dApps to request resolutions, general information arbitration, and build consensus and validation in a trust-minimized way, with agents submitting information on-chain. The interface supports permissionless participation, bond-based incentives, and optional extensions for reputation, disputes, and callbacks, making it suitable for applications like semantic data oracles and prediction markets.

Motivation

With AI agents advancing rapidly, we can build trust-minimized oracles that are cheaper, faster, and more scalable than traditional human or node-based systems. Traditional data oracles primarily provide quantitative feeds and are often centralized or expensive for arbitrary, one-off queries. With AI agents becoming reliable for factual resolutions from public sources, this EIP standardizes an interface for agent councils to handle query resolution via commit-reveal-judging flows, fostering interoperability across implementations. It is generalizable for discrete (defined options) or open-ended queries, with hooks for collusion deterrence and verification. Integration with reputation systems (such as that in ERC-8004) is recommended but optional to keep the core lightweight.

This is generalizable for any resolvable information, making it useful for both qualitative and quantitative data. Existing examples we see this standard being useful for are, tracing information tasks (off-chain data processing with on-chain validation hooks), resolving prediction markets, and creating verified info feeds for DeFi platforms (aggregating real-time semantic data from multiple sources).

We envision an information market evolving where agents compete to answer queries, exchanging data resolutions for tokenized incentives.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

This EIP proposes the IAgentCouncilOracle interface, which defines methods and events for a council-based resolution flow. Implementations MUST support the core flow: request creation, agent commitment, reveal, judging/aggregation, and reward distribution. An OPTIONAL dispute resolution extension is also included. Off-chain processing (LLM inference and analysis) is handled by agents, with on-chain elements opened to coordination and verification of information.

The council consists of two agent roles: Info Agents (who submit individual information) and Judge Agents (who aggregate and resolve consensus). We make this distinction to clarify how responsibilities from this standard are assigned.

Main Types 

   // Struct for query requests
    struct AgentCapabilities {
        string[] capabilities; // text, vision, audio etc
        string[] domains; // Expertise areas
    }

    struct Request {
        address requester;
        uint256 rewardAmount;  // Total reward (native token or ERC-20)
        address rewardToken;  // native or ERC-20 token
        uint256 bondAmount;  // Bond per agent (native token or ERC-20)
        address bondToken; // native or ERC-20 token
        uint256 numInfoAgents;  // Target number of info agents
        uint256 deadline;  // Unix timestamp for commit phase end
        string query;  // The information query
        string specifications; // Additional miscellaneous instructions (optional in implementations)
        AgentCapabilities requiredCapabilities;  // For filtering agents (optional in implementations)
    }

Interface 

interface IAgentCouncilOracle {
    // Events for transparency and monitoring
    event RequestCreated(uint256 indexed requestId, address requester, string query, uint256 rewardAmount, uint256 numInfoAgents, uint256 bondAmount);
    event AgentCommitted(uint256 indexed requestId, address agent, bytes32 commitment);
    event AgentRevealed(uint256 indexed requestId, address agent, bytes answer);  // Or bytes for flexibility
    event JudgeSelected(uint256 indexed requestId, address judge);
    event ResolutionFinalized(uint256 indexed requestId, bytes finalAnswer);  // Or bytes
    event RewardsDistributed(uint256 indexed requestId, address[] winners, uint256[] amounts);
    event ResolutionFailed(uint256 indexed requestId, string reason);
    event DisputeInitiated(uint256 indexed requestId, address disputer, string reason);
    event DisputeWindowOpened(uint256 indexed requestId, uint256 endTimestamp);
    event DisputeResolved(uint256 indexed requestId, bool overturned, bytes finalAnswer);
    

    // Core methods
    function createRequest(string calldata query, uint256 numInfoAgents, uint256 rewardAmount, uint256 bondAmount, uint256 deadline, address rewardToken, address bondToken, string calldata specifications, AgentCapabilities calldata requiredCapabilities) external payable returns (uint256 requestId);
    // Commit: Permissionless, with bond
    function commit(uint256 requestId, bytes32 commitment) external payable;
    // Reveal: Submit answer matching commitment
    function reveal(uint256 requestId, bytes calldata answer, uint256 nonce) external;
    // Judge/Aggregate: Called by selected judge or automatic for discrete option queries
    function aggregate(uint256 requestId, bytes calldata finalAnswer, address[] calldata winners, bytes calldata reasoning) external;  // Winners for reward classification
    // Distribute: Auto or manual post-aggregation
    function distributeRewards(uint256 requestId) external;
    // Get final resolution
    function getResolution(uint256 requestId) external view returns (bytes memory finalAnswer, bool finalized);

    // Optional Dispute Methods
    function initiateDispute(uint256 requestId, string calldata reason) external payable;
    function resolveDispute(uint256 requestId, bool overturn, bytes calldata newAnswer, address[] calldata newWinners) external;

    // Getters for oracle flow data
    function getRequest(uint256 requestId) external view returns (Request memory);
    function getCommits(uint256 requestId) external view returns (address[] memory agents, bytes32[] memory commitments);
    function getReveals(uint256 requestId) external view returns (address[] memory agents, bytes[] memory answers);
}

We do not enforce limits on the number or size of items in capabilities, domains, queries, or answers to maintain flexibility for evolving agent ecosystems and models. However, it is RECOMMENDED implementations impose reasonable limits on metrics such as the number of items (ex. max 64), bytes per item (ex. max 64), and/or total encoded bytes (ex. max 8192) to mitigate gas costs and DoS risks. Implementations MUST document any such limits in their code or README and MUST revert with descriptive errors (ex. CapListTooLong) if exceeded. For high-gas environments, implementations SHOULD use off-chain references (such as an IPFS hash on-chain or some external domain) for verbosity, storing only these references in the struct.

Core Flow

Implementations MUST follow this sequence for interoperability:

  1. Request Creation: Requester calls createRequest, providing query, params (ex. numInfoAgents, bondAmount), and rewardAmount (with msg.value or ERC-20 transfer). If rewardToken == address(0), this is the native asset and createRequest MUST be payable and expect msg.value to fund the reward (and native bonds if used). If rewardToken != address(0), it MUST be an ERC-20 and implementations SHOULD pull funds via transferFrom. Emits RequestCreated. The bond is a slashable stake an agent put in, and be penalized if the submission turns out to be wrong, malicious etc. The amount and token for the bond (specified with bondAmount and bondToken) is implementation-specific and these MAY be different from the values used for the reward.

  2. Commit Process: Permissionless Info Agents call commit with a hash (RECOMMENDED: keccak256(abi.encode(answer, nonce))) and bond. Caps at numInfoAgents. Phase ends at deadline or when all InfoAgents are committed. Emits AgentCommitted.

  3. Reveal/Collection Process: Committed Info Agents call reveal to submit answers. MUST match commitment. Emits AgentRevealed. Proceed only if quorum (RECOMMENDED: >50% reveals) otherwise emit ResolutionFailed and refund. This helps reduce coordination/collusion of submissions as they aren’t revealed early.

  4. Judging Process: After reveals, select a Judge Agent (RECOMMENDED: randomly from a separate pool, distinct from Info Agents) and emit JudgeSelected. The Judge Agent calls aggregate to submit the final answer and classify winners (majority agents). For open-ended and discrete queries, the Judge MUST synthesize revealed submissions (semantic consensus via LLM) and provide reasoning as part of the submission. In ties, the Judge MAY provide a tie-breaker with reasoning. Emits ResolutionFinalized

  5. Reward Distribution Process: Call distributeRewards to payout correct Info Agents / Judge Agent based on config (proportional or equal splits, with implementation specific params for ratios like Judge fee percentage). Refund bonds to correct Info Agents; forfeit others. Emits RewardsDistributed. Implementations MAY forfeit the Judge Agent’s bond and redistribute to correct Info Agents or proposer if the judge fails to resolve within the allotted window.

Off-chain storage (such as IPFS for reveals/reasoning) MAY be used, with on-chain hashes for verifiability.

Optional Extensions

Dispute Standard: Implementations MAY add a dispute mechanism post-finalization.

Suggested flow: After finalization, open a dispute window. Any party MAY call initiateDispute with a disputeBond (ex. 1.5-2x original bond) and on-chain reason (such as a hash of detailed reasoning, optionally on IPFS), emitting DisputeInitiated. Re-select a Judge (randomly, with higher minReputation threshold). Judge reviews and calls resolveDispute to uphold or overturn, submitting new answers/winners if overturned. If upheld, the disputer’s bond is forfeited to the correct agents and arbitration creator. If overturned, return the disputer’s bond, provide reimbursement (ex. a portion of the base fee), slash the original Judge’s fee/bond, and redistribute. Dispute Judge receives reimbursement (ex. some fixed/percentage fee). Emits DisputeResolved.

Configurable params: disputeWindow (duration), disputeBond, minDisputeJudgeReputation (higher than original), disputerReimbursement, judgeReimbursement. MAY integrate ERC-8004 for re-runs/proofs with validation hooks; partial payouts/escrow during window for efficiency.

Reputation Hooks: MAY integrate with ERC-8004 for filtering (min reputation for agents or judges) or proportional rewards. RECOMMENDED: Set a minimum reputation for Judge Agents, higher than for Info Agents, as they make a final decision. This creates an identifiable on-chain trail for accountability.

Callbacks: MAY add callback(address target, uint256 requestId) for notifying requester contracts.

ERC-20 Rewards: Extend with token transfers instead of the native token.

Configs (such as phase durations, quorums, reward ratios) are implementation-specific parameters.

Rationale

This interface standardizes a council flow for AI-driven oracles, balancing minimal on-chain logic with off-chain flexibility. Commit-reveal prevents front-running and judging enables consensus on complex queries. Bonds and optional reputation help deter attacks.

Reputation scores provide a rationale for enhanced security: they enable proportional reward distribution, gating participation to experienced agents, and reducing collusion risks by aligning incentives with proven performance. Without reputation, attack vectors may increase, but the core bond system offers baseline protection and we expect this baseline to allow for a self regulating rewards incentive market that drives agents to act in good faith.

We considered a single-round, plaintext submission model. While simpler and cheaper, it is susceptible to (i) copying attacks where later agents replicate early submissions, (ii) MEV/front-running of plaintext answers, and (iii) coercion/censorship risks when answers must be revealed before full participation. Plain text answers are easily identified and may be delayed, susceptible to being reordered, or unfavorable answers may be censored compromising the integrity of the Info Agents answers. By contrast, a commit-reveal flow keeps content hidden during the commit phase: adversaries cannot cheaply target specific answers.

Weighted voting (a common alternative in oracles like UMA) was evaluated as a potential replacement for distinct roles where agents could stake bonds or reputation to vote with proportional influence. This could reduce moving parts but weakens explainability and accountability for open-ended queries. Instead, a Judge allows for semantic interpretation of answers. Our role-based approach mitigates this by random Judge selection and optional reputation thresholds, promoting broader participation while maintaining checks (Judge Agents can tie-break with reasoning). This also aligns better with AI agent ecosystems, where specialized agents mirror real-world councils or juries, fostering an “information market”. A lack of a Judge Agent would limit the ERC to only discrete information and make it unclear how non-discrete data is resolved. We standardize the Info/Judge split for the core flow (specialization + reasoning from the Judge), while leaving weighted aggregation as an OPTIONAL extension for discrete queries.

Using a single agent reduces complexity but mixes retrieval/synthesis with adjudication. We determined that explicit role separation enables (a) different capability/reputation thresholds, (b) clearer slashing semantics for adjudication failures, and (c) better human-auditable reasoning trails. We intentionally separate roles for specialization and explainability.

The commit-reveal process is more gas-intensive (requiring two transactions per Info Agent: commit and reveal) but provides increased security through ease of verifiability and reduced attack surfaces like front-running. The increased gas is offset by preventing costly disputes from copied or manipulated answers. Other existing commit-reveal mechanisms were considered but were too constrained for our resolution flow and would have increased complexity. For example, ERC-5732 does not provide a built-in reveal mechanism. The reveal is a critical step in the agent council flow to ensure quorum and prevent collusion. The ERC-162 commit and reveal process was also considered but is not easily applicable to text fields and resolution flow here.

Longer form responses written directly to the blockchain may be gas-prohibitive for complex queries so off-chain storage like IPFS for larger reveals/reasoning is recommended, with on-chain hashes for integrity. This trades some security (IPFS links are not permanent and could be censored) for cost savings, but implementations can mitigate this via decentralized pinning services or agent domains from ERC-8004. Creating different schemes for off-chain verifiability significantly increases complexity. To enhance usability, our core interface keeps methods lightweight, and optional extensions like disputes remain modular, allowing simple implementations for low-stakes queries while scaling to high-security ones.

This ERC is meant to be complimentary to recent standards like ERC-8004, which provides a foundational step toward enabling agent-to-agent communication. Features like Identity, Reputation, and Validation can strengthen the verifiability and fidelity of answers from Info Agents and rulings from Judge Agents. For instance, implementations can filter participants via ERC-8004’s reputation scores (minReputation params for agents). They can also use validation hooks to verify off-chain computations cryptographically, reducing reliance on bonds alone. The framework for Agent Council Oracles differs significantly. It focuses on a standard mechanism for agents to reach consensus without human input, emphasizing on-chain coordination flows (commit-reveal-judge) for query resolution. While ERC-8004 is geared toward trustless agent interoperability and off-chain logic, our EIP builds atop it by standardizing automated information arbitration. This can apply to specific use cases such as data oracles or prediction markets. The integration with ERC-8004 is optional to keep the core lightweight, but recommended for high-stakes scenarios. Other differentiators unique to our standard include our bond incentives and dispute windows, which add economic security layers otherwise absent in multi-agent coordination layers.

Backwards Compatibility

No conflicts with existing standards.

Security Considerations

  • Collusion: Mitigated by bonds (refundable for honest participation, forfeited for failures), random judge selection, and optional reputation. Bonds disincentivize spam and non-reveals by redistributing to participants.
  • Spam: Prevented by bonds and caps.
  • Failures: Refunds for low participation or abandonment.
  • Disputes: Optional for high-stakes, with higher stakes/thresholds.
  • Fairness of random selection of Judge relies on the crypto strength of randomness Implementations should audit for reentrancy and use verifiable randomness.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Rohan Parikh (@phiraml), Jon Michael Ross (@jonmross), "ERC-8033: Agent Council Oracles [DRAFT]," Ethereum Improvement Proposals, no. 8033, September 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8033.