Fee Evasion

Description

Fee Evasion can occur if the Allocator signs data—submitted along with the user's signature—without proper verification. This allows an attacker to manipulate the arbiter field in a segment and arbitrarily control the fee distribution.

The arbiter, which is the entity authorized to make claims, can be a specific contract. It is responsible for appropriately splitting the unlocked assets of the user, including distributing fees. When the allocator is implemented off-chain, it should receive a portion of the fees. Additionally, to incentivize broader participation from Across relayers, a portion of the fees can also be allocated to them.

In The Compact's claim signature verification logic, the contract ensures that both the sponsor and the allocator have signed the claim. Specifically, the unlocking and splitting of assets—such as for fees—is based on the idsAndAmounts field. This field is composed of id and allocatedAmount from the SplitBatchClaimComponent struct. Notably, the portions, which specify how the assets should be split among parties, are not included in the signature verification.

In other words, how the unlocked assets are actually distributed is determined by a designated arbiter contract, which must be agreed upon by the involved parties. Therefore, since the arbiter plays a critical role in splitting the unlocked assets—such as distributing fees—it is essential that the arbiter contract is carefully selected and agreed upon by the relevant parties.

// Validate that the sponsor has authorized the claim.
_validateSponsor(
    sponsor, messageHash, calldataPointer, sponsorDomainSeparator, typehash, idsAndAmounts, shortestResetPeriod
);

// Validate that the allocator has authorized the claim.
_validateAllocator(allocator, sponsor, messageHash, calldataPointer, idsAndAmounts, nonce, expires);

struct SplitBatchClaimComponent {
    uint256 id; // The token ID of the ERC6909 token to allocate.
    uint256 allocatedAmount; // The original allocated amount of ERC6909 tokens.
    SplitComponent[] portions; // claimants and amounts.
}

The sponsor and relayer could potentially collude to harm the allocator. For example, if they designate an arbitrary contract as the arbiter — one that is not agreed upon by all relevant parties (i.e., the allocator, sponsor, claimant, and arbiter) — they could bypass the allocator and claim funds without distributing the appropriate fee.

Mitigation

Ensure that the arbiter address is whitelisted off-chain. Alternatively, implement on-chain verification logic using a whitelisted address book to validate the arbiter.