SoulBound Finance — Security & Privacy Overview
What we protect, what we don't, and why Soulbound Fi works the way it does.
A plain-language explanation of what we protect, what we don’t, and why the design works the way it does. For users, partners, charities, and anyone evaluating the system.
This post builds on our Protocol Technical Overview, which covers the contract architecture, fee model, and on-chain mechanics. The core protocol is open source under AGPL-3.0 on GitHub.
What the system does
SoulBound Finance lets you send crypto privately to someone — without putting your wallet next to theirs on a public block explorer, and without trusting an exchange or a third-party intermediary with either of your identities.
You generate a redemption code that looks like a gift card, optionally add a security code, and hand the code to the recipient through any channel you choose: in person, on a printed flyer, by text message, on a donation card, or embedded in a nonprofit's fundraising page.
The recipient redeems it on a public web page by entering the code, the security code if any, and the wallet address where they want their funds delivered. The funds arrive in their wallet, and the link between you and them is, by design, very hard to reconstruct.
The system is built for charitable giving, personal gifts, nonprofit fundraising, veteran and humanitarian support, remittances, and any other transfer where the parties have a legitimate reason to keep their on-chain identities separate — at 1% cost versus the 8–10% that centralized fundraising platforms take.
It is a privacy floor, not a hiding place. It is not a mixer. It is not an anonymity network. It is closer in spirit to a digital bearer instrument — a gift card or money order that travels at the speed of the internet.
How it works, end to end
You deposit funds into a shared pool by sending a normal on-chain transaction. This part is visible on the public chain. Anyone can see your wallet sent tokens to the deposit pool.
You generate a redemption code locally in your browser. The code and any security code you set are encrypted end-to-end with a key derived from your wallet — our backend never sees the plaintext of either. What we store is an opaque blob that only your wallet can unlock.
You give the code to the recipient through any channel you trust. Print it. Hand it over. Mail it. Text it. The system does not care how it travels.
Time passes. Hours, days, weeks, months. There is no on-chain activity on your account during this gap. As far as the public blockchain is concerned, you simply made a deposit and went about your life. The recipient may not even exist yet — you might generate codes for a charity drive in advance and distribute them weeks later.
The recipient redeems by typing the transfer code, the security code if any, and their wallet address into a public web page. They do not need a wallet of their own to use the page — only an address where they want to be paid. They never connect their wallet to anything; they just type.
The system delivers their funds from a shared claim pool, batched together with other unrelated redemptions, in one on-chain transaction. The recipient’s wallet receives funds from a pool address. Nothing on the chain ties that delivery back to your original deposit.
What we protect — and why it actually works
Sender and recipient never appear in the same on-chain transaction
This is the structural guarantee. When you deposit, your wallet interacts with the deposit pool. When the recipient claims, their wallet receives funds from the claim pool. The two pools are operational siblings, not the same contract your deposit touched. There is no on-chain transaction in which both wallets appear together.
An observer scanning the chain sees two unrelated events: “wallet A made a deposit” and “wallet B received a payout.” Nothing on the chain joins them. The smart contracts that enforce this separation are open source and auditable.
The time gap multiplies the privacy beyond the protocol level
This is the part most people underestimate. In practice, a typical SoulBound transfer has days, weeks, or months between when you generate a code and when the recipient redeems it. A church distributes printed donation codes at Sunday service; some recipients claim them that evening, others the following weekend, others not until the next month. An organization like Mission 22 issues veteran support codes at the start of a quarter; recipients claim them on their own schedule. A birthday gift sent to a relative may sit in a drawer until they remember to use it — and unlike a GoFundMe campaign that takes 8–10% off the top, the sender paid 1% total.
During that gap, the shared claim pool processes hundreds or thousands of unrelated redemptions from unrelated codes. By the time your recipient claims, the pool has been churning continuously, mixed with every other transfer the protocol has processed in the interim. To correlate your deposit with your recipient’s claim, an observer would need to:
Narrow the candidate window of deposits to a specific time range — impossible without internal data, because there is no on-chain signal that tells them which deposit “belongs to” which claim
Match by amount — defeated by the standard deposit amounts everyone uses, plus the volume of other deposits in the same range
Match by token — defeated similarly
Cross-reference any of the above with internal database access we do not grant
A sophisticated chain analytics firm with full forensic tooling could produce a probabilistic guess in a small system. In a busy system with continuous flows, even probabilistic guessing breaks down. The privacy gets stronger as the system gets more popular, which is the opposite of how most privacy systems behave.
This is meaningfully better than the obvious alternative — sending through an exchange hot wallet — because exchange hot wallets settle within seconds or minutes, not weeks, and exchanges keep complete records of every customer for legal retention periods. The time gap simply does not exist in the exchange model. Here it does, naturally, because the OTU code is dormant in the recipient’s pocket the entire time.
No on-chain footprint on the sender’s account at redemption time
When the recipient claims, nothing happens to your wallet on the chain. There is no withdrawal, no transfer, no event log entry, no nonce increment, no balance change. The entire claim is processed by the shared pool, not by you. An observer watching your wallet would see no signal whatsoever that one of your generated codes was just claimed by anyone, anywhere. They would have to be watching the entire pool, in the entire window, for every claim, and trying to back-correlate to your deposit by matching amounts and times — which the time gap and the volume of unrelated activity makes impractical.
The recipient receives only what they need to claim
The redemption page never shows the recipient anything about you, the transfer’s internal identity, the creation time, or any other piece of data they did not already bring with them. They see the code they typed (because they typed it), the wallet address they typed (because they typed it), and a confirmation that the redemption was submitted. Nothing else.
They cannot screenshot any field that would let them, or anyone watching their screen, look up your account, your detail page, or your other transfers. The recipient brings three pieces of information to the protocol — code, PIN, address — and the protocol returns one piece of information: success.
Your security code is yours to recover, and only yours
If you set a security code on a Soulbound Transfer, the security code is encrypted alongside the code itself in the same end-to-end encrypted package. The encryption key is derived from your wallet.
Our backend stores only opaque ciphertext — we cannot read your security code, even if compelled to. If you forget which security code you put on which code (a real problem when distributing 20 codes for a fundraising drive), you can recover it from the code’s detail page by confirming your wallet identity.
Only your wallet can decrypt. We never see the plaintext at any point in the lifecycle.
Secrets never touch the page until you ask for them
The detail page where you manage your generated codes is designed around a simple principle: nothing sensitive exists anywhere on the page — not in the visible UI, not in the underlying page structure — until you explicitly click a reveal button for that specific field. Each secret (the redemption QR, the Soulbound Transfer code, the security code) is revealed independently.
When you click hide, the secret is fully removed from the page, not just visually concealed.
This matters because modern devices routinely run software that reads page content — screen readers, browser extensions, accessibility tools, AI assistants. If a secret is on the page, those tools can see it. So we don’t put it on the page until you decide to look at it, and we take it off the page the moment you’re done.
Stateless design — no recipient address in our database
The recipient’s wallet address is never stored in plaintext in our system. We never log it. We never index it. There is no table you could subpoena from us that would yield “the addresses that have redeemed codes from sender X.”
That table does not exist, by deliberate design. The recipient’s information exists only for the brief moment it takes to construct and send the on-chain settlement transaction, then it’s gone.
Creator-facing transparency is by design
The creator — the person who deposited funds and generated the code — can see their own transaction details: amount, token, creation timestamp, redemption timestamp, and proof of settlement. This is intentional and correct. The creator gave someone money. They have a legitimate interest in knowing whether and when that money was claimed.
This is the same visibility you get from your bank when you write a check: you can see it was cashed, when, and for how much. What you cannot see — and what the system deliberately withholds — is who cashed it.
The redemption timestamp and amount are not privacy leaks. They are the creator’s own records of their own financial activity. The privacy boundary in SoulBound is between the creator and the redeemer, not between the creator and the system.
Even our own admin console cannot see your data
The system that runs the protocol needs an admin dashboard — every payment system does. The question is what the admin can see and do. In most fintech products, admin access means full visibility: transaction details, user balances, account histories, the lot. SoulBound takes the opposite approach.
Our admin console is authenticated using Soulbound Auth (SBA), an open-source Web3 authentication system we built and released under MIT license.
SBA never stores Ethereum addresses server-side. Instead, it uses the same SoulBound Token identity model as the rest of the platform — the admin authenticates by proving ownership of a specific hardware wallet whose identity is hardcoded into the backend’s access control list.
No password, no email, no stored credentials. If you don’t hold the physical hardware wallet, you don’t get in. There is no “forgot password” flow because there is no password to forget.
What the admin console can do is deliberately narrow: view aggregate platform metrics (total value locked, fee revenue, queue depth), trigger operational processes, and monitor system health. That is the full list.
What the admin console cannot do is equally deliberate: it cannot view individual codes, cannot see who generated which transfer, cannot read encrypted data, cannot access user balances, cannot look up recipient addresses (those don’t exist in the database), and cannot make direct database connections.
The admin’s elevated privilege is operational, not informational.
This means that even in a worst-case scenario where an attacker compromises the admin hardware wallet, the damage is bounded. They cannot extract any user data because the admin surface was never wired to return it. The attack surface of the admin console is, by construction, the same as the public attack surface: zero user data exposure. Not because we redacted the data, but because the console never had it.
What we don’t protect — and where the line is
This is not a mixer. We do not promise unconditional cryptographic anonymity. A determined investigator with full internal access, sufficient subpoena authority, and a narrow target can usually reconstruct a specific transfer within a single batch window.
We are not trying to defeat targeted forensic investigation, sanctions enforcement, or properly served legal process. We are a registered company in Northern Ireland that complies with the law.
We don’t protect against you revealing yourself. If you tell the recipient who you are, or you screenshot a code with your wallet visible in the same frame, or you log into the redemption page from the same browser, device, and IP that generated the code, you have created correlations the protocol cannot erase.
The system is built for users who want privacy and behave consistently with that preference. We give you the tools; the discipline is yours.
We don’t protect against malware on your machine. If your computer is compromised — keylogger, screen reader, hostile browser extension, AI assistant that reads your tabs — anything you display on screen can be captured.
We mitigate this with the click-to-reveal pattern described above, but your device must be trusted by you. We cannot defend a compromised endpoint.
We don’t hide on-chain settlement. When the claim pool sends funds, that transaction is on the public chain forever. Anyone can see it.
Our privacy comes from the fact that no observer can tell which code triggered which payout — not from pretending the payout never happened.
Compared to the alternatives
Versus a direct on-chain transfer: Direct transfers put your wallet next to the recipient’s wallet on a block explorer, forever, in a single linkable transaction. Anyone who finds either wallet can find the other. SoulBound breaks this at the protocol level — there is never a moment when both wallets appear in the same transaction.
Versus an exchange hot wallet: Exchanges hide the direct link, but exchanges are required by law to log every customer, KYC every account, retain records for years, and respond to subpoenas.
They are also persistent targets for breaches that periodically expose customer histories at scale. SoulBound stores no recipient addresses, no code plaintext, and no sender-to-recipient link table.
And critically, exchange hot wallets settle immediately — the time gap that is the foundation of SoulBound’s privacy model does not exist in the exchange model.
Versus a privacy coin or mixer: These offer stronger cryptographic guarantees but are operationally and legally hostile to non-technical users, and several have been sanctioned.
SoulBound is not a mixer. It is a stateless transfer protocol. The privacy is structural and operational, not cryptographic obfuscation, which keeps it usable for nonprofits like Amnesty International, veteran support organizations, families sending private gifts, and ordinary donors — without the legal exposure that scares legitimate users away from mixers, and at 1% versus the 8–10% that platforms like GoFundMe ask for.
Versus a paper check or gift card: Functionally, SoulBound transfers behave like a digital bearer instrument: the holder of the code is the holder of the funds. Like a check, you can give one to anyone and they can claim it later.
Unlike a check, the recipient never has to share their bank account number with you, the issuer (us) never learns who the recipient is, and the settlement happens in minutes once the recipient is ready, not in days through a clearing system that can revoke or freeze.
Identity, KYC, and what the SoulBound Token actually is
Every user who deposits funds mints a SoulBound Token (SBT) — a non-transferable on-chain token bound to their wallet, defined in the open-source protocol contracts. The SBT is the user’s identity within the protocol.
It gates deposit, code generation, and access to the creator’s detail pages. It is not a financial instrument. It cannot be traded, sold, or moved to another wallet. It simply says: “this wallet has an account with SoulBound Finance.”
What makes this design flexible is what the SBT does not require. At launch, minting an SBT requires accepting the terms of service and confirming your jurisdiction and usage purpose via two on-chain attestation checkboxes. That is it.
The protocol works — and its privacy model holds — with nothing more than a wallet address and those two self-declared attestations.
KYC is optional — and the security model does not depend on it
The privacy guarantees described in this document — the structural separation of sender and recipient, the time gap, the stateless redemption, the end-to-end encryption — none of them require KYC.
They work identically whether the user has verified their identity or not. KYC is a compliance layer, not a security layer. The two are independent by design.
When SoulBound pursues regulated market access (FCA sandbox in the UK, EU MiCA, US MSB licensing), KYC will be introduced as an optional gate for users in jurisdictions that require it.
The SBT contract already has the plumbing for this — a field reserved for a zero-knowledge proof credential that can be issued by an identity provider and verified on-chain without revealing any personal data to us or to the public chain.
And neither KYC nor the SBT affects the privacy properties of the transfer itself — the bearer instrument, the batch settlement, the encrypted blob, the stateless redemption. Those are architectural properties of the protocol, not policy properties of the identity layer.
What ZKP-based identity verification means in practice
Zero-knowledge proof (ZKP) identity verification lets a user prove a fact about themselves — “I have passed KYC with an accredited provider” — without revealing the underlying data. The verifier learns that the statement is true.
They do not learn the user’s name, address, date of birth, document number, or anything else. The proof is cryptographic: it cannot be forged, and it cannot be reverse-engineered to extract the original data.
In SoulBound’s context, this means a user in a regulated jurisdiction can satisfy their local compliance requirements without surrendering personal information to our protocol.
The KYC provider holds the data (as required by law in that jurisdiction). SoulBound holds only a cryptographic commitment that says “this wallet’s owner has been verified” without saying who that owner is. If a regulator needs the underlying identity for a specific investigation, they go to the KYC provider with proper legal authority, not to us.
We do not have it. We never had it. That is the point.
The SBT is a container — we can add anything to it
The SBT is designed as an extensible identity anchor. Today it holds a wallet binding, EULA acceptance, and two attestation checkboxes.
Tomorrow it could hold a ZKP-KYC commitment. In the future it could hold accredited investor status, institutional verification, jurisdictional clearances, or tier-based compliance levels.
This is a deliberate architectural choice. The identity layer and the transfer layer are decoupled.
You can tighten identity requirements for specific markets without re-engineering the protocol, and you can run the protocol in permissionless markets without carrying the overhead of identity infrastructure that nobody there needs.
What you have to know to use this safely
The full list of things you need to remember:
Treat the transfer code like cash in your hand. Anyone who sees it can claim the funds.
Treat the Security code the same way. Don’t put it on the same surface as the code.
Don’t reveal codes on screens that other people — or software on your computer — can see. The detail page is built to keep secrets out of sight until you click reveal, but a compromised device can defeat any UI.
Once sent, the funds are gone from your control. There are no take-backs. This is by design — bearer instruments don’t reverse.
That’s it. Everything else — the encryption, the batch settlement, the gas abstraction, the shared pool accounting, the rate limiting, the entire backend privacy posture — happens automatically. You never have to configure it, manage it, or trust a third party with your secrets.
The protocol does the work, and the work is much simpler than it looks because the privacy comes from the shape of the system, not from any one clever cryptographic trick.
SoulBound Security Ltd · Londonderry, Northern Ireland
Protocol Technical Overview · Core Protocol (AGPL-3.0) · Soulbound Auth (MIT)
 | A guest post by
|