Four ways to send on Sanect: a practical privacy guide

The three things any send transaction can reveal

Every payment on a blockchain has three independent attributes that can be made public or kept hidden:

• Sender — the address that funded the transaction
• Recipient — the address that receives the funds
• Amount — how much was sent

On a transparent chain like Ethereum, all three are visible to anyone who looks at the block explorer. On a fully private chain like Zcash, all three are hidden inside zero-knowledge proofs. Sanect sits in between by design: it lets you pick which of the three you want to hide, depending on what you're actually trying to accomplish.

There are four practical combinations. Each maps to one specific use case.

The four modes at a glance

Mode 1: Public send

This is the standard EVM transfer. You sign a regular eth_sendTransaction from MetaMask. The recipient's balance updates immediately. Anyone watching the chain — Etherscan, a tax tool, a counterparty's analytics provider — sees the transaction in full.

Use this when: the payment is already public anyway (paying a published exchange address, settling an on-chain auction, or interacting with a public DeFi protocol). There is no privacy gain from routing a fundamentally public payment through a privacy pool.

Mode 2: Shield-to-recipient

You have public SNCT in your wallet but no shielded balance yet. You want to pay someone privately. Sanect routes the payment through the shielded pool in one transaction: your SNCT goes from your public balance into a newly created note that only the recipient's viewing key can decrypt.

What everyone sees: "Your address deposited N SNCT into the privacy pool." A new commitment appears in the on-chain Merkle tree. The encrypted memo bytes are visible but unreadable.

What no one sees: who the recipient is, that they received anything, or what they do with it next.

The trade-off: your identity as the depositor is public because you paid the msg.value. To outside observers it looks identical to you shielding for yourself. The recipient stays completely invisible until they choose to spend or withdraw.

Use this when: you want to pay one person privately and don't already have shielded funds. It's the fastest way to do a first-time private payment without onboarding into the privacy pool yourself.

Mode 3: Anonymous send to ETH address

Inverse of mode 2. You have shielded SNCT in the pool already. You want to pay a regular Ethereum-style address — someone who hasn't set up shielded keys, or a service that needs a normal wallet to credit. You sign a transaction that spends a note from the pool and routes the funds out to an ETH address.

What everyone sees: "The privacy pool sent N SNCT to address 0x…" That address now has the funds in their normal balance, indistinguishable from any other on-chain credit they receive.

What no one sees: who funded the note that paid this — i.e. who you are. The cryptographic nullifier hides which leaf in the Merkle tree was spent, breaking the link back to your original deposit.

The trade-off: the recipient and amount are public, but your identity as the sender is hidden behind the anonymity set of every other shielded depositor in the pool. Larger pools mean stronger sender anonymity.

Use this when: paying counterparties who don't have privacy set up but you don't want them (or anyone watching) to trace the payment back to your address. Think contractor payouts, donations, or settling debts without revealing your full transaction history.

Mode 4: Fully private send

Both you and the recipient have shielded balances. You want maximum privacy. Sanect routes the entire payment inside the shielded pool. Your existing note is spent (revealing only a nullifier, not which leaf), a new note is created for the recipient (revealing only an encrypted memo), and the public balance of the pool doesn't change at all.

What everyone sees: "Some pool activity happened." A nullifier was published. A new commitment was added. Nothing else.

What no one sees: who sent, who received, how much, or which existing note funded the transfer.

The trade-off: requires both parties to have a shielded balance. Slightly slower in practice because the dApp generates a Plonk proof that combines spend, nullifier, and new commitment in one circuit.

Use this when: the strongest privacy is appropriate. Salary, recurring payments, settling between counterparties who both care about discretion.

Worked example: paying Alice 100 SNCT

Let's walk through what an outside observer sees in each mode. You are R, you want to pay Alice A 100 SNCT.

Mode 1 — public send

An observer pulling the transaction off the explorer sees: "R sent 100 SNCT to A." Full link, full amount. R's wallet history and A's wallet history both reflect the transfer.

Mode 2 — shield-to-recipient (R has no shielded balance)

An observer sees: "R deposited 100 SNCT into the privacy pool. The pool's commitment count went up by 1. A new encrypted memo was published."

A's wallet history contains nothing. A only learns about the payment when she opens her wallet, scans the pool's events, and her viewing key decrypts the new memo. The chain has no record of A receiving anything.

Mode 3 — anonymous send to ETH (R has shielded balance)

An observer sees: "The privacy pool sent 100 SNCT to A. One nullifier was consumed." A's balance shows the credit, but the chain offers no way to determine which depositor's funds paid for it.

R's wallet history is silent. Her shielded balance went down by 100 internally, but only she can verify that.

Mode 4 — fully private send (both have shielded balance)

An observer sees: "Pool activity. One nullifier consumed, one commitment added."

That's the entire visible footprint. Nothing identifies R, A, or the amount. Both sides only see the change reflected in their own scanned balance.

Which mode should you actually use?

The honest answer: most of the time, mode 4 if both sides have privacy set up, mode 2 if only one side does, and mode 3 if you specifically need to deliver funds to a public address while staying anonymous as the sender. Mode 1 — the public send — is the default for routine interactions where privacy isn't the point.

The Sanect dApp tries to pick the right mode automatically. When you paste a recipient address into the Send tab, the app detects whether it's a regular ETH address or a sanect shielded address, checks whether you have enough shielded balance to cover the amount, and chooses the appropriate underlying transaction. The status banner under the field tells you which mode is about to fire and what that mode will and won't hide.

What none of these modes hide

Worth being explicit about what stays public regardless of mode:

• Gas paid — every transaction reveals the sender's address via the gas-paying account. For modes 3 and 4, this is an on-chain detail that's irrelevant to the privacy of the transfer itself (gas paid is a separate, tiny payment). Future Sanect work on meta-transactions will move this off the sender's address entirely.
• Timing — when a transaction happens is always visible. For low-traffic chains this is a real correlation vector. The Anonymity Maintenance Bot (queued for shipping after this guide) will pad the timing channel by generating realistic decoy traffic on the chain at a steady rate.
• The fact that you're using the privacy pool — anyone watching can tell which addresses interact with the shielded pool contract, even if they can't tell what was transferred. This is irreducible: privacy comes from blending with others doing the same thing, not from invisibility.

The takeaway

Privacy isn't binary. Different payments have different threat models. Sanect's four modes let you match each transfer to its actual privacy requirement instead of paying the full cost of maximum privacy for every transaction — or worse, accepting full transparency because the full-privacy option is too inconvenient.

For most users, the right pattern is: shield once, then send privately whenever you want, unshielding only when the recipient genuinely needs public funds. The lower the friction to using shielded sends, the more often they get used, the larger the anonymity set grows for everyone, and the stronger the privacy guarantee becomes.