"Integrate a Wallet" — Which Layer Are You Actually Selling?
A single Telegram message asking to "integrate a wallet" can mean frontend work, signing logic, or contract authorization. Reading the action words first beats sending a blind quote.
You have quoted a price like this before.
A project team asks in a group chat, “Can you integrate a wallet?” You send back a frontend-integration quote. Three days later they tell you they have found someone else — not because of the price, but because what they actually needed was not “connecting a wallet” at all. It was “users approved the allowance without reading it and we need to fix that.” You quoted the layer that was not the one hurting.
This scene is not a single closed deal. It is a pattern that security-sales peers mention when they remind each other that the word “integrate” means different work to different people (illustrative composite scenario, not project-level data).
If you had that message back, where would you start reading?
Three actions, one message, three different paths
Imagine you see this in a project’s technical discussion group on Telegram:
Illustrative / composite Telegram group message — @alex_build: Our DApp needs wallet integration. Users come in through WalletConnect and sign transactions. We also need the confirmation prompt on the approval side — someone approved without checking the allowance before. Teams that can finish within two weeks, DM us. Budget negotiable.
Three lines, three action words: connect (WalletConnect), sign (signing transactions), approve (confirmation prompt + allowance).
These are not three ways to say the same thing. They point to different technical layers. They map to different quote ranges. They also tell you what stage the project team is at. You do not need to handle all three yourself. You do need to see that they are not one thing.
“Connect” — the entry point, not the answer
WalletConnect is an open-source protocol that establishes a link between a phone wallet and a web-based DApp (decentralized application). A user scans a QR code or taps an authorization prompt on their phone, and the DApp can read the wallet address and send transaction requests. This layer touches no smart contracts and writes nothing to the chain. It is pure frontend integration.
If you see “WalletConnect” and quote, you quote for frontend work. But in this illustrative scene, the project team’s most urgent problem is not that.
The value of “connect” is not in the quote. It helps you judge the team’s makeup. If the reply is “our frontend person is already on it,” someone is handling that piece — you can skip it and talk about the rest. If the reply is “we have not found anyone yet, we want to solve it all together,” you may be looking at a team without frontend capacity. In that case, what they need may not be a security solution first — it may be a referral to someone who can build that layer, or a clearer understanding of whether they are really looking for a frontend developer right now.
In this message, “connect” is the entry point. Not the answer.
“Sign” — what the user sees before they tap confirm
Signing is the cryptographic act of approving a transaction with a private key. Once a signed transaction is broadcast to the chain, reversing it is almost impossible.
The problem is what the user sees at the moment they tap confirm. If the DApp sends a signing request to the wallet without parsing the parameters, the user sees a hex string — not a readable line like “Send 100 USDT to 0xABC.” Tapping confirm on content you do not understand is blind signing. A legitimate DApp’s signing request and a phishing site’s malicious request look identical in the wallet popup. The user cannot tell them apart.
If you follow this direction, the entry is not rewriting their frontend code. It is one question you can ask in a single sentence: “Can your users see the amount and the recipient before they confirm?” If they cannot answer, you decide — does this fall inside the signing-audit work you offer?
“Approve” — the hole the user already stepped into
That last line — “someone approved without checking the allowance before” — is the part of the message worth following most closely.
Approval is the mechanism where a user authorizes a specific contract address to move tokens from their wallet. The ERC-20 standard’s approve method, when called without a limit — set to uint256 maximum — means the approved contract can drain the full token balance in one transaction. Many well-known phishing incidents trace back to exactly this.
The project team sees the problem. That is why they are looking for a fix. But the “high-amount warning” they mention is frontend copy — a red line of text that pops up to warn the user. Some users will notice. The ones who caused the first incident may click through it the same way.
A more thorough fix lives at the contract layer: cap the approval allowance to the amount actually needed, or use increaseAllowance / decreaseAllowance to adjust it dynamically. A more subtle pattern is EIP-2612’s Permit — off-chain approval that lets the user sign off-chain, and the allowance is granted without the user ever seeing an on-chain transaction.
In this simulated message, the project team’s most pressing problem sits at the approval layer. User feedback already exists. The problem has a concrete shape. This is not a “preventive” requirement — it is a requirement with visible consequences.
Two numbers you need before you quote
The group message gives you direction. It does not give you a basis to quote. As of the moment this message was seen, two critical pieces of information are not confirmable from the group alone.
First, what does “high amount” actually mean here? A “high amount” for a routine token transfer and a “high amount” for a cross-chain bridge (a protocol that moves assets between different blockchains) are not different by a factor of two. They can differ by two or three orders of magnitude. You would need to see the contract parameters, or at least know the token type and the use case, before you can judge what “high” refers to. Another possibility: the project team does not have a clear number either. They received user feedback but have not broken it down to a quantitative level yet.
Second, where does the two-week deadline come from? If it comes from a roadmap commitment, a security audit may not be in this version of the contract at all — they may simply be looking for frontend contractors. If it comes from a partner’s requirement, that partner may have specific security standards you need to align with. The first scenario points your follow-up toward “the smallest security review we can finish inside a two-week window.” The second scenario points toward a more complete proposal.
The group chat gives you the entry point. Without those two numbers, you cannot quote.
You already know what to ask first
Look at the message again. The sender is offline now. You are not in a hurry to reply.
What you read is no longer “a wallet-integration request.” “Connect” tells you about the team’s stage. “Sign” points to a blind spot in the user interaction. “Approve” shows you the hole a user already stepped into. You do not need to cover all three at once. You pick one layer and ask the first question.
In this simulated scene, the approval layer is the clearest starting point because user feedback is already on the table. You can ask: “How are you setting the approval allowance right now?” If the answer is “no limit — straight to max,” that is the cleanest follow-up signal you can get. If the answer is “I am not sure which pattern we are using,” there is someone missing from the decision chain — your first step is confirming who the contact is.
You could also ask either of the other two questions, depending on what you are strongest at. “Can users see the amount before they sign?” opens the signing-audit door. “Is your own frontend handling the WalletConnect integration?” helps you gauge team completeness.
Whichever question you choose, the goal is not to finish all three layers in one conversation. It is to use the first answer to decide direction. What they say back determines whether you go deeper on this layer or pivot to another.
When you reopen the saved context for this message, you see that the sender asked about contract testing in a neighboring technical group last week, and the “approved without checking” reference this time is a continuation of the same wallet project. History and current message sit together. No digging required.
You already know what to ask first.
Market and risk discussion is supporting evidence
Top Prospect is primarily a Telegram lead-generation product. Market and risk discussion can add context to a candidate lead, but it does not become a verified incident, trend, or sales opportunity automatically.
