Analysis of the Virtuals-UNCX Vesting Case

6 min read1 day ago

Overview

This document provides an in-depth analysis of how UNCX’s vesting mechanism interacts with the token unwrapping process used by Virtuals platforms.

The goal is to clarify why some previously locked tokens become freely claimable after an unwrap event and to propose solutions for improving protocols compatibility in the future.

Importantly, this is not a blame assessment but rather an exploration of incompatibilities that arise due to differing design choices between Virtuals and UNCX. It is also worth noting that there has not been any ‘exploit’ of any kind on UNCX (vesting and all other services).

While this behavior is an expected outcome, there are potential solutions that could be implemented to improve interoperability.

Background: How Virtuals Token Unwrapping Works

1. Token Creation and Launch

A project launches a token on a Virtuals platform, where an initial wrapped version is issued to its creator.
This wrapped token is freely tradable and can be used in external contracts, including UNCX’s vesting system.

2. Vesting on UNCX

Users lock their wrapped tokens into UNCX’s vesting contract, which schedules releases over time.
The vesting contract does not track raw balances but instead issues shares, ensuring compatibility with rebasing and reflection-based tokens. It is important to note this is (was and still is, the product is live for years!) a deliberate choice from our end, ensuring compatibility with all types of vesting schedules being created on the platform.

3. The Unwrap Process

If the project meets its fundraising goals on Virtuals, the Unwrap Tokens function is then called.
This function burns all wrapped tokens and airdrops the equivalent amount of the unwrapped token to all prior holders.

4. Key Issue: Vesting Logic is Not Preserved

Since the airdrop is a simple balance transfer, any vesting schedules or ownership logic tied to the old tokens is lost.
The UNCX vesting contract receives the full airdrop as a new balance, but with no associated vesting terms.

Example: Bob’s Token Locking Experience

To illustrate how this process works in real scenarios, let’s walk through Bob’s experience step by step.

Step 1: Bob Locks Wrapped Tokens

Bob is the token creator of $XYZ, a project launching through Virtuals. Before the fundraising phase ends, he decides to lock 100 wrapped $XYZ in the UNCX vesting contract for 1 year.

Here’s what happens:
> The vesting contract does not store a raw balance of 100 tokens directly. Instead, it assigns Bob a proportional amount of shares based on the total supply of $XYZ locked at the time.
> Let’s assume Bob owns 100% of the shares since he’s the only one locking $XYZ in the vesting contract. 100% of the shares represent 100 XYZ tokens.

At this stage, Bob feels confident because, under normal vesting usage and conditions, he would be able to withdraw his tokens gradually over the next year according to his vesting schedule.

Step 2: The Token Successfully Unwraps

A few hours later, the fundraising phase ends, and $XYZ succeeds. The function called “Unwrap Tokens” is called, which:

Burns all the wrapped $XYZ in circulation.
Airdrops the same amount of the final unwrapped token to all previous holders.

Bob, along with all other $XYZ holders, receives an equivalent amount of unwrapped tokens in their wallets. However, here’s what happens inside the UNCX vesting contract:
> Since the wrapped $XYZ was burned, the shares assigned to Bob no longer correspond to any real token balance.
> The vesting contract receives an airdrop of all the tokens that were previously locked — but without any schedule or ownership data attached.

At this point, Bob still expects his vesting to continue, but in reality, all of the locked tokens are now just a free balance sitting in the contract.

Step 3: Alice Locks the New Token and Claims Everything

Alice, another investor, notices that the UNCX vesting contract now holds a large balance of unwrapped $XYZ but has no active locks. She decides to create a new vesting schedule and lock for a few moments 1 unwrapped $XYZ.

Since UNCX’s vesting contract allocates shares based on the first locker for each asset, Alice now:
> Receives 100% of the shares for unwrapped $XYZ in the contract.
> Effectively owns the entire airdropped supply since no previous shares were carried over.

This means Alice can now claim all of Bob’s previously locked tokens, even though she was never part of the original vesting schedule. Bob, meanwhile, has lost all his locked tokens.

Why? Because the airdrop function ‘Unwrap tokens’ treated the vesting contract like any other wallet, sending the new tokens without recognizing logic — or in this case, vesting terms and ownership.

Understanding the UNCX Vesting Contract Behavior

1. Share-Based Vesting vs. Raw Balance Locking

UNCX’s vesting system does not store raw token balances. Instead, it:
>Allocates shares to users, ensuring compatibility with rebasing and reflection-based tokens.
> Supports tokens with dynamic supplies, avoiding issues caused by direct balance locking.

What Happens Post-Unwrap:

Since the wrapped tokens are burned, all prior share allocations become meaningless.
The airdropped tokens appear as a fresh balance in the vesting contract, but with no assigned owners or schedules.
The first user to lock tokens post-unwrap effectively owns 100% of the new token supply in the vesting contract.

2. This Outcome is Expected in Any Share-Based Vesting System

Any vesting or locking platform that operates on shares (rather than raw balances) would experience the same result.
This is not a bug — it’s an inherent consequence of how Virtuals token migrations work when paired with a share-based accounting or vesting system.

3. Raw Balance-Based Vesting would not have a positive outcome either

If a raw balance-based vesting protocol was used instead:

Since wrapped tokens are burned, the contract would permanently lose all locked balances.
The new tokens would be airdropped as free-floating balances, with no mechanism to reassign them to the original vesting participants.
In a decentralized, immutable vesting contract, these tokens would certainly be irretrievable, leading to a total loss.

Any external DeFi protocol holding wrapped tokens at the time of unwrapping could encounter unintended consequences.

Bottom line: This issue could impact any third-party smart contract that interacted with wrapped tokens, as the Virtuals unwrapping function inherently breaks prior logic and associations.

Recommendations for Improving Protocol Compatibility

While this is an expected outcome based on current protocol designs, there are ways to improve compatibility between Virtuals and vesting solutions like UNCX.

1. Virtuals and UNCX Collaboration

UNCX is open to working with Virtuals to integrate custom vesting-compatible airdrop mechanics.
> This could involve custom migration logic, ensuring tokens retain vesting terms upon unwrapping.
> We are happy to collaborate with any division of their team looking to make their tokens compatible with secure third-party vesting solutions.

2. Virtuals Could Adjust their Wrapped Token Logic

To limit unintended interactions, Virtuals could also:
> Restrict wrapped tokens from interacting with non-native vesting protocols until after unwrapping.
> Provide clear guidelines to their users on how wrapped tokens should be handled when interacting with third-party external DeFi applications.

3. Improve User Awareness

Both projects and investors should be made aware that:
> Wrapped tokens carry inherent risks when used in vesting contracts.
> If a token will undergo unwrapping mechanics within its infancy, vesting should ideally be done after the unwrap event, not before.

Conclusion

This is not a bug in UNCX’s system & contracts but a protocol incompatibility resulting from how Virtuals handles tokens unwrapping.

Solutions exist, and UNCX is ready to collaborate with Virtuals to improve vesting compatibility for future projects.

The UNCX Team

Resources

> ETH Mainnet Vesting contract (public, verified, audited): Contract

> BASE Mainnet Vesting contract (public, verified, audited): Contract

> UNCX Documentation: Docs

> UNCX Dapp: Link