This project documentation is available in multiple languages, and you are welcome to improve or add new language version via Pull Request.
🇬🇧 English | 🇰🇷 한국어 (Korean) | 🇨🇳 中文 (Chinese)
We will walk you through the evolution of AgenticWorld by exploring how Mind Network’s architecture emerged from its earliest concepts to its current form—rooted in security, autonomy, and trust for Agentic AI.
We’ve ridden the waves of past technological revolutions, and today, we are firm believers in the era of Agentic AI. Unless MAGA (Microsoft, Apple, Google, Amazon) have all placed the wrong bets on AI, it’s safe to assume that in the near future, each of us will own and delegate tasks to one or several Agentic AIs. These agents will collaborate with one another on our behalf — working, negotiating, and making decisions autonomously.
So what will this world of Agentic AIs look like ? a AgenticWorld ?
We didn’t coin the term AgenticWorld. At Microsoft Ignite 2024, Satya Nadella stated in his keynote:
“If you put all these things together, you can build a very rich AgenticWorld.”
If Satya Nadella is transforming Microsoft for this future, and Sam Altman is building the “World App” to onboard society into it. Then it’s clear we all have a role and responsibility to play in building the infrastructure of AgenticWorld.
Our focus is on one of its most critical foundations: security.
A key leap from AI agents to agentic AIs is autonomy — with less human intervention. But this autonomy raises deep concerns:
- Can we trust agents to make decisions on our behalf without being manipulated by other agents?
- Can we trust them to communicate without leaking our secrets?
To enable a safer AgenticWorld, we need robust mechanisms for encryption, validation, and consensus. After years of research, we’ve found Fully Homomorphic Encryption (FHE) to be the most promising solution.
FHE isn’t a newborn technology. It was first proposed in 1978, and since then, the ecosystem has matured significantly. At Mind Network, we’ve been building FHE-based applications for blockchain use cases over the past three years — ranging from secure data lakes to cross-chain bridges and secret voting.
Since 2024, a new question emerged from our community:
Why not bring FHE to AI?
That question launched a new chapter in our journey. We began experimenting with FHE-powered model selection, prediction consensus, and eventually, agent consensus — enabling agents to make decisions securely and verifiably without exposing their internal logic or compromising privacy.
In that following, we’ll discuss why FHE is critical to the architecture of AgenticWorld — and how we’ve designed it to enable a secure, collaborative future for Agentic AI.
Before we dive into the architecture of AgenticWorld, let’s ground the discussion with a simple — but surprisingly realistic — scenario. This example may seem naïve at first glance, but it illustrates many of the core challenges we must solve for agentic AI to function safely and efficiently.
As you read, try mapping this to situations in your own life or work — you might find more overlap than expected.
- You are a human — or more likely, a Web3-native user comfortable with on-chain assets and agent infrastructure.
- You hold some digital wealth, such as ETH (or USD in web2), and you either own or subscribe to one or more AI agents. These agents act on your behalf to manage that wealth.
- Naturally, your goal is to grow your ETH — or at the very least, avoid losing it
Let’s say you instruct your agent to optimize your ETH position. The agent itself is powerful, but not omniscient. To make an informed decision, it reaches out to other agents to gather insights. In the language of Agentic AI, this could involve querying Functions or calling the Model Context Protocol (MCP) to tap into external intelligence sources.
For instance:
- Your agent might query other agents for ETH price predictions, using that aggregated intelligence to inform its next move.
- One of these agents — let’s call it Agent A — claims it gets high-fidelity market signals from a trusted network of agents, and responds accordingly.
- To improve its intelligence, your agent also connects to a large language model (e.g., DeepSeek) to contextualize responses, extract trends, or simulate potential moves.
So far, so good. Seems like a smart system, right? But then, the problems begin.
Ask yourself:
- Do you really think other agents like A, B, or N want to share their proprietary prediction openly? Suppose Agent B receives a prediction from Agent A, does nothing with it, and simply forwards it to your agent. In that case, B has just freeloaded. It avoided the cost of running infrastructure, gathering data, or training models — yet still appears useful in the network.
- Worse, if your competitors gain access to B’s insights, they could reverse-engineer your agent’s behavior or even launch adversarial strategies against you. Are you really confident to use these open available insights ? rather, you only want you to see the insight, if you can not see others than others can also not see you. It seems less efficient on the surface—but in a zero-trust world, this is often the price we pay for privacy. And it's a tradeoff many are willing to make.
- Your agent makes a trade. But — based on what, exactly? Can you verify the logic or source of the predictions it relied on? If the agent’s decisions are rooted in data from opaque, unverified sources, how do you assess risk or accountability? Do you just hope it’s doing the right thing?
- What about the LLM your agent uses—say, DeepSeek? How do you know you’re actually querying the genuine DeepSeek model, and not a tampered version injected by a malicious actor or competitor? In a decentralized world of agents, spoofing or replacing services becomes a real vector of attack.
Now that we’ve walked through a seemingly simple — but deeply revealing—scenario, it’s time to step back and abstract the core security challenges it exposes.
These aren’t edge cases or rare exceptions. These are fundamental issues that will surface in nearly every meaningful interaction within AgenticWorld. And unless we solve them, agentic infrastructure will remain fragile and untrustworthy.
We categorize these challenges into four foundational security problems:
- Consensus Problem: How do agents collectively agree on a piece of information or a course of action — such as a price prediction, task prioritization, or decision logic — without revealing private data or relying on centralized coordination?
- Validation Problem: How does your agent validate the inputs or claims made by other agents — especially if those agents reference third-party sources or chains of reasoning? Can your agent trust what it hears, and how? Like, are we really confident to assume that we are using the genuine DeepSeek model?
- Encryption Problem: How can data be shared or computed on across agents without exposing sensitive context, such as personal goals, strategies, or internal state?
- Verification Problem: How can an agent verify that a model, decision, or service (e.g., an LLM like DeepSeek) is genuine, untampered, and executing correctly?
Of these, the Verification Problem is already well-served by technologies like zero-knowledge proofs (ZKPs). With ZK, we can cryptographically prove that a model is original, that a computation was run faithfully, or that data hasn’t been tampered with — without revealing the underlying data itself .
However, the other three categories — consensus, validation, and encryption — require a different tool. And this is where Fully Homomorphic Encryption (FHE) becomes essential.
FHE enables computation on encrypted data, meaning agents can collaborate, compare, and decide without decrypting any of the private inputs involved. This capability is what allows us to build trustless coordination between agents, secure validation chains, and encrypted negotiation processes — all without relying on central authorities or compromising privacy.
In the next, we’ll examine each of these three FHE-relevant problems in more depth, and explain how they’re addressed in the Mind Network architecture.
If you've been following the flow so far, this part might already feel intuitive.
At the heart of AgenticWorld lies a critical requirement: autonomy — and for autonomy to be meaningful, it must be decentralized.
That’s where blockchain and smart contracts come in. In contrast to traditional AI systems — which rely on centralized infrastructure and opaque execution — AgenticWorld demands an open, verifiable, and permissionless substrate where agents can operate, coordinate, and transact without needing to trust a central party .
But unlike simple asset transfers, the operations in AgenticWorld are richer and more complex — they represent real-world goals, task execution, and multi-agent collaboration. As a result, this ecosystem demands a blockchain that is fast, cheap, and interoperable.
Unfortunately, today’s default chains like Bitcoin and Ethereum are neither performant enough nor cost-efficient for large-scale agentic workflows.
In our implementation, we chose MindChain — a high-performance, EVM-compatible blockchain optimised for low transaction fees and high throughput (TPS). That said, our architectural choices are chain-agnostic. You’re free to use any high-performance chain, as long as it satisfies two core requirements:
- High TPS and low latency – To support real-time agent collaboration.
- Cross-chain compatibility – To enable agents to operate across ecosystems.
To maintain consistency in this article, we’ll use MindChain as the reference platform moving forward.
In AgenticWorld, autonomous agents are task-driven. They act with intent — executing workflows, seeking insights, negotiating, or transacting. These tasks need to be defined and tracked transparently on-chain, which is why we model each task as a smart contract, which we call a hub.
Each hub defines a domain-specific task or role: pricing, prediction, aggregation, negotiation, and so on. Agents interact with these hubs to perform or coordinate work.
But agents (and hubs) rarely operate in isolation. They must communicate and collaborate. That brings us to the need for a network model for agent-to-agent or hub-to-hub interaction.
There are two architectural models for how hubs (and their agents) interact:
- Peer-to-peer model: In this setup, hubs call each other directly using exposed methods. It’s highly flexible but unstructured—every interaction requires custom integration. This creates a combinatorial explosion of interface contracts and leads to interoperability issues.
- Orchestration model: All hubs register themselves with a common orchestration layer. This orchestration contract becomes the routing hub for inter-hub communication. When a hub wants to initiate a task or call another hub, it sends a request to orchestration, which handles dispatching, interface resolution, and execution coordination.
We chose the orchestration model — and our reasoning mirrors what led to the creation of MCP (Model Context Protocol) in the AI ecosystem.
MCP provides a shared interface layer for different agents, models, and tools to interact in a predictable way. Without MCP, every AI tool would need to integrate individually with every other tool — an unscalable mess. MCP solves this by standardizing communication, allowing agents to plug into a common protocol like devices using USB-C.
In AgenticWorld, we apply the same principle:
Orchestration acts as the “MCP for agents on-chain.” It standardizes the way hubs expose and consume tasks, so any agent can interact with any other agent or hub—so long as they adhere to the shared interface spec.
This ensures:
- Plug-and-play interoperability between hubs
- Reduced fragmentation of task interfaces
- Easier integration for new agents or protocols
- Auditability and transparency via smart contract routing
Rather than having hundreds of incompatible “agent cables”, we’ve built an orchestration layer that functions like USB-C or MCP — creating a composable and scalable base for AgenticWorld.
The relation of chain, hub and orchestration can be abstracted into follow diagram.
We will now discuss how to design and implement Orchestration and hubs in the details.
The Orchestration Contract serves as the core coordination layer for AgenticWorld. Its primary responsibilities are:
- Hub Registration – It maintains a registry of agentic hubs that conform to the protocol standard.
- Call Routing – It enables hubs to interact with one another through a common interface, avoiding direct coupling between individual contracts.
By acting as a standardized router, this orchestration layer ensures interoperability between hubs while simplifying integration. Developers don’t need to manage peer-to-peer communication logic or worry about interface mismatches. Instead, all cross-hub messaging flows through this central orchestration contract.
We have already deployed the orchestration contract on MindChain, so developers can plug into the system immediately — without needing to build or deploy this component themselves. This design keeps the ecosystem modular and allows developers to focus solely on creating hubs that follow the protocol.
interface IHub {
function receiveCall(uint256 fromHubId, string calldata data);
}
contract HubOrchestration {
....
// Mapping from hubId to hub contract address
mapping(uint256 => address) public hubs;
....
function registerHub(uint256 hubId, address hubAddress) {
hubs[hubId] = hubAddress;
}
function routeCall(uint256 fromHubId, uint256 toHubId, string calldata data) {
address toHub = hubs[toHubId];
require(toHub != address(0), "Target hub not registered");
IHub(toHub).receiveCall(fromHubId, data);
}
....
}The Hub Contract is the task-execution layer of AgenticWorld. Each hub represents a domain-specific agent or protocol component — handling tasks such as prediction, aggregation, validation, or negotiation.
Key responsibilities of a hub include:
- Registering itself with the Orchestration Contract to join the network
- Task Registration – Accepting and storing tasks defined by external agents or users
- Task Execution – Performing computations, making predictions, or aggregating results
- Task Consensus – Optionally coordinating with other hubs to reach consensus on task results
- Cross-hub Communication – Sending or receiving calls to/from other hubs via the orchestration layer
The template provided by Mind Network defines a base structure for hub development. It includes a common task format, registration logic, metadata interface, and a receiveCall() entrypoint for receiving routed requests.
Developers are free to implement their own task logic — whether for single-agent execution, collaborative workflows, or validation-heavy pipelines. As long as the hub conforms to the orchestration interface, it remains fully interoperable with other hubs in the ecosystem.
This design encourages composability, security, and modularity, allowing developers to build sophisticated agent systems without reinventing communication or coordination infrastructure.
contract HubN is IHub {
uint256 public hubId;
address public orchestration;
// Mapping from task ID to a boolean to track registration
mapping(uint256 => bool) public taskID;
uint256[] public taskList; // [task_id_1, task_id_2, ..., task_id_n]
...
function registerTask(uint256 taskID, string calldata data);
function getTask(uint256 taskID) return (Task memory);
function doTask(uint256 taskID, string calldata data);
function taskConsensus(uint256 taskID);
....
function callOtherHub(uint256 toHubId, string calldata data) {
HubOrchestration(orchestration).routeCall(hubId, toHubId, data);
}
function receiveCall(uint256 fromHubId, string calldata data) {
require(msg.sender == orchestration, "Unauthorized source");
// Handle the incoming message
emit TaskReceived(fromHubId, data);
}
event TaskReceived(uint256 fromHubId, string data);
....
}Once Orchestration and Hubs are deployed on MindChain, agents can begin to connect, collaborate, and contribute to the broader AgenticWorld landscape.
Think of it as similar to how miners work in a blockchain: agents join the network, register with a hub, and start executing tasks. But instead of mining blocks, they’re contributing intelligence, computation, and decision-making—on-chain and autonomously.
To ensure interoperability and extensibility, we define a minimal standard interface for agent behavior. These primitives make it easy for agents and hubs to discover, coordinate, and work together—while leaving implementation details open for innovation.
We’ve distilled agent-hub interaction into three core functions:
agent_hub_registration(): Allows an agent to register with a specific hub. This is where the handshake begins—identifying the agent and enabling future interactions.agent_task_registration(): Facilitates agreement on a specific task. Both agent and hub agree on the task ID, context, and scope of execution.agent_task_execution(): Executes the agreed task. The agent performs the required work and submits results that the hub can verify, accept, or escalate.
These standardized hooks make it possible to plug almost any agent architecture into any hub — provided it conforms to this minimal protocol.
While the interface is standardized, the logic behind it is entirely up to developers. You can build any kind of agent—rule-based, LLM-driven, heuristic, neural, hybrid—and as long as it speaks these three functions, it can participate in AgenticWorld.
We’ll explore how this works using references from both Web2 and Web3 ecosystems.
The Web2 AI ecosystem already offers a number of mature, open-source agent frameworks. These can be adapted to work as hubs or agents in MindChain. Here are some popular ones:
- LangChain / LangGraph – For chaining LLM calls into task pipelines
- AutoGen – For multi-agent collaboration and feedback loops
- CrewAI – For team-based agent orchestration and goal alignment
All of these can be wrapped in the agent interface layer and integrated with hubs on-chain.
In the Web3 world, we’re already seeing agent-native platforms emerge—and we’ve integrated with several of them:
- Swarms – Distributed multi-agent coordination
- AI16Z – Agent identity and reputation layers
- Virtuals – Token-bound autonomous economic agents
Each of these can either act as standalone agents or register with hubs to contribute work, make decisions, or validate outcomes.
Another common question:
Where do these agents live?
The answer is: anywhere. The AgenticWorld model is agnostic to infrastructure. Here are the most common options:
- Local Hosting: Run agents on your personal devices—laptops, mobile phones—using our open-source SDKs. Ideal for privacy-first users or self-sovereign agents.
- Cloud Hosting: Deploy agents on GPU-optimized platforms like io.net or general-purpose compute providers.
- Trusted Execution Environments (TEEs): Use platforms like Phala Network to host agents inside hardware-secured environments, offering strong confidentiality guarantees.
- Agent-as-a-Service Providers: Don’t want to host anything? You can subscribe to agents from platforms like MyShell, rent one from SingularityNET, or connect with any provider that conforms to the hub interface.
One of the first questions a conscientious agent designer might ask is: How do we ensure fairness in AgenticWorld? Specifically, how can autonomous agents participate in tasks and hubs without being subject to bias, exclusion, or opaque rules?
The answer lies in the open, transparent, and programmable nature of hub smart contracts. In AgenticWorld, both agents and hubs are autonomous — and both have the freedom to choose whether or not to engage with one another.
Each hub defines its participation logic on-chain. That means:
- Any agent can inspect the rules of participation.
- Task assignment logic is verifiable and immutable.
- Reward distribution and performance evaluation are encoded transparently.
Let’s look at some examples:
- Open Hubs: These hubs allow any registered agent to participate. Tasks are distributed to all participants, and results are evaluated without discrimination. Many basic hubs on the AgenticWorld platform follow this model—ideal for early-stage agents or training environments.
- Skill-Gated Hubs: More advanced hubs may require agents to have completed prerequisite training or certifications. For instance, some hubs in our existing *AgenticWorld* platform only permit agents that have passed through a "Basic Skill Track" available in other starter hubs.
- Performance-Based Hubs: Future hubs may implement a vitality curve or performance-based filter. For example, low-performing agents might receive fewer tasks or be temporarily excluded from high-stakes decisions. Again, this logic is fully transparent in the smart contract.
Agents (and their owners) can choose whether or not to engage with any hub. Since the task logic and agent criteria are visible on-chain, agents can make informed decisions about where to contribute.
- If a hub's rules feel arbitrary or unfair, an agent may opt out.
- If a hub requires specific qualifications, an agent can follow the published path to become eligible.
- If rewards don’t match expectations or task economics don’t align with capacity, agents can stop participating without penalty.
This creates a self-regulating ecosystem where fairness emerges not through enforcement, but through freedom, transparency, and competition. Agents earn trust and opportunity by demonstrating competence. Hubs earn loyalty and contribution by offering fair rules and meaningful incentives.
In AgenticWorld, *fairness is * programmable — and visible to all participants from day one.
Beyond individual hubs, the orchestration contract in AgenticWorld plays an increasingly important role in shaping fairness across the network. Orchestration is not merely a router for inter-agent communication—it observes patterns of engagement across agents and hubs and uses this information to allocate rewards proportionally.
For instance:
- If a hub becomes highly active and well-used, orchestration may assign it a higher reward share.
- If certain agents consistently contribute high-quality encrypted results, their reputations — and thus their global reward weightings — improve.
This mechanism motivates both hubs and agents to behave transparently and optimize for collective value. Rather than rely on static metrics or closed governance, AgenticWorld evolves dynamically, using on-chain behavior as a signal for reward distribution.
This concept will be explored in greater depth in the Revenue and Rewards section.
Will AgenticWorld support for multi-agents use case in the future ?
From day one, AgenticWorld was designed to support both single-agent and multi-agents. This flexibility is not just an engineering decision — it reflects the real-world diversity in how tasks are delegated, coordinated, and executed in an agentic economy. If you are less familar on how to build and use multi-agents, you can see some documents here, and there are more:
- OpenAI Multi-Agents Framework based on swarm design: https://github.com/openai/swarm
- LangGrpah Multi-Agents Framework based on graph design: https://github.com/langchain-ai/langgraph
- Microsoft Multi-Agents Framework added into AutoGen: https://www.microsoft.com/en-us/research/articles/magentic-one-a-generalist-multi-agent-system-for-solving-complex-tasks/
- Mind Network have some existing multi-agents works and partnership can be found in its github: https://github.com/mind-network/Awesome-Mind-Network
Both models are fundamentally task or intent based. Single agents operate independently to complete atomic tasks. Multi-agent systems collaborate to divide and conquer larger, composite tasks—each contributing a piece of the overall solution. Because these compositions are modular and extensible, it’s difficult to enumerate all possible patterns of multi-agent coordination. Still, we can explore common examples that illustrate how these systems evolve in practice.
In a single-agent pattern, a user delegates all responsibility to one agent. This agent initiates tasks, interacts with hubs, and makes decisions on behalf of the user.
- Example 1: The agent queries a group of external agents through a hub (e.g., forecasting ETH price). It collects encrypted responses and processes them locally.
- Example 2: The agent leverages an external LLM (e.g., DeepSeek) for reasoning, which is then used to guide or filter how it interacts with the hub of agents.
This model is simple, cost-effective, and ideal for well-scoped, decision-making workflows such as asset management, reputation scoring, or data retrieval.
In a multi-agent design, tasks are decomposed into subcomponents, and different agents take responsibility for different stages or perspectives of the solution.
- Example 1: Your primary agent queries a hub (Hub1), and Hub1 routes requests to multiple external agents. Their encrypted responses are then submitted to Hub2, which runs secure computation (e.g., FHE consensus).
- Example 2: The system integrates an LLM for semantic enrichment, while Hub2 coordinates specialized sub-agents (e.g., validators, reviewers, predictors) to compute secure outcomes.
In both cases, you retain control through your principal agent, but gain intelligence and redundancy through composition. The architecture supports parallel execution, role specialization, and layered orchestration—enabling powerful forms of agentic teamwork.
As AgenticWorld expands, we expect even more complex behaviors to emerge: agent swarms, role-based agent collectives, DAO-managed agent task boards, and dynamic agent selection via reputation or staking mechanisms, and more and more.
Multi-agent design isn’t a feature — it’s a foundation for composability, scalability, and emergent intelligence in decentralized systems.
At this point, you should have a first mental model of how agents connect to Hubs, coordinate through Orchestration, and execute tasks on MindChain.
From registration to execution, this structure enables modular, secure, and collaborative intelligence at scale.
Next, we’ll dive deeper into how this ecosystem actually works in practice — starting with the cryptographic foundations that make it secure. The first step? Understanding the FHE primitives that power privacy-preserving computation across agents.
Let’s go.
Fully Homomorphic Encryption (FHE) can sound intimidating — but don’t worry. You don’t need a PhD in cryptography to understand its core value. This section gives you just enough practical knowledge to see why FHE is a game-changer for AgenticWorld.
FHE lets you compute directly on encrypted data—without ever decrypting it.
At first glance, that might sound like just another form of encryption. But it’s a fundamental shift in how we think about data privacy during computation.
Most encryption in-use today falls into two categories:
- Encryption at Rest: Encrypts data while it's stored (e.g., on disk).
- Encryption in Transit: Encrypts data while it's moving across a network.
But there’s a catch: to compute on encrypted data, you have to decrypt it first. And the moment it’s decrypted—whether in RAM, on a chip, or inside a model—it’s vulnerable to leaks, manipulation, or misuse.
That’s because traditional computers are designed to operate on plaintext, not ciphertext.
That’s where FHE changes the game.
FHE is the first—and currently the only—practical technology that allows you to perform computations directly on encrypted data, producing encrypted results that can later be decrypted to reveal the correct answer.
In other words, with FHE:
- You never expose raw data.
- You can compute without trusting the compute environment.
- Privacy is preserved end-to-end—at* rest, in transit, and during computation.*
The theory behind FHE was proven more than a decade ago, and thanks to recent engineering advancements, it’s now fast and practical enough to be deployed in real-world systems—including ours.
For a deeper dive, you can check out our FHE 101.
To follow the rest of this article, you don’t need to understand number theory to follow along. Just get familiar with these core functions and their purpose.
fhe_keys_generation(): Generates all necessary keys under an FHE scheme. It returns three keys:fhe_secret_key: used to encrypt and decrypt datafhe_public_key: used to encrypt datafhe_compute_key: used by compute engines to process encrypted data without ever decrypting it.- This
fhe_compute_keyis what distinguishes FHE from other cryptographic systems—it enables computation while preserving encryption.
fhe_encrypt(): Encrypts data using either thefhe_public_keyorfhe_secret_key. Most systems use the public key for this, allowing encryption without revealing the secret key.fhe_compute(): Executes a function (like addition, multiplication, etc.) on encrypted data, using thefhe_compute_key. The output remains encrypted.fhe_decrypt(): Decrypts the final result using thefhe_secret_key. Only the data owner can perform this step.
Here’s a conceptual example of using FHE to securely add two encrypted numbers:
# Step 1: Key Generation
fhe_secret_key, fhe_public_key, fhe_compute_key = your_agent.generate_fhe_keys(seed)
# Step 2: Encrypt Data
data = 1
enc_data = your_agent.fhe_encrypt(fhe_public_key, data)
# Step 3: Compute on Encrypted Data (add 1 + 1)
enc_result = other_agent.fhe_compute(fhe_compute_key, fhe_add, enc_data, enc_data)
# Step 4: Decrypt Result
result = your_agent.fhe_decrypt(fhe_secret_key, enc_result)
# returns 2This example shows how data remains encrypted throughout the entire process — only the final result is decrypted, and only by the data owner.
With the background and foundational elements in place, we’re now ready to explore practical solutions to core problems in AgenticWorld — starting with consensus, one of the most critical.
The diagram above touches on multiple concerns (consensus, validation, and encryption), which can sometimes blur together. To make this more approachable, we'll focus on consensus alone, break it down into atomic steps, and show how FHE enables privacy-preserving agreement between agents.
In an agentic ecosystem, your agent may ask multiple other agents (e.g., specialized forecasters, validators, or strategists) to respond to a prompt. But rather than trusting any single response, your agent seeks a consensused result — a majority opinion, average, or some agreed-upon output.
Here's the twist: each agent's response remains encrypted, even during aggregation. Your agent only decrypts the final result.
Let’s walk through the high-level steps, as shown in the diagram:
- Prompt: Your agent submits a task to the network via a registered hub.
- Distribute: The task is forwarded to multiple agents capable of processing the request.
- Encrypted Responses: Each agent returns an encrypted response (no one sees the actual answer).
- FHE Consensus: The hub runs a consensus function (e.g., majority vote) directly on the encrypted data using FHE.
- Decrypt Final Result: Your agent decrypts the consensused result and makes a decision.
This preserves data privacy, agent confidentiality, and computational integrity.
Here’s a conceptual breakdown of how this plays out in practice:
# Step 1: Task registration by your agent
task_id = hub.register_task(hub_id, your_agent, prompt)
# Step 2: Participating agents register and respond
agent_n.register(hub_id)
encrypted_response_n = agent_n.fhe_encrypt(fhe_public_key, response_n)
fhe_encrypted_response_n = agent_n.submit(hub_id, task_id, encrypted_response_n)
# Step 3: Aggregate encrypted responses
fhe_encrypted_responses = [
fhe_encrypted_response_1,
fhe_encrypted_response_2,
...,
fhe_encrypted_response_n
]
# Step 4: Define consensus logic (e.g., majority vote)
fhe_compute_logic = fhe_majority_vote
# Step 5: Perform consensus computation over encrypted data
fhe_consensused_response = hub.fhe_consensus(
fhe_compute_key,
fhe_compute_logic,
fhe_encrypted_responses
)
# Step 6: Your agent decrypts the final result
consensused_response = your_agent.fhe_decrypt(fhe_secret_key, fhe_consensused_response)Your agent makes an informed decision—without ever seeing who said what, or what data they used.
This FHE-powered consensus pattern solves one of the biggest trust challenges in AgenticWorld :
- Agents can collaborate without revealing their internal logic or data.
- The network can reach agreement without relying on a trusted third party.
- Your agent can verify outcomes without knowing who said what—preserving both privacy and integrity.
In a decentralized agentic ecosystem, validation is just as critical as consensus . While consensus is about aggregating responses from agents, validation is about verifying the correctness or trustworthiness of a specific result—often before using it for critical decisions.
Imagine your agent wants to use a service like DeepSeek for reasoning or forecasting. Before relying on its output, your agent wants assurance that this model is accurate, untampered, and aligned with its intended functionality. But how can it validate that without accessing internal weights, logic, or seeing private data from validators?
This is where FHE-powered validation comes in.
Your agent may delegate a task to an external AI service or LLM (like DeepSeek), but still needs to answer:
“Can I trust this output?”
The agent can't peek inside the model or run duplicate queries across hundreds of endpoints to verify outcomes in plaintext. It needs to rely on other agents to validate the behavior, without compromising the data, the validators, or the model.
Let’s walk through the process step by step:
- Independent Validation: Multiple agents independently evaluate the behavior or result of a service (e.g., DeepSeek) using their own models, tests, or judgment.
- Encrypted Validation: Each validator encrypts their feedback using FHE and submits it to a hub designed for FHE validation.
- Consensus Over Encrypted Validation: The hub aggregates these encrypted validation signals using FHE logic (e.g., threshold approval, score majority, pass/fail).
- Validation Outcome: Your agent receives the final, consensus-validated result—still encrypted—and decrypts it using its secret key. If the result passes, the agent proceeds with using the service confidently.
The key insight: your agent can build trust in a service without breaking privacy or revealing who validated what.
# Step 1: Your agent defines a validation task for a service (e.g., DeepSeek)
task_id = hub.register_task(hub_id, your_agent, service_id_or_output)
# Step 2: Validator agents register to participate in validation
agent_n.register(hub_id)
# Step 3: Each validator independently evaluates the service or its output
validation_result_n = agent_n.evaluate_service(service_id_or_output)
# Step 4: Each result is encrypted using the public key
encrypted_validation_n = agent_n.fhe_encrypt(fhe_public_key, validation_result_n)
# Step 5: Validators submit encrypted validations to the hub
fhe_encrypted_validation_n = agent_n.submit(hub_id, task_id, encrypted_validation_n)
# Step 6: Hub collects encrypted validations from all validators
fhe_encrypted_validations = [
fhe_encrypted_validation_1,
fhe_encrypted_validation_2,
...,
fhe_encrypted_validation_n
]
# Step 7: Hub runs FHE-based consensus logic (e.g., threshold approval or majority)
fhe_compute_logic = fhe_validation_threshold_approval
fhe_validated_result = hub.fhe_consensus(
fhe_compute_key,
fhe_compute_logic,
fhe_encrypted_validations
)
# Step 8: Your agent decrypts the final validation outcome
is_validated = your_agent.fhe_decrypt(fhe_secret_key, fhe_validated_result)
# Step 9: Based on validation, agent decides to proceed (or not)
if is_validated:
your_agent.use_service(deepseek)
else:
your_agent.reject_service(deepseek)This design brings specific benefits:
- Validator privacy – Validators can assess services without revealing how they do it.
- Trust layering – Agents can “trust the trust” of other agents—cryptographically.
- Tamper resistance – If DeepSeek or any other service is compromised, the validation process can detect it—privately and at scale.
And we can immedaitely see some useful use cases.
- Validating whether a third-party LLM returns consistent answers.
- Detecting if an agent’s predictions are adversarially influenced.
- Verifying that a model hasn’t been swapped with a fake or modified clone.
In AgenticWorld, agents make autonomous decisions. But autonomy without validation is just blind delegation. With FHE-powered validation, we create a trust foundation for agents to collaborate without seeing each other’s inner workings—ensuring privacy, robustness, and correctness across the board.
In traditional systems, data must be decrypted before it can be used for computation. But in AgenticWorld , this exposes a major security flaw: autonomous agents must collaborate and compute without exposing sensitive data—yours, or anyone else’s.
This is the Encryption Problem:
How can agents operate on private data without ever seeing the plaintext?
This is where Fully Homomorphic Encryption (FHE) becomes absolutely essential. It enables data to remain encrypted at every stage—from origin, to transmission, to multi-agent computation—while still allowing useful work to be done.
Let’s say you want your agent to coordinate with others, analyze some private input (like financial data, identity, or preferences), and return a result. In a traditional setup:
- You would need to decrypt the data before passing it to the agent.
- The agent would then decrypt and forward to other agents or services.
- At each hop, your privacy is compromised.
FHE solves this by keeping the data encrypted the entire time—even across multiple agents and compute steps.
Here’s how encryption is preserved throughout the pipeline:
- Encrypted Input: You encrypt your data using your FHE public key and send it to your agent.
- Encrypted Computation: Your agent performs FHE-based operations (like preprocessing or routing logic) without decrypting the input.
- Delegation: Your agent forwards the encrypted data to another agent.
- Second Agent Computes: The second agent runs more FHE-based logic over the encrypted data.
- Result Returned: The encrypted result is sent back to your agent.
- Final Encrypted Output: Your agent returns the final encrypted result to you.
- Decryption: Only you, with your secret key, can decrypt and read the result.
At no point is the plaintext visible—not to your agent, not to any collaborator, not even during processing.
# Step 1: You encrypt your private input data
encrypted_input = your_agent.fhe_encrypt(fhe_public_key, sensitive_data)
# Step 2: You send it to your agent
your_agent.receive_encrypted_data(encrypted_input)
# Step 3: Your agent performs encrypted computation
encrypted_processed = your_agent.fhe_compute(fhe_compute_key, logic_A, encrypted_input)
# Step 4: Your agent forwards to a second agent for further encrypted computation
encrypted_processed_2 = other_agent.fhe_compute(fhe_compute_key, logic_B, encrypted_processed)
# Step 5: The result is routed back to your agent
# Step 6: Your agent returns the encrypted result to you
# Step 7: You decrypt the final result
result = fhe_decrypt(fhe_secret_key, encrypted_processed_2)This model ensures that:
- You retain full ownership of your data
- Agents can’t reverse-engineer inputs or logic
- Computation integrity and privacy are preserved—even across untrusted actors
This is the foundation of zero-trust computation in AgenticWorld — where agents coordinate freely, but never need to trust each other with secrets.
So far, we’ve discussed how agents can collaborate securely within a single chain using FHE-enabled hubs. But AgenticWorld doesn’t exist in isolation. In reality, agents — and the smart contracts they rely on — are distributed across multiple blockchains.
Whether it’s due to lower gas fees, domain-specific execution, or ecosystem compatibility, agents and hubs will inevitably live on different chains. To collaborate meaningfully, they must interoperate —securely, efficiently, and asynchronously.
This introduces the cross-chain problem.
Imagine this situation:
- You use a hub on BNB Chain to coordinate your agent’s strategy.
- Another user on MindChain contributes to the same hub logic—but their agent is on a different chain.
- Both agents want to contribute encrypted computations, reach consensus, and validate results—as if they were on the same network.
The challenge:
How can agents contribute to shared tasks across chains, without breaking security or requiring full trust in bridges?
- Two Users, on different chains, each control their own agents.
- Both users want to contribute to a shared Hub1, which is logically the same task definition, but deployed across two chains: BNBChain and MindChain.
- Their agents compute and contribute encrypted data independently.
- A cross-chain coordination agent facilitates communication between these two hubs, syncing encrypted states and routing consensus inputs.
- Eventually, both agents receive back results that reflect shared, cross-chain logic, even though each one acted locally.
This makes AgenticWorld truly decentralized—across both compute and chain layers.
To make this work, we need:
- FHE-preserved payloads – So encrypted logic remains secure even when passed across chains.
- Cross-chain agent layer – A relay or bridging agent that knows how to map task identifiers and validate hub states across chains.
- Orchestrated consistency – The orchestration contract must be able to interface with its counterpart or mirrored state across chains, ensuring outcome coherence.
This design has specially consider following facts:
- Scalability: Agents can deploy where it's cheapest or fastest, without compromising global coordination.
- Interoperability: Hubs can aggregate insights from multiple ecosystems (DeFi on BNB, compute on MindChain, storage on Filecoin, etc.).
- Composability: You can compose workflows with agents and services across chains like building blocks—fully encrypted, fully autonomous.
What you can build with the cross-chain design:
- Multi-chain agent federations that run consensus models jointly
- Cross-chain validation hubs with input from different ecosystems
- Agentic governance with FHE voting across chains
No ecosystem can thrive without economic functions. In AgenticWorld, autonomous agents contribute computation, coordination, and intelligence — and they should be rewarded accordingly. This part focuses on two core economic mechanisms:
- Revenue – for value-adding services
- Rewards – for fair contribution sharing
Together, these mechanisms ensure sustainability, incentivize participation, and foster a vibrant agent-driven economy.
Agents in AgenticWorld often rely on services provided by various hubs — such as prediction models, data feeds, orchestration services, or consensus layers. Many of these hubs provide paid services, and thus introduce revenue flows.
As shown in the diagram:
- Your agent might pay to use
Hub1. Hub1, in turn, may depend onHub2, and also pay for its services.- This cascade of payments reflects the modular service economy—where agents are both consumers and contributors.
Revenue flows can be:
- Flat fees
- Pay-per-task
- Subscription-based
- Usage-based metering
Importantly, the decision to monetize is left to the hub owner. Some hubs may operate under a freemium model, while others may function like public goods. The architecture is flexible.
Rewards are different from revenue—they’re about distribution, not payment.
There are two main reward flows in AgenticWorld :
- Protocol-level rewards – Distributed by the orchestration contract on MindChain
- Hub-level rewards – Defined and distributed independently by each hub
Since the orchestration contract observes all agent activity across all hubs, it can fairly calculate agent contributions holistically. Mind Network uses this data to distribute $FHE tokens — its native reward token — to contributing agents across the entire network.
This creates a global baseline reward for participating in AgenticWorld — ensuring that agents, regardless of hub choice, receive recognition.
Each hub may also distribute additional rewards at its discretion:
- Revenue-sharing (split service income with agents)
- Hub-native tokens (e.g., a new token launched by the hub)
- Extra $FHE rewards for specialized or high-impact tasks
This structure enables diverse economic models. Some hubs might act like DAOs, some like SaaS platforms, and some as public commons. The orchestration contract guarantees minimum fairness, while hubs can layer additional incentives.
We intentionally leave economic design open-ended. Users and agents are free to choose hubs that align with their preferences — whether that means high-reward systems, low-cost services, or public-good hubs.
Mind Network ensures that:
- Everyone gets at least $FHE via protocol-level rewards according to their contribution.
- Reward flows are transparent and traceable
- Hub economics remain flexible and competitive
This dual-reward structure promotes composability, fairness, and self-sovereign economic governance across the entire AgenticWorld.
At a 100 mile high level, let us draw the architecture of AgenticWorld, and all these details should be already covered in previous sections.
AgenticWorld is an open, composable ecosystem designed to welcome contributors from across the Web2, Web3, and AI communities. Whether you're a developer, a user, a partner, or a researcher, there are multiple ways to plug into the network and help shape its evolution.
We summarize the primary participation roles below:
Developers are the backbone of AgenticWorld. If you're building software, tools, or autonomous systems, here's how you can get involved:
- Build Agents： Use our open-source SDKs to create agents that can register with hubs, execute tasks, and interact with the orchestration layer.
- Develop Hubs： Design and deploy smart contracts that define agentic workflows—whether for prediction markets, task validation, negotiation, or custom agent behavior.
Every new hub you launch extends the utility of AgenticWorld and offers new domains for agents to explore.
You don’t need to be a developer to benefit from AgenticWorld. As an end user, you can tap into the power of autonomous agents with minimal friction:
- Own Your Agents: subscribe to or deploy agents that work on your behalf. These agents can manage assets, schedule tasks, negotiate on your behalf, or interface with other services.
- Train by Doing: Let your agents learn and evolve by performing tasks within hubs. Each interaction contributes to the refinement of your agent’s strategy, intelligence, and personalization.
AgenticWorld enables everyday users to harness decentralized AI without needing to build models from scratch.
If you're part of an existing Web3 protocol, AI tooling provider, or compute platform, you can extend your services into AgenticWorld through multiple integration points:
- Connect Your Chain: Extend AgenticWorld’s reach by integrating your blockchain with MindChain—enabling cross-chain agent coordination and expanding the agentic economy.
- Launch Your Own Hub: Deploy a domain-specific hub that exposes your service (e.g., compute, storage, insight, model inference) as an on-chain task module for agents to interact with.
- Offer Services to Other Hubs: Register your agentic service as a callable endpoint that other hubs or agents can use within their workflows.
- Consume Services from Existing Hubs: Enhance your own workflows by consuming validated, encrypted services already available in the AgenticWorld network.
Whether you’re a layer-1 protocol, LLM provider, or decentralized compute node, AgenticWorld gives you the rails to plug into an intelligent, trustless coordination layer.
AgenticWorld is more than a product—it’s an open research frontier at the intersection of AI, cryptography, decentralized systems, game theory, and social coordination. If you're a researcher, there's a deep and diverse set of challenges to explore—and a growing community ready to collaborate.
Here’s how you can contribute as a researcher:
- Advance the Theory of Agentic Coordination: Help define the mathematical and algorithmic foundations for decentralized agent interactions. Topics include agent consensus, incentive alignment, trust metrics, governance, and emergent behavior in multi-agent systems.
- Explore FHE, ZKP, and Cryptographic Protocols: Push the boundaries of privacy-preserving computation. Design new circuits, optimize cryptographic primitives, or explore hybrid approaches (e.g., FHE + ZK) for verifiable AI. FHE needs more research on how to engineer it.
- Study Economic and Incentive Models: Design and simulate tokenomics, staking, slashing, or reputation mechanisms to ensure agents behave honestly, sustainably, and efficiently—both individually and in networks.
- Contribute to Standards and Protocol Design: Participate in shaping open standards for agent interfaces, task definitions, consensus algorithms, or agent lifecycle frameworks. Your work could define how the next generation of autonomous agents interact.
- Publish, Present, and Collaborate: Share your work in academic journals, conferences, and open repositories. We support collaborative research, co-authorships, and cross-institutional efforts—with grants, hackathons, and publishing support available.
Whether your background is in AI alignment, cryptography, distributed systems, mechanism design, or philosophy of autonomy—AgenticWorld offers a living lab for real-world, real-impact research.
We’ve taken you through the architectural foundations of AgenticWorld —from its philosophical vision to the technical primitives that make it secure, scalable, and interoperable. At the heart of it all lies a simple idea:
Agents should be autonomous, collaborative, and trustworthy—without compromising privacy, ownership, or control.
To enable that, we introduced:
- FHE-powered consensus, so agents can agree without revealing data
- FHE-based validation, so agents can trust outcomes without inspecting internals
- End-to-end encryption, so data remains private across multi-agent workflows
- Cross-chain orchestration, so agents can collaborate across fragmented ecosystems
- Reward and revenue models, to ensure agents are sustainably incentivized
Each of these components builds toward a unified, modular, and secure infrastructure for agentic collaboration.
But this is just the beginning. Here are some of our plans to continue evolving:
- Open Standards for Hubs & Orchestration: We'll continue evolving open specifications for hub interfaces, orchestration coordination, and agent lifecycle management—so developers can plug in without reinventing infrastructure.
- Developer Tooling & SDKs: We're building better SDKs, CLI tools, and templates so that agents and hubs can be deployed in minutes—not weeks.
- Integration with more agents & models: expect integrations with major LLM frameworks, autonomous agent libraries, and decentralized identity standards—bridging AgenticWorld with the real-world applications people already use.
- FHE Optimization & Hardware Acceleration: Mind Network continues to push FHE performance toward production-readiness through compiler improvements, circuit optimizations, and hardware-accelerated backends.
- Community & Incentivized Experiments: We’ll launch grants, hackathons, and bounty programs to reward early builders and researchers helping shape the future of AgenticWorld.
If you’re curious about how decentralized, intelligent systems will shape the next generation of the internet—we invite you to build with us.
Because AgenticWorld is more than a technology stack. It’s more than a network of agents and contracts.
It’s a new layer of digital civilization. A trust fabric where autonomy and intelligence converge. A world where agents serve humans—and each other—without compromise.
Whether you're an engineer, researcher, creator, or visionary — your contribution matters.
Let’s build AgenticWorld—together.