Public

SECURITY AUDIT REPORT

for

VIRTUAL Protocol

Prepared By: Xiaomi Huang

PeckShield
March 10, 2024

1/25 PeckShield Audit Report #: 2024-072

 Public

Document Properties

Client VIRTUAL Protocol

Title Security Audit Report
Target VIRTUAL
Version 1.0
Author Xuxian Jiang
Auditors Daisy Cao, Xuxian Jiang
Reviewed by Xiaomi Huang
Approved by Xuxian Jiang
Classification Public

Version Info

Version Date Author(s) Description

1.0 March 10, 2024 Xuxian Jiang Final Release
1.0-rc March 5, 2024 Xuxian Jiang Release Candidate #1

Contact

For more information about this document and its contents, please contact PeckShield Inc.

Name Xiaomi Huang

Phone +86 183 5897 7782
Email [email protected]

2/25 PeckShield Audit Report #: 2024-072

 Public

Contents

1 Introduction 4
1.1 About VIRTUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 About PeckShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Findings 9
2.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Detailed Results 11
3.1 Manipulation of Account Scores/Proposal Maturity in AgentDAO . . . . . . . . . . . 11
3.2 Suggested Adherence of Checks-Effects-Interactions in AgentFactory . . . . . . . . . 14
3.3 Accommodation of Non-ERC20-Compliant Tokens . . . . . . . . . . . . . . . . . . . 15
3.4 Lack of Founder Score Initialization in AgentNft::mint() . . . . . . . . . . . . . . . . 17
3.5 Improved Protocol Parameters Update Logic in TimeLockStaking . . . . . . . . . . . 19
3.6 Improved AgentNft/AgentDAO Initialization Logic . . . . . . . . . . . . . . . . . . . 20
3.7 Trust Issue of Admin Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Conclusion 23

References 24

3/25 PeckShield Audit Report #: 2024-072

 Public

1 | Introduction

Given the opportunity to review the design document and related smart contract source code of
the VIRTUAL protocol, we outline in the report our systematic approach to evaluate potential security
issues in the smart contract implementation, expose possible semantic inconsistencies between smart
contract code and design document, and provide additional suggestions or recommendations for
improvement. Our results show that the given version of smart contracts can be further improved
due to the presence of several issues related to either security or performance. This document outlines
our audit results.

1.1 About VIRTUAL

VIRTUAL protocol is designed to align incentives for the decentralized creation and monetization of
AI personas for every virtual interaction (gaming, metaverses, online interactions, or beyond). It
creates co-owned, human-curated, plug-and-play gaming AIs by acting as a decentralized factory. In
other words, it makes all sorts of AI characters (that can respond via text, voice and motion) for
different virtual worlds, like games or online spaces. The basic information of audited contracts is as
follows:
Table 1.1: Basic Information of VIRTUAL

Item Description
Name VIRTUAL Protocol
Website https://virtuals.io/
Type Solidity
Language EVM
Audit Method Whitebox
Latest Audit Report March 10, 2024

In the following, we show the Git repository of reviewed files and the commit hash value used in
this audit.

4/25 PeckShield Audit Report #: 2024-072

 Public

• https://github.com/Virtual-Protocol/protocol-contracts.git (480b53f)

And here is the commit ID after all fixes for the issues found in the audit have been checked in:

• https://github.com/Virtual-Protocol/protocol-contracts.git (be42a7d)

1.2 About PeckShield

PeckShield Inc. [12] is a leading blockchain security company with the goal of elevating the secu-
rity, privacy, and usability of current blockchain ecosystems by offering top-notch, industry-leading
services and products (including the service of smart contract auditing). We are reachable at Telegram
(https://t.me/peckshield), Twitter (http://twitter.com/peckshield), or Email ([email protected]).

Table 1.2: Vulnerability Severity Classification

High Critical High Medium

Impact

Medium High Medium Low

Low Medium Low Low

High Medium Low

Likelihood

1.3 Methodology
To standardize the evaluation, we define the following terminology based on OWASP Risk Rating
Methodology [11]:

• Likelihood represents how likely a particular vulnerability is to be uncovered and exploited in

the wild;

• Impact measures the technical loss and business damage of a successful attack;

• Severity demonstrates the overall criticality of the risk.

Likelihood and impact are categorized into three ratings: H, M and L, i.e., high, medium and
low respectively. Severity is determined by likelihood and impact, and can be accordingly classified
into four categories, i.e., Critical, High, Medium, Low shown in Table 1.2.

5/25 PeckShield Audit Report #: 2024-072

 Public

Table 1.3: The Full List of Check Items

Category Check Item

Constructor Mismatch
Ownership Takeover
Redundant Fallback Function
Overflows & Underflows
Reentrancy
Money-Giving Bug
Blackhole
Unauthorized Self-Destruct
Revert DoS
Basic Coding Bugs
Unchecked External Call
Gasless Send
Send Instead Of Transfer
Costly Loop
(Unsafe) Use Of Untrusted Libraries
(Unsafe) Use Of Predictable Variables
Transaction Ordering Dependence
Deprecated Uses
Semantic Consistency Checks Semantic Consistency Checks
Business Logics Review
Functionality Checks
Authentication Management
Access Control & Authorization
Oracle Security
Digital Asset Escrow
Advanced DeFi Scrutiny
Kill-Switch Mechanism
Operation Trails & Event Generation
ERC20 Idiosyncrasies Handling
Frontend-Contract Integration
Deployment Consistency
Holistic Risk Management
Avoiding Use of Variadic Byte Array
Using Fixed Compiler Version
Additional Recommendations Making Visibility Level Explicit
Making Type Inference Explicit
Adhering To Function Declaration Strictly
Following Other Best Practices

6/25 PeckShield Audit Report #: 2024-072

 Public

To evaluate the risk, we go through a list of check items and each would be labeled with
a severity category. For one check item, if our tool or analysis does not identify any issue, the
contract is considered safe regarding the check item. For any discovered issue, we might further
deploy contracts on our private testnet and run tests to confirm the findings. If necessary, we would
additionally build a PoC to demonstrate the possibility of exploitation. The concrete list of check
items is shown in Table 1.3.
In particular, we perform the audit according to the following procedure:

• Basic Coding Bugs: We first statically analyze given smart contracts with our proprietary static
code analyzer for known coding bugs, and then manually verify (reject or confirm) all the issues
found by our tool.

• Semantic Consistency Checks: We then manually check the logic of implemented smart con-
tracts and compare with the description in the white paper.

• Advanced DeFi Scrutiny: We further review business logics, examine system operations, and
place DeFi-related aspects under scrutiny to uncover possible pitfalls and/or bugs.

• Additional Recommendations: We also provide additional suggestions regarding the coding and
development of smart contracts from the perspective of proven programming practices.

To better describe each issue we identified, we categorize the findings with Common Weakness
Enumeration (CWE-699) [10], which is a community-developed list of software weakness types to
better delineate and organize weaknesses around concepts frequently encountered in software devel-
opment. Though some categories used in CWE-699 may not be relevant in smart contracts, we use
the CWE categories in Table 1.4 to classify our findings. Moreover, in case there is an issue that
may affect an active protocol that has been deployed, the public version of this report may omit
such issue, but will be amended with full details right after the affected protocol is upgraded with
respective fixes.

1.4 Disclaimer
Note that this security audit is not designed to replace functional tests required before any software
release, and does not give any warranties on finding all possible security issues of the given smart
contract(s) or blockchain software, i.e., the evaluation result does not guarantee the nonexistence
of any further findings of security issues. As one audit-based assessment cannot be considered
comprehensive, we always recommend proceeding with several independent audits and a public bug
bounty program to ensure the security of smart contract(s). Last but not least, this security audit
should not be used as investment advice.

7/25 PeckShield Audit Report #: 2024-072

 Public

Table 1.4: Common Weakness Enumeration (CWE) Classifications Used in This Audit

Category Summary
Configuration Weaknesses in this category are typically introduced during
the configuration of the software.
Data Processing Issues Weaknesses in this category are typically found in functional-
ity that processes data.
Numeric Errors Weaknesses in this category are related to improper calcula-
tion or conversion of numbers.
Security Features Weaknesses in this category are concerned with topics like
authentication, access control, confidentiality, cryptography,
and privilege management. (Software security is not security
software.)
Time and State Weaknesses in this category are related to the improper man-
agement of time and state in an environment that supports
simultaneous or near-simultaneous computation by multiple
systems, processes, or threads.
Error Conditions, Weaknesses in this category include weaknesses that occur if
Return Values, a function does not generate the correct return/status code,
Status Codes or if the application does not handle all possible return/status
codes that could be generated by a function.
Resource Management Weaknesses in this category are related to improper manage-
ment of system resources.
Behavioral Issues Weaknesses in this category are related to unexpected behav-
iors from code that an application uses.
Business Logics Weaknesses in this category identify some of the underlying
problems that commonly allow attackers to manipulate the
business logic of an application. Errors in business logic can
be devastating to an entire application.
Initialization and Cleanup Weaknesses in this category occur in behaviors that are used
for initialization and breakdown.
Arguments and Parameters Weaknesses in this category are related to improper use of
arguments or parameters within function calls.
Expression Issues Weaknesses in this category are related to incorrectly written
expressions within code.
Coding Practices Weaknesses in this category are related to coding practices
that are deemed unsafe and increase the chances that an ex-
ploitable vulnerability will be present in the application. They
may not directly introduce a vulnerability, but indicate the
product has not been carefully developed or maintained.

8/25 PeckShield Audit Report #: 2024-072

 Public

2 | Findings

2.1 Summary
Here is a summary of our findings after analyzing the VIRTUAL implementations. During the first
phase of our audit, we study the smart contract source code and run our in-house static code
analyzer through the codebase. The purpose here is to statically identify known coding bugs, and
then manually verify (reject or confirm) issues reported by our tool. We further manually review
business logics, examine system operations, and place DeFi-related aspects under scrutiny to uncover
possible pitfalls and/or bugs.

Severity # of Findings
Critical 0
High 0
Medium 3
Low 4
Total 7

We have so far identified a list of potential issues: some of them involve subtle corner cases that might
not be previously thought of, while others refer to unusual interactions among multiple contracts.
For each uncovered issue, we have therefore developed test cases for reasoning, reproduction, and/or
verification. After further analysis and internal discussion, we determined a few issues of varying
severities need to be brought up and paid more attention to, which are categorized in the above
table. More information can be found in the next subsection, and the detailed discussions of each of
them are in Section 3.

9/25 PeckShield Audit Report #: 2024-072

 Public

2.2 Key Findings

Overall, these smart contracts are well-designed and engineered, though the implementation can
be improved by resolving the identified issues (shown in Table 2.1), including 3 medium-severity
vulnerabilities and 4 low-severity vulnerabilities.

Table 2.1: Key Audit Findings

ID Severity Title Category Status

PVE-001 Medium Manipulation of Account Scores/Pro- Business Logic Resolved
posal Maturity in AgentDAO
PVE-002 Low Suggested Adherence of Checks-Effects- Time and State Resolved
Interactions in AgentFactory
PVE-003 Low Accommodation of Non-ERC20- Business Logic Resolved
Compliant Tokens
PVE-004 Medium Lack of Founder Score Initialization in Business Logic Resolved
AgentNft::mint()
PVE-005 Low Improved Protocol Parameters Update Business Logic Resolved
Logic in TimeLockStaking
PVE-006 Low Improved AgentNft/AgentDAO Initial- Coding Practices Resolved
ization Logic
PVE-007 Medium Trust Issue of Admin Keys Security Features Mitigated

Beside the identified issues, we emphasize that for any user-facing applications and services, it is
always important to develop necessary risk-control mechanisms and make contingency plans, which
may need to be exercised before the mainnet deployment. The risk-control mechanisms should kick
in at the very moment when the contracts are being deployed on mainnet. Please refer to Section 3
for details.

10/25 PeckShield Audit Report #: 2024-072

 Public

3 | Detailed Results

3.1 Manipulation of Account Scores/Proposal Maturity in

AgentDAO

• ID: PVE-001 • Target: AgentDAO

• Severity: Medium • Category: Business Logic [8]
• Likelihood: Medium • CWE subcategory: CWE-837 [4]
• Impact: Medium

Description
The VIRTUAL protocol has a key AgentDAO contract that supports the governance on the created virtual
instance. In the process of examining the governance logic, we notice current score calculation for
voters may be manipulated.
In the following, we show the code snippet of the related _castVote() routine. This routine has
a rather straightforward logic in casting the user vote. We notice the vote has the associated voter
score update (lines 163 − 168). The update logic basically counts the number of proposals the voter
has participated and the user participation can be all types of votes, including Against, For, Abstain,
and Deliberate. It comes to our attention that Deliberate type may be abused to inflate the vote
score.
149 function _castVote (
150 uint256 proposalId ,
151 address account ,
152 uint8 support ,
153 string memory reason ,
154 bytes memory params
155 ) internal override returns ( uint256 ) {
156 uint256 weight = super . _castVote (
157 proposalId ,
158 account ,
159 support ,
160 reason ,

11/25 PeckShield Audit Report #: 2024-072

 Public

161 params
162 );
163 if ( hasVoted ( proposalId , account ) ) {
164 _scores [ account ]. push (
165 SafeCast . toUint48 ( block . number ) ,
166 SafeCast . toUint208 ( scoreOf ( account ) ) + 1
167 );
168 }
169
170 if ( params . length > 0) {
171 _ up da t eM at u ri t y ( account , proposalId , weight , params ) ;
172 }
173
174 return weight ;
175 }

Listing 3.1: AgentDAO::_castVote()

Specifically, a malicious voter Malice may chose a specific proposal and then start to make multiple
votes on the same proposal. The first vote can be For to make the hasVoted(proposalId, account)
call to return true. After that, Malice makes repeated votes with the Deliberate vote type. Each
Deliberate vote will basically increase the Malice vote score by 1. It will also negatively affect the
proposal maturity calculation.
663 function _castVote (
664 uint256 proposalId ,
665 address account ,
666 uint8 support ,
667 string memory reason ,
668 bytes memory params
669 ) internal virtual returns ( uint256 ) {
670 _ v a l i d a t e S t a t e B i t m a p ( proposalId , _ e n c o d e S t a t e B i t m a p ( ProposalState . Active ) ) ;
671
672 uint256 weight = _getVotes ( account , p r o p o s a l S n a p s h o t ( proposalId ) , params ) ;
673 _countVote ( proposalId , account , support , weight , params ) ;
674
675 if ( params . length == 0) {
676 emit VoteCast ( account , proposalId , support , weight , reason ) ;
677 } else {
678 emit V o t e C a s t W i t h P a r a m s ( account , proposalId , support , weight , reason , params
);
679 }
680
681 return weight ;
682 }

Listing 3.2: GovernorUpgradeable::_castVote()

103 function _countVote (

104 uint256 proposalId ,
105 address account ,

12/25 PeckShield Audit Report #: 2024-072

 Public

106 uint8 support ,

107 uint256 weight ,
108 bytes memory // params
109 ) internal virtual override {
110 ProposalVote storage proposalVote = _ propos alVote s [ proposalId ];
111
112 // Allow user to cast vote with opinion and type " Deliberate " to signal that
they are not voting
113 if ( support == uint8 ( VoteType . Deliberate ) ) {
114 return ;
115 }
116
117 if ( proposalVote . hasVoted [ account ]) {
118 revert G o v e r n o r A l r e a d y C a s t V o t e ( account ) ;
119 }
120
121 proposalVote . hasVoted [ account ] = true ;
122
123 if ( support == uint8 ( VoteType . Against ) ) {
124 proposalVote . againstVotes += weight ;
125 } else if ( support == uint8 ( VoteType . For ) ) {
126 proposalVote . forVotes += weight ;
127 } else if ( support == uint8 ( VoteType . Abstain ) ) {
128 proposalVote . abstainVotes += weight ;
129 } else {
130 revert G o v e r n o r I n v a l i d V o t e T y p e () ;
131 }
132 }

Listing 3.3: GovernorCountingSimpleUpgradeable::_countVote()

Recommendation Revisit the above logic to enable reliable and safe voting.

Status This issue has been fixed by the following commit: 33d61c3.

13/25 PeckShield Audit Report #: 2024-072

 Public

3.2 Suggested Adherence of Checks-Effects-Interactions in

AgentFactory

• ID: PVE-002 • Target: Multiple Contracts

• Severity: Low • Category: Time and State [9]
• Likelihood: Low • CWE subcategory: CWE-663 [3]
• Impact: Low

Description
A common coding best practice in Solidity is the adherence of checks-effects-interactions principle.
This principle is effective in mitigating a serious attack vector known as re-entrancy. Via this
particular attack vector, a malicious contract can be reentering a vulnerable contract in a nested
manner. Specifically, it first calls a function in the vulnerable contract, but before the first instance
of the function call is finished, second call can be arranged to re-enter the vulnerable contract by
invoking functions that should only be executed once. This attack was part of several most prominent
hacks in Ethereum history, including the DAO [14] exploit, and the Uniswap/Lendf.Me hack [13].
We notice there are occasions where the checks-effects-interactions principle is violated. Using
the AgentFactory as an example, the withdraw() function (see the code snippet below) is provided to
externally call a token contract to transfer assets. However, the invocation of an external contract
requires extra care in avoiding the above re-entrancy. For example, the interaction with the external
contract (line 183) start before effecting the update on internal state (lines 187−188), hence violating
the principle. In this particular case, if the external contract has certain hidden logic that may be
capable of launching re-entrancy via the same entry function.
164 function withdraw ( uint256 id ) public {
165 Application storage application = _applications [ id ];
166
167 require (
168 msg . sender == application . proposer
169 hasRole ( WITHDRAW_ROLE , msg . sender ) ,
170 " Not proposer "
171 );
172
173 require (
174 application . status == A p p l i c a t i o n S t a t u s . Active ,
175 " Application is not active "
176 );
177
178 require (
179 block . number > application . proposalEndBlock ,
180 " Application is not matured yet "

14/25 PeckShield Audit Report #: 2024-072

 Public

181 );
182
183 IERC20 ( assetToken ) . transfer (
184 application . proposer ,
185 application . w i t h d r a w a b l e A m o u n t
186 );
187 application . w i t h d r a w a b l e A m o u n t = 0;
188 application . status = A p p l i c a t i o n S t a t u s . Withdrawn ;
189 }

Listing 3.4: AgentFactory::withdraw()

While the supported tokens in the protocol do implement rather standard ERC20 interfaces and
their related token contracts are not vulnerable or exploitable for re-entrancy, it is important to take
precautions to thwart possible re-entrancy.

Recommendation Apply necessary reentrancy prevention by following the checks-effects-

interactions principle and utilizing the necessary nonReentrant modifier to block possible re-entrancy
. Note this issue affects a number of routines, including AgentToken::withraw(), AgentReward::
_claimStakerRewards(), and AgentReward::_claimValidatorRewards().

Status This issue has been fixed by the following commit: 33d61c3.

3.3 Accommodation of Non-ERC20-Compliant Tokens

• ID: PVE-003 • Target: Multiple Contracts

• Severity: Low • Category: Business Logic [8]
• Likelihood: Low • CWE subcategory: CWE-841 [5]
• Impact: Low

Description
Though there is a standardized ERC-20 specification, many token contracts may not strictly follow the
specification or have additional functionalities beyond the specification. In this section, we examine
the transfer() routine and possible idiosyncrasies from current widely-used token contracts.
In particular, we use the popular stablecoin, i.e., USDT, as our example. We show the related
code snippet below. Specifically, the transfer() routine does not have a return value defined and
implemented. However, the IERC20 interface has defined the transfer() interface with a bool return
value. As a result, the call to transfer() may expect a return value. With the lack of return value
of USDT’s transfer(), the call will be unfortunately reverted.
126 function transfer ( address _to , uint _value ) public o n ly Pa y lo ad S iz e (2 * 32) {
127 uint fee = ( _value . mul ( ba s is Po i nt sR a te ) ) . div (10000) ;

15/25 PeckShield Audit Report #: 2024-072

 Public

128 if ( fee > maximumFee ) {

129 fee = maximumFee ;
130 }
131 uint sendAmount = _value . sub ( fee ) ;
132 balances [ msg . sender ] = balances [ msg . sender ]. sub ( _value ) ;
133 balances [ _to ] = balances [ _to ]. add ( sendAmount ) ;
134 if ( fee > 0) {
135 balances [ owner ] = balances [ owner ]. add ( fee ) ;
136 Transfer ( msg . sender , owner , fee ) ;
137 }
138 Transfer ( msg . sender , _to , sendAmount ) ;
139 }

Listing 3.5: USDT::transfer()

Because of that, a normal call to transfer() is suggested to use the safe version, i.e., safeTransfer
(), In essence, it is a wrapper around ERC20 operations that may either throw on failure or return
false without reverts. Moreover, the safe version also supports tokens that return no value (and
instead revert or throw on failure). Note that non-reverting calls are assumed to be successful.
In current implementation, if we examine the AgentFactory::proposePersona() routine that is
designed to propose a new persona. To accommodate the specific idiosyncrasy, there is a need to
user safeTransferFrom(), instead of transferFrom() (line 133).
111 function pro posePe rsona (
112 string memory name ,
113 string memory symbol ,
114 string memory tokenURI ,
115 uint8 [] memory cores ,
116 bytes32 tbaSalt ,
117 address tbaImplementation ,
118 uint32 daoVotingPeriod ,
119 uint256 daoThreshold
120 ) external returns ( uint256 ) {
121 address sender = msg . sender ;
122 require (
123 IERC20 ( assetToken ) . balanceOf ( sender ) >= applicationThreshold ,
124 " Insufficient asset token "
125 );
126 require (
127 IERC20 ( assetToken ) . allowance ( sender , address ( this ) ) >=
128 applicationThreshold ,
129 " Insufficient asset token allowance "
130 );
131 require ( cores . length > 0 , " Cores must be provided " ) ;

133 IERC20 ( assetToken ) . transferFrom (

134 sender ,
135 address ( this ) ,
136 applicationThreshold
137 );

16/25 PeckShield Audit Report #: 2024-072

 Public

139 uint256 id = _nextId ++;

140 uint256 p r o p o s a l E n d B l o c k = block . number +
141 IGovernor ( protocolDAO ) . votingPeriod () +
142 IGovernor ( protocolDAO ) . votingDelay () ;
143 Application memory application = Application (
144 name ,
145 symbol ,
146 tokenURI ,
147 A p p l i c a t i o n S t a t u s . Active ,
148 applicationThreshold ,
149 sender ,
150 cores ,
151 proposalEndBlock ,
152 0,
153 tbaSalt ,
154 tbaImplementation ,
155 daoVotingPeriod ,
156 daoThreshold
157 );
158 _applications [ id ] = application ;
159 emit NewApp licati on ( id ) ;

161 return id ;
162 }

Listing 3.6: AgentFactory::proposePersona()

In the meantime, we also suggest to use the safe-versions of transfer()/transferFrom() in other

related routines, including Airdrop::airdrop() and AgentFactory::withdraw().

Recommendation Accommodate the above-mentioned idiosyncrasy about ERC20-related

approve()/transfer()/transferFrom().

Status This issue has been fixed by the following commit: be42a7d.

3.4 Lack of Founder Score Initialization in AgentNft::mint()

• ID: PVE-004 • Target: AgentNft

• Severity: Medium • Category: Business Logic [8]
• Likelihood: Medium • CWE subcategory: CWE-841 [5]
• Impact: Medium

Description
The VIRTUAL protocol has a core AgentNft contract to keep track of every virtual instantiation. Each
virtual has its own DAO that is protected with so-called validators. These validators serve as the

17/25 PeckShield Audit Report #: 2024-072

 Public

gatekeepers by reviewing and certifying the inputs from contributors. Our analysis shows the founder
will automatically become one validator. Our analysis shows the founder score is not properly
initialized.
In the following, we show the implementation of the related routine, i.e., mint(). As the name indi-
cates, this routine mints the NFT-representation of a new virtual. Notice that the founder is added into
the validator list (line 91). However, it does not properly initialize the score, i.e., _initValidatorScore
(virtualId, founder).

74 function mint (
75 address to ,
76 string memory newTokenURI ,
77 address payable theDAO ,
78 address founder ,
79 uint8 [] memory coreTypes
80 ) external onlyRole ( MINTER_ROLE ) returns ( uint256 ) {
81 uint256 virtualId = _ nextVi rtualI d ++;
82 _mint ( to , virtualId ) ;
83 _setTokenURI ( virtualId , newTokenURI ) ;
84 VirtualInfo storage info = virtualInfos [ virtualId ];
85 info . dao = theDAO ;
86 info . coreTypes = coreTypes ;
87 info . founder = founder ;
88 IERC5805 daoToken = GovernorVotes ( theDAO ) . token () ;
89 info . token = address ( daoToken ) ;
90 _ s t a k i n g T o k e n T o V i r t u a l I d [ address ( daoToken ) ] = virtualId ;
91 _addValidator ( virtualId , founder ) ;
92 return virtualId ;
93 }

Listing 3.7: AgentNft::mint()

Recommendation Revisit the above virtual initialization logic by setting up the initial score of
the first validator, i.e., founder.

Status This issue has been fixed by the following commit: 33d61c3.

18/25 PeckShield Audit Report #: 2024-072

 Public

3.5 Improved Protocol Parameters Update Logic in

TimeLockStaking

• ID: PVE-005 • Target: TimeLockStaking

• Severity: Low • Category: Coding Practices [7]
• Likelihood: Low • CWE subcategory: CWE-1126 [1]
• Impact: Low

Description
DeFi protocols typically have a number of system-wide parameters that can be dynamically configured
on demand. The VIRTUAL protocol is no exception. Specifically, if we examine the TimeLockStaking con-
tract, it has defined a number of protocol-wide risk parameters, such as maxBonus and maxLockDuration.
In the following, we show the corresponding routines that allow for their changes.
147 f u n c t i o n a d j u s t M a x B o n u s ( u i n t 2 5 6 _maxBonus ) e x t e r n a l o n l y G o v {
148 maxBonus = _maxBonus ;
149 }
150
151 f u n c t i o n a d j u s t M a x L o c k P e r i o d ( u i n t 2 5 6 _maxLockDuration ) e x t e r n a l o n l y G o v {
152 m a x L o c k D u r a t i o n = _maxLockDuration ;
153 }

Listing 3.8: TimeLockStaking::adjustMaxBonus()/adjustMaxLockPeriod()

These parameters define various aspects of the protocol operation and maintenance and need
to exercise extra care when configuring or updating them. Our analysis shows the update logic on
these parameters can be improved by applying more rigorous sanity checks. Based on the current
implementation, certain corner cases may lead to an undesirable consequence. For example, an
unlikely mis-configuration of maxBonus may violate the restriction on current curve elements.

Recommendation Validate any changes regarding these system-wide parameters to ensure

they fall in an appropriate range. In the following, we show below example revisions:
147 f u n c t i o n a d j u s t M a x B o n u s ( u i n t 2 5 6 _maxBonus ) e x t e r n a l o n l y G o v {
148 i f ( _curve . l e n g t h >= 2 ) {
149 r e q u i r e ( _maxBonus>= c u r v e [ c u r v e . l e n g t h −1]) ;
150 }
151 maxBonus = _maxBonus ;
152 }
153
154 f u n c t i o n a d j u s t M a x L o c k P e r i o d ( u i n t 2 5 6 _maxLockDuration ) e x t e r n a l o n l y G o v {
155 m a x L o c k D u r a t i o n = _maxLockDuration ;
156 u n i t = _maxLockDuration / ( c u r v e . l e n g t h − 1 ) ;

19/25 PeckShield Audit Report #: 2024-072

 Public

157 }

Listing 3.9: Revised TimeLockStaking::adjustMaxBonus()/adjustMaxLockPeriod()

Status This issue has been fixed by the following commit: 33d61c3.

3.6 Improved AgentNft/AgentDAO Initialization Logic

• ID: PVE-006 • Target: AgentNft, AgentDAO

• Severity: Low • Category: Coding Practices [7]
• Likelihood: Low • CWE subcategory: CWE-1126 [1]
• Impact: Low

Description
To facilitate possible future upgrade, a number of contracts in VIRTUAL are instantiated as a proxy
with actual logic contracts in the backend. While examining the related contract construction and
initialization logic, we notice current construction can be improved.
In the following, we use the AgentNft contract as an example and show its initialization routine.
We notice its constructor does not have any payload. With that, it can be improved by adding the
following statement, i.e., _disableInitializers();. Note this statement is called in the logic contract
where the initializer is locked. Therefore any user will not able to call the initialize() function in
the state of the logic contract and perform any malicious activity. Note that the proxy contract state
will still be able to call this function since the constructor does not effect the state of the proxy
contract.
52 function initialize ( address defaultAdmin ) public initializer {
53 __ERC721_init ( " Persona " , " PERSONA " ) ;
54 _ _ C o r e R e g i s t r y _ i n i t () ;
55 __ValidatorRegistry_init (
56 _validatorScoreOf ,
57 totalProposals ,
58 _getPastValidatorScore
59 );
60 _ _ A c c e s s C o n t r o l _ i n i t () ;
61 _grantRole ( DEFAULT_ADMIN_ROLE , defaultAdmin ) ;
62 _grantRole ( VALIDATOR_ADMIN_ROLE , defaultAdmin ) ;
63 _ne xtVirt ualId = 1;
64 }

Listing 3.10: AgentNft::initialize()

Moreover, the above initialize() routine can be improved by also initializing the inherited con-
tract ERC721URIStorageUpgradeable by calling __ERC721URIStorage_init().

20/25 PeckShield Audit Report #: 2024-072

 Public

Recommendation Improve the above-mentioned constructor routine in AgentNft. Note the

AgentDAO contract shares the same issue.

Status This issue has been fixed by the following commit: 33d61c3.

3.7 Trust Issue of Admin Keys

• ID: PVE-007 • Target: Multiple Contracts

• Severity: Medium • Category: Security Features [6]
• Likelihood: Low • CWE subcategory: CWE-287 [2]
• Impact: High

Description
In VIRTUAL, there is a privileged account (with the role ). This account plays a critical role in governing
and regulating the system-wide operations (e.g., configure parameters, create virtuals, execute priv-
ileged operations, etc.). Our analysis shows that this privileged account needs to be scrutinized. In
the following, we use the AgentFactory contract as an example and show the representative functions
potentially affected by the privileged account.
289 function s e t A p p l i c a t i o n T h r e s h o l d (
290 uint256 newThreshold
291 ) public onlyRole ( D E F A U L T _ A D M I N _ R O L E ) {
292 a p p l i c a t i o n T h r e s h o l d = newThreshold ;
293 emit A p p l i c a t i o n T h r e s h o l d U p d a t e d ( newThreshold ) ;
294 }
295
296 function setGov ( address newGov ) public onlyRole ( D E F A U L T _ A D M I N _ R O L E ) {
297 gov = newGov ;
298 emit GovUpdated ( newGov ) ;
299 }
300
301 function setVault (
302 address newVault
303 ) public onlyRole ( D E F A U L T _ A D M I N _ R O L E ) {
304 _vault = newVault ;
305 }
306
307 function s e t I m p l e m e n t a t i o n s (
308 address token ,
309 address dao
310 ) public onlyRole ( D E F A U L T _ A D M I N _ R O L E ) {
311 t o k e n I m p l e m e n t a t i o n = token ;
312 d a o I m p l e m e n t a t i o n = dao ;

21/25 PeckShield Audit Report #: 2024-072

 Public

313 }

Listing 3.11: Privileged Operations in AgentFactory

We understand the need of the privileged functions for proper protocol operations, but at the
same time the extra power to the owner may also be a counter-party risk to the protocol users.
Therefore, we list this concern as an issue here from the audit perspective and highly recommend
making these privileges explicit or raising necessary awareness among protocol users.

Recommendation Promptly transfer the privileged account to the intended DAO-like governance
contract. All changed to privileged operations may need to be mediated with necessary timelocks.
Eventually, activate the normal on-chain community-based governance life-cycle and ensure the in-
tended trustless nature and high-quality distributed governance.

Status This issue has been mitigated as the team plans to assign admin role to a multi-sig
wallet managed by Fireblocks.

22/25 PeckShield Audit Report #: 2024-072

 Public

4 | Conclusion

In this audit, we have analyzed the design and implementation of the VIRTUAL protocol, which is
designed to align incentives for the decentralized creation and monetization of AI personas for every
virtual interaction (gaming, metaverses, online interactions, or beyond). It creates co-owned, human-
curated, plug-and-play gaming AIs by acting as a decentralized factory. In other words, it makes all
sorts of AI characters (that can respond via text, voice and motion) for different virtual worlds,
like games or online spaces. The current code base is well structured and neatly organized. Those
identified issues are promptly confirmed and addressed.
Meanwhile, we need to emphasize that smart contracts as a whole are still in an early, but exciting
stage of development. To improve this report, we greatly appreciate any constructive feedbacks or
suggestions, on our methodology, audit findings, or potential gaps in scope/coverage.
ł

23/25 PeckShield Audit Report #: 2024-072

 Public

References

[1] MITRE. CWE-1126: Declaration of Variable with Unnecessarily Wide Scope. https://cwe.

mitre.org/data/definitions/1126.html.

[2] MITRE. CWE-287: Improper Authentication. https://cwe.mitre.org/data/definitions/287.html.

[3] MITRE. CWE-663: Use of a Non-reentrant Function in a Concurrent Context. https://cwe.

mitre.org/data/definitions/663.html.

[4] MITRE. CWE-837: Improper Enforcement of a Single, Unique Action. https://cwe.mitre.org/

data/definitions/837.html.

[5] MITRE. CWE-841: Improper Enforcement of Behavioral Workflow. https://cwe.mitre.org/

data/definitions/841.html.

[6] MITRE. CWE CATEGORY: 7PK - Security Features. https://cwe.mitre.org/data/definitions/

254.html.

[7] MITRE. CWE CATEGORY: Bad Coding Practices. https://cwe.mitre.org/data/definitions/

1006.html.

[8] MITRE. CWE CATEGORY: Business Logic Errors. https://cwe.mitre.org/data/definitions/

840.html.

[9] MITRE. CWE CATEGORY: Concurrency. https://cwe.mitre.org/data/definitions/557.html.

24/25 PeckShield Audit Report #: 2024-072

 Public

[10] MITRE. CWE VIEW: Development Concepts. https://cwe.mitre.org/data/definitions/699.

html.

[11] OWASP. Risk Rating Methodology. https://www.owasp.org/index.php/OWASP_Risk_

Rating_Methodology.

[12] PeckShield. PeckShield Inc. https://www.peckshield.com.

[13] PeckShield. Uniswap/Lendf.Me Hacks: Root Cause and Loss Analysis. https://medium.com/

@peckshield/uniswap-lendf-me-hacks-root-cause-and-loss-analysis-50f3263dcc09.

[14] David Siegel. Understanding The DAO Attack. https://www.coindesk.com/

understanding-dao-hack-journalists.

25/25 PeckShield Audit Report #: 2024-072