What connecting a wallet actually shares, and what it does not
The difference between connecting and signing, what a site learns when you connect, and which requests mean you should close the tab.
Two different actions get called the same thing in casual conversation, and confusing them is how people end up either paranoid about something harmless or relaxed about something dangerous.
Connecting is not signing. Let's separate them properly.
What connecting does
You click connect, your wallet asks for permission, you approve. Now the site has exactly one thing: your public address. Nothing more.
Public addresses are exactly what they sound like. They sit on a public ledger, anybody can look one up, and knowing one grants nobody the ability to move a single lamport. Somebody can see your balances and your transaction history. They cannot spend a lamport.
So the mental model is closer to giving someone your bank account number than your card. They can send you things and they can see what arrives. They can't withdraw.
What signing does
Signing is where authority changes hands, and it's always a separate prompt.
When you sign, you're cryptographically authorising a specific instruction: transfer this much SOL to this address, or grant this program permission to move this token. Your wallet shows you what it is before you approve, and nothing happens until you do.
Which means the security question is never "should I connect". It's always "what exactly am I signing".
What a site can see once connected
Worth being concrete, because vagueness here breeds bad instincts.
Connected sites can read your public address, your SOL balance, every token you hold, your full transaction history going back to the first deposit, and by extension every other address you have ever sent to or received from. All of that was already public. Connecting just tells the site which address to look at.
A connected site cannot see your seed phrase, your private key, your other unconnected accounts, or anything at all outside the chain.
Which requests are normal
So what should a service actually ask for? For one like this, the entire legitimate flow is 2 steps:
- Connect, so the site can read which mints you hold
- Sign exactly one transfer, if you decide to pay
That's the whole list. Reading balances needs no permission beyond the address, and payment needs 1 signature.
Which requests mean close the tab
Some requests have no legitimate version. Not "usually suspicious". No legitimate version.
A seed phrase or private key. No site ever needs this. Not to verify you, not to connect you, not to run anything on your behalf. Everyone who lost funds to a drainer believed they'd found the exception.
A token approval you didn't initiate. Approvals let a program move a token on your behalf, which is normal for a swap you asked for and abnormal for a site that just wants to "verify" something. Solana token approvals covers how to read and revoke them.
A transaction whose preview you don't understand. Can you explain what it does in one sentence? If not, reject it. Rejecting a legitimate transaction costs you 20 seconds. Approving a malicious one costs you everything in the account.
Anything urgent. Drainers manufacture time pressure because reading takes time. Any real service can wait 5 minutes while you think about it.
The habit that actually protects you
Separate your accounts by job, and the whole category of risk shrinks.
Keep a storage wallet, ideally hardware-backed, that connects to nothing. Keep a separate wallet for launching and interacting, funded with what that job needs and no more. When you're trying an unfamiliar tool, use the second one.
Then the worst case for a bad signature is bounded by whatever was in the interaction wallet, rather than by everything you own. Phantom vs Solflare vs Backpack covers which wallet suits which job, but honestly the separation matters more than the choice.
Why this comes up on a volume service
Because the request pattern is the fastest way to judge one.
A campaign needs to read your public address, so it can list the Pump.fun mints you hold, and it needs one signed payment. Nothing else. Any service asking for a key or a standing approval is either badly built or built for a different purpose than the one advertised, and you don't get to find out which until afterwards.
That check sits near the top of how to judge a volume service for exactly that reason. The console is a reasonable reference for what the safe version looks like: connect to read, configure, see the full price, sign one transfer.
Frequently asked
No. Connecting shares a public address and grants no authority. Money moves only when you sign a transaction, which is a separate action with its own prompt.
It's good hygiene and costs nothing, though the real risk was never the connection. Standing token approvals are the thing worth auditing and revoking.
Only the account you selected is shared. But that address is public, so anything it has ever done is visible to whoever holds it, including links to other addresses you funded from it.
Everything in this guide describes mechanics that settle on Solana mainnet, so you can check any of it yourself. Mint addresses, swap signatures, curve progress and wallet counts are all public, and an explorer will disagree with us if we are wrong.
Curvegrad sells a volume service, and guides that touch on what a campaign does say so in the text rather than in a footnote.
- Solana mainnet transaction history, read through the standard RPC methods
- Pump.fun bonding curve and PumpSwap pool accounts as they appear on-chain
- Public block explorers, where every claim here can be verified against a real mint
- Campaigns run through our own engine, which is where the operational detail comes from