HyperCore fee receiver (referral fees at destination)

[0x4rde]

Summary

Adds RangoHyperCoreFeeReceiver, a standalone (non-diamond) receiver for HyperCore → EVM withdrawals that splits the withdrawn USDC between up to eight referrers and the recipient, atomically on the destination chain. Supersedes the earlier RangoCCTPV2HyperCoreMiddleware (removed here — it was never merged).

Background

Withdrawals from HyperCore are burned by Circle's CoreDepositWallet, not by a Rango contract, so there is no source-side hook and the fee must be taken at the destination. Circle caps user hook data at 1024 bytes and prepends a 60-byte envelope; a diamond onChainSwaps call does not fit that budget, so this contract uses a compact packed payload and pays out with direct transfers — no CALL, no whitelist dependency, no LibInterchainV2.

Design

• Inherits RangoBaseInterchainMiddlewareV2 for ownership, pause, and refund. The base constructor sets owner = deployer at deploy time, so there is no initialization window to front-run.
• Version-2 packed payload: a fixed 43-byte header (version, requestId, recipient, dAppTag) followed by a variable array of up to eight (referrer, bps) entries. The fee count is derived from the payload length, so there is no count field to disagree with the bytes.
• Fees are basis points, computed off the amount that actually arrived (Circle deducts a variable feeExecuted), with the combined take capped at 20%. Rounding dust goes to the recipient.
• processMessageAndTransferUSDC (onlyOwner) recovers any message the split flow cannot process, minting and delivering directly while ignoring the payload.
• Relaying is permissionless: destinationCaller is zero and the attested payload fully determines the payout.

Notes

• One new file; the superseded RangoCCTPV2HyperCoreMiddleware.sol is removed.
• Received amount is verified as amount - feeExecuted; the payout is bounded to that, so pre-existing balances cannot be redirected by a crafted message.