Core V2 - IP.World

IPWorld.harvest() initializes the IP owner vesting schedule only after it has collected at least one wei of WETH.

if (wethAmount != 0) {
    …
    if (recipient != address(0) && !IIPOwnerVault(ownerVault).vesting(token).isSet) {
        IIPOwnerVault(ownerVault).createVestingOnTokenDeploy(token);
    }
}

Exploit Scenario:

• No fees have accrued yet — immediately after createIpToken() mints liquidity, fee counters are at zero.

• Permissionless harvest — anyone can call harvest(token); the IP owner does not need to be the first caller.

• The caller invokes harvest before any swap occurs, resulting in wethAmount == 0 and bypassing the vesting process.

• Single-range deployment (optional) — if the token was deployed with a single tick range, this zero-fee harvest also removes all liquidity from the pool and burns a portion of the IP tokens.

Impact:

• The vesting schedule is never established; the IP owner cannot withdraw their allocation (vesting(token).isSet == false).

• Protocol revenue sharing (distributeOwdAmount) is delayed.

• In the case of a single tick range, the situation is permanently blocked because no further WETH fees can accrue without liquidity.

Run forge test --mt test_Vesting_CreatedVerified -vvv, as in here we are receiving no harvest. We can observe that the vesting schedule is not created:

Create the vesting schedule promptly once both prerequisites are satisfied:

• Tokens are stored in the vault.

• An IP recipient has been assigned.

address recipient = _ipaRecipient[ipaId];
if (recipient != address(0) && !IIPOwnerVault(ownerVault).vesting(token).isSet) {
    IIPOwnerVault(ownerVault).createVestingOnTokenDeploy(token);
}

if (wethAmount != 0) {
    … // fee distribution logic
}

SOLVED: The suggested mitigation has been implemented by the IPWorld team.

When IPWorld.harvest() completes fee collection, it forwards a portion of the WETH to the IP-token and calls repositionBidWall():

uint256 bidWallAmount = wethAmount * bidWallShare / PRECISION;
IERC20(_weth).transfer(address(token), bidWallAmount);
IIPToken(token).repositionBidWall();

The IPToken.repositionBidWall() function removes the existing "bid-wall" liquidity position and mints a new one one tick away from the current price. The following describes the two symmetric failure scenarios:

• Left boundary (−MAX_TICK): occurs when the IP-token is token0 (nativeIsZero == false).

_collectLiquidity(pool, bidWallTickLower, nativeIsZero);
...
int24 baseTick   = currentTick - 1;           // = −887 221
newTickUpper     = _validTick(baseTick, true); // clamps to −MAX_TICK
newTickLower     = newTickUpper - TICK_SPACING; // −887 280   < MIN_TICK
_addLiquidity(... newTickLower ...)            // ↯ TickMath.revert("T")

• Right boundary (+MAX_TICK): occurs when WETH is token0 (nativeIsZero == true).

_collectLiquidity(pool, bidWallTickLower, nativeIsZero);
...
int24 baseTick   = currentTick + 1;           // = 887 221
newTickLower     = _validTick(baseTick, false); // clamps to +MAX_TICK
newTickUpper     = newTickLower + TICK_SPACING; // 887 280  > MAX_TICK
_addLiquidity(... newTickUpper ...)            // ↯ TickMath.revert("T")

In cases where newTickLower underflows below TickMath.MIN_TICK (−887,272), or newTickUpper overflows above TickMath.MAX_TICK (887,220), both scenarios cause TickMath to revert with the generic "T()" error, effectively rendering harvest() inoperable.

Impact:

• This is an edge case but can result in a repeatedly-triggerable denial-of-service for IPWorld.harvest() on affected tokens.

• Protocol fee distribution, bid-wall refresh, treasury income, and IP-owner vesting are all interrupted.

• The attack cost is minimal once the attacker possesses enough tokens to manipulate the thin one-sided pool.

Add the following test case to test/IPWorld.t.sol:

 function test_BidWall_DoS_Revert() public {
        vm.prank(address(operator));
        (, address tokenAddr) =
            ipWorld.createIpToken(alice, "CHILL", "CHILL", address(0), startTickList, allocationList);

        IPToken ipToken = IPToken(tokenAddr);

        // 2. Fund the token with a small amount of WETH to bypass the 0-balance guard.
        //    This mimics the WETH that IPWorld would send during harvest.
        weth.deposit{value: 1 ether}();
        weth.transfer(tokenAddr, 1 ether);

        // 3. Calling `repositionBidWall()` now must revert with Uniswap's 'T' error
        //    because the computed `newTickLower` underflows below MIN_TICK.
        vm.expectRevert(bytes("T()"));
        ipToken.repositionBidWall();
    }

Clamp tick bounds within repositionBidWall() (and _collectLiquidity) to ensure:

• If newTickLower would be below MIN_TICK, it is set to MIN_TICK.

• If newTickUpper would be above MAX_TICK, it is set to MAX_TICK.

SOLVED: The IPWorld team implemented boundary checks after tick calculation. The system now skips repositioning when near tick boundaries while maintaining all essential protocol functions, including fee collection, distribution, token burning, and treasury payments, which continue to operate normally. This approach creates a system where the bid wall temporarily halts repositioning at extreme price levels that are economically costly to reach and sustain, rather than disrupting the entire protocol. Repositioning automatically resumes when market conditions normalize.

The IPOwnerVault::initialize function in V2 retains the initializer modifier from version 1.

function initialize(address initialOwner) public initializer {
    __Ownable_init(initialOwner);
    __UUPSUpgradeable_init();
}

Since the proxy has already been initialized using version 1, this call will revert.

Rename it to initializeV2 and protect it using reinitializer(2).

SOLVED: The IPWorld team has implemented the recommended mitigation measures.

IPWorld.sol defines an upgrade hook:

function initialize(address initialOwner) public reinitializer(2) {
    __UUPSUpgradeable_init();     
    __Ownable_init(initialOwner); 
}

Both __UUPSUpgradeable_init() and __Ownable_init() are tagged with initializer (version 1). After the proxy is deployed, version 1 is already consumed. Calling them again from inside a reinitializer(2) will therefore revert with "contract is already initialized". Similar issue exists in IPOwnerVault.sol.

Remove the base initializers and only set new variables:

function initializeV2(..) public reinitializer(2) {
    // no __UUPSUpgradeable_init or __Ownable_init here
    newStateVar = …;
}

SOLVED: The suggested mitigation was implemented.

After upgrading the IPWorld contract, the harvest() function fails when called on tokens deployed with older versions of IPToken that lack the repositionBidWall() function. This introduces a critical backward compatibility issue, preventing successful fee collection and distribution for existing tokens.

function harvest(address token) external {
    // ... fee collection logic ...
    
    if (wethAmount != 0) {
        uint256 bidWallAmount = wethAmount * bidWallShare / PRECISION;
        uint256 ipOwnerAmount = wethAmount * ipOwnerShare / PRECISION;
        IERC20(_weth).transfer(address(token), bidWallAmount);
        IIPToken(token).repositionBidWall(); 
        
        // ... rest of distribution logic
    }
}

Impact:

• Failure to harvest fees from legacy tokens

• Blocked distribution of LP fees to IP owners and stakers

• Potential accumulation of unharvested fees within pools

Implement a fallback mechanism that:

1. Attempts to retrieve the pool address via the liquidityPool() function.

2. If this attempt fails, calculates the pool address using the Uniswap V3 Factory.

3. For legacy tokens, skips the buyback process and directs the buyback funds to the treasury instead.

SOLVED: The above fix was implemented by IPWorld team.

The IPWorldLPManager forwards liquidity operations to the NonfungiblePositionManager. For both mint() and burn() functions, it sets the deadline parameter to block.timestamp instead of accepting it from the user:

deadline: block.timestamp            

Since the call is executed within the same transaction, the check require(block.timestamp <= deadline) within the periphery contract always passes, even if the user's transaction remains in the mempool for minutes or hours. This hard-coded value effectively nullifies the purpose of the deadline parameter, leaving liquidity providers vulnerable to price fluctuations and MEV exploitation while their transaction is pending.

Accept a uint256 deadline parameter from the caller and pass it unchanged to the position-manager struct:

function mint(..., uint256 deadline) external payable returns (...) {
    require(block.timestamp <= deadline, "deadline passed");
    INonfungiblePositionManager.MintParams memory params = … { deadline: deadline };
    ...
}

Similarly, this applies to the burn() helper function.

SOLVED: The IPWorld team has implemented the recommended mitigation measures.

IPWorld::claimToken() permits the Operator to transfer any ERC-20 tokens held by the IPWorld contract to an arbitrary set of recipients:

function claimToken(address token, address[] calldata addressList, uint256[] calldata amountList)
    external
    onlyOperator
{
    …
    if (amount > 0) IERC20(token).transfer(recipient, amount);
}

However, this function is never invoked by the designated Operator contract.

Additional vulnerabilities within claimToken() increase the security risk:

• The function does not enforce that addressList.length == amountList.length.

• It ignores the return value of IERC20.transfer, potentially losing funds when interacting with non-standard ERC-20 tokens.

• No events are emitted, which hampers off-chain monitoring and auditing.

1. Clarify responsibility:

   • If token recovery is meant to be manual, restrict the function to onlyOwner (or remove it entirely) and execute via multisig.

   • If it must remain operator-controlled, expose a wrapper in Operator that is protected by off-chain signatures.

2. Add the missing safety guards:

   • require(addressList.length == amountList.length);

   • Emit an event (e.g., TokenClaimed(token, recipient, amount)).

   • Use SafeERC20.safeTransfer to handle non-standard tokens.

SOLVED:

This finding was fixed with following comment from IPWorld team:

• Regarding "unused function": The claimToken() function will be called by an EOA (Externally Owned Account) Operator, not by the Operator contract. This is an intentional design decision for manual token distribution.

• Implemented fix: Added array length validation to prevent out-of-bounds access

  • Added new error IPWorld_InvalidArgument for invalid arguments

  • Added validation: if (length \!= amountList.length) revert Errors.IPWorld_InvalidArgument();

  • This ensures addressList and amountList have matching lengths

Operator::_transferETH() sends ETH to a recipient using a hard-coded gas stipend of 30,000:

(bool success,) = to.call{value: value, gas: 30_000}(new bytes(0));
if (!success) revert();

Many smart contract wallets (e.g., Gnosis Safe) and on-chain interactions require more than 30,000 gas to execute their fallback functions. When the recipient is such a contract, the call reverts, preventing users from receiving refunds or proceeds after createIpTokenWithSig and other processes that rely on _transferETH.

Consequently, certain wallet types (e.g., safes, paymasters, proxy wallets) are unable to interact with the protocol because refund transactions fail.

1. Use Address.sendValue (forwards all available gas and reverts on failure) or an unconstrained call{value: value}.

2. Alternatively, allow the caller to withdraw unclaimed ETH manually.

SOLVED: Removed the hardcoded gas limit of 30,000 from the _transferETH function and replaced it with a call to to.call{value: value}("")

In IPWorld::constructor, the variables burnShare, ipOwnerShare, and bidWallShare are only validated individually through range checks. However, if the sum of ipOwnerShare and bidWallShare exceeds PRECISION (1,000,000), it causes an underflow in the treasury payout calculation, resulting in every harvest() transaction reverting.

(success,) = treasury.call{value: wethAmount - ipOwnerAmount - bidWallAmount}("");

Include the following check in the constructor:

require(ipOwnerShare + bidWallShare <= PRECISION, "Share overflow");

SOLVED: The IPWorld team has implemented the recommended mitigation measures.

The IPWorld::claimIp() function allows an operator to overwrite the existing recipient for any IP without checking whether the IP was previously claimed or that the caller is the current owner.

Add basic safeguards such as:

require(_ipaRecipient[ipaId] == address(0), "IP already claimed");

or implement a two-step transfer process, requiring the current recipient to approve any changes.

SOLVED: Implemented a two-step transfer process requiring approval from the current owner.

In Operator::setExpectedSigner, setting signer to address(0) blocks all future EIP-712 operations.

function setExpectedSigner(address expectedSigner_) external onlyOwner {
    expectedSigner = expectedSigner_;
}

Add a check for address(0):

require(expectedSigner_ != address(0), "zero signer");

SOLVED: The setExpectedSigner function now performs proper validation to prevent setting the zero address.

In IPWorld, loop counters utilize checked arithmetic, although overflow cannot occur in this context.

for (uint256 i = 1; i <= length; ++i) { ... }

Use the unchecked block for for loop increments in IPWorld.sol:

for (uint256 i = 1; i <= length; ) {
    ...
    unchecked { ++i; }
}

ACKNOWLEDGED: The IPWorld team acknowledged the finding with following comment - "While the suggestion is technically valid, the trade-off between code clarity and minimal gas savings doesn't justify the change at this time."

Several contracts still contain // TODO comments indicating incomplete logic. These placeholders range from missing event emissions to generic revert() statements lacking specific error codes. Leaving such TODOs in deployed code reduces transparency, disrupts off-chain accounting, and can result in vague or misleading failure messages.

Complete the implementation or removal of all TODO items prior to deployment:

• IPToken.sol::storyHuntV3MintCallback

• IPWorldLPManager.sol::whitelistToken

• IPWorldLPManager.sol::burn

• IPOwnerVault.sol::constructor

• IPWorld.sol::harvest

SOLVED: The issues marked with TODO placeholders have been addressed and resolved.