feat: Add contract security verification before transaction signing

[lau90eth]

Describe the solution you'd like

Problem

Users interacting with dApps built on OnchainKit have zero visibility
into contract safety before signing a transaction. There is currently
no way to know if a contract is verified, is a proxy, or presents
any risk signals.

Proposed Solution

Add a <SecurityCheck /> component that automatically analyzes
contract addresses from TransactionContext and displays risk
indicators before the user signs.

<Transaction calls={calls}>
  <SecurityCheck />
  <TransactionButton />
</Transaction>

Shows:

• ✅ Contract verified
• ⚠️ Proxy contract (with implementation address)
• 🔴 Contract not verified

Implementation

PR #2636 implements this feature as a standalone component
with no dependency on other open PRs.

Describe alternatives you've considered

Revoke.cash / existing allowance managers — standalone tools
that users must visit separately. Not integrated into the transaction
flow where the risk actually occurs.

Manual implementation per dApp — each team builds their own
contract verification check. Inconsistent, unaudited, duplicated effort.

OnchainKit's SecurityCheck solves this at the framework level —
one implementation, consistent UX across all dApps built with OnchainKit.

[harryohh]

[osr21]

Great proposal. We ran into the adjacent problem from the user-facing side while building BasePay — a USDC payments dApp on Base Mainnet — and have a concrete use case that might expand the scope slightly.

The MetaMask/Blockaid false-positive problem

Our gasless transfer feature uses EIP-3009 (transferWithAuthorization) — the user signs an off-chain typed message authorising a direct USDC transfer to a recipient. MetaMask's Blockaid engine flags this as a "deceptive request" and labels the recipient address as an "untrusted spender". This happens because Blockaid applies the same heuristic it uses for EIP-2612 Permit, treating the to field as a "spender" even though it's the final recipient and funds move directly to them.

The contract being interacted with (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 — Circle's USDC on Base) is verified, audited, and well-known. But Blockaid's signal is about the message recipient, not the contract. Our users see a red warning screen before a completely safe signature.

How a <SecurityCheck /> could help here

Beyond the verified/proxy/unverified checks you've proposed, there's a related signal worth surfacing: "this is a well-known contract signing a recognised standard". Specifically:

• Detect that the verifyingContract in an EIP-712 domain is a known token (e.g., USDC, DAI)
• Identify the primaryType as a known safe standard (TransferWithAuthorization, PermitTransferFrom, Permit)
• Surface that to the user before they hit the wallet: "You're signing a USDC EIP-3009 transfer — this is a gasless payment standard, not a contract approval"

That kind of context would dramatically reduce the friction from Blockaid false positives, which disproportionately affect EIP-3009 and EIP-2612 flows on Base where USDC gasless transfers are a primary UX pattern.

Happy to share the full security audit notes from our implementation if it's useful context: https://github.com/osr21/basepay-dapp/blob/main/docs/SECURITY.md

[osr21]

Real-world experience building BasePay — a USDC payments dApp on Base Mainnet — that's directly relevant to this issue.

The Blockaid false-positive problem

Even with contracts source-verified on Basescan, MetaMask/Blockaid still shows the "this dApp is not trusted" warning for newly deployed contracts. The warning appears on every EIP-712 typed signature (both EIP-2612 permit and EIP-3009 TransferWithAuthorization), not just contract calls.

Root cause: Blockaid operates an off-chain database that needs to independently index contracts after deployment. Etherscan verification is a separate system — Blockaid doesn't pull from it automatically. New contracts can be fully verified on-chain but still flagged until Blockaid processes them (typically days to weeks with no clear SLA).

What we shipped as a workaround

Since we couldn't prevent the warning, we added an in-app BlockaidNotice component that renders above every sign button with context:

// Shows above every permit/authorization sign button
<BlockaidNotice />  // explains why MetaMask may flag, links to verified contract

The notice explains: (1) contracts are source-verified on Basescan, (2) Blockaid is a separate off-chain database that indexes independently, (3) how to verify yourself before signing.

Wallet differences matter

Worth noting for this feature: Rabby Wallet has zero Blockaid warnings on the same contracts. Rabby reads contract source directly from the block explorer and performs its own analysis — so verified contracts get a clean prompt immediately. The warning is MetaMask-specific because of the Blockaid dependency.

A <SecurityCheck /> component like the one proposed here would be most valuable for MetaMask users. Consider detecting wallet type and showing context-appropriate messaging — "Blockaid hasn't indexed this contract yet" is a more accurate explanation than just "contract verified ✓" for MetaMask users.

Registration path

For teams hitting this: submitting contracts at account.blockaid.io is the only way to resolve it proactively. Would be great if OnchainKit could surface a dev-mode warning when contracts aren't in Blockaid's registry yet.

[harryohh]

Yes, why cant it ?

…

On Fri, Jun 5, 2026 at 10:54 AM osr21 ***@***.***> wrote: *osr21* left a comment (coinbase/onchainkit#2637) <#2637 (comment)> Real-world experience building BasePay <https://github.com/osr21/basepay-dapp> — a USDC payments dApp on Base Mainnet — that's directly relevant to this issue. The Blockaid false-positive problem Even with contracts *source-verified on Basescan*, MetaMask/Blockaid still shows the "this dApp is not trusted" warning for newly deployed contracts. The warning appears on every EIP-712 typed signature (both EIP-2612 permit and EIP-3009 TransferWithAuthorization), not just contract calls. *Root cause:* Blockaid operates an off-chain database that needs to independently index contracts after deployment. Etherscan verification is a separate system — Blockaid doesn't pull from it automatically. New contracts can be fully verified on-chain but still flagged until Blockaid processes them (typically days to weeks with no clear SLA). What we shipped as a workaround Since we couldn't prevent the warning, we added an in-app BlockaidNotice component that renders above every sign button with context: // Shows above every permit/authorization sign button<BlockaidNotice /> // explains why MetaMask may flag, links to verified contract The notice explains: (1) contracts are source-verified on Basescan, (2) Blockaid is a separate off-chain database that indexes independently, (3) how to verify yourself before signing. Wallet differences matter Worth noting for this feature: *Rabby Wallet has zero Blockaid warnings* on the same contracts. Rabby reads contract source directly from the block explorer and performs its own analysis — so verified contracts get a clean prompt immediately. The warning is MetaMask-specific because of the Blockaid dependency. A <SecurityCheck /> component like the one proposed here would be most valuable for MetaMask users. Consider detecting wallet type and showing context-appropriate messaging — "Blockaid hasn't indexed this contract yet" is a more accurate explanation than just "contract verified ✓" for MetaMask users. Registration path For teams hitting this: submitting contracts at account.blockaid.io is the only way to resolve it proactively. Would be great if OnchainKit could surface a dev-mode warning when contracts aren't in Blockaid's registry yet. — Reply to this email directly, view it on GitHub <#2637?email_source=notifications&email_token=CDDFNYWPHVC5KIWHXAX3JYD46LNL5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTGI4DIMJSGMY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4632841231>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CDDFNYRTQDTWGJ7N2ACF6MT46LNL5AVCNFSM6AAAAACYNNHPOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMZSHA2DCMRTGE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CDDFNYTDIS6S3NZLWN63MOT46LNL5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTGI4DIMJSGMY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CDDFNYSTGCUPOI27NHDGMP346LNL5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTGI4DIMJSGMY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>