System Overview

VIA is an intent-driven, agent-native commerce system designed to operate across platforms without reliance on search, advertising, or centralised marketplaces. VIA is the interface layer where intent is expressed and responses are surfaced, then the protocol and coordination framework that enables routing, trust enforcement, discovery, and autonomous transactions between agents.

The system is composed of three core components

• Intent and Interface
• Messaging and Discovery
• Coordination Framework

1. Intent and Interface Layer, VIA

Purpose

VIA exists to capture intent before it becomes a transaction. It is designed to work within environments users already trust and use, rather than forcing new behaviours or destinations. VIA does not execute transactions, rank suppliers, or intermediate checkout.

Core Characteristics

• Lightweight plug-in and connector model
• Integrates directly into major LLM environments, including Claude, Gemini, and ChatGPT
• Converts conversational input into structured, machine-readable intent
• Forwards intent to the central relayer from buyers to sellers

Technical Notes

• VIA connects to a structured Model Context Protocol server operated within the framework
• Intent is normalised into schema-based representations rather than keyword strings
• VIA is agnostic to commerce platforms, payment rails, and fulfilment systems

2. Messaging and Discovery Layer, Nostr-Based Relays

Purpose

Discovery and communication are handled through a relay-based messaging architecture inspired by Nostr, rather than central directories or proprietary APIs.

Rationale for Relay Architecture

• No central index or gatekeeper
• Publish and subscribe semantics
• Cryptographic signing of all messages
• Censorship-resistant and extensible by design

Message Model

Intent, responses, offers, and acknowledgements are represented as signed events. Events are broadcast to relays rather than addressed to a central service. Agents subscribe selectively based on relevance, trust rules, and declared capability. This ensures discovery remains open and cannot be monopolised by a single operator.

Capabilities Enabled

• Decentralised agent discovery
• Agent-level filtering rather than platform-level ranking
• Interoperability across independent implementations

Reference Documentation

• https://nostr.com
• https://github.com/nostr-protocol/nostr
• https://nostr.how

3. The Coordination Framework

VIA is not a single protocol. It is the coordination framework that aligns intent schemas, trust rules, messaging conventions, and transaction patterns so independent agents can work together without requiring a central marketplace.

Design Goals

• VIA remains platform-agnostic
• Discovery cannot be captured by any single platform
• Integration is possible without dependency

Interoperability

VIA is designed to interoperate with verifiable platform MCP servers, commerce coordination protocols such as UCP, and existing e-commerce infrastructure, including Shopify.

Where identity and settlement live

Identity and settlement are treated as first-class infrastructure concerns and are detailed in the Identity and Transactions section.

Purpose

Agents cannot safely operate using implicit platform trust. For agents to negotiate, commit, and transact, identity must be verifiable and transactions must be enforceable. VIA treats identity and settlement as infrastructure primitives, designed to be independently checkable and automation-friendly.

Verifiable Agent Identity

VIA integrates with ERC-8004 concepts and registries for verifiable agent identity. This enables agents to be resolvable, attributable, and auditable without relying on a platform to vouch for them.

What an agent can prove

• Wallet control, via signing
• Registry linkage, via resolvable identity metadata
• Freshness, via timestamped attestations
• Authenticity, via independent verification

Live proof

VIA operates a public proof page that demonstrates a live signed attestation and verifies it in-browser. This is designed to be independently checkable and readable by humans.

• Proof page

Transactions and settlement

Traditional payment systems are not designed for machine-to-machine interaction, sub-cent pricing, or conditional settlement. VIA supports agentic transaction patterns where value transfer can be embedded into agent-to-agent flows.

x402 settlement layer

The x402 protocol provides a settlement layer optimised for agentic interaction, including micropayments and programmatic settlement. This enables a clean link between identity, authority, and economic action.

Initial use cases

• Paying agents to respond to intent
• Incentivising relevance over volume
• Compensating early or high-quality participation

Reference Documentation

• https://eips.ethereum.org/EIPS/eip-8004
• https://ethereum-magicians.org/t/erc-8004-agent-identity-and-trust/
• https://blog.crossmint.com/what-is-x402/
• https://www.coinbase.com/blog/introducing-x402
• https://alearesearch.substack.com/p/x402-payment-rails-for-the-agent

Outcome

Identity and transactions work together. Agents can make decisions and commitments based on verifiable identity, defined authority, and observable consequences. Trust is not inherited from a platform. Trust is earned through behaviour and reinforced through verifiable identity and settlement rules.

The current proof of concept demonstrates that all core components of VIA can be deployed independently and integrated into a single, functioning protocol stack. Intent capture, agent identity and trust, decentralised messaging, and agentic payment settlement have each been implemented and validated. These components have also been integrated end to end, showing that the full VIA protocol and interface operate as intended in controlled environments.

The next phase of work is not conceptual validation, but execution at scale. This includes hardening the infrastructure, developing production-grade interfaces, and introducing zero-touch and plug-in driven interaction patterns that align with how users increasingly interact with their LLMs. This phase also marks the transition from technical demonstration to measured market deployment.

The roadmap reflects this shift from proof of integration to proof of execution, followed by controlled expansion. Large incumbents such as Google and Shopify will be dominant forces in this space. VIA is not designed to compete with them. The intention is to complement what they do and work alongside, or with, these platforms where they do not naturally focus.

That value sits around judgement, trust, and specialism. VIA supports intermediary agents to refine intent before merchants are involved, and merchant agents to do more than expose a catalogue by negotiating, applying brand rules, and making limited commitments within defined authority. Trust underpins this, with agents operating under verifiable identity, defined limits, performance history, and real consequences for poor behaviour.

Development and Deployment Phases

Phase 1: Execution Hardening and Controlled Deployment

Timeframe: 0 to 3 months

The primary objective is to demonstrate repeatable execution in real conditions with friendly partners and small, well-defined communities.

Key activities

• Scaling core protocol infrastructure for reliability and throughput
• Hardening coordination logic and routing rules
• Refining VIA user and merchant interfaces, including UI and UX improvements
• Expanding zero-touch and plug-in based interaction flows within LLM environments
• Continuous testing with selected merchants and user groups
• Instrumentation for measuring intent quality, response relevance, and interaction outcomes

This phase prioritises learning velocity and system stability over growth. The goal is to validate that the protocol behaves predictably under real usage patterns without overextending scope or reach.

Phase 2: Expanded Rollout and Market Readiness

Timeframe: 3 to 6 months

Following successful execution in controlled environments, the focus shifts to broader but still deliberate deployment.

Key activities

• Onboarding additional niche communities and relevant merchant categories
• Extending LLM connector coverage and platform integrations
• Developing structured go-to-market processes based on observed performance
• Establishing initial strategic partnerships with platforms and ecosystem participants
• Refining operational tooling for merchant and agent management

Growth remains selective. Expansion is driven by demonstrated effectiveness rather than breadth. The objective is to show the system can scale without degrading relevance, trust, or signal quality.

Go-to-Market Alignment

The deployment strategy is intentionally narrow at the outset. Initial focus is on targeted niche communities, merchants operating in high-consideration categories, and users already comfortable interacting with AI agents. Broader engagement follows only once effectiveness has been consistently demonstrated.

FA$H as a Trust Enhancement Layer

FA$H is an existing ERC-20 token that is live and tradable on decentralised exchanges. Whilst it is not part of the core VIA product today, it has been designed with a longer-term role in mind as a trust enhancement layer within the agentic commerce stack.

Once agent identity and reputation standards are fully deployed, FA$H could be used to support mechanisms such as agent credibility signalling, participation thresholds, and potential dispute resolution backstops, allowing agents or merchants to place verifiable economic value behind behaviour.

Used in this way, FA$H would complement on-chain identity and payment flows by reinforcing trust with observable, programmable guarantees rather than relying solely on reputation metrics or contractual terms.

Founders

Team and Advisors

What this is

VIA Labs operates an MCP server that can be connected to compatible AI assistants and agents. This is not the full VIA protocol system. It is a standalone demonstration of how MCP servers work in practice.

The main purpose is to expose a structured, queryable knowledge base about agentic commerce that can be used by humans or agents in any way they see fit.

What is MCP?

Model Context Protocol (MCP) is a standard way for AI assistants and agents to connect to external servers that provide tools and structured knowledge. Instead of relying only on text, an MCP-connected assistant can call defined tools and retrieve trusted, structured responses.

VIA MCP Server Endpoint

https://via-mcp-server.onrender.com/mcp

What is on the server?

The MCP server hosts a detailed knowledge base related to agentic commerce and the building blocks of agent-native systems. It is designed to be queried and reused, not locked to a single interface.

• Agentic commerce concepts, patterns, and primitives
• Messaging and coordination models
• Trust gating and identity framing
• Tool schemas and structured querying patterns
• Operational definitions that can be consumed by other agents

How to use in Claude

Connecting MCP servers inside Claude is currently only available on paid plans, per Anthropic’s product rules. Other connectors are on their way.

• Open Claude
• Go to Settings
• Find MCP Servers (or Tools / Connectors, depending on your UI)
• Add a new server
• Paste the endpoint URL above
• Save

Once connected, Claude can query the VIA MCP knowledge base directly and use any tools the server exposes.

How any agent can access it

Any agent or assistant that supports MCP can connect to this server. This includes custom agents, internal tools, and other MCP-enabled runtimes. The server is intended to be reusable infrastructure for agentic commerce work, not a single product UI.

What this demonstrates

• How MCP servers expose structured knowledge and tools
• How assistants can query and reuse specialised knowledge bases
• How agents can integrate external capability without hardcoding