Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Public materials describe Virtuals Protocol as an onchain ecosystem for autonomous AI agents that need to coordinate work, transact value, and settle outcomes with both humans and other agents. The same materials frame token-based coordination as the mechanism for aligning capital formation, participation, and incentives with agent output and economic contribution.
Virtuals Protocol White Paper: https://whitepaper.virtuals.io/
(b) Operational priorities
The public record ties ongoing operations to Virtuals Protocol’s multi-layer agent operating-system architecture, spanning identity and banking, commerce, capital formation, physical labor, and law and governance. Public sources state that strategic direction, capital allocation, and protocol upgrades evolve through onchain governance, while ecosystem incentives, agent launches, agent-to-agent commerce, and treasury-directed trading-fee flows support continuing development and operations. Virtuals Protocol White Paper: https://whitepaper.virtuals.io/
(c) High-level project overview
At a high level, Virtuals Protocol is described as an economic operating system for agents that provides infrastructure for autonomous agents to transact, raise funds, coordinate work, and participate in commerce. The public whitepaper organizes the system around five interconnected layers: identity and banking, commerce, capital formation, physical labor, and law and governance.
Virtuals Protocol White Paper: https://whitepaper.virtuals.io/
(d) Primary token functions
The public source set states that $VIRTUAL functions as the base liquidity pair and transactional currency across agent interactions and agent token markets. It also states that locking $VIRTUAL mints veVIRTUAL, which provides governance power in the Virtuals ecosystem.
Virtuals Protocol White Paper: https://whitepaper.virtuals.io/ Staking: https://whitepaper.virtuals.io/info-hub/usdvirtual/staking
(e) Control surface reliance
The public control surface relies materially on veVIRTUAL governance. Public governance materials state that any wallet holding at least 0.10% of total veVIRTUAL supply can submit a proposal, that proposals move through a 72-hour comment window followed by a 72-hour vote, that 25% quorum is required, and that 50% + 1 determines the outcome once quorum is met.
Governance: https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Jansen Teng | Core Contributor | Former BCG consultant, serial entrepreneur in deep tech focused on AI and biochemistry, and Imperial College London graduate. |
Wee Kee | Core Contributor | BTC / ETH participant since 2016, former BCG consultant and private-equity professional, and Imperial College London graduate. |
Bryan | Core Contributor | AI researcher at the Adaptive and Intelligent Robotics Lab at Imperial College London. |
Brianna | Core Contributor | Product and data engineering background and Imperial College London graduate. |
Jae-Sonn | Core Contributor | Former BCG consultant turned startup operator who scaled a digital bank from scratch and is described as scaling ACP. |
Celeste | Core Contributor | Former Lead Data Scientist at Oliver Wyman, former Senior Data Scientist at Grab, and holder of a master’s degree in Computer Science from Georgia Tech. |
Sally Wang | Core Contributor | BTC / ETH participant since 2018. Former venture capitalist turned builder, with a background in cross-border payments and crypto infrastructure |
Chris | Core Contributor | Former founder of multiple UCI professional cycling teams, and graduate of the University of Pennsylvania. |
Sean | Core Contributor | Former Gartner Research and former Navy. Carnegie Mellon University graduate. |
Javier | Core Contributor | 5+ years of experience in AI and data science. Engineering background from Imperial College London. Experience developing LoRAs for Stable Diffusion, nested LLM pipelines, and voice models. |
Yifei You | Core Contributor | Former Senior Product Expert at Alibaba and VP Business at BlueCity. Serial entrepreneur. Crypto participant since 2020. London Business School graduate |
Yujie | Core Contributor | Former Bain consultant. Full-time AI builder. |
Koo Huang | Core Contributor | BTC / ETH / ICP participant. Former engineering head at Bybit, where he led product initiatives across DEX, mining, staking, and trading automation. |
Kahwai | Core Contributor | Built L1 blockchain infrastructure, crypto mining farm management tools, and crypto algorithmic trading bots. |
Matthew | Core Contributor | Engineering background from Cambridge University. Former BCG consultant. |
Hanan | Core Contributor | Former Gates Foundation and Deloitte Ventures. Crypto investor at Outlier Ventures. Focused on incentive design, founder support, and shaping the agentic network. |
Harry | Core Contributor | Former Bain Manager |
Xie Ong | Core Contributor | Former actuary and global development specialist. LSE graduate. |
Khoon Kheng | Core Contributor | Former McKinsey consultant and PETRONAS data strategist, and University of Cambridge graduate. |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
No public data found in cited sources. |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
No public data found in cited sources. |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
The public record supports a tokenholder-governance structure built around veVIRTUAL rather than a separately disclosed public legal DAO wrapper. Public sources describe governance as transparent and permissionless and state that strategic direction, capital allocation, and protocol upgrades evolve through onchain governance.
Governance: https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
(b) Contract/admin powers
Public sources state that any wallet holding at least 0.10% of total veVIRTUAL supply can submit a proposal, that proposals move through a 72-hour comment window and a 72-hour vote, that 25% quorum is required, and that a simple majority of 50% + 1 determines the outcome once quorum is met. The same public governance page states that passed proposals become eligible for execution and that governance decides how the protocol grows, what it funds, and which risks it accepts.
Governance: https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
(c) Locked-token rights (conditional)
Public sources state that veVIRTUAL is received by locking $VIRTUAL and that governance power is tied to the amount and duration of the lock. Public governance materials state that veVIRTUAL holders may participate in protocol governance, including proposal voting, and that voting power cannot be rented or delegated. Public materials also state that veVIRTUAL holdings may provide eligibility for airdrops, including airdrops associated with agent launches.
Governance: https://whitepaper.virtuals.io/info-hub/usdvirtual/governance Staking: https://whitepaper.virtuals.io/info-hub/usdvirtual/staking
(d) Value accrual & holder rights
Public sources state that the 35% ecosystem allocation sits in a DAO-controlled multi-sig wallet, is dedicated to the ecosystem treasury, and is subject to governance approval before deployment, with emissions capped at 10% per year for the next 3 years. Public launch-module materials state that all launches route 30% of the 1% trading fee to Virtuals Treasury, with launches using the 60 Days module additionally locking the founder's 70% share during the trial period. The public record does not disclose a broader public revenue-distribution right from protocol fees or treasury assets directly to tokenholders
(e) Dissolution authority
No public data found in cited sources.
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
No public data found in cited sources.
(b) IP ownership & control
No public data found in cited sources.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No public data found in cited sources.
(d) Powers over DevCo
No public data found in cited sources.
(e) Contract/admin powers
No public data found in cited sources.
(f) Current economic arrangements and distribution policies
No public data found in cited sources.
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The clearest public DevCo surface in the cited materials is Virtuals Protocol itself. Public terms identify Virtuals Protocol as the operator of the Platform and Services, including launchpad, bridge, staking, and other Dapp access, while official repositories under the Virtual-Protocol organization describe ACP and core protocol-contract components maintained as part of that operating surface. The cited sources do not disclose a separate legal-entity name or jurisdiction for that DevCo surface.
Virtuals Terms of Use: https://app.virtuals.io/terms_of_use.pdf Agent Commerce Protocol (ACP) : https://os.virtuals.io/acp/overview Virtual Protocol Contracts : https://whitepaper.virtuals.io/info-hub/usdvirtual
(b) IP ownership & control
Public terms state that the platform, services, content, and Virtuals trademarks are property of the Company or its licensors or suppliers, and the launchpad agreement states that the Service Provider owns the Intellectual Property Rights in the Service, including the Launchpad and its modifications. The cited public record does not disclose a fuller public repository-control or subsidiary map for the DevCo surface.
Virtuals Terms of Use: https://app.virtuals.io/terms_of_use.pdf Virtuals Launchpad Agreement: https://app.virtuals.io/launchpad_agreement.pdf
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
Public governance materials state that strategic direction, capital allocation, and protocol upgrades are no longer set by a core team alone and instead evolve through onchain governance. Separately, official contract documentation discloses role-gated admin surfaces including AgentFactory with DEFAULT_ADMIN_ROLE and WITHDRAW_ROLE, AgentNft with DEFAULT_ADMIN_ROLE, VALIDATOR_ADMIN_ROLE, and MINTER_ROLE, AgentReward with GOV_ROLE and TOKEN_SAVER_ROLE, and ACP contracts that are UUPS-upgradeable and use OpenZeppelin AccessControl. The ACP and launchpad agreements also state that the operator may determine which AI agents and developers are listed, may remove or delist integrated AI agents, and may remove projects and digital assets from the launchpad at sole discretion. The public record does not disclose a complete public token-administration matrix beyond those governance, role-based contract, and platform-administration surfaces.
Governance: https://whitepaper.virtuals.io/info-hub/usdvirtual/governance Virtuals Protocol Contracts: https://whitepaper.virtuals.io/info-hub/usdvirtual Agent Commerce Protocol (ACP) : https://os.virtuals.io/acp/overview Agent Commerce Protocol Developer Agreement: https://app.virtuals.io/acp_developer_agreement.pdf Virtuals Launchpad Agreement: https://app.virtuals.io/launchpad_agreement.pdf
(d) Powers over Foundation
No public data found in cited sources.
(e) Contract/admin powers
Public agreements state that the Company may determine which AI agents and developers to integrate with and list on ACP, may revoke graduation or require re-work, may delist, reclassify, restrict, suspend, or revert an AI agent to Sandbox status, and may remove a project and its digital assets from the launchpad at any time in its sole discretion. Official protocol documentation separately discloses privileged contract roles across AgentFactory, AgentNft, and AgentReward, and describes ACPRouter as the central router with upgradeable modules for accounts, jobs, memos, and payments.
Virtuals Protocol Contracts: https://whitepaper.virtuals.io/info-hub/usdvirtual Agent Commerce Protocol (ACP) : https://os.virtuals.io/acp/overview Agent Commerce Protocol Developer Agreement: https://app.virtuals.io/acp_developer_agreement.pdf Virtuals Launchpad Agreement: https://app.virtuals.io/launchpad_agreement.pdf
(f) Current economic arrangements and distribution policies
Public terms state that the Company may charge platform fees on platform transactions and may revise those fees at any time, while official protocol-contract documentation states that the backend calls AgentReward.distributeRewards daily to transfer VIRTUAL into AgentReward and update claimable amounts for Protocol, Stakers, Validators, Dataset Contributors, and Model Contributors. The public record does not disclose a more detailed public policy tying protocol-controlled resources directly to equityholders or named DevCo participants.
Virtuals Terms of Use: https://app.virtuals.io/terms_of_use.pdf Virtuals Protocol Contracts: https://whitepaper.virtuals.io/info-hub/usdvirtual
Token Supply & Allocations
Initial Allocation
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
VIRTUAL | Public distribution | Public / Sale | 0.6 | 600000000 | 1.0 | 600000000 | 0 | 0.0 | 0 | 1 | Yes | Public distribution tokens are stated to be in public circulation. All tokens are fully unlocked and vested. Source: https://whitepaper.virtuals.io/about-virtuals-1/usdvirtual-tokenomics/token-distribution | ||
VIRTUAL | Liquidity pool | Liquidity | 0.05 | 50000000 | 1.0 | 50000000 | 0 | 0.0 | 0 | 1 | Yes | Liquidity-pool allocation. All tokens are fully unlocked and vested. Source: https://whitepaper.virtuals.io/about-virtuals-1/usdvirtual-tokenomics/token-distribution | ||
VIRTUAL | Ecosystem treasury | Ecosystem | 0.35 | 350000000 | 1.0 | 350000000 | 0 | 0.0 | 0 | 1 | Conditional | Dedicated to the ecosystem treasury for community incentives and growth initiatives. All tokens are fully unlocked and vested; deployment is governance-gated and emissions are capped at 10% per year for 3 years. Source: https://whitepaper.virtuals.io/about-virtuals-1/usdvirtual-tokenomics/token-distribution |
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
(a) Planned but not yet executed airdrop
No public materials in the cited source set disclose a completed or planned $VIRTUAL token TGE airdrop.
(b) Executed airdrop
No public materials in the cited source set disclose a completed or planned $VIRTUAL token TGE airdrop.
(c) No airdrop planned or conducted
No public materials in the cited source set disclose a completed or planned $VIRTUAL token TGE airdrop.
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: (a) Market maker's name — the market maker's name; (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply; (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable, (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
No public data found in cited sources. |
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair); (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply; (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable, (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
No public data found in cited sources. |
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
No public data found in cited sources. |
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
No public exploit or incident affecting tokenholders or protocol funds was identified in the cited materials as of 2026-04-18. The cited public record instead documents continuing audit coverage and publicly disclosed vulnerability findings, including 32 unique vulnerabilities in the April-May 2025 Code4rena review, 7 issues in the $VIRTUAL staking assessment, and 5 findings (gas-optimization and informational only) in the Genesis token-contract review.
Security Audit Reports: https://whitepaper.virtuals.io/info-hub/security/security-audit-reports Virtuals Protocol Findings & Analysis Report:https://code4rena.com/reports/2025-04-virtuals-protocol Virtuals Protocol Smart Contract Security Assessment: https://4242579099-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Frrll8DWDA3BJwEBqOtxm%2Fuploads%2FOn9IPp8c4x9oIPxOSRxn%2F%24VIRTUAL%20Staking%20Contract%20Audit%20Report.pdf?alt=media&token=8c73810b-27c8-46ae-8b1a-0922e9f5df52 Virtuals Protocol Contracts Security Review: https://4242579099-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Frrll8DWDA3BJwEBqOtxm%2Fuploads%2FzJ0JLeYiaEj32wwEna7w%2FGenesis%20Token%20Contract%20Audit%20Report.pdf?alt=media&token=c0f20c0d-2eb8-4cd0-a848-85c8963a2fc1
(b) Exploit vector summary
No public exploit vector affecting tokenholders or protocol funds was identified in the cited materials. The public security record instead discloses review findings such as unauthorized validator injection through AgentNftV2::addValidator(), delegate-control risk through AgentVeToken.stake() with 1 wei, premature graduation and reward manipulation through flashloan attacks, double execution risk in VirtualGenesisDAO.sol::earlyExecute(), and possible loss of unclaimed agentTokens if a second launch occurs before rewards from the first are claimed.
Virtuals Protocol Findings & Analysis Report: https://code4rena.com/reports/2025-04-virtuals-protocol
(c) Quantified impact
No public quantified loss event affecting tokenholders or protocol funds was identified in the cited materials.
Security Audit Reports: https://whitepaper.virtuals.io/info-hub/security/security-audit-reports Virtuals Protocol Findings & Analysis Report:https://code4rena.com/reports/2025-04-virtuals-protocol Virtuals Protocol Smart Contract Security Assessment: https://4242579099-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Frrll8DWDA3BJwEBqOtxm%2Fuploads%2FOn9IPp8c4x9oIPxOSRxn%2F%24VIRTUAL%20Staking%20Contract%20Audit%20Report.pdf?alt=media&token=8c73810b-27c8-46ae-8b1a-0922e9f5df52 Virtuals Protocol Contracts Security Review: https://4242579099-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Frrll8DWDA3BJwEBqOtxm%2Fuploads%2FzJ0JLeYiaEj32wwEna7w%2FGenesis%20Token%20Contract%20Audit%20Report.pdf?alt=media&token=c0f20c0d-2eb8-4cd0-a848-85c8963a2fc1
(d) Remediation/response taken
Public sources describe ongoing remediation surfaces including independent audits, a bug-bounty / responsible-disclosure process, 24-hour acknowledgement targets, 3-business-day progress updates, and a 15-day resolution target for critical issues. Public audit artifacts also mark multiple staking-review findings as resolved and verified by Zenith, including the autoRenew unfair-advantage issue, lock-index switching risk, 0-week staking risk, maxWeeks accounting issue, and an unbounded-loop issue. The cited public record does not disclose a prior funds-affecting incident response.
Security Audit Reports: https://whitepaper.virtuals.io/info-hub/security/security-audit-reports Virtuals Protocol Findings & Analysis Report:https://code4rena.com/reports/2025-04-virtuals-protocol Virtuals Protocol Smart Contract Security Assessment: https://4242579099-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Frrll8DWDA3BJwEBqOtxm%2Fuploads%2FOn9IPp8c4x9oIPxOSRxn%2F%24VIRTUAL%20Staking%20Contract%20Audit%20Report.pdf?alt=media&token=8c73810b-27c8-46ae-8b1a-0922e9f5df52 Virtuals Protocol Contracts Security Review: https://4242579099-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Frrll8DWDA3BJwEBqOtxm%2Fuploads%2FzJ0JLeYiaEj32wwEna7w%2FGenesis%20Token%20Contract%20Audit%20Report.pdf?alt=media&token=c0f20c0d-2eb8-4cd0-a848-85c8963a2fc1
(e) Current status
No public data found in cited sources beyond the absence of a disclosed prior exploit affecting tokenholders or protocol funds in the reviewed source set and the continued presence of public audit and disclosure programs.
Security Audit Reports: https://whitepaper.virtuals.io/info-hub/security/security-audit-reports Security Policy: https://whitepaper.virtuals.io/info-hub/security/security-policy-responsible-disclosure
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
- (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
- Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
- Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
- Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
- Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
- (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
- Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
- Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
- (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
- Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
- Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
(1) Impact of Regulatory Change on TGE and Listings Public legal materials state that the platform and services are not registered or licensed by any governmental or regulatory authority, that regulatory inquiries or action could impede or limit access to the platform and services, and that the launchpad provider cannot guarantee project success, trading volume, or token value. Public launchpad terms also state that the Service Provider may remove a project and its digital assets from the launchpad at any time in its sole discretion.
(2) Entity-Level Regulatory Impact Public agreements place significant legal-compliance obligations on the protocol’s operating surfaces and counterparties. The ACP and launchpad agreements state that the operator may delist, restrict, suspend, or remove agents or projects, while public legal terms also state that the operator may conduct background or source-of-funds checks and may suspend or terminate access if those checks are unsatisfactory.
(3) Tokenholder Tax Treatment Public legal materials do not provide holder-specific tax advice. They instead state that users are solely responsible for determining and paying applicable taxes and that launchpad clients are solely responsible for tax liabilities associated with payments and distributions tied to their projects.
(4) Jurisdictional & User Access Restrictions Public terms state that users must not be citizens of, located in, or ordinarily resident in Restricted Jurisdictions and must not be controlled by sanctioned or otherwise restricted persons. Public terms state that users must not be citizens of, located in, or ordinarily resident in any Restricted Jurisdictions, must not be subject to UN, BVI, UK, U.S., or EU sanctions or designation lists (including OFAC SDN, OFAC FSE, and the BIS Entity List), and that the Company may suspend or terminate access if background or source-of-funds checks are unsatisfactory.
(b) Protocol, Technology & Security Risks
(1) Bugs and Design Flaws
Public audit artifacts show repeated identification of nontrivial issues across reviewed contracts, 32 unique vulnerabilities in the April-May 2025 Code4rena review, 7 issues in the $VIRTUAL staking assessment, and 5 findings (gas-optimization and informational only) in the Genesis token-contract review. Public launchpad terms also warn of downtime, delays, security breaches, smart-contract failures, bots, exploitative third-party behavior, and other technical defects that could disrupt launches or platform use.
(2) Security Measures & Their Limitations Public security materials state that Virtuals Protocol conducts independent audits for all critical smart contracts, maintains an official archive of completed audits, is actively working with Immunefi on a comprehensive bug-bounty program, has paid out over $30,000 in bounties as of 2025-08-05, and targets an initial response within 24 hours for vulnerability reports. Those same public materials and audit reports also show the limits of those controls: competitive and targeted audits still surfaced multiple issues, even when some later findings were marked resolved and verified, and public terms warn that technical defects, downtime, and security breaches may still occur.
(c) Token Economics, Unlocks & Incentive Risks
(1) Critical Economic Assumptions Public materials describe $VIRTUAL as the base liquidity pair and transactional currency for agent interactions, require token locking to obtain veVIRTUAL governance rights and Genesis-airdrop eligibility, and disclose that 5% of every new launch is automatically airdropped to $VIRTUAL stakers and Virtuals ecosystem participants. Public materials also state that launches using the 60 Days module depend on trading activity, Automated Capital Formation, and treasury / founder fee splits, while tokenomics disclosures state that 60% of supply is in public circulation and 35% sits in an ecosystem treasury. If agent-activity demand, locking participation, or launch-market activity weakens, the protocol’s stated utility, governance participation, and incentive alignment could weaken as well.
(2) Governance Control over Monetary Policy & Rewards Public sources state that veVIRTUAL governance determines strategic direction, capital allocation, and protocol upgrades and that proposals require 0.10% of total veVIRTUAL supply to submit, 25% quorum, and 50% + 1 to pass once quorum is met. Public tokenomics also state that the ecosystem allocation cannot be deployed without governance approval and is capped at 10% annual emissions for 3 years, while staking materials state that 10% of the total daily point supply is allocated through veVIRTUAL voting and may be adjusted in the future. Separately, the Genesis refund-policy page discloses a week-based reward mix across $VIRTUAL staking, points, and ecosystem activity and states that 5% of every new launch is automatically airdropped to $VIRTUAL stakers and Virtuals ecosystem participants. The same governance page further states that passed proposals have already allocated 1% of $VIRTUAL supply to the Sniper Defense & Yield Fund and up to 6% of supply to milestone-based incentives for core contributors.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Virtuals Protocol is solely responsible for the content, accuracy, and legality of its disclosures.