Fixed 30,000 gas stipend in _transferNative leads to potential incompatibility with contract recipients

All native BNB transfers in the protocol go through _transferNative, which uses a hardcoded gas stipend of 30,000:

uint256 private constant GAS_LIMIT = 30000;

function _transferNative(
    address to, uint256 amount
) private {
    (bool success, ) =
        to.call{value: amount, gas: GAS_LIMIT}("");
    if (!success) revert TransferFailed();
}

While 30,000 gas is sufficient for EOAs and most common contract wallets (including Gnosis Safe), certain smart contract wallets or custom contracts with heavier receive()/fallback() logic could exceed this stipend. If feeCollector or a user's prerotatedKeyHash resolves to such a contract, all native BNB operations involving that address would revert.

This affects fee collection in _handleWrap (line 377), remainder transfers in _handleWrap (line 387), unwrap payouts in _handleUnwrap (lines 416-417), and plain native transfers (line 324).

Notably, emergencyWithdrawBNB at line 461 uses no gas limit at all:

(bool sent, ) = to.call{value: balance}("");

This inconsistency suggests the gas limit may not be intentional across the board. The reentrancy risk that GAS_LIMIT was likely intended to mitigate is already handled by the nonReentrant modifier on all entry points.

Native BNB operations (wrap, unwrap, transfer) could fail if the recipient is a contract whose receive()/fallback() exceeds 30,000 gas. This would block fee collection or balance migration for affected addresses.

Since all external entry points already use nonReentrant, consider removing the gas stipend or increasing it significantly (e.g., 100,000) to accommodate a wider range of contract recipients. Alternatively, align _transferNative with the pattern used in emergencyWithdrawBNB by removing the gas limit entirely.

YadaCoin, Confirmed.

Zealynx, Fixed.