Cheerful Taffy Dolphin - Restrictive Domain Validation in Verifier Contract Breaks Zero-Domain Message Processing and Market Integrations

[sherlock-admin2]

Cheerful Taffy Dolphin

Medium

Restrictive Domain Validation in Verifier Contract Breaks Zero-Domain Message Processing and Market Integrations

Summary

The Verifier contract implements critical signature verification functionality for the Perennial protocol but relies on a VerifierBase implementation that does not match its documented behavior for domain validation.

The contract's documentation explicitly states:

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/core/contracts/Verifier.sol#L58

/// Messages verification request must come from the domain address if it is set.
/// - In the case of intent / fills, this means that the market should be set as the domain.

However, through inheritance of VerifierBase's validateAndCancel modifier, all verification functions (verifyIntent, verifyOperatorUpdate, verifySignerUpdate, verifyAccessUpdateBatch) enforce a stricter domain validation that requires msg.sender to match the domain in all cases.

Impact

The restrictive domain validation in the Verifier contract has critical implications for the protocol's operation, particularly in the verification of intents and signature processing:

1. Intent Processing Disruption:
   When markets attempt to verify intents via verifyIntent(), the current implementation forces a strict domain match even for legitimate zero-domain cases. This directly impacts order fills since every intent verification must route through a specific market address as msg.sender, preventing any flexible intent verification patterns.

2. Market Integration Limitations:
   Since verifyIntent() is a key entry point for order processing, markets must be the msg.sender for any intent verification. Consider a case where multiple markets need to verify the same intent - the current domain validation makes this impossible since the intent can only be verified by the specific market set in the domain field.

3. Excessive Domain Enforcement:
   Operations like verifyOperatorUpdate() and verifySignerUpdate() which manage protocol permissions are unnecessarily restricted. These administrative functions should reasonably support zero-domain verification, especially for direct account management. However, the current validation forces even these basic account operations to route through a domain address.

These restrictions conflict with the protocol's own documentation which specifies domain validation should only occur "if it is set," suggesting the current behavior is unintentional and could be blocking legitimate protocol interactions.

Recommended mitigation steps

Update the Verifier contract to override or implement its own domain validation:

contract Verifier is VerifierBase, IVerifier, Initializable {
    modifier validateDomain(Common calldata common) {
        if (common.domain != address(0) && common.domain != msg.sender) 
            revert VerifierInvalidDomainError();
        _;
    }

    function verifyIntent(Intent calldata intent, bytes calldata signature)
        external
        validateDomain(intent.common)  // Add flexible domain validation
        validateAndCancel(intent.common, signature)
    {
        // ... existing implementation
    }
    
    // Apply to other verification functions
}