Skip to main content

Transaction approval

Every transaction and signature a dapp requests passes through an approval screen. Understanding what the user sees helps you build requests that get approved — and explains why some get refused.

What the screen shows​

  • Who's asking — the origin, title, and icon of the requesting site.
  • What it does — decoded intent where Core recognises the call: token and amount for transfers, spender and allowance for approvals, typed fields for EIP-712 signatures, decoded operations for X/P-Chain transactions and encrypted ERC-20s.
  • Balance changes — a simulation of what the account gains and loses.
  • Fees — with user-adjustable priority on EVM networks.

Risk screening​

Transactions and signature requests are screened (via Blockaid) before the user decides. Known-malicious targets, drainer patterns, and suspicious approvals get a prominent warning or are blocked outright. Screening is a wallet-side protection; it does not change your dapp's API surface.

What this means for your dapp​

  • Readable requests approve better. A bounded ERC-20 allowance renders as "approve 100 USDC to a named spender"; an unlimited one triggers warnings users increasingly heed.
  • Simulation punishes surprises. If the balance-change preview doesn't match what your UI told the user, expect rejections.
  • A rejection is 4001 whether the user declined by choice or a warning scared them off — your dapp can't tell the difference, so treat every rejection with grace.