LAUNCH-BLOCKER: MetaMask Blockaid flags bridge approve transaction as 'deceptive request'

Brouie commented

2026-04-24 05:06:09 +00:00

(Migrated from gitlab.com)

Found during Bridge #116 Section E (Token approval) verification.

Repro

Go to https://bridge.cl8y.com/
FROM: BNB Chain, TO: Terra Classic, amount 1.1 testa (above minimum)
Click 'Autofill with connected wallet' for recipient (terra17eevck6u6cp7z207ys4j02yxp90mav2f8r6acr)
Click 'BRIDGE FROM EVM'
MetaMask opens the spending cap approval modal with a RED Blockaid warning

MetaMask Blockaid warning shown

Red banner: 'This is a deceptive request'
'If you approve this request, a third party known for scams will take all your assets.'
Spending cap amount labeled 'Malicious...' with red warning icon
'Powered by Blockaid'
Options: Cancel / Review alert

Cancelled the request. No tokens approved, no transaction signed.

Why launch-blocker

Any user connecting via MetaMask to bridge EVM tokens will see this warning. Behavioral outcome on mainstream users:

99% will click Cancel (or Review alert, see the scam warning, and not proceed)
YieldOmega launch + ust1-window deployments rely on the bridge for CL8Y + USDM movement
MetaMask dominant share in EVM wallets = effective bridge denial-of-service for most users
Reputation damage persists in Blockaid database even after fix until contract is resubmitted and reviewed by them

Possible causes (not diagnosed yet)

Bridge spender contract flagged on Blockaid's blocklist (true positive — compromised or historically abused contract address)
Contract not verified on BscScan / unverified bytecode
Suspicious transaction pattern (e.g. unlimited approvals as default, low-trust deployer history)
Contract address collides with a known malicious address

Next steps

Identify which exact contract address MetaMask is warning about (spender in the approval)
Check Blockaid submission status for that address
If legitimate contract, submit to Blockaid for delisting / review
Check BscScan contract verification status

Context

Mainnet https://bridge.cl8y.com/ frontend 0.1.82 (8efb987). MetaMask latest version with Blockaid enabled (default).

cc @PlasticDigits urgent — gates YO launch and ust1-window deployments

Found during Bridge #116 Section E (Token approval) verification. ## Repro 1. Go to https://bridge.cl8y.com/ 2. FROM: BNB Chain, TO: Terra Classic, amount 1.1 testa (above minimum) 3. Click 'Autofill with connected wallet' for recipient (terra17eevck6u6cp7z207ys4j02yxp90mav2f8r6acr) 4. Click 'BRIDGE FROM EVM' 5. MetaMask opens the spending cap approval modal with a RED Blockaid warning ## MetaMask Blockaid warning shown - Red banner: 'This is a deceptive request' - 'If you approve this request, a third party known for scams will take all your assets.' - Spending cap amount labeled 'Malicious...' with red warning icon - 'Powered by Blockaid' - Options: Cancel / Review alert Cancelled the request. No tokens approved, no transaction signed. ## Why launch-blocker Any user connecting via MetaMask to bridge EVM tokens will see this warning. Behavioral outcome on mainstream users: - 99% will click Cancel (or Review alert, see the scam warning, and not proceed) - YieldOmega launch + ust1-window deployments rely on the bridge for CL8Y + USDM movement - MetaMask dominant share in EVM wallets = effective bridge denial-of-service for most users - Reputation damage persists in Blockaid database even after fix until contract is resubmitted and reviewed by them ## Possible causes (not diagnosed yet) 1. Bridge spender contract flagged on Blockaid's blocklist (true positive — compromised or historically abused contract address) 2. Contract not verified on BscScan / unverified bytecode 3. Suspicious transaction pattern (e.g. unlimited approvals as default, low-trust deployer history) 4. Contract address collides with a known malicious address ## Next steps - Identify which exact contract address MetaMask is warning about (spender in the approval) - Check Blockaid submission status for that address - If legitimate contract, submit to Blockaid for delisting / review - Check BscScan contract verification status ## Context Mainnet https://bridge.cl8y.com/ frontend 0.1.82 (8efb987). MetaMask latest version with Blockaid enabled (default). cc @PlasticDigits urgent — gates YO launch and ust1-window deployments

Brouie commented

2026-04-24 05:06:54 +00:00

(Migrated from gitlab.com)

{width=900 height=393}

![image.png](/uploads/520d59443c93dd4309906cced6425749/image.png){width=900 height=393}

Brouie commented

2026-04-24 05:15:17 +00:00

(Migrated from gitlab.com)

Additional repro details after clicking 'See details' and proceeding through:

Both the approve AND the bridge transfer are flagged by Blockaid

First transaction (ERC20 approve): Blockaid 'Malicious address' warning on the spender contract — 'If you confirm this request, you will probably lose your assets to a scammer'. Required acknowledging 2 warning layers to proceed. Approve completed on-chain: 0x95b47c96a5c39fcb48dffd86d796bd6f556feb2549bbc150495b59cdadb038b2
Second transaction (bridge transfer call): After approve confirmed, the actual bridge call gets a second Blockaid warning: 'deceptive request', 'You send -1.1 Malicious...', 'scammer will take all your assets'. So it's not just the token spender — the bridge contract's main entry point is also flagged.

Scope update for fix

Spender contract on BNB Chain (the ERC20 approve target) → flagged
Bridge main contract on BNB Chain (the transfer call target) → flagged

Both addresses need to be submitted to Blockaid for delisting/review. Recommend listing the specific addresses in a comment here so they can be tracked separately in Blockaid's review queue.

Positive note

The bridge itself worked — approve landed on-chain, flow progressed to Transfer Status page with 4-step stepper. The blocker is purely Blockaid reputation, not contract logic.

Additional repro details after clicking 'See details' and proceeding through: ## Both the approve AND the bridge transfer are flagged by Blockaid 1. **First transaction (ERC20 approve):** Blockaid 'Malicious address' warning on the spender contract — 'If you confirm this request, you will probably lose your assets to a scammer'. Required acknowledging 2 warning layers to proceed. Approve completed on-chain: `0x95b47c96a5c39fcb48dffd86d796bd6f556feb2549bbc150495b59cdadb038b2` 2. **Second transaction (bridge transfer call):** After approve confirmed, the actual bridge call gets a second Blockaid warning: 'deceptive request', 'You send -1.1 Malicious...', 'scammer will take all your assets'. So it's not just the token spender — the bridge contract's main entry point is also flagged. ## Scope update for fix - Spender contract on BNB Chain (the ERC20 approve target) → flagged - Bridge main contract on BNB Chain (the transfer call target) → flagged Both addresses need to be submitted to Blockaid for delisting/review. Recommend listing the specific addresses in a comment here so they can be tracked separately in Blockaid's review queue. ## Positive note The bridge itself worked — approve landed on-chain, flow progressed to Transfer Status page with 4-step stepper. The blocker is purely Blockaid reputation, not contract logic.

Brouie commented

2026-04-24 05:17:46 +00:00

(Migrated from gitlab.com)

{width=900 height=387}

{width=900 height=474}

{width=900 height=368}

{width=900 height=353}

![image.png](/uploads/9c5180bdbb5b1d53284b9459426c3bda/image.png){width=900 height=387} ![image.png](/uploads/088fdbb4b2d6bce7999ebf10301cb5db/image.png){width=900 height=474} ![image.png](/uploads/64cbaf00fdc9962aeeabfe7e6ffe9383/image.png){width=900 height=368} ![image.png](/uploads/4c7acd0288d91773aa02d7cb232fa2c5/image.png){width=900 height=353}

PlasticDigits commented

2026-04-24 06:03:58 +00:00

(Migrated from gitlab.com)

@brouie GL-118 resolution (docs + process — no contract/UI code change)

This launch blocker is MetaMask Security Alerts / Blockaid classification on BSC (and same proxies on opBNB), not a bridge logic failure. The flow can succeed on-chain while the wallet shows red banners until Blockaid/MetaMask update their database.

Merged to main: commit `474f850` — adds INV-BLK1, canonical addresses, and false-positive reporting steps.

Docs (repo):

docs/METAMASK_BLOCKAID_EVM.md — full narrative + MetaMask Help Center link
skills/agent-metamask-blockaid-evm.md — for automation / third-party agents
Cross-links: README doc table, `docs/security-model.md`, `docs/frontend.md`, `docs/FRONTEND_BRIDGE_INVARIANTS.md`, `skills/agent-bridge-recipient-validation.md`

Canonical BSC proxy addresses to track in Blockaid review (separate tickets if their UI allows):

Role	Address
ERC-20 approve spender (LockUnlock)	`0xd7b3bf05987052009c350874e810df98da95d258`
Bridge lock/transfer target	`0xb2a22c74da8e3642e0effc107d3ac362ce885369`

(Same proxy addresses on opBNB per README.)

Verification checklist for you

On `https://bridge.cl8y.com/`, reproduce BNB → Terra; in MetaMask tx preview confirm spender = LockUnlock and contract = Bridge (match table above).
From the Blockaid banner: See details → Report an issue; submit once per flagged address if the form allows, with links to official site + README + BscScan contract pages.
Optionally open MetaMask Support chat per MetaMask security alerts help (“How to report a false classification”).
Confirm BscScan/opBNBScan contract verification is in good shape (helps review).
After provider responds, re-test with Security alerts ON; expect warnings to clear or downgrade after their SLA (often multi-day).

Tests: `packages/frontend` `npm run test:unit` — 605 passed (docs-only change).

Leaving issue open until Blockaid/MetaMask classification is fixed in production wallets.

@brouie **GL-118 resolution (docs + process — no contract/UI code change)** This launch blocker is **MetaMask Security Alerts / Blockaid** classification on **BSC** (and same proxies on **opBNB**), not a bridge logic failure. The flow can succeed on-chain while the wallet shows red banners until Blockaid/MetaMask update their database. **Merged to `main`:** commit \`474f850\` — adds **INV-BLK1**, canonical addresses, and false-positive reporting steps. **Docs (repo):** - [docs/METAMASK_BLOCKAID_EVM.md](https://gitlab.com/PlasticDigits/cl8y-bridge-monorepo/-/blob/main/docs/METAMASK_BLOCKAID_EVM.md) — full narrative + MetaMask Help Center link - [skills/agent-metamask-blockaid-evm.md](https://gitlab.com/PlasticDigits/cl8y-bridge-monorepo/-/blob/main/skills/agent-metamask-blockaid-evm.md) — for automation / third-party agents - Cross-links: README doc table, \`docs/security-model.md\`, \`docs/frontend.md\`, \`docs/FRONTEND_BRIDGE_INVARIANTS.md\`, \`skills/agent-bridge-recipient-validation.md\` **Canonical BSC proxy addresses to track in Blockaid review (separate tickets if their UI allows):** | Role | Address | |------|---------| | ERC-20 **approve** spender (LockUnlock) | \`0xd7b3bf05987052009c350874e810df98da95d258\` | | **Bridge** lock/transfer target | \`0xb2a22c74da8e3642e0effc107d3ac362ce885369\` | (Same proxy addresses on opBNB per README.) **Verification checklist for you** - [ ] On \`https://bridge.cl8y.com/\`, reproduce BNB → Terra; in MetaMask tx preview confirm **spender** = LockUnlock and **contract** = Bridge (match table above). - [ ] From the Blockaid banner: **See details** → **Report an issue**; submit **once per flagged address** if the form allows, with links to official site + README + BscScan contract pages. - [ ] Optionally open MetaMask Support chat per [MetaMask security alerts help](https://support.metamask.io/privacy-and-security/how-to-turn-on-security-alerts/) (“How to report a false classification”). - [ ] Confirm BscScan/opBNBScan **contract verification** is in good shape (helps review). - [ ] After provider responds, re-test with **Security alerts ON**; expect warnings to clear or downgrade after their SLA (often multi-day). **Tests:** \`packages/frontend\` \`npm run test:unit\` — 605 passed (docs-only change). Leaving issue **open** until Blockaid/MetaMask classification is fixed in production wallets.

Brouie commented

2026-04-24 06:06:19 +00:00

(Migrated from gitlab.com)

mentioned in issue #116

PlasticDigits commented

2026-04-24 06:12:24 +00:00

(Migrated from gitlab.com)

mentioned in commit 8e0c040ee2

mentioned in commit 8e0c040ee2e186401fbc9ae7c7441de2c9db9d86

PlasticDigits commented

2026-04-24 06:12:50 +00:00

(Migrated from gitlab.com)

mentioned in issue #119

Brouie commented

2026-04-26 04:32:26 +00:00

(Migrated from gitlab.com)

@PlasticDigits acknowledged on 474f850. Docs side verified Sunday source review:

7 files merged (README, FRONTEND_BRIDGE_INVARIANTS, METAMASK_BLOCKAID_EVM, frontend.md, security-model.md, agent-bridge-recipient-validation.md, agent-metamask-blockaid-evm.md), no contract or app code touched
Canonical addresses consistent across README L47/L49, docs/deployment-solana-mainnet.md, docs/qa-onboarding.md, docs/METAMASK_BLOCKAID_EVM.md L17-18, skills/agent-metamask-blockaid-evm.md L14-15. No mismatch.
BscScan addresses both reachable (HTTP 200 on /address/.../code for LockUnlock and Bridge). Verification status (verified-source check, green-tick) needs browser visit, deferred to next live session.

Deferred to a normal weekday session:

Live MetaMask repro confirming spender = LockUnlock and contract = Bridge match (needs frontend + funded wallet)
BscScan verification badge confirmation (needs browser)
Blockaid false-positive report submission per checklist

Issue stays open per your note until Blockaid/MetaMask classification updates in production wallets.

@PlasticDigits acknowledged on 474f850. Docs side verified Sunday source review: - 7 files merged (README, FRONTEND_BRIDGE_INVARIANTS, METAMASK_BLOCKAID_EVM, frontend.md, security-model.md, agent-bridge-recipient-validation.md, agent-metamask-blockaid-evm.md), no contract or app code touched - Canonical addresses consistent across README L47/L49, docs/deployment-solana-mainnet.md, docs/qa-onboarding.md, docs/METAMASK_BLOCKAID_EVM.md L17-18, skills/agent-metamask-blockaid-evm.md L14-15. No mismatch. - BscScan addresses both reachable (HTTP 200 on /address/.../code for LockUnlock and Bridge). Verification status (verified-source check, green-tick) needs browser visit, deferred to next live session. Deferred to a normal weekday session: - Live MetaMask repro confirming spender = LockUnlock and contract = Bridge match (needs frontend + funded wallet) - BscScan verification badge confirmation (needs browser) - Blockaid false-positive report submission per checklist Issue stays open per your note until Blockaid/MetaMask classification updates in production wallets.

Brouie commented

2026-05-07 05:44:42 +00:00

(Migrated from gitlab.com)

@PlasticDigits — adding the deferred live items to the Monday 2026-05-11 bridge mainnet session per #128 thread:

live MetaMask repro confirming spender = LockUnlock and contract = Bridge match
BscScan verification badge confirmation
Blockaid false-positive report submission per the checklist

will report classification status post-walk. SLA on the wallet provider end is what it is — leaving issue open per your note until external classification clears.

@PlasticDigits — adding the deferred live items to the Monday 2026-05-11 bridge mainnet session per #128 thread: - live MetaMask repro confirming spender = LockUnlock and contract = Bridge match - BscScan verification badge confirmation - Blockaid false-positive report submission per the checklist will report classification status post-walk. SLA on the wallet provider end is what it is — leaving issue open per your note until external classification clears.