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)

SoulBound Finance launches on Arbitrum mainnet on April 20, 2026 — the first privacy-preserving payment protocol that embeds regulatory compliance at the smart contract layer rather than bolting it on after the fact.

This post and the accompanying repository cover the on-chain smart contracts only, released under AGPL-3.0. The full platform — application frontend, backend OTU generation and redemption services, and operational infrastructure — is proprietary and not included in the open-source release. What you’re reading about here is the settlement layer: the contracts that custody funds, enforce access control, verify attestations, and process redemptions.

The protocol enables users to deposit crypto, generate anonymous one-time-use (OTU) transfer codes, and have those codes redeemed to ephemeral addresses — all while maintaining an immutable attestation of purpose on-chain. It is purpose-built for charitable giving, donations, and personal gifts where the sender’s identity should be verifiable by regulators but invisible to recipients.

The contracts are written in Solidity 0.8.19, built with Foundry, and carry zero external dependencies (no OpenZeppelin). Every line was written from scratch.

This post serves two purposes: to explain how the on-chain protocol works for anyone evaluating it, and to solicit security review from the community before mainnet deployment. We’re publishing the contract source code now because we want real scrutiny from people who break things for a living — not a rubber stamp.

The protocol repo: github.com/SoulboundSecurity/sbf-protocol

The System at a Glance

Three operational contracts, deployed and linked atomically by a fourth deployer contract:

• SoulBoundToken Non-transferable identity token. Gates access to the protocol.

• DepositPool Accepts multi-token deposits. Generates OTUs with EIP-712 attestations.

• ClaimPool Processes anonymous OTU redemptions to ephemeral addresses.

• SoulBoundDeployer Atomic deployment, linking, and ownership handoff of the three contracts above.

The flow is: Mint SBT → Deposit → Generate OTU (with attestation) → Redeem anonymously.

SoulBoundToken — Identity Without Addresses

The SBT is a non-transferable token that represents a user’s identity within the protocol. It is not an ERC-721. There is no transfer, no approve, no tokenId. One address, one SBT, forever.

What it stores

Each SBT contains:

• encryptedAccountId — A deterministic hash of the user’s address, a protocol-specific salt, and the chain ID. The protocol never stores raw wallet addresses in its identity layer.

• zkpCommitment — A slot for a zero-knowledge proof commitment (Privado ID). Set at mint or updated later. Enables privacy-preserving KYC without revealing identity.

• nonce — A counter that increments every time the user generates an OTU. This is the backbone of replay protection for attestation signatures.

• eulaHash — The keccak256 of the terms the user accepted at mint time. This is an immutable on-chain record of which version of the terms were signed. When terms update, old SBTs retain their version.

• mintedAt — Timestamp of creation.

Minting

Minting requires the user to provide the current EULA hash. The transaction signature itself is the cryptographic proof of acceptance — no separate signing step. If the EULA hash doesn’t match what the controller has set, the mint reverts.

Once minted, the SBT cannot be transferred, burned, or re-minted. The identity is permanent.

Nonce Management

Only the DepositPool contract can increment a user’s nonce, and it does so exactly once per OTU generation. This prevents attestation signature replay: each attestation is bound to a specific nonce value, and once the nonce increments, that signature is permanently invalidated.

DepositPool — Multi-Token Deposits and OTU Generation

This is where funds live and where the attestation logic happens.

Deposits

Users with a valid SBT can deposit ETH (native) or any whitelisted ERC-20 token. Deposits have no protocol fees. Balances are tracked per-user, per-token in an internal mapping.

Supported tokens at launch: ETH, USDC, USDT, WBTC. The controller can add or remove tokens from the whitelist. ETH cannot be removed.

OTU Generation — The Core Mechanism

This is the most security-critical function in the protocol. When a user generates an OTU, they are converting deposited funds into an anonymous bearer instrument that can be redeemed by anyone who possesses the code.

The generation process requires an EIP-712 typed data signature from the user that attests to the purpose of the transfer. This attestation is:

1. Per-transaction — The fee tier (charitable vs. commercial) is not stored per-user. The same user can generate a charitable OTU for a church donation and a commercial OTU for a business payment, each with its own attestation.

2. Nonce-bound — The attestation includes the user’s current SBT nonce. After generation, the nonce increments, permanently invalidating that specific attestation signature.

3. Immutable on-chain — The user’s signature is a cryptographic commitment to their stated purpose. If they attest “charitable” but use the funds commercially, they have signed a false attestation on a permanent, public ledger. The legal exposure falls on the user, not the protocol.

Fee Structure

Fees are charged on OTU generation, not on deposits:

• Charitable tier: 1.00% protocol fee + 0.25% gas reserve = 1.25% total

• Commercial tier: 2.00% protocol fee + 0.25% gas reserve = 2.25% total (disabled at launch)

The gas fee (0.25%) is immutable — hardcoded at 25 basis points as a Solidity constant. Protocol fees are controller-adjustable but capped at 5% maximum (500 bps). Both caps are enforced in the contract.

Fees are calculated on top of the OTU amount: if you generate a 1 ETH OTU, you pay 1.0125 ETH from your balance (charitable tier). The recipient receives exactly 1 ETH.

Fee Distribution

Protocol fees go directly to the protocol treasury address. The OTU amount plus gas fee goes to the ClaimPool. These are separate transfers in the same transaction.

The protocol treasury address is mutable — the controller can update it (for multisig rotation, etc.). The ClaimPool link, by contrast, is set once and cannot be changed.

EIP-712 Attestation Verification

The signature verification implements full EIP-712 with:

• Domain separator bound to contract address + chain ID (prevents cross-chain and cross-contract replay)

• Struct hash includes: depositor address, token, amount, fee tier, nonce, and a purpose hash

• ECDSA recovery with EIP-2 s-value enforcement (restricts s to lower half of the curve order to prevent signature malleability)

• v-value validation (must be 27 or 28)

• Recovered signer must equal msg.sender

The purpose hash is a keccak256 of a human-readable string that appears in the user’s wallet signing prompt:

• Charitable: “I attest this withdrawal is for charitable, donation, or personal gift purposes”

• Commercial: “I attest this withdrawal is for commercial or business purposes”

Emergency Withdrawal

Any SBT holder can withdraw their full balance for any token at any time. No fees. No whitelist check (works even if the token has been delisted). This is the escape hatch — it always works.

ClaimPool — Anonymous Redemption

The ClaimPool receives funds from the DepositPool and processes redemptions. It maintains two separate balance pools:

• Redemption balance — Funds available for OTU redemptions

• Gas fund balance — The 0.25% gas fee reserve, used for operational costs (DeFi yield, gas subsidies)

Redemption Processing

An operator (backend service) processes redemptions. The key design property: recipient addresses are ephemeral. They are used exactly once in the redemption transaction and never stored on-chain beyond that transaction’s logs.

Each redemption requires a unique redemptionHash — a hash of the OTU code. The contract tracks which hashes have been processed, preventing double-spend. Once a hash is marked as processed, it can never be used again.

Batch Redemptions

The operator can process multiple redemptions in a single transaction. This is a privacy feature: by batching redemptions together, it becomes harder to correlate the timing of a deposit with a specific redemption. Individual timing analysis is defeated when multiple redemptions are processed atomically.

The batch function is fault-tolerant: if an individual redemption in the batch has already been processed, has a zero amount, or targets the zero address, it is skipped rather than reverting the entire batch.

Maximum batch size is 50 items.

Gas Fund

The gas fund receives the 0.25% fee from every OTU generation. The gas manager can use these funds for DeFi operations (e.g., depositing to Aave for yield) or operational costs. The useGasFund function accepts arbitrary calldata, enabling interaction with any DeFi protocol.

The gas manager role is separate from the operator role. The operator processes redemptions; the gas manager manages the operational treasury. A compromised gas manager key could drain the gas fund — the gas manager key should be held in an HSM or secure enclave with monitoring on gas fund balance.

SoulBoundDeployer — Atomic System Bootstrap

The deployer is deployed independently, then creates all three operational contracts, links them together, and transfers ownership — all in one transaction via deploySystem(). This eliminates the risk of partially-configured systems or ownership gaps.

Deployment Flow

1. Deploy SoulBoundToken (deployer contract as temporary controller)

2. Deploy DepositPool (deployer contract as temporary controller)

3. Deploy ClaimPool (deployer contract as temporary operator)

4. Link all contracts to each other and configure: SBT ↔ DepositPool, DepositPool → ClaimPool + Treasury, ClaimPool → DepositPool + Gas Manager, EULA hash on SBT

5. Whitelist initial tokens

6. Transfer all roles to msg.sender (expected: multisig)

If any step fails, the entire transaction reverts. There is no state where one contract exists without the others being properly configured.

Post-Deployment Validation

The deployer includes a validateDeployment() function that returns a boolean and an array of issue strings. It checks every linkage, every configuration, and every role assignment. This is designed to be called by deployment scripts to verify the system is correctly configured before proceeding.

Operator Trust Model

The protocol has three privileged roles, each with a clearly scoped trust boundary:

Controller (SBT + DepositPool): Can update EULA, modify fee rates (capped at 5%), toggle commercial tier, add/remove tokens, update the treasury address. Cannot access user funds. Cannot generate OTUs on behalf of users. Cannot process redemptions.

Operator (ClaimPool): Can process redemptions and batch redemptions. This role is held by the backend application — the bridge between off-chain OTU validation and on-chain fund transfer. A compromised operator could drain the ClaimPool redemption balance. Mitigation: operator key should be held in a secure enclave or HSM, with monitoring on ClaimPool balance and redemption patterns.

Gas Manager (ClaimPool): Can deploy gas fund to external contracts (Aave, etc.) via arbitrary calldata. Cannot access redemption balance. Same key management recommendations as operator.

Testing

Our internal test suite covers 78 Forge unit tests and 24 live-chain smoke tests against local Anvil deployments. Every public function has happy path, revert case, and edge case coverage. The smoke tests run the full deposit-to-redemption cycle with real transactions, randomized deployer wallets, and gas metering — different contract addresses every run.

Test philosophy: every revert path gets its own test. If the contract has a custom error, there’s a test that triggers it. Fee calculations are verified to the wei. EIP-712 attestation tests cover valid signatures, replayed nonces, wrong signers, malformed signatures, and cross-tier mismatches. Batch redemption tests verify skip logic for already-processed hashes, zero amounts, and zero addresses within a single batch.

Full test coverage documentation is available at TESTING.md in the repo.

We do not publish our internal test suite, but we welcome community-contributed tests. If you write tests that break something — or prove something holds — we want them. Contributions should follow the existing contract conventions: Forge-std, custom errors for all revert cases, and the same happy path / revert / edge case structure documented in TESTING.md. See CLA.md for contribution terms.

Security Properties We Believe Hold

These are the properties we’re asking reviewers to verify or challenge:

1. No double-spend. Each redemptionHash can only be processed once. The processedRedemptions mapping prevents replay.

2. No attestation replay. Each attestation signature is bound to a specific nonce. The nonce increments after each OTU generation. A used attestation signature can never produce a valid OTU again.

3. No signature malleability. EIP-2 s-value range check ensures each signature has exactly one valid form.

4. No cross-chain replay. The EIP-712 domain separator includes address(this) and block.chainid, binding signatures to a specific contract on a specific chain.

5. No fund extraction beyond balance. Users can only generate OTUs up to their deposited balance minus fees. The balance check is performed before any state mutation.

6. No unauthorized fund movement. Only the DepositPool can send funds to the ClaimPool (via receiveFunds/receiveFundsETH). Only the operator can process redemptions. Only the gas manager can use the gas fund.

7. No reconfiguration of critical links. The DepositPool ↔ ClaimPool link and the SBT ↔ DepositPool link are set once and cannot be changed.

8. Emergency withdrawal always works. Bypasses the token whitelist, charges no fees, and returns the user’s full balance. This is the unconditional escape hatch.

9. Checks-effects-interactions pattern maintained. All balance updates occur before external calls in every function that transfers funds. Note: generateOTU updates balances, then calls incrementNonce on the SBT contract (an external call), then distributes funds. The intermediate SBT call occurs after balance deduction but before fund transfers — reentrancy through the SBT cannot double-spend because the balance is already zeroed.

10. No delegatecall, no selfdestruct, no tx.origin. The protocol uses none of these patterns.

What We’re Asking For

We’re asking the security community to:

• Read the contracts. They’re compact — SoulBoundToken is ~220 lines, DepositPool is ~500, ClaimPool is ~330. No inheritance trees, no abstract base classes, no OpenZeppelin.

• Challenge the properties above. If any of them don’t hold, we want to know.

• Look for edge cases in the fee calculation, the EIP-712 verification, the batch redemption logic, and the gas fund operations.

• Consider the interaction patterns. The contracts are designed to be called in a specific order. Are there orderings that produce unexpected states?

Mainnet deployment is April 20, 2026. The application will be live at soulbound.finance on launch day.

Responsible Disclosure

If you identify a vulnerability, please report it to security@soulboundsecurity.io before public disclosure. We take every report seriously and will acknowledge receipt within 24 hours.

Links

Protocol repo github.com/SoulboundSecurity/sbf-protocol
Website soulboundsecurity.io
App (live April 20) soulbound.finance
Security contact security@soulboundsecurity.io
License AGPL-3.0
Owner SoulBound Security Ltd (NI735885)

Stablecoins had $27.6 trillion in transaction volume last year. USDC is live on every major blockchain. Circle just got conditional OCC approval for a national trust charter. Stripe bought Bridge for $1.1 billion. The infrastructure for moving dollars on-chain has never been better.

So why is a $1,500 donation to a veterans’ charity still losing $124.54 to a payment processor?

That’s a real screenshot. A real donation to Folds of Honor — a 4-star Charity Navigator organization that funds scholarships for families of fallen service members. Our investor sponsored their tournament at TPC Treviso Bay this week. 8.3% gone before a dollar hits the mission.

The standard credit card processing fee for charitable donations is 2.9% plus 30 cents. However, when you stack the platform fee, the gateway fee, and the administrative layer on top of that 2.9%, the “cover the fees” checkbox becomes effectively mandatory - or the organization will be routinely losing 5-10% per transaction.

This is the most broken payment rail in finance. And it’s enormous.

The Market Nobody’s Building For

Global charitable giving hit $2.3 trillion in last year. That’s not a typo; $2.3 trillion which is larger than the GDP of Italy.

Religious giving alone dwarfs most DeFi categories. In the US, religious organizations received $146.54 billion last year — the single largest charitable subcategory, bigger than education, health, and human services. Globally, Islamic zakat — the obligatory 2.5% annual wealth contribution that is one of the Five Pillars — is estimated at $600 billion per year by itself. The UNDP and World Bank place the total annual zakat pool between $200 billion and $1 trillion.

Add Christian tithing outside the US, Hindu dana, Jewish tzedakah, Sikh dasvandh, Buddhist giving, and the vast network of informal community-based giving in every faith tradition — and global faith-based giving conservatively exceeds $1 trillion annually.

For context: all of DeFi had roughly $170 billion in locked assets at peak. The religious giving market moves that amount every two months.

Every dollar of it runs on Stripe, Square, PayPal Giving Fund, and legacy card rails extracting 5-10%. There is no DeFi product serving this market. Zero. The entire stablecoin ecosystem has ignored the single largest recurring payment category in the world.

Two Reasons Why It’s Ignored (And Why That’s the Opportunity)

First, it’s not sexy. Crypto builders chase trading, lending, and speculation. Charitable giving doesn’t generate yield, doesn’t create leveraged positions, and doesn’t produce governance tokens. It’s a payment — and payments are “boring.”

Except Stripe just paid $1.1 billion for stablecoin payment infrastructure. PayPal launched PYUSD. Coinbase embedded USDC into Base. The market has figured out that stablecoin payments are the real endgame. Charitable giving is just the payment vertical nobody’s claimed yet.

Second, it requires privacy. This is the part crypto has struggled with since Tornado Cash.

A donor sending $500 to their local food bank doesn’t want that on a public ledger. A family tithing 10% of their income doesn’t want their financial life visible to anyone who looks up the church’s receiving address. These aren’t criminals. They are the most generous segment of the global population, and they need the same privacy that a cash donation in a collection plate has always provided.

The existing privacy tools in DeFi — mixers and shielded pools — are either sanctioned, abandoned, or designed for crypto-native power users. Nobody has built a privacy-preserving payment product simple enough for a church treasurer to use.

Where Privacy Becomes a Safety Requirement

And then there’s the part of this market where privacy isn’t about preference — it’s about survival.

The USCIRF 2026 Annual Report identifies 18 countries where governments engage in “particularly severe” violations of religious freedom. Two-thirds of the world’s population lives in nations where religious communities face persecution. In those jurisdictions, a financial record of a charitable donation is a surveillance vector.

In China, the CCP has made charitable giving itself a crime for certain communities. In testimony before the Congressional-Executive Commission on China in November 2025, ChinaAid’s president described the government’s latest crackdown as explicitly targeting the criminalization of tithing, offerings, and normal church finances.

For Uyghur Muslims in Xinjiang, it’s worse. China banned zakat — the obligatory Islamic charitable contribution — in the region in 2016. Uyghur businessman, Elijan Ismail, organized charitable donations to community members in need. Police branded his group of donors an “ethnic separatist group.” He was sentenced to 18 years in prison for giving money to people who needed it.

This is a region with 400 million surveillance cameras, facial recognition systems built to track ethnic and religious minorities, and mandatory phone monitoring apps. Financial transactions are cross-referenced against identity databases. The infrastructure that made his giving visible is the infrastructure that put him in prison.

Nigeria. India. Pakistan. North Korea. The pattern repeats: Uyghur Muslims, Chinese Christians, Baha’is, Ahmadiyya communities, Tibetan Buddhists — authoritarian governments use financial records to identify and punish people for the act of giving to their own communities.

Cash solved this for centuries. The collection plate, the zakat box, the charity basket — anonymous by design. Digital payments eliminated that privacy, and nobody in crypto has built the replacement yet.

SoulBound: 1% Fee. No Payment Trail. Cash-Like Simplicity.

This is the product we’ve been building.

A donor deposits stablecoins into their private SoulBound account — verified once at entry via soulbound token and ZKP-based identity. They generate a one-time-use code for any amount — a QR code or a shareable link. That code is the donation. The recipient redeems it to any wallet. No login required. No payment trail between sender and receiver. No database linking the two.

1% flat fee. That’s it.

On a $1,500 Folds of Honor donation: $15 instead of $124.54.

For a mosque handling $500,000 in annual zakat collections, or a church processing the same in tithes: $5,000 instead of $25,000-$50,000 lost to processors. That’s $20,000-$45,000 back in the budget every year. Staff positions. Building repairs. Food for families.

Redemption is free. The code works like digital cash — bearer instrument, redeemable by anyone who holds it, on their timeline, to their address. Like handing someone an envelope, except it works across borders and the denomination is dollar-stable.

The Super Bowl pool problem we wrote about in January? Same architecture, different vertical. OTU codes solve group payout distribution for prediction markets, and they solve private giving for $1 trillion in annual religious donations. The infrastructure is identical.

April 20: Mainnet Beta on Arbitrum

We’re going live April 20, 2026.

Initial launch is a mainnet beta focused on charitable and religious giving, deployed on Arbitrum One. USDC and native ETH supported at launch.

Geo-restricted beta. Not available in the US, UK, or EU at launch. Access requires EULA acceptance and a cryptographic signature confirming jurisdictional eligibility. Standard DeFi launch practice — Polymarket ran this exact playbook before achieving regulatory clarity domestically.

We’re simultaneously entering the FCA’s stablecoin regulatory sandbox in the UK, targeting full US/UK availability in 2027.

Core protocol ships AGPL-3.0 before launch. Open infrastructure, composable by default. More on that in our next post.

The communities that need this most are operating outside Western regulatory jurisdictions — where payment infrastructure extracts the most, where financial privacy carries the highest stakes, and where $1 trillion in annual giving is waiting for a better rail.

SoulBound is that rail.

Subscribe now

SoulBound Finance launches on Arbitrum, April 20, 2026.

Follow: soulboundsecurity.substack.com

Prediction markets changed the game. Whether you’re on Polymarket, Kalshi (now available through Coinbase in all 50 states), or Binance — you and your friends can pool capital on anything from elections to earnings calls to the Super Bowl. The problem? You’re not placing bets—you’re trading tokens and event contracts.

And when your buddy in London, your cousin in Berlin, and your college roommate in Austin all chip into the same pool, someone has to handle the accounting when the Pats win.

That someone is usually whoever set up the wallet. Congratulations, you’re now running a multi-jurisdictional trading desk for your fantasy league.

The Scale of the Problem

This isn’t a niche issue. Prediction markets did $44 billion in combined volume in 2025. Kalshi alone is valued at $11 billion. Coinbase just launched prediction markets nationwide. These aren’t fringe platforms anymore—they’re becoming default infrastructure for information discovery.

But the tooling assumes solo traders, not groups.

The Cash Model

Here’s how it used to work with physical cash: everyone throws money in an envelope, winner gets the envelope, everyone handles their own business. Simple. Clean. The pool organizer isn’t responsible for what happens after the handoff.

SoulBound brings that model on-chain.

How It Works

1. Your group deposits USDC into a shared SoulBound account (one person sets it up, others contribute, privately via SoulBound if desired)

2. The pooled funds are used to trade on Polymarket, Kalshi, Coinbase, Binance—wherever

3. When you win, the organizer generates OTU codes—one for each participant’s share

4. Each person redeems their own code to their own wallet

The organizer distributes bearer instruments, not wallet-to-wallet transfers. Each winner receives what’s essentially digital cash—redeemable anywhere, by anyone holding the code. What they do with it after that is their business, in their jurisdiction, on their own timeline.

CEX or DEX—Same Problem

Doesn’t matter if you’re on a centralized exchange like Coinbase or Binance, or a decentralized protocol like Polymarket. The moment you pool with friends across borders:

• One wallet holds everything

• Payouts create wallet-to-wallet transfer chains

• The organizer becomes the hub for everyone’s downstream complexity

Whether the prediction market is regulated (Kalshi/Coinbase) or decentralized (Polymarket), the payout problem is identical.

What Groups Actually Need

• Privacy between members (not everyone wants the pool to see their full wallet history)

• Clean separation at payout (no single point of distribution complexity)

• Cash-like finality (once you hand over the code, you’re done)

SoulBound delivers all three. Pool together, win together, split cleanly.

The Bigger Picture

This isn’t just about Super Bowl squares. It’s about any scenario where groups coordinate capital and need to distribute returns without one person becoming the back-office:

• International teams splitting project revenue

• Creator collectives dividing sponsorship money

• Investment clubs distributing profits

• Fantasy sports with actual stakes

Anywhere you’d say “let’s just Venmo each other after”—except Venmo doesn’t work across borders, exposes transaction history, and makes one person the hub.

SoulBound makes group finance work like handing out envelopes. Digital cash for a digital world.

Subscribe now

SoulBound launches on Arbitrum Q2 2026.