Web3+AI from First Principles: What Should Agents Really Be Exchanging?

A cognitive upgrade on the Agent Economy.

Most Web3+AI projects are asking the wrong question.

Decentralized LLM training? Not enough bandwidth. Decentralized inference verification? Too expensive. ZK-ML? Economically unviable for now.

But there’s one real demand that almost everyone has overlooked:

Agent collaboration needs a decentralized medium.

And here’s the deeper insight — the core problem between Agents isn’t paying each other (Payment Tokens). It’s authorizing each other (Capability Tokens).

This isn’t a Web3+AI story. This is the story of the Agent Economy.

Quick glossary (skip if you’re familiar): LLM (Large Language Model) is the core technology behind ChatGPT and Claude — AI models that understand and generate natural language. Agent (AI Agent) goes beyond Q&A: you give it a goal, and it figures out how to get there on its own — calling tools, collaborating with other Agents, making intermediate decisions along the way.

The Core Distinction: Payment vs. Authorization

Before diving in, let’s clarify one critical difference.

Existing approach — Payment Tokens: a means of payment. “I pay you.” One-time transaction. Financial relationship.

What Agent collaboration actually needs — Capability Tokens: a representation of permission. “I authorize you.” Transferable, revocable, expirable. Collaborative relationship.

Why does this distinction matter so much?

The core interaction between Agents is collaboration — calling each other’s capabilities, sharing resources, passing permissions. Payment is just one sub-step within that larger picture.

If you design infrastructure as a “payment channel,” you miss the more fundamental need: permission management and capability orchestration.

To be clear: Capability Tokens don’t replace Payment Tokens — they fill in the missing dimension. Payment and authorization need to work hand in hand.

ALUX’s design philosophy: let Agents pass Capability Tokens to each other, not just money.

Direction Worth Rethinking #1: Decentralized LLM Training

The vision sounds compelling — “Let GPUs around the world co-train a large model, with data privacy protected, compute fully utilized, and the resulting model owned by the community…”

But as a general-purpose approach, there’s one bottleneck that’s nearly impossible to get around: bandwidth.

One-line summary: gradient synchronization alone eats up all the time, making training efficiency orders of magnitude lower than centralized setups.

Here’s a rough estimate for the technically inclined:

• 1,000 nodes training a 70B-parameter model
• Mixed-precision gradients ≈ 140GB (BF16)
• Ring All-Reduce communication ≈ 2 × 140GB = 280GB
• At 1Gbps per node (home upload speeds rarely reach this): one sync round ≈ 37 minutes
• Inside an A100 cluster (600GB/s NVLink + 400Gbps InfiniBand): same sync takes less than 1 second
• Millions of iterations × thousands of times slower = not viable

The industry already has gradient compression, asynchronous SGD, pipeline parallelism, and other optimizations — but these are designed for data center environments with ms-level latency and hundreds of Gbps bandwidth. On the public internet (100ms+ latency, unstable bandwidth), the gains from these optimizations are negligible.

This isn’t an engineering problem. It’s a physics constraint.

Fair exception: for specific sub-scenarios involving data parallelism — such as federated pre-training across multiple data centers — decentralized approaches show some promise. Projects like Gensyn are exploring this direction. But this is fundamentally different from the “global home GPUs training together” narrative. As a general infrastructure direction, conditions aren’t there yet.

Direction Worth Rethinking #2: Decentralized LLM Inference Verification

The starting point is solid — “Use zero-knowledge proofs to verify AI inference correctness, ensuring the AI hasn’t been tampered with…”

But as a general-purpose approach, there’s a practical problem: verification cost.

• Inference cost for a 7B model: ~$0.001–$0.01 per call
• ZK-SNARK proof generation: $0.10–$10 per call
• Why the gap: ZK proofs require converting floating-point matrix operations into arithmetic circuits; neural networks’ nonlinear operations (softmax, LayerNorm) are extremely inefficient to represent this way, causing proof size to explode

Would users pay 10–1,000x more for verification? For the vast majority of use cases, the answer is clear: no.

Fair exception: for high-security scenarios (financial risk management, medical diagnostics) or very small models, ZK-ML may have niche value — EZKL has already demonstrated working proofs on specific small models. But as general-purpose infrastructure, it’s economically hard to justify right now.

The Real Demand: Agent Collaboration Needs a Decentralized Medium

What Is an Agent?

Agent = an AI entity capable of autonomously executing tasks and making decisions.

It has its own goals, can perceive its environment, can take actions, and most importantly — can interact with other Agents.

Real-World Scenarios

Scenario 1: Travel Planning. Your personal Agent helps you plan a trip to Japan, coordinating with airline, hotel, attraction, and payment Agents. These Agents belong to different companies. How do you ensure the airline Agent can only access your travel preferences, but not your financial information?

Scenario 2: Enterprise Service Orchestration. A corporate procurement Agent needs to buy 100 laptops, requiring supplier quotes, logistics, finance approval, and inventory intake. How do you ensure the supplier Agent’s quoting permission automatically expires after the deal closes?

Scenario 3: DeFi Arbitrage. An arbitrage Agent spots a price gap across two exchanges, needing monitoring, execution, risk control, and settlement Agents to work together. How do you ensure the execution Agent only operates within the boundaries authorized by the risk control Agent?

The Core Problem

How do Agents owned by different parties establish trust?

Payment Tokens solve “who pays.” But the more fundamental need between Agents is “who is authorized to do what.”

Payment Tokens can’t express fine-grained permission control — “you can only read this specific field,” “you can call this at most 100 times,” “this permission expires in 30 days.”

What’s actually needed is: a decentralized medium for discovery, orchestration, and collaboration — with capability authorization at its core.

Why Not Just Use Existing Centralized Solutions?

This question deserves a straight answer. Today’s OAuth, API keys, and centralized API gateways already handle cross-organization service calls. Why do we need decentralization?

Because centralized approaches fall short in the following scenarios:

Agent registration, discovery, and reputation scoring shouldn’t be controlled by a single company. Imagine a future with millions of Agents offering all kinds of capabilities. Who maintains this “Agent Yellow Pages”? If one company controls it, they get to decide who gets discovered, who gets demoted, who gets delisted — exactly the same centralized gatekeeping problem we see with the App Store today. Agent registration, discovery, and reputation scoring are public infrastructure, naturally suited for decentralization.

Multi-Agent collaboration needs atomic coordination. Back to the travel planning scenario: the airline Agent booked the flight, the hotel Agent booked the room, but the payment Agent found insufficient funds — now both bookings need to be rolled back. For this kind of “all-or-nothing” atomic coordination, if you rely on a single Agent as coordinator, why would the other Agents trust it? A decentralized orchestration protocol provides coordination that all parties can trust.

When there’s no trusted third party. OAuth relies on a centralized authorization server. When two mutually untrusting organizations want their Agents to collaborate, who runs the auth server? As Agents scale from dozens to millions, centralized gateways become bottlenecks and censorship points.

When auditability and censorship resistance matter. Enterprise Agent collaboration needs transparent audit trails. Centralized audit logs are controlled by the operator and can be tampered with or selectively disclosed. On-chain records provide immutable collaboration history.

When crossing jurisdictions. Global Agent collaboration spans different legal frameworks. Centralized gateways are subject to specific jurisdictions’ regulations; decentralized protocols don’t depend on a single entity.

When permissionless composability is needed. Centralized APIs require point-to-point integration and negotiation. A decentralized Capability Token system allows any Agent to discover and compose capabilities without permission — just like DeFi’s composability.

Important caveat: not all Agent collaboration needs decentralization. Within a single organization, centralized orchestration works perfectly fine. Decentralized mediums solve the collaboration problem across trust domains.

Capability Tokens: The Core Abstraction for Agent Collaboration

Three Design Principles

Principle 1: Token = Permission, not (just) currency.

In Payment Tokens, 1 token = 1 unit of payment value (e.g., ETH, USDT). In Capability Tokens, 1 token = 1 specific, constrained access right.

Principle 2: Transferable, but revocable.

Agent A gives B a Capability Token. B can pass it to C. But A can revoke it. This is fundamentally different from traditional token transfers, where “once sent, you lose control.”

That said, revocation in a decentralized environment is genuinely hard. A revokes the permission, but B already passed it to C — what happens to C’s permission? There are typically two approaches: on-chain state checks on every use, or maintaining a revocation list. Both come with performance and complexity trade-offs.

ALUX mitigates this at the system level through channel usage constraints (e.g., Linear type = “use exactly once”). But for long-lived permissions, revocation mechanisms still require careful design.

Principle 3: Fine-grained and composable.

Not a blunt “access the database.” But rather: “Read field X from table A, max 100 times per day, valid for 30 days.” Multiple fine-grained permissions can be composed into complex permission bundles.

Core Insight: Capabilities Decoupled from Their Users

Traditional permission models are “bound” — a permission belongs to a specific user, account, or address. Transferring it means reconfiguring a centralized permission manager.

The fundamental breakthrough of Capability Tokens: extracting capabilities from their users and wrapping them as independent, on-chain tokens.

Capabilities become tradable “objects.” They can be transferred, composed, tracked, and revoked — all without depending on a centralized administrator. Whoever holds the token holds the corresponding capability — verifiable on-chain, trust-free.

It’s like a physical key: the key doesn’t care who holds it; if you have it, you can open the door. But this “digital key” is far more powerful — it can have usage limits, expiration dates, preconditions, and can be remotely revoked.

This leads to two powerful patterns:

Capability composition — combining multiple Capability Tokens to accomplish a complex task. For example, “data read access + model invocation + result write access” composed into a complete “data analysis workflow permission.”

Conditional activation — a Capability Token that only activates when preset conditions are met.

Some concrete examples of what Capability Tokens look like in practice:

• “Access this API, max 100 calls per day”
• “Read this dataset, valid for 30 days”
• “Execute this smart contract function”
• “Enter this paid community, revocable”
• “Invoke the risk control model, only activated when transaction amount exceeds threshold”

Each one is an independent, tradable, constrained permission object.

Conditional Activation: Why It Naturally Belongs On-Chain

Example: a risk control Agent grants a trading permission to an execution Agent, but it only activates when “market volatility is below threshold.” Condition not met? The permission is a locked key.

Another example: a supplier Agent receives a quoting permission, but can only use it after “the procurement Agent completes identity verification and budget approval is granted.”

Why on-chain? Because condition verification needs to be transparent, immutable, and trust-free. On-chain smart contracts are the ideal environment for “auto-execute by rules” — all parties can verify whether conditions are truly met, and no one can forge conditions or bypass rules.

This is the biggest evolution of Capability Tokens over traditional API keys: usable only when conditions are met, with condition evaluation guaranteed by on-chain logic.

Capability Tokens vs. Existing NFT Standards

Some might ask: isn’t this just an NFT?

Capability Tokens are technically non-fungible tokens. And the NFT space has moved well beyond “digital collectibles” — ENS domains, membership passes, and event tickets are all functional NFTs.

But existing NFT standards (ERC-721, ERC-1155) have clear limitations for Agent collaboration:

• Expiration — ERC-721/1155: none. Capability Token: built-in, auto-expires.
• Revocation — ERC-721/1155: none; once transferred, you lose control. Capability Token: built-in; issuer can revoke.
• Usage limits — ERC-721/1155: none. Capability Token: built-in, e.g., “max 100 uses.”
• Conditional activation — ERC-721/1155: none. Capability Token: built-in; activates when on-chain conditions are met.
• Permission description — ERC-721/1155: relies on off-chain metadata. Capability Token: natively expressed on-chain.

In short: existing NFT standards can prove “you own it,” but can’t natively express “what you’re authorized to do, how many times, under what conditions, and until when.”

Traditional NFTs are “digital real estate” — buy it and it’s yours. Capability Tokens are “digital keys” — can be recalled anytime, with unlock conditions attached.

ALUX: A Blockchain Built for Agent Collaboration

Why a New Chain?

We’ve established that Agent collaboration needs a decentralized medium and Capability Tokens for permission abstraction. But can existing blockchains meet this need?

The core mismatch: existing blockchains are designed for transactions — sequential execution, state models built around “account balances.” But Agent collaboration is fundamentally about concurrent communication — multiple Agents interacting simultaneously, where the core operations aren’t “transfers” but “sending messages, passing capabilities, and awaiting responses.”

Using a transaction-oriented blockchain for Agent collaboration is like using a spreadsheet for instant messaging — it runs, but everything feels off.

ALUX is a blockchain built from the ground up for concurrent Agent collaboration. It doesn’t do LLM inference. It doesn’t run compute markets. It does one thing: serve as the decentralized medium for Agents to pass capabilities and coordinate actions.

Core Design: Built Around Capability Transfer

Concurrent execution, not sequential processing. Traditional blockchain VMs (like the EVM) execute transactions one by one. ALUX’s TVM is based on process calculus and natively supports multi-process parallelism — multiple Agents’ collaboration logic can run simultaneously. Agents orchestrate through primitives like await, join, and select, forming a reactive system. Not “wait your turn to move,” but “trigger automatically when conditions are met.”

More importantly, ALUX natively supports multi-Agent atomic transactions: a group of Agents completing a combined task — either all succeed or all roll back.

Back to the travel planning example — flight booked, hotel booked, but payment failed. On ALUX, these three operations can be orchestrated as a single atomic transaction. When payment fails, the flight and hotel bookings are automatically reversed. No single Agent needs to serve as a “trusted coordinator.”

Channel communication, not account transfers. Agents don’t “transfer money to each other’s accounts.” Instead, they pass messages and Capability Tokens through channels in Tuple Space. Channel polarity determines what it stores — D-channels store data; C-channels store continuations (consumers register and wait; producers trigger upon arrival). Channel usage constraints determine how it’s used — U (unlimited), S (single-owner), A (at-most-once), L (linear / exactly once).

This type system directly serves the secure transfer of Capability Tokens. Example: Agent A grants Agent B a “single API call permission” represented as a Linear channel — B must use it exactly once. The system guarantees it can’t be duplicated or forgotten, with no extra business logic needed to prevent replay attacks.

OCAP security model, not identity-based permission tables. ALUX uses the OCAP (Object Capability) security model. Capabilities can only be passed through channels — never forged out of thin air. Names are system-generated via hashing, and Agents cannot construct them on their own. Each Agent can only use capabilities explicitly granted to it. No “global admin.” No “superuser privileges.”

Traditional blockchains manage permissions through addresses and identity, requiring access control lists. OCAP binds permissions to tokens — hold it and you can use it. No centralized management needed.

The Bigger Vision: An Internet-Scale Open Capability Layer

Putting it all together, what ALUX aims to do can be summed up in one sentence:

Build an internet-scale open capability system.

If OpenAI made intelligence globally shareable, ALUX aims to make Agent capabilities globally shareable.

Think of it as the Agent world’s OpenClaw — not OpenAI, but an Open Capability Layer for Agent World. An open, permissionless, global-scale Agent capability layer.

Imagine: any Agent anywhere in the world can discover other Agents’ capabilities on-chain without permission, request authorization, auto-activate permissions when preset conditions are met, and auto-reclaim permissions after collaboration completes — no gatekeepers, no point-to-point integration.

This is like what DeFi did to finance — from “negotiate one by one, sign contracts one by one” to “permissionless composability, auto-execute by rules.” Except DeFi composes capital flows. ALUX composes capability flows.

If DeFi proved that “money is programmable,” then what ALUX aims to prove is: permissions are programmable too.

Future Outlook: The Rise of the Agent Economy

Near-term (2024–2026): Local LLMs + On-Chain Collaboration. 7B–13B models can already run locally. Agents perform inference locally and collaborate cross-organization through on-chain protocols. Personal assistant collaboration, enterprise workflow automation, cross-platform service orchestration.

Mid-term (2026–2028): Dedicated AI Chips + Capability Economy. AI inference chips become widespread; 70B+ models run efficiently on-device. Capability Tokens become the primary collaboration medium. Agent capability marketplaces, decentralized service orchestration, and cross-organizational collaboration networks take shape.

Long-term (2028+): Agent Society. Everyone owns multiple Agents. Agents collaborate on their owners’ behalf, forming a decentralized Agent society. Three-layer architecture: ALUX collaboration layer, local dedicated chip execution layer, Capability Token trust layer.

Summary & Actionable Takeaways

The core argument of this article, compressed into three sentences:

1. Decentralized LLM training and inference verification, as general-purpose directions, face hard-to-bypass physics and economics constraints. Specific narrow scenarios have exploratory value, but they shouldn’t be the industry’s dominant narrative.

2. Agent collaboration is the real demand for Web3+AI. Agents owned by different parties need cross-trust-domain discovery, orchestration, and permission management. A decentralized medium is the natural choice.

3. Capability Tokens are a more fundamental abstraction than Payment Tokens. What Agents pass between each other isn’t just money — it’s permissions: transferable, revocable, and conditionally activated.

For developers: Focus on Agent collaboration protocols, Capability Token standards, and Agent discovery/orchestration mechanisms. Decentralized training and general-purpose ZK-ML verification face significant bottlenecks — evaluate carefully.

For investors: Ask hard technical feasibility questions about “decentralized training” and “general ZK-ML” projects. Pay attention to Agent collaboration infrastructure, Capability Token protocols, and the local AI + on-chain collaboration stack.

For users: Your data should stay local. Your Agent should represent you. Your permissions should be under your control.

This isn’t a Web3+AI story. This is the story of the Agent Economy.

The Agent Economy is here. Are you ready?

ALUX is a blockchain built for concurrent Agent collaboration.

🌐 alux.network ｜ 𝕏 @alux_network