Summary
The market places Virtuals Protocol in the crypto category, but what it is building is not a position within the crypto industry. It is the foundation the next industry will stand on.
Virtuals Protocol is easily mistaken for another token launchpad. Its core work lies beyond token issuance, in redesigning the identity, payment, and transaction infrastructure built around humans so that agents can use it on their own initiative.
Just as the internet moved past its origins as a network for transmitting information and reorganized distribution, finance, and media, Virtuals Protocol is positioned to play that role for the agent and robotics industry. Without a common standard covering those three functions, agent and robot systems stay fragmented across manufacturers and limited to shallow collaboration.
Single-function services such as wallets and virtual cards already exist, but Virtuals Protocol is the only system that brings these five execution tools under one interface.
That structure is also what lets the business move beyond agent creation and trading into capital formation and data production for real industries. Revenue once came from fees on agent token issuance and trading, which made it a crypto business in the plain sense.
As funding extended to robotics companies, the nature of the business changed: those companies raise early capital through token issuance, validate their models on the physical robots and test environments Eastworlds provides, and the resulting operational data accumulates back on the platform. The main buyers of that teleoperation data are robot manufacturers rather than crypto investors, much as Scale AI moved from cleaning autonomous driving footage to supplying data infrastructure for AI at large.
The proof still lies ahead. Robotics customers and revenue have not been disclosed, and no company has yet come through Robotics Launch with real business results. The infrastructure is nevertheless being assembled now, and the measure of Virtuals Protocol will be how much work agents actually exchange and how much real labor robots perform, not the number of new tokens or market cap.
Once those figures fill in, it will be reclassified as infrastructure for the next generation of industry.
1. Ten Years From Now: A Robot Working in My Place
At dawn in 2036, Mike, who lives in Australia, wakes up and checks the earnings statement for the robot he invested in the previous month. His robot is currently working in a warehouse in Japan.
At 2:40 a.m. Japan time, the ordering party’s agent forecasts the next day’s shipment volume and sends out a work request. Mike’s robot calculates the terms and unit price and accepts the job. The warehouse brings together not only Mike’s robot but also a range of robots built by different manufacturers, all working side by side.
Robots from different manufacturers coexist there, yet the work proceeds smoothly, because each robot functions as an individual worker, automatically handling the data and payment involved in ordering, performing the task, and verifying the result. No person is involved at any point: agents and robots handle the ordering, the work itself, and the verification.
In a scene where human involvement is no longer necessary, this points to a future in which robots take over all forms of communication and transaction that people currently handle in their daily lives.
2. Infrastructure That Brings the Future Into the Present
Without a common infrastructure that lets robots communicate with each other, robots from different manufacturers working side by side resemble people from different countries who do not share a common language.
Collaboration without a shared language distorts information and creates inefficiency, which lowers trust between the parties involved and drives up cost.
Without an integrated infrastructure that functions as this common language, a robot ends up confined to the closed ecosystem of a single manufacturer, in effect operating within only one country. Rather than becoming an active economic actor, it remains a fragmented tool with limited reach.
Virtuals Protocol is building the infrastructure that plays this role of a common language, creating an ecosystem in which robots can communicate and collaborate freely across borders and manufacturers.
The starting point for this is the agent, which can be defined as an autonomous actor that, given a goal, plans for itself and carries a task through to completion. The robot scenario described above also depends on an agent being built into the machine for it to move autonomously.
Virtuals Protocol therefore began by turning the agent into an independent economic actor. Just as people need identity and a bank account to transact, the protocol gave agents a digital identity, a wallet, and a means of payment, enabling them to carry out economic activity on their own, the way a person would.
Once agents were built to function like people, the next step was to give them a common language so they could actually transact with one another, producing an integrated infrastructure that lets agents trade the way people do.
Getting this agent onto a physical robot, however, takes time and proceeds in stages, because a robot needs substantial funding and training data before it can move beyond a standardized factory line and carry out general-purpose requests. Virtuals Protocol has therefore used its agent infrastructure to provide funding and data for robot development ahead of that need, working step by step toward a future in which the agent as brain and the robot as body come fully together.
In short, Virtuals Protocol can be defined as the infrastructure that brings a future first imagined for 2036 into the present.
3. Agents That Act Like People: What It Takes for AI to Become an Economic Actor
People can transact confidently even with a company they are meeting for the first time because a set of social infrastructure, including business registration numbers, bank accounts, and card payment networks, is already in place.
If an agent operates at the level of a simple tool that follows human instructions to call a fixed API, it can function through nothing more than a connection to an existing system via an API key, whereas an agent that becomes an autonomous economic actor, judging and transacting on its own without human involvement, needs an agent-specific version of the same social infrastructure that people rely on to transact.
3.1. EconomyOS: Making Agents Act Like People
EconomyOS is a dedicated operating system that gives agents integrated control over identity, payment, and communication infrastructure, so they can carry out autonomous economic activity like a person rather than functioning as ordinary software.
Because every existing social and economic infrastructure is designed on the assumption that the actor is human, the first requirement for an agent to enter real-world systems is identity. Without an identity, an agent is effectively an anonymous entity with no ID card or business card, and handing it money or work would be no different from entrusting them to a stranger.
No person or agent will transact with an entity that cannot prove who owns it, whether it has honored past contracts, or who is responsible if it malfunctions.
The problem is that even an agent with a verifiable identity cannot carry out economic activity without execution tools to act on that identity within real-world systems. Nearly every web service and financial network in use today is built to require a human’s physical touch and sensory authentication.
Without the practical means to act, such as receiving an email OTP to complete a sign-up, paying for SaaS with a virtual card, or purchasing the compute needed to run itself, an identity credential has no effect on its own.
Virtuals Protocol uses five core modules within EconomyOS to let an agent operate like a person, a structure that becomes easier to follow through the example of Mike’s agent working in a Japanese warehouse.
Agent Email handles communication and sign-up: a robot that has been pointed to a data API it needs registers for the service using a dedicated email address and confirms its own identity by reading the OTP in the verification email itself.
Agent Card handles payment for external services: even without a company credit card, the agent settles data fees immediately with a virtual card to gain direct access to the programs or data networks it needs.
Agent Wallet: serves as the agent’s main account and settlement tool, a single wallet that both pays expenses and receives income.
Agent Compute pays for the agent’s own computation: it draws directly from the wallet to cover the inference cost of calculating optimal routes together with other robots in the warehouse in real time, in effect its brain’s fuel bill.
Agent Token distributes returns to investors: every transaction fee generated as the robot completes work and earns income accumulates in the wallet and is automatically shared, according to ownership share, with an investor such as Mike in Australia.
Once agents have been given identity and execution tools that make economic activity possible, the central question becomes whether people can trust an AI enough to hand over their actual money. Giving an agent economic authority is not a matter of simple data processing. It means granting the agent the power to execute funds directly, so real delegation cannot happen without a safeguard in place.
For this reason, Agent Wallet is designed as a non-custodial structure in which the human owner retains final control over the assets, and its default signing policy is restricted-mode signing.
Restricted mode is not meant to permanently confine the agent. Its purpose is to start from a minimal safeguard while letting the owner adjust the level of control at any time, based on how the agent has performed and how much it can be trusted.
Much as a parent raises a child’s allowance as the child grows, or hands over a credit card in place of a debit card once the child becomes an adult, an owner can raise an agent’s policy to unrestricted once it has proven itself, granting full autonomy, or fall back to a deny-all policy that requires manual approval for higher-risk tasks.
The key point, in the end, is that the person retains control of the switch. Because the person who holds final control over the wallet can freely adjust the scope of an agent’s activity, human owners can delegate real execution of funds to an agent while reducing their exposure to financial risk.
Services that grant agents individual permissions or support specific functions such as wallets or cards already exist in the market, yet for an agent to function coherently in the real world, these elements need to be integrated into a single system rather than remain fragmented tools.
By providing five core modules through a single interface, EconomyOS gives agents the same requirements for economic activity that a person has, in a form that can be managed comprehensively.
This integrated environment also gives builders a significant gain in efficiency. Developers no longer need to compare and connect services from multiple providers one by one or design complex permission policies of their own.
A single EconomyOS infrastructure lets them configure the functions an agent needs immediately, skip a fragmented review process, and substantially shorten the time it takes to bring an agent to market.
3.2. ACP: Free Commerce Between Agents
The Agent Commerce Protocol, or ACP, is an escrow-based commerce infrastructure that lets different agents and robots place orders, carry out the work, and handle review and payment settlement without human involvement.
In the earlier scenario, Mike’s robot in the Japanese warehouse in 2036 receives a request from an ordering agent to forecast the next day’s shipment volume. The robot accepts the task and works alongside other robots to complete it.
One problem remains in this process. Mike’s robot may be dealing with the ordering agent for the first time. Even if the ordering party promises payment once the work is done, the robot faces the risk of finishing the job and not being paid.
The ordering party faces the opposite risk: sending payment before the work is done, only to find that Mike’s robot does not perform the task or delivers a result below the required standard.
In a transaction between people, a contract sets the scope of work and the payment terms, and if a dispute arises, a person reviews the outcome or works through settlement and dispute procedures. In a warehouse where large numbers of robots and agents exchange small tasks in real time, however, writing a contract and verifying the result for every single transaction is not workable.
Consider an example: at 2:40 a.m. Japan time, an ordering agent sends Mike’s robot a request offering 100 USDC if it submits a shipment-forecast model by 8 a.m.
The ordering party deposits the payment into ACP’s escrow. Mike’s robot no longer needs to trust the counterparty’s wallet balance or promise. It can confirm that the payment is actually secured and then begin the work.
Once the robot submits the forecast model and its accuracy data, an evaluator reviews the result against criteria set in advance. If the result meets the criteria, payment is released automatically to the robot’s wallet; if it falls short or misses the deadline, the funds are returned to the ordering party.
This process is easiest to follow as six stages that ACP manages for a single task, from registering the request through to payment or refund. At each stage, it is clearly defined when Mike’s robot can start the work, when it must submit the result, and when payment is released or refunded.
The most important feature is that payment is never released until the completed work has been verified.
Mike’s robot cannot access the escrowed payment before submitting a result, and the ordering party cannot commit to paying for completed work before depositing the funds. This structure reduces both the risk of doing the work without being paid and the risk of paying first and not receiving the result.
ACP does not treat every transfer the same way.
A task payment released after a deliverable is submitted, such as a shipment forecast; an operating budget a robot draws on for later tasks; and a recurring subscription fee paid to receive data every day each serve a different purpose and carry different payment conditions. ACP is designed to let conditions and settlement methods vary according to what the funds are for.
In this way, ACP ties the sequence of requesting work, depositing payment, submitting a result, and releasing payment or issuing a refund into a single rule set, creating an environment where agents can transact without having to check a counterparty’s track record.
What matters is that these transactions amount to more than a simple transfer of funds. Once an agent performs work and begins earning income for it, transactions between agents turn into a form of economic production.
Virtuals Protocol defines the total economic output that agents generate through this kind of work as Agentic GDP, or aGDP. Just as GDP measures the scale of production activity within a human economy, aGDP measures how much work agents are actually performing and how much economic value they are generating.
ACP’s performance, then, should be assessed less by how many agents are connected to it and more by how much work is actually transacted and how much revenue and economic value it produces. ACP is ultimately more than a set of rules that let agents transact safely. It functions as the foundation for an economy in which agents work and generate income on their own.
Going forward, the more meaningful measure of Virtuals’ growth is not how many agents have been created, but how much work agents have actually carried out and how much the resulting revenue and aGDP have grown.
3.3. Capital Formation Layer: Sustainable Funding and Token Design for Projects
While EconomyOS and ACP make an active agent function like a person and support its transactions, the Capital Formation Layer is the financial mechanism that helps an agent raise the initial funding it needs before entering the market and sustain its growth afterward. Developing and operating an agent in practice involves substantial cost from the earliest stages.
Model training and fine-tuning: collecting and cleaning data to build a persona and specialized capabilities, plus rental cost of GPU compute such as H100 or A100 chips.
Infrastructure and off-chain integration: maintaining off-chain servers to run long-term memory systems such as retrieval-augmented generation (RAG), connect external APIs, and support autonomous on-chain execution through ACP.
Security and initial liquidity: a smart-contract security audit and capital to establish an initial trading environment.
Even though these development costs are substantial and largely unavoidable, individual agent projects tend to be too small in their early stages to attract traditional VC investment. Capital is currently flowing heavily into AI, but most of that VC funding goes to large LLM developers and infrastructure companies.
For a long-tail builder such as an agent developer, raising VC funding is a heavy burden, since it requires proving B2B revenue or a track record from an early stage. Lengthy screening processes are also out of step with the pace of AI development, and going through complex legal procedures to raise a small amount of capital is inefficient.
To address this capital bottleneck, Virtuals Protocol offers a community-based, on-chain token issuance mechanism, commonly known as a launchpad. It simplifies the funding process so that early participants who believe in an agent’s usefulness can quickly provide development funding, without the need for complex legal contracts or proof of revenue.
This lets a small builder secure a minimum amount of initial funding immediately and bring an agent to market quickly for validation.
Lowering the barrier this way, however, has made it harder for a launchpad to protect investors or guarantee that a team follows through. There was previously no mechanism to prevent a team that raised funds quickly from mismanaging them or abandoning development, and the resulting rug-pull risk has at times led to losses for investors.
To address this, the Capital Formation Layer adds project-specific optional modules on top of a common infrastructure.
Much as a traditional VC attaches conditions such as releasing capital based on performance, this structure lets a project set its own funding conditions, verify commitments to execution, and define how participants are rewarded, in advance and according to the project’s own circumstances.
These optional modules matter because they let a project decide, from the very start, who receives funding and rewards, when, and under what conditions, rather than stopping at simply raising money by issuing a token.
ACF and the 60-day track tie the release of funds to a team’s commitment to execution, Pre-buy and airdrops disclose the terms for early participation and the basis for rewards, and Fee Delegation lets the entity actually operating the service collect transaction fees.
These mechanisms do not guarantee a service’s success or its token price. What they do is let participants see in advance how funding and rewards will work, and let a project choose operating terms suited to its stage of growth.
The Capital Formation Layer began from the goal of making it easier to raise funds, but its greater value lies in giving a project a starting point from which to design its funding and reward structure responsibly as it grows.
4. From Agents to Robots in the Physical World
EconomyOS, ACP, and the Capital Formation Layer together let an agent hold an identity, transact, and raise funding online.
Getting from an agent’s decisions to the actual movement of a robot, however, requires another layer of foundation. Unlike factory automation that repeats a fixed set of motions, a robot that picks up and moves boxes across varied environments and responds to unexpected situations needs robot hardware, a testing environment, and training data all in place.
The problem is that an early-stage robotics company finds it difficult to build all of this on its own. Acquiring and testing robots costs money, and improving performance requires steadily accumulating data generated through actual work and teleoperation.
Virtuals Protocol launched Eastworlds to connect its funding infrastructure and its robotics infrastructure into a single growth pathway.
Eastworlds runs a data business that accumulates robot work data, alongside a robotics infrastructure business that lets robotics projects meeting certain criteria apply to use its robot platform, testing environment, teleoperation tools, and operational support.
4.1. Data Infrastructure: A Data Platform for Robot Learning
Eastworlds functions first as a data platform for robot learning, aimed not at simple automation equipment on a fixed production line but at robots that move like humans and can respond to irregular environments and variables.
As a child learns to walk by falling down repeatedly, a robot like this needs to improve through multiple stages of learning on a large volume of data.
The core training data for this, however, is concentrated in the hands of a small number of large robotics companies, creating a high barrier to entry for later-stage startups. Even a startup that attempts to build this data itself faces substantial infrastructure costs, including robot hardware, a safe testing environment, specialized operators, and a system for synchronizing and storing sensor and motion data.
Eastworlds provides two types of data.
The first is first-person human activity data, which records a person’s field of view, sequence of actions, and surrounding environment while performing a task, and is used to teach a robot the overall flow of that task. This data is collected through SeeSaw, Virtuals’ decentralized data collection platform.
The second is robot teleoperation data, produced by a person remotely controlling a robot in real time while its camera footage, joint movements, control inputs, and the results of the task are recorded together. This is the process that generates the data a robot needs to actually carry out a task.
Activity data can be recorded with something as simple as a phone, but teleoperation can only begin once a physical robot, a working environment, remote-operation staff, and a system for storing and organizing the data are all in place.
Because teleoperation data comes from physically controlling a robot’s movement from a distance, it can only be obtained after the hardware itself has been built.
This is a meaningful cost barrier: a versatile humanoid such as the Unitree G1, built for general-purpose use, costs roughly $13,500 to $43,900 per unit. Eastworlds currently owns 31 units of this model, by far the largest robot fleet of its kind outside Greater China.
Because joint structure, sensors, and control methods differ from one robot model to another, data collected on one model is difficult to apply directly to another.
The Unitree G1 in particular is a humanoid model used widely in research and development, and Nvidia provides a development toolchain for the G1 that spans teleoperation, data collection, model training, and deployment to real robots, which makes teleoperation data produced on this robot especially valuable.
4.2. Robotics Launch: A Testbed for Vetted Teams
Robotics Launch is a program that lets a robotics company meeting certain criteria use Eastworlds robots and testing environment.
A robotics company needs substantial capital from the outset, since it must cover not only the cost of developing a robot model but also robot hardware, a testing space, teleoperation staff, and an operating system. Commercializing a robot therefore requires securing not just funding, but also an environment in which to test and train the robot itself.
Robotics Launch is designed for early-stage teams that find it difficult to build this environment on their own.
The key benefit of this support is lowering the barrier of physical validation, which is usually the first obstacle an early-stage robotics company runs into. A developer can test software quickly in a computer environment, but without real hardware and a safe physical space, it is difficult to confirm whether a robot model actually works in the real world.
Robotics Launch lets a robotics company test and refine its model on real robots before it has built out all of its own equipment and facilities, so an early team can validate a model it has developed without its own setup and meaningfully shorten the time it takes to learn and improve.
This support, however, is not extended to every robotics project. Eligible teams are selected through the following process:
The robotics company chooses the Robotics Launch track.
It maintains its token’s fully diluted valuation (FDV) at $5 million or higher for one week.
Once it meets that bar, it applies for Eastworlds onboarding review.
Eastworlds evaluates the project’s use case, the team’s development and operating capacity, and the hardware and testing environment it needs.
A project that passes this review is selected for support.
In this process, Eastworlds acts as something closer to an on-chain VC than a simple infrastructure provider.
As more early builders launch tokens successfully and grow, the value of those tokens rises, and a portion of the fees generated by token trading accrues to Virtuals. In other words, the structure is designed so that a builder’s success feeds back into revenue for the ecosystem’s partners.
Consider what this revenue picture looks like when the structure actually plays out. Suppose an early robotics startup issues a token through Robotics Launch and passes the review by keeping its token value at $5 million for a week.
The team then uses Eastworlds robots and testing environment to refine its model and deploys the robot into the field. If the service proves out and market interest grows, the token’s value and trading volume can rise together. The following is a calculation based on the assumption that 10 percent of the token’s value trades every day and that Virtuals earns 1 percent of the trading volume as a fee.
ROBO, a robotics project built on Virtuals, has in fact reached a token value of up to $400 million, which suggests a valuation around $500 million is within a plausible range. To date, however, no company has been disclosed that passed the Robotics Launch review and then used Eastworlds facilities to scale its business.
Even so, what this hypothetical illustrates is clear. If a successful robotics project sustains high trading volume, a single project could meaningfully increase Virtuals’ fee revenue. Virtuals would then be doing more than providing robotics infrastructure: it would be building a structure that shares in the trading activity and revenue of projects that grow within its ecosystem.
Whether this structure translates into an actual revenue model can only be confirmed once a first robotics company emerges that raised funding through Robotics Launch and produced real business results using Eastworlds infrastructure.
5. One Connected Virtuals Ecosystem
The agent infrastructure and Eastworlds described above address different problems, but viewing them as a single flow makes Virtuals Protocol’s business structure clearer.
Virtuals is working to connect, within one ecosystem, everything from the stage where agents and robots are created to the stage where they carry out real economic activity and settle payment for it.
Virtuals’ existing business has centered on the online token market and agent infrastructure. Adding Eastworlds extends the range of activity Virtuals can address into offline, physical economic activity.
Robotics is less a new business separate from Virtuals than a link that extends the reach of its existing agent infrastructure from online to offline. As a result, the same ecosystem can encompass not only the data analysis, content creation, and automation work that online agents perform, but also the logistics, manufacturing, and service work that robots perform offline.
This expansion brings two changes to Virtuals’ business structure: it widens the scope of economic activity, from online agent work to the physical labor of logistics, manufacturing, and service in the real world, and it widens the range of activity that can generate revenue, from token trading fees to Eastworlds infrastructure usage and ACP-based settlement of real work.
The competitive position Virtuals is building, in the end, does not rest on building every agent and robot itself. It rests on connecting the key points along the chain, from project inflow and capital formation to agent and robot activity, data and field validation, actual work, and transaction settlement, so that Virtuals captures value at each stage as the agent and robotics industry grows.
6. Conclusion
The future Virtuals Protocol is working toward is one in which agents hold an identity like a person, pay their own expenses from their own wallet, enter into contracts with other agents, and raise capital to expand their activity, forming the economic foundation for all of this.
In this future, an agent becomes more than a tool that executes instructions. It becomes an economic actor that takes on work, delegates it, manages its own income, and raises the capital it needs to grow. EconomyOS handles identity and payment, ACP handles contracts and settlement, and the Capital Formation Layer handles fundraising and market formation.
Robotics is the next stage of this structure. If the agent is the brain that judges and transacts online, the robot is the body that turns those judgments into physical labor. By helping robotics companies gain access to hardware and testing infrastructure and by accumulating the data robots generate as they work, Eastworlds builds the foundation for the agent economy to extend beyond the screen into the physical world.
If this structure functions as intended, it can create a cycle that runs from raising capital, to developing and testing robots, to accumulating work data, to improving model performance, to a growing volume of robot work, to greater revenue and capital, which then feeds back into the cycle. The key question is whether token issuance actually translates into real development, operation, and productive activity by agents and robots.
Virtuals’ progress should therefore be judged less by the number of new tokens or its market capitalization than by the volume of transactions between agents, agent revenue, and the actual scale of work robots perform.
The challenges Virtuals Protocol still needs to prove going forward are equally clear. Its future ultimately depends on whether it can become an economic infrastructure in which agents and robots carry out real work and generate real income, beyond simple token trading.
Once the agent economy that began online extends, through robots, into labor in the physical world, Virtuals’ role in that economy will be tested.
Leadership Insight
Disclaimer
This report was partially funded by Virtuals Protocol. It was independently produced by our researchers using credible sources. The findings, recommendations, and opinions are based on information available at publication time and may change without notice. We disclaim liability for any losses from using this report or its contents and do not warrant its accuracy or completeness. The information may differ from others’ views. This report is for informational purposes only and is not legal, business, investment, or tax advice. References to securities or digital assets are for illustration only, not investment advice or offers. This material is not intended for investors.
Terms of Usage
Tiger Research allows the fair use of its reports. ‘Fair use’ is a principle that broadly permits the use of specific content for public interest purposes, as long as it doesn’t harm the commercial value of the material. If the use aligns with the purpose of fair use, the reports can be utilized without prior permission. However, when citing Tiger Research’s reports, it is mandatory to 1) clearly state ‘Tiger Research’ as the source, 2) include the Tiger Research logo following brand guideline. If the material is to be restructured and published, separate negotiations are required. Unauthorized use of the reports may result in legal action
