Earlier parts of this series covered what a wallet actually stores, how Zelcore derives keys across 80-plus chains, how to send your first transaction, and which coins each account type supports. Now it is time to plug Zelcore into the rest of the on-chain world. WalletConnect is the protocol that lets a dApp in your desktop browser ask your phone to sign a transaction, without ever touching your keys — if you use it correctly.
Before You Start
Get three things in place before you tap Connect.
Unlock Zelcore on the device that holds the account you want to expose, and make sure both that device and the device running the dApp have live internet. WalletConnect rides on a public relay network; Bluetooth, AirDrop, and local Wi-Fi do not come into this. If either side is on airplane mode, a corporate VPN that blocks relay.walletconnect.org, or a captive portal, pairing will silently fail.
Decide which wallet you are actually connecting. When you approve a session, Zelcore asks you to pick one wallet under Select wallet and shares that wallet's address on each chain the dApp requested (Zelcore's WalletConnect guide). Pick a wallet with the funds you need for this swap or mint — not your top-balance hot wallet and certainly not one that holds long-term stacks. Think of every WalletConnect session as a temporary hot-wallet spin-up.
Understand the mistakes that cause almost every WalletConnect drain. The first is approving a session proposal from a site you have not verified: approval itself only connects your wallet, but it lets that site send you signing requests. The second is signing a request you cannot read. The third is leaving sessions and token approvals alive for months on dApps you have forgotten. Both are easy to avoid once you know what to look for, which is most of what this article teaches.
What WalletConnect Actually Is
WalletConnect is an open protocol for end-to-end encrypted messaging between a dApp and a wallet over a public relay network. It was built by WalletConnect Inc., which renamed itself Reown in 2024 (Reown's announcement). In v1.0 the session and pairing were coupled, while in v2.0 a pairing can be proposed independently from the session and they exist in parallel (WalletConnect Sign API specification). Zelcore uses WalletConnect v2 through Reown WalletKit (Zelcore's WalletConnect guide).
Three primitives are worth knowing by name.
Pairing is the initial handshake. When you scan a QR code or tap a deep link, your wallet and the dApp set up a shared symmetric key. The wc: URI, and the QR code that encodes it, carries that key in its symKey field (WalletConnect pairing URI specification). Treat a live link or QR code as private: never post it, send it to someone, or paste one that someone else sent you.
Session is the scoped agreement layered on top of the pairing. It says which chains the dApp may request, which JSON-RPC methods it may call, and which of your accounts it can see. A session has a finite lifetime and can be revoked from either side. In WalletKit, the SDK Zelcore builds on, sessions have a default expiry of 7 days, and the wallet can extend a session by another 7 days (WalletKit usage docs). When a session ends, connect again from the dApp.
Relay is the encrypted pub/sub transport between the two peers. The relay sees ciphertext only. Even if the relay operator were fully compromised, they could not read your transactions or derive your keys.
The v2 upgrade that matters most day-to-day is multi-chain namespaces. A single session can be scoped across Ethereum mainnet, Base, Polygon, Arbitrum, and more at once, using EIP-155 chain IDs like eip155:1 and eip155:8453. You no longer re-pair every time the dApp switches network, but you now have to check which chains a session covers.
In Zelcore: pairing a dApp step by step
The most common flow is desktop dApp plus mobile Zelcore.
- On the dApp, click Connect Wallet and choose WalletConnect from the modal. A QR code appears along with a list of wallet logos.
- Open Zelcore on your phone and tap Scan.
- Point the camera at the dApp's QR code. The Incoming Proposal dialog opens on the phone, with a countdown.
- Check the dApp's name, website, domain check and any scam warning (next section), choose the wallet to share under Select wallet, and only then tap Approve (or Reject if anything looks wrong). If d2FA is on, Zelcore asks for your PIN.
- The dApp now shows your address as connected. From here on, every transaction or message signature the dApp requests opens its own Incoming Request in Zelcore, which you approve or reject one at a time.
The mobile-to-mobile flow is almost identical. Instead of scanning a QR, tap Copy Link in the dApp modal and paste the link into Zelcore's WalletConnect field (or let it hand off via the OS). Zelcore opens the same proposal from the wc: URI.
Zelcore desktop has no scanner. Copy the WalletConnect link from the dApp, click the WalletConnect icon in Zelcore's top bar, paste the link into the Wallet Connect URI field, and click Connect.
The browser extension uses the same WalletConnect screens as the desktop and mobile apps (Zelcore's WalletConnect guide). Open its WalletConnect menu, paste the link into the Wallet Connect URI field and click Connect.
For a broader look at WalletConnect alongside Zelcore’s other advanced tools, see the tour of Zelcore’s advanced features.
Hardware wallet accounts can't connect to dApps; hardware wallets pair with Zelcore on desktop only and sign sends from the Send screen.
Pairing links are short-lived: the specification says a link's expiry timestamp should be generated five minutes in the future (WalletConnect pairing URI specification). If Zelcore says the link has expired or was already used, copy a fresh link from the dApp and connect again (Zelcore's WalletConnect guide). Never scan a stale QR from a screenshot someone sent you. That is a textbook phishing vector.
Reading the Permission Prompt Like an Auditor
Zelcore's approval screen is the last checkpoint before a dApp can ask you to sign anything. Read it the way a security auditor would.
Verify the origin first. The dApp's name, icon, and URL all appear at the top of the screen, with a domain check label: Domain match, Unverified, Mismatch or Threat. Check that the URL exactly matches the tab you think you are on. Phishing clones swap one letter or use a homograph domain, and drainer kits copy legitimate branding pixel-perfect.
Check the chains after you connect. Zelcore's proposal doesn't list chains; once paired, open the dApp in the WalletConnect list and look at Connected Chains. If a DEX you expect to be Ethereum-only is connected on a dozen chains — or on a chain the project does not actually deploy to — disconnect. Over-broad namespaces are a drainer tell.
Check the request type. Each Incoming Request names its type, such as Personal Sign, Send Transaction or Sign Typed Data (v4). Typed data is EIP-712, a standard for hashing and signing typed structured data rather than plain bytestrings (EIP-712). Token permits use it: an EIP-2612 permit is an ERC-20 approval given through an EIP-712 signature (EIP-2612). Legacy eth_sign is effectively never safe — reject any dApp that asks for it. A browse-only or read-only dApp has no business asking you to send a transaction the moment you connect.
Refuse blind signing up front. A legitimate DEX may first ask for a token approval or a permit before the swap itself, and a prompt may not show every amount clearly. For every request, check the action, token, spender, amount, recipient and chain, and reject any request you cannot understand. If the first thing a dApp pushes is a signature before you have clicked anything meaningful, assume drainer until proven otherwise. Signature phishing is how wallet drainers work: Scam Sniffer's 2024 report describes drainers as malware on phishing sites that steals crypto by inducing users to sign malicious transactions, puts 2024 losses from them at approximately $494 million, and found that Permit remains the primary method for token phishing attacks. That is part of why token approvals are the real attack surface in DeFi.
Refuse unlimited approvals by reflex. If a dApp pushes an ERC-20 approve(spender, uint256.max) as the first transaction, it is asking for unbounded spending of that token forever. Zelcore doesn't let you edit the amount in the request, but it spells out what the approval grants, for example "Grants unlimited USDC to" followed by the spender. If it says unlimited, reject it and set an exact amount on the dApp if it offers one; if it doesn't, don't approve.
Treat Permit2 as a double-edged tool. Uniswap's Permit2 is the union of two contracts: AllowanceTransfer, which gives spenders permission over a specified amount for a specified duration of time, and SignatureTransfer, where an allowance on the token is bypassed and permissions to the spender only last for the duration of the transaction in which the one-time signature is spent (Uniswap's Permit2 repository). Before contracts can request your tokens through Permit2, you must approve the Permit2 contract through the specific token contract (Uniswap's Permit2 repository). Apps often ask for the maximum amount there, and that ERC-20 approval stays on-chain until you revoke it. After that, the two modules behave differently: an AllowanceTransfer permission lets that spender keep transferring until the amount is used up or the time runs out, while a SignatureTransfer leaves no standing allowance. The problem is that drainers copy this UX pattern to steal tokens. Always verify the contract address is the real Uniswap Permit2 for your chain. Uniswap's Permit2 SDK returns 0x000000000022D473030F116dDEE9F6B43aC78BA3 as the Permit2 address for every chain except chain ID 324 (zkSync Era), where it returns 0x0000000000225e31D15943971F47aD3022F714Fa (Uniswap's Permit2 SDK). If the address differs, it is not Permit2.
For a broader picture of how signature phishing and wallet drainers actually work, keep that companion article open in another tab the first few times you connect to a new protocol.
Revoking Sessions and Revoking On-Chain Approvals Are Different
This is the single biggest user misunderstanding on WalletConnect. Killing a session stops the dApp from requesting new signatures. It does not revoke any approvals you have already signed on-chain. Those live in the token contracts themselves and survive until you explicitly reset them.
You need to do both.
Revoke the WalletConnect session. In Zelcore, open the WalletConnect menu (the WalletConnect icon in the top bar on desktop), find the dApp in the list of paired sessions, and choose Disconnect. Disconnecting stops the dApp from sending new requests (Zelcore's WalletConnect guide). Under the hood, the wallet sends the dApp a request to close and delete the session (WalletConnect's session methods). On-chain approvals stay where they are. For good measure, click Disconnect on the dApp side too, so neither peer has a half-open state that could re-emit requests.
Revoke on-chain token approvals. On Revoke.cash, enter your address or connect the same wallet, select the network the approval lives on, and you get a list of the token approvals on that network, each of which you can revoke (Revoke.cash's revoking guide). It supports 80-plus networks, not every chain, so check that yours is listed before you rely on an empty result. Each revoke costs gas on the chain where the approval lives. Permit2 adds its own layer: the token's approval of Permit2, and the spending permissions Permit2 grants to other contracts on top of it (Revoke.cash on Permit2) — review both.
Signed permits don't show up until they are used. A permit you signed but nobody has submitted yet is not an on-chain approval, so revoke tools won't list it and disconnecting doesn't cancel it. An EIP-2612 permit stays usable until the deadline written into it, and only while your nonce on that token still matches the one in the signature (EIP-2612). If you think you signed a malicious permit or Permit2 signature, check its deadline and whether the token or Permit2 offers a way to cancel it by using up its nonce, move what you can to a fresh wallet, and get help for that specific chain before you treat the address as safe.
Use block-explorer tools as a second opinion. Etherscan has a built-in Token Approval Checker at etherscan.io/tokenapprovalchecker. BscScan, Polygonscan, Arbiscan, and Basescan all offer the same tool for their chain. If something on revoke.cash looks off, cross-check on the explorer before you sign the reset transaction.
Build a habit: audit approvals monthly and revoke anything you have not used in thirty days. Drainers exploit approvals you forgot, not approvals you remember. This is the same discipline that shows up on your full crypto attack surface, which is worth re-reading after your first few WalletConnect sessions.
For a practical guide to Ethereum fees, approvals, and L2 choices in Zelcore, read holding Ethereum in Zelcore.
Troubleshooting
QR will not scan. Tap Copy Link on the dApp modal and paste the wc: URI directly into Zelcore's WalletConnect screen. This bypasses camera focus and lighting problems.
Stuck on "connecting…" The relay occasionally hiccups. Cancel, refresh the dApp, and generate a fresh QR. Do not reuse the old one: if Zelcore says the link was already used or has expired, copy a fresh link from the dApp.
Session drops mid-swap. Zelcore doesn't re-pair on its own: refresh the dApp and connect again. Before you retry, look up the transaction hash on a block explorer. What happens to a transaction you already sent depends on the chain. On Ethereum and other EVM networks, a broadcast transaction stays pending until a proposer includes it, until another transaction with the same nonce replaces it, or until it is dropped (Ethereum glossary), so retrying while it is still pending can spend gas twice. On Solana, all transactions expire by default if they are not committed to a block within a certain amount of time (Solana's transaction confirmation guide), so check whether it landed or expired before you send it again. On other networks, check that chain's explorer the same way before you retry.
"Unsupported chain" error. The dApp is asking for a chain the session doesn't cover. Disconnect, switch the dApp to the chain you intend to use, and pair again, then check Connected Chains. If Zelcore says the dApp requested required chains Zelcore does not support, it rejects the pairing, and re-pairing will not help.
Phone and dApp cannot see each other. Both sides need internet. Airplane mode, a corporate VPN that blocks WalletConnect relays, or an overly aggressive ad-blocker on desktop will all break pairing.
When in doubt, tear it all down. Disconnect on Zelcore, clear the session on the dApp, refresh the page, and pair from scratch. This is faster than debugging a half-dead pairing and it resets any stale state on either peer.
Next in the Series
You can now plug Zelcore into DeFi front-ends, NFT marketplaces, and governance portals with your eyes open. But sessions and approvals are only part of the story — they all depend on a seed phrase that, if lost, takes every account with it. Part 7 covers backup and recovery: how to write down your seed, where to store it, how to test a restore without moving funds, and how to plan for the day your phone takes a swim.
