Update hooksAddressesAllowlist.ts

[titaniclhx-rgb]

Summary

Add whitelist buy hook address to BSC chain allowlist in hooksAddressesAllowlist.ts, per Uniswap hook intake requirements.

Hook Details

• Hook Name: BUY_HOOK_V3_ON_BNB
• Contract Address: 0xDF4e5F77eBbe97bdeE477D685B946CA27a538080
• Chain: BSC Mainnet (Chain ID: 56)
• Functionality: Restricts swap operations to pre-approved whitelisted addresses via beforeSwap hook
• Read-only validation, no state modification, no fund custody

Related

• Hook Intake Form has been submitted to Uniswap
• Source Code: https://github.com/titaniclhx-rgb/uniswap_v4_hook/blob/main/WhitelistBuyHook.sol

Testing

• Hook deployed and tested on BSC mainnet
• Allowlist addition verified, no syntax errors
• No impact on existing routing-api functionality

[titaniclhx-rgb]

Hi @Ponx 👋
Could you please help review and merge this PR?
This is my new whitelist hook for BSC, and I've already submitted the Hook Intake Form.

Thank you so much!

[titaniclhx-rgb]

Hi @Ponx
I'm reaching out again regarding PR #1397 (BSC hook). I know you're very busy, but I just wanted to gently check in since it's been a few months since I submitted the Hook Intake Form and opened this PR.
Could you please let me know if this PR is still in the review queue, or if there's any action required from my side? I'm happy to make any adjustments needed.
Thanks again for your help!

[titaniclhx-rgb]

Hi @Ponx
I've located the problematic code in my hook. Could you help
me confirm the correct way to fix it? please,please help me, thank you very much!

Hook Logic (What I'm trying to do)

My hook is a "whitelist buy gate":

• Token0 → Token1 swaps (buying Token1): only whitelisted users allowed
• Token1 → Token0 swaps (selling Token1): everyone allowed
• I use two flags (restrictToken0 / restrictToken1) for flexibility, since
  I'm not 100% sure which position my token will be in (Token0 or Token1).

The Problematic Code

In _beforeSwap, I need to get the real user address (not the router address).
Currently I'm using the IMsgSender pattern:

address swapper;
try IMsgSender(sender).msgSender() returns (address res) {
    swapper = res;
} catch {
    revert("Router does not implement msgSender()");  // ← Problem here
}

The Issue

When the Quoter calls swap() during routing simulation, it does NOT implement
msgSender(). So the try/catch block reverts, the simulation fails, and the
frontend shows "No route found" — even though the pool has liquidity.

My Question

What is the correct way to handle this? Specifically:

1. Should I bypass the whitelist check entirely when sender is the Quoter
   (since Quoter is read-only simulation and cannot move funds)?

2. Or should I only call msgSender() on trusted routers (Universal Router)
   and skip it for other callers?

3. Or is there a different recommended pattern for hooks that need to
   identify the real user address?

4. Does the Quoter contract on BSC
   (0x9f75dd27D6664c475b90e105573E550fF69437B0) implement msgSender()?
   Or is there a different way the Quoter identifies itself?

Context

• Chain: BSC
• PoolManager: 0x28e2Ea090877bF75740558f6BFB36A5ffeE9e9dF
• Universal Router 2.1.1 (V4): 0x8B844F885672F333Bc0042CB669255f93a4C1e6B
• Universal Router (V3): 0x1906C1d672B88Cd1b9Ac7593301CA990F94Eae07
• Quoter: 0x9f75dd27D6664c475b90e105573E550fF69437B0

I want to make sure I follow the official recommended pattern before redeploying.
Thanks! 🙏