It just needed one zero.

On August 1, 2022, the Nomad cross-chain bridge was drained of roughly $190 million in liquidity. The number was staggering, but the mechanics were stranger still: once the exploit went public, more than 300 addresses joined the feeding frenzy.

Most of them weren’t writing custom exploits. They were copying a working transaction’s input data, pasting their own wallet address into the recipient field, and resubmitting it. It became one of the most chaotic copy-paste heists in Web3 history.

At the center was one value doing two jobs: 0x00 meant “no proof recorded” in one place and “trusted” in another.

The Architecture: How Nomad Decided What Was Real

To understand how the flaw worked, you first need to understand how Nomad handles cross-chain messages.

Nomad is an optimistic interoperability protocol. When you send assets across chains, the message is committed into a Merkle tree on the source chain. An off-chain Updater signs each new root, the root is relayed to the destination chain, and it only becomes usable once a challenge window has passed. On the destination chain, a contract named Replica decides whether a message is valid and allowed to execute.

The fundamental security boundary is simple:

An inbound message must only execute after the protocol proves it belongs to a valid, accepted Merkle root.

If Replica accepts an unproven message, everything downstream of it (the routers, the liquidity pools, the token vaults) is exposed. The cryptography doesn’t fail here. The access-control gate simply opens the door.

The Assumption: What Happens When a Mapping Is Empty?

In Solidity, storage mappings don’t throw errors for keys that haven’t been set. Query a key that doesn’t exist and the Ethereum Virtual Machine (EVM) returns the default zero value for that type.

After its June 2022 upgrade, Replica tracked trust with two mappings:

// message hash => the root it was proven under
mapping(bytes32 => bytes32) public messages;

// root => timestamp after which the root is acceptable
mapping(bytes32 => uint256) public confirmAt;

For an unseen, fake or unproven message, messages[unknownMessage] naturally returns:

0x0000000000000000000000000000000000000000000000000000000000000000

Under normal circumstances, that’s fine. Zero means “nothing has been proven yet.” Zero represents absence.

The Collision: When “Nothing” Became “Everything”

The vulnerability became exploitable after a smart contract upgrade on June 21, 2022. The state that made it possible had been set two months earlier.

When Nomad deployed the Replica proxy on April 21, 2022, its initial committed root was set to bytes32(0). The initializer pre-approves whatever root it is given:

committedRoot = _committedRoot;   // _committedRoot was bytes32(0)
// pre-approve the committed root.
confirmAt[_committedRoot] = 1;    // so confirmAt[0x00] = 1

confirmAt stores a timestamp: the moment a root becomes acceptable. A value of 1 means one second past midnight on January 1, 1970, so as far as the contract was concerned, the zero root had been trusted for more than half a century.

Before June, that entry sat unused, because the old process() checked a message status rather than looking up a root. The June 21 upgrade changed how process() verified messages. It now fetched the root a message was proven under and asked whether that root was acceptable:

bytes32 _messageHash = _m.keccak();
require(acceptableRoot(messages[_messageHash]), "!proven");

Inside acceptableRoot(), the decision came down to that timestamp:

uint256 _time = confirmAt[_root];
if (_time == 0) {
    return false;
}
return block.timestamp >= _time;

An unproven message now resolved to bytes32(0), the same value that had already been marked as trusted. That created a semantic collision:

• Interpretation A (storage): 0x00 = “This message has no recorded proof.”

• Interpretation B (validation): 0x00 = “This root is pre-approved and trusted.”

Imagine a venue where security checks every visitor against an approval database. If a visitor has no record, the lookup returns a blank entry. But during setup, the system had marked that blank entry itself as approved.

Now someone with no valid pass gets waved through, not because their identity was verified, but because the system mistakes “no record” for “approved.”

That is exactly what process() did with an unproven message. It looked up the message’s root (0x00), found that confirmAt[0x00] equaled 1, saw that the current time was later than 1970, and decided the check had passed.

Absence of proof became evidence of validity.

The Check Was There. The Meaning Was Wrong.

This wasn’t a case of developers forgetting to write a check. The protocol did perform validation.

The flaw was that two distinct layers assigned contradictory meanings to the same state value:

• Layer 1 treated zero as an uninitialized placeholder.

• Layer 2 treated zero as a trusted root.

When system components agree on the syntax but disagree on the semantics, security invariants collapse.

The Copycat Wave: The Economics of an On-Chain Template

The bug was probed before it was looted. On July 31, an address later involved in the exploit sent small test transactions straight to process(), and they went through without proofs.

Active exploitation began at 21:32 UTC on August 1, in Ethereum block 15259101. The first two exploit transactions, each taking 100 WBTC, were routed privately through Flashbots via helper contracts, which kept the payload out of the public mempool. A third exploiter in the same block skipped the helper and called the contract directly, publishing the raw payload for anyone watching.

Because Ethereum transactions are entirely transparent, observers quickly realized what was happening:

1. Copy the raw payload of a working exploit transaction.

2. Replace the original attacker’s address with their own wallet address.

3. Send the modified transaction.

That’s what made it feel like a crowdsourced loot box. The barrier dropped from “discover, understand, and construct” to “observe, modify, and submit.” Coinbase’s analysis noted that attackers drained the bridge in identical chunks when they could have emptied it in a single transaction, a sign they were replaying payloads rather than writing their own.

Blockchain security firm PeckShield counted more than 300 addresses taking funds, with roughly 41 of them taking about $152 million, around 80% of the total. Bot operators, MEV searchers, at least one address tied to an earlier DeFi exploit, and white hats trying to get funds out of harm’s way all squeezed into the same window. By 05:49 UTC on August 2, the bridge was effectively empty.

The aftermath wasn’t purely theft, either. Nomad offered a 10% bounty to anyone who returned at least 90% of what they took, and by mid-August reported that more than $37 million, about 20% of the stolen funds, had come back.

The Regulator’s Read

In December 2025, the US Federal Trade Commission announced a proposed settlement with Illusory Systems, the company behind Nomad. The FTC’s complaint alleged that the June 2022 upgrade introduced inadequately tested code containing a significant vulnerability, and that weak security and incident response kept Nomad from stopping a loss of $186 million. The proposed order requires a comprehensive information security program and the return of recovered funds to affected users.

These are allegations resolved by a proposed consent order, not a court finding. The signal for builders is still plain: an upgrade that breaks a state invariant has now been described by a regulator as a failure of reasonable security, not bad luck.

The Fix Was Three Lines

Nomad’s patched Replica, published in its public repository, closes the hole at every point where the zero value could reach a trust decision:

// initialize(): never pre-approve the zero root
if (_committedRoot != bytes32(0)) confirmAt[_committedRoot] = 1;

// acceptableRoot(): "no record" is never acceptable
if (_root == LEGACY_STATUS_PROCESSED || _root == LEGACY_STATUS_NONE)
    return false;

// setConfirmation(): governance cannot re-trust zero
require(_root != bytes32(0) || _confirmAt == 0, "can't set zero root");

LEGACY_STATUS_NONE is simply bytes32(0). Each line encodes the same rule: zero means absence, and absence must never reach a trust gate.

The Real Lesson: State Invariants Across Upgrades

The vulnerability wasn’t baked into the initial code. It was introduced by an upgrade.

When upgrading smart contracts, teams can focus on new logic while overlooking how it interacts with state and assumptions established earlier. Storage survives an upgrade. The meaning attached to it may not.

For teams shipping upgradeable contracts, that turns into a short checklist:

• Reserve zero for “unset” and reject it explicitly at every trust or authorization gate.

• Validate initializer parameters, and treat values set at deploy time as part of the attack surface.

• Review upgrades against live storage, not just the code diff. Ask what every existing value will mean to the new logic.

• Run invariant tests against a fork of the post-upgrade chain state, so the values that actually went live are the ones being tested.

• Build a way to stop. Pauses, rate limits and withdrawal caps can turn an eight-hour drain into a contained incident.

About Soulbound Security

This research comes from Soulbound Security’s 31337 security research team, which focuses on securing blockchain infrastructure.

Soulbound Security is a blockchain technology company focused on protocol-level security infrastructure. We design and ship systems where privacy, compliance, and auditability are architectural properties, not policy promises.

Soulbound Security is an approved organization under Anthropic’s Cyber Verification Program.

Got questions or insights on cross-chain security, or want to collaborate on a research piece? Reach out to Gakarot at gakarot@soulboundsecurity.io.

Sources

• Coinbase, Nomad Bridge incident analysis (August 2022)

• Mandiant, Decentralized Robbery: Dissecting the Nomad Bridge Hack and Following the Money (November 2022)

• The Block, Nomad’s $190 million bridge exploit drew hacking feeding frenzy of 300 addresses (PeckShield figures, August 2022)

• nft now, Nomad Offers Hackers a Chance at Redemption (reporting Nomad’s August 18, 2022 recovery update)

• US Federal Trade Commission, FTC Will Require Illusory Systems to Return Money Stolen by Hackers and Implement Information Security Program (December 2025)

• Nomad, Replica.sol (patched implementation)

The image above was captured mid-stream on YouTube, where a sports broadcast gave way to what looked like a presidential address and a banner telling viewers to “scan or regret.” Whether footage like this is fully synthetic or real footage with a cloned voice, the goal is the same: get you to pick up your phone and scan before you think.

Streams like this are cheap to make, quick to relaunch and close to impossible to enforce against. Here is how the scam works, what responsible QR design looks like, and how to spot the fake behind it.

Why the QR code is the scammer’s favorite link

A QR code is a link you cannot read, which is why the US Federal Trade Commission has warned consumers that scammers hide harmful links inside them. Three properties do most of the work:

• You can’t inspect it. There is no hover and no visible URL, and email filters that check text links often miss one hidden in an image.

• It moves you to your phone. The stream plays on a TV, but the scan happens where your wallet lives, behind a small screen and a truncated address bar.

• It borrows authority, and enforcement lags. A code on a broadcast looks official. Channels get renamed, domains rotate within hours, and the stream is gone before a report is read.

What happens after the scan

Most funnels end one of three ways: a “send to receive” giveaway that never sends anything back, a wallet drainer that gets you to sign an approval letting its contract move your tokens, or a fake support form that asks for your seed phrase. On-chain transfers are final, so there is no chargeback.

No public figure, exchange or protocol will ever ask you to scan, connect and sign to receive free crypto. That request is the scam, whatever face is attached to it.

QR codes are not the problem

QR codes are genuinely useful. They carry boarding passes and menus, and in crypto, scanning an address is safer than typing one, because a single wrong character can lose funds for good. A QR code is just a container for a web address. The risk lives in where it sends you and what that page asks you to do.

A responsibly designed QR code points to a domain you can verify and asks for nothing that can move your money on its own.

How we use QR codes at Soulbound Finance

Soulbound Finance uses QR codes in two places, and both follow one rule: no QR code we generate leads to a wallet connection, a signature, a token approval or an on-chain transaction. Both open one page on our own domain, soulbound.finance/redeem.

Transfer cards. A member can download a Soulbound Transfer as a card for offline delivery or secure messaging. Its QR code opens the redemption page with the code filled in, so treat the card like a password. Redeeming needs no wallet, account or gas, and the page warns that redemption is irreversible before anything is submitted. Getting Started walks through it.

Request pages. Members publish request pages to collect Soulbound Transfers for a charity, a personal cause or a pooled purchase, like our launch Mission 22 page. The request QR prefills the destination address, and the donor types it again before redeeming. The page is built to resist abuse:

• Published and frozen. Each page shows the Soulbound ID that published it, and its title, address and links can’t be edited, so nobody can earn trust and then swap the address.

• Recorded at publication. An ENS name or wallet-linked domain is stored with the address it resolved to and when, and social links are validated against their platforms.

• Cancelled, never erased. Cancelling removes the QR code and stops new transfers, but the page stays public as a permanent record.

Contract addresses sit in the footer of every page, verified on Arbiscan, with the protocol source on GitHub. More in our Security and Privacy Overview.

What design can’t do. Immutability proves a page hasn’t changed, not that its creator is the organization named on it, so confirm the address on the organization’s own site first. And because our redemption page asks for a code, a copycat would want exactly that. If a scan opens anything other than soulbound.finance/redeem, or any page asks you to connect a wallet to redeem a Soulbound Transfer, close it.

Spotting deepfakes, and why the tells won’t last

Today’s fakes still leave marks, and knowing them buys you time:

• Video: lips out of sync on “p” and “b” sounds, hands that loop or stay out of frame, hairlines that shimmer, set pieces that look cloned, and a “live” stream with comments off and a QR code pinned the whole time.

• Audio: flat pitch and pace, no breaths or mouth sounds, an even metronome rhythm, and a studio-clean voice in a room that should echo.

Those tells fade with every model release, which makes detection an arms race defenders can’t win. Our VoiceKey research at the AI Integrity Alliance flips the question: instead of hunting for what AI adds, it measures what only biology produces. A human voice carries micro-tremors and chaotic variation that a smooth generator can’t reproduce, however much noise is layered on top.

Our open-source proof of concept measures two complexity statistics, Higuchi fractal dimension and detrended fluctuation analysis. Synthetic voices scored higher on both, meaning more self-similar and more predictable than real speech. Human voices were messier, and the mess is the signal. The sample is small and the work is early, so the code is MIT-licensed for others to test and try to break.

The durable defense isn’t spotting the fake. It’s never letting a video be what authorizes you to move money. Go to the official site or verified account directly, never through anything shown in the stream.

The five-second checklist

• Before you scan: free crypto from a public figure is always a scam, and “scan or regret” urgency is pressure, not information.

• Before you open: read the full domain in the preview, and skip anything you can’t confirm from an independent source.

• Before you connect or sign: never enter a seed phrase, reject any signature you can’t read, and keep savings in a wallet that never touches new sites.

• If it already happened: revoke token approvals, move what’s left to a new wallet, and report the stream, the domain and the loss.

The one-sentence test

Any platform that puts a QR code in front of you should be able to say in one sentence what that code can and cannot do.

Ours opens soulbound.finance/redeem and nothing else, and nothing moves until a person has checked the address and confirmed.

Further reading: Getting Started with Soulbound Finance, Security and Privacy Overview, Where Privacy Actually Lives and VoiceKey: Proving You’re Human.

Spotted a scam using our name? Report it to security@soulboundsecurity.io.

Soulbound Security is a blockchain security and technology company. The AI Integrity Alliance builds open-source verification infrastructure for trustworthy AI and proof of humanity.

Every private transfer system makes the same promise: an observer watching the ledger cannot reconstruct who sent value to whom. The systems differ enormously in where that promise is kept, what it costs a user to reach it, and who else holds keys while it is being kept. For a charity, a congregation or a regulated fintech choosing a rail for real value, those differences matter far more than the headline claim.

Three broad families of cryptographically private transfer systems are in production today: privacy coins, privacy chains, and transaction-level protocols on existing EVM networks. The first two solve a different problem from the one Soulbound Finance solves, so we cover them briefly. The rest of this piece is a protocol-level security review of Privacy Boost, a shielded-pool protocol built by Sunnyside Labs, set against Soulbound Finance.

Neither is ahead or behind. They are differentiated offerings built for different jobs: Privacy Boost is, architecturally, an advanced mixer, while Soulbound Finance is built for regulatory approval of private, blockchain-based transfers.

Privacy coins: private asset, public exits

Monero and Zcash are the reference designs, with privacy built into the asset itself. The cryptography is mature. The problem is everything around it. Value has to be converted into the coin to become private and back out to be useful, and every conversion runs through an exchange that increasingly will not touch the asset. Binance, OKX and Kraken have delisted Monero in some or all markets, and the EU’s Anti-Money Laundering Regulation bars crypto-asset service providers from handling privacy-enhancing coins from July 2027.

A donor who wants to give USDC privately does not want to become a Monero trader first. Privacy coins protect an asset, not a transfer in the assets people actually hold.

Privacy chains: private domain, public ramps

Aztec, Aleo, Secret and Namada move privacy down a layer, so every asset on the chain inherits it. Inside the chain that is genuinely more private than anything on a transparent L1 or L2. It also relocates the exposure rather than removing it. You bridge in and bridge out, and the bridge is a public choke point, frequently multisig-governed, that records exactly the amount and timing an analyst needs. The tokens a treasury or individual actually holds arrive only as wrapped representations whose redemption depends on the bridge.

The action moves to the on and off ramps, which is precisely where regulators, analytics firms and attackers already look.

Transaction-level protocols: same layer, different jobs

The third family keeps users on the chain they already use, with the tokens they already hold, and adds privacy at the level of the individual transfer. Tornado Cash was the first widely used example. Privacy Boost belongs to that mixer lineage, rebuilt with far more advanced cryptography. Soulbound Finance shares the layer but not the goal.

Privacy Boost is a UTXO-style shielded pool. Deposits become Poseidon2 note commitments in a Merkle tree; spending a note requires a nullifier and an EdDSA signature checked inside a Groth16 zero-knowledge proof, with transfers batched into epochs by a prover and relay running in a trusted execution environment (TEE).

Soulbound Finance gates deposits behind a non-transferable Soulbound Token (SBT). A depositor funds a DepositPool, generates a one-time-use (OTU) redemption code off-chain and signs an on-chain EIP-712 attestation of purpose, charitable or commercial. A separate party redeems the code from a ClaimPool to a fresh address, and the protocol never records which deposit that redemption corresponds to.

What each hides, and what neither hides

Both protocols are public at the boundary: anyone can see who deposited, who withdrew, which token, how much and when. The difference is in between. Privacy Boost shields its internal state cryptographically, so which note was spent, who owned it and how value moved inside the pool are hidden by construction. Soulbound Finance’s privacy is structural: the pairing between a deposit and a redemption simply does not exist on-chain to be read.

Privacy Boost optimises for cryptographic concealment inside the pool; Soulbound Finance optimises for unlinkability that a regulator can examine without either party’s identity being exposed. Neither changes what is public at the edges.

Complexity is a cost, not a credential

Privacy Boost’s machinery, including Groth16 verifiers with a trusted-setup dependency, a TEE, relayer infrastructure and auth snapshots, buys a real property. It should be judged on whether that property is worth the surface area, not read as a security credential in itself. Every additional component is another place for a bug, a misconfiguration or a compromised role to matter.

Soulbound Finance’s core flow fits on one line, and its core contracts carry no third-party protocol or library dependencies such as OpenZeppelin or Chainlink, removing a whole class of inherited assumptions from review.

A bank’s risk committee can be walked through the entire Soulbound Finance system in a single sitting.

Who holds the keys

Soulbound Finance has two core roles. The Controller sets fees, supported tokens and the EULA, and is walled off from funds. The Operator can move ClaimPool redemption balances, making it the one key whose compromise is a direct path to lost funds; our own specification says so, and the mitigation is conventional HSM or enclave custody plus balance monitoring. An auxiliary Gas Manager can deploy a dedicated gas fund only to Operator-approved targets and cannot touch the redemption balance.

Privacy Boost spreads power wider. A fully compromised TEE operator cannot forge a spend, because every spend still needs a valid signature and proof; it leaks metadata, not funds. A rogue relay can stall submissions but cannot bypass on-chain verification. The deeper exposure is governance: Privacy Boost’s own threat model acknowledges that misuse of the ProxyAdmin and verifier-owner roles can affect verifier selection, implementation behaviour, relay policy and economic parameters. A compromised key there does not take one balance; it can change what the proof system accepts as valid.

The two designs carry different risk profiles, one direct and narrowly scoped, the other systemic, and a serious reviewer should weigh both.

Immutable versus upgradeable

Soulbound Finance contracts are immutable: no proxies, no delegatecall, nothing to redirect after deployment. Privacy Boost is proxy-upgradeable, and its documentation is candid that the absence of a setter on the forced-withdrawal verifier is not absolute immutability while the proxy remains upgradeable. Upgradeability is a legitimate choice that lets a team patch without migrating users, but it changes the category of guarantee.

Soulbound Finance’s rules cannot be changed by any key. Privacy Boost’s rules can.

Getting your money out

Soulbound Finance’s emergencyWithdraw is unconditional: any SBT holder can pull their full balance at any time, with no fee, even for a token that has since been delisted.

Privacy Boost’s forced withdrawal bypasses the TEE with a client-side proof, which is valuable, but only for keys already captured in an on-chain auth snapshot, and snapshots are created by relays rather than on user demand. A user registered after the latest snapshot cannot force an exit until the next one lands. Privacy Boost documents this window itself. It is a narrow edge case in normal operation and exactly the case that matters when the relays are what has failed.

What Privacy Boost optimises for

Privacy Boost is built to conceal what happens inside the pool, and it does that job with serious machinery and serious documentation: three commissioned OpenZeppelin audits across 2026 and fourteen specification documents with a per-actor trust table, numbered invariants, a leakage table and a candid list of its own known weaknesses. For a user whose only requirement is internal concealment, that is a coherent design. It is simply not designed to be approved by a financial regulator.

What Soulbound Finance optimises for

Soulbound Finance’s core focus is regulatory approval for private, blockchain-based transfers, and the protocol is built around that goal.

• Per-transaction attestation. Every transfer carries a proprietary EIP-712 attestation, designed as a legal artefact: a signed, immutable, attributable statement of purpose, with responsibility for a false statement resting on the signer.

• On-chain Soulbound ID. Identity lives in the non-transferable SBT, with Privado ID zero-knowledge verification on the 2027 roadmap alongside the regulatory approval path, so identity can be proven without being disclosed. KYC applies where a user’s local jurisdiction requires it.

• No stored addresses. Across every layer of the stack, from contracts to backend to database, Soulbound holds zero knowledge of, and stores none of, the Ethereum addresses on either side of a transfer.

Privacy Boost has no equivalent layer: we checked, and it has no KYC or KYB logic, no user allowlist and no identity requirement.

The regulatory question, sized honestly

The obvious precedent is Tornado Cash, and the record is mixed. OFAC designated it in August 2022, alleging billions laundered including Lazarus Group proceeds. That was agency action. In Van Loon v. Treasury the Fifth Circuit held that immutable smart contracts are not blockable property, and Treasury delisted the protocol in March 2025: tested case law, but narrow, turning on immutability rather than endorsing unidentified shielded pools.

Two points follow. Whatever protection Van Loon offers attaches to immutability, and a proxy-upgradeable system with identifiable governance, TEE and relay operators is not obviously inside that holding. More practically, the realistic exposure for a fintech is not a sudden designation but banking-partner risk.

The hard conversation is explaining to a correspondent bank why volume flows through a pool where nobody on either end has attested to anything.

Privacy Boost has no connection to the Tornado Cash matter. The point is architectural.

Different tools, different jobs

Privacy coins protect an asset few people want to transfer value in. Privacy chains protect a domain you have to bridge into. At the transaction level, Privacy Boost and Soulbound Finance are differentiated offerings rather than rivals on one scale.

Privacy Boost is an advanced mixer: deep cryptographic concealment inside its pool, delivered through a larger system with upgradeable rules, more privileged roles and a conditional exit.

Soulbound Finance is built for regulatory approval: per-transaction attestations, on-chain Soulbound ID with zero-knowledge verification, no stored addresses anywhere in the stack, immutable rules and an unconditional exit.

Soulbound Finance has been live on Arbitrum mainnet since April 2026.

The protocol-level security review behind this piece was conducted by Gakarot, Director of Blockchain Security at Soulbound Security. Questions on the analysis: gakarot@soulboundsecurity.io.

Joining Soulbound Finance

Soulbound Finance is built on the blockchain so anyone with a wallet can use it and as such is available worldwide like all platforms on-chain.

Members must attest on-chain that they are not located in a restricted jurisdiction (US, UK, or EU) when they sign in.

Once connect your wallet and you will need to claim your Soulbound ID.

Soulbound ID is a free, non-transferable token that serves as your membership credential, this also enables us to operate without storing any wallet addresses in our system, by using Soulbound authentication.

Once you have it, you’re a verified member with full access to the platform.

In 2027, your Soulbound ID will be upgradeable with zero-knowledge identity verification, which will allow us to seek approval in regulated jurisdictions without compromising member privacy.

You’ll earn 100 Soulbound Points just for signing up!

Depositing tokens into Soulbound Finance

Once you’ve claimed your Soulbound ID, the next step is depositing tokens.

Your member dashboard shows your wallet balance for each supported token (ETH, USDC, DAI, and WBTC) alongside your Soulbound balance.

Press the deposit button to move approved tokens from your wallet into the protocol.

Soulbound Transfers are generated from your Soulbound balance, not directly from your wallet.

Your dashboard also reflects your Active and Redeemed transfers.

You can deposit as much or as little as you want, and you can always withdraw your full balance at any time using the withdrawal button at the bottom of your dashboard.

Sending a transfer

When you send a Soulbound Transfer card, you’re creating a gift card that can be shared with and redeemed by anyone, anywhere, anytime.

The sender and recipient are never linked. Not on-chain, not in our database, not anywhere. We built it so that connection simply doesn't exist in our system, which means nobody can find what was never stored.

Pick your approved token (ETH, USDC, DAI, or WBTC), choose a standard size or enter a custom size.

The traceability score tells you how common this size is across all Soulbound transfers, entering a custom amount will result in an elevated rating.

This does not change platform privacy, it means that your non-standard transfer size may be more obvious when redeemed because fewer members are sending transfers of same size.

A 1% transfer fee (+ .25% network fee) is applied at this point, so what the recipient redeems is the net amount.

Your transfer card is encrypted by your wallet. This means only you, signed in with your Soulbound ID, can ever decrypt and view your cards.

Our servers store encrypted data. We cannot see your transfer cards, and we cannot recover them if you lose access to your wallet.

This is client-side encryption at the same level as secure messaging like Signal and iMessage.

Security codes add a second factor. You can optionally protect your transfer with a security code (4-16 characters). The recipient will need both the transfer card and the security code to claim the tokens.

This is recommended for larger amounts or transfers that won’t be redeemed immediately.

If you choose not to use a security code, the platform will warn you of the risks clearly.

With no security code anyone who has the access to your transfer card can redeem the Soulbound Transfer, and there is no recovery if the code is lost or stolen.

Just like most gift cards, once created, a transfer must be redeemed within one year. If it hasn’t been claimed, it expires and tokens release to the protocol.

You can always redeem your own transfers back to yourself at no additional cost if you change your mind or the recipient never claims it.

Securely share the transfer card however you would like, but treat it like a password or your crypto keys.

The redemption code on the card IS the transfer. Whoever has it can redeem it, unless a security code was added like a gift card pin.

Redeeming a transfer

The recipient doesn’t pay any fees or need a Soulbound ID to receive transfers.

Just like a gift card, the recipient only needs the details on their Soulbound transfer card and the security code if you set one you set when you created the transfer.

In order to redeem a Soulbound transfer:

1. Visit the public redeem page https://soulbound.finance/redeem

2. Enter the redemption code off of the transfer card: XXXX-XXXX-XXXX-XXXX

3. Enter the recipient wallet address: 0x… or name.eth

4. Enter security code or Check No Code.

5. Press Review Redemption

6. Confirm Recipient Address and transfer details.

7. Done.

If a security code at the time of transfer creation, the transfer card will note this, and it should be provided separately by the sender to enable redemption.

Recipient address is never stored in our system after the outgoing transfer is confirmed on chain, all redemption processing and data is fully isolated from sender details. No linkage is possible beyond time correlations.

Soulbound Finance processes the transfers on-chain in batches of up to 50 which helps to further ensure recipient privacy, as a result there may be a one to five minute delay in redemption.

There is no wallet connection or gas cost necessary to to redeem.

Redemptions are sent directly to the recipients wallet, if you are logged into Soulbound Finance when you receive a transfer you will see it in your Wallet balance on your member dashboard, not your Soulbound balance.

Requesting transfers

Raising money for a charity or want to make it easy for your friends to send you transfers for a group purchase?

The private request page lets you publish a shareable page with a branded QR code where anyone can send you a Soulbound transfer.

Perfect for donations, fundraisers, or personal gifts in any of our supported tokens.

You give the request a title and description, enter the destination address or crypto domain, and optionally add links to your website and social accounts.

Once published, the public request page is locked and can’t be changed to prevent fraud and malicious use.

Share the link or save your custom request card for offline use or secure messager delivery.

The QR Code on requests cards leads you to the campaign detail page just like GoFundMe or Kickstarter.

The request page shows visitors the value of Soulbound transfers have been received at that address in real time across all four tokens. Because of this, it’s best to use a fresh address for each request so the totals reflect that specific purpose.

Visitors see everything they need before deciding to send: your description, your links, the sharable request card, and received tokens breakdown.

You can share or cancel a request at any time. Cancelled requests stop accepting new transfers, but the page itself always remains publicly visible for transparency and security purposes.

Live Example: Soulbound Transfer Request | Mission 22 — United in the War Against Veteran Suicide

Looking up a specific transfer

Most Soulbound transfers use our platform default sizing. That means after a few transfers, a specific one can be hard to spot in your dashboard history.

Every transfer you send has a unique on-chain transaction hash, which acts as its fingerprint. (This just shows that you created the transfer, not who redeemed it.)

You can find this hash in the transaction history of whatever wallet you use (MetaMask, Rainbow, Brave Wallet, or any Arbitrum-compatible wallet). Paste it into the “Transaction Hash Lookup” tool on your member dashboard to pull up that exact transfer

You’ll see the amount, status, traceability tier, security code, and when it was created. In the rare case a transfer verified on-on chain can’t be found, the lookup will generate a network refund request for you.

Only the sender can look up their own transfers once signed in with their Soulbound ID.

Soulbound Points: How you earn

Every Soulbound Transfer sent on the platform earns Soulbound Points (SBP). Your point total determines your membership level, and higher levels earn points faster.

Transfers: 1 SBP for every DAI you send through the platform. This is the primary earning mechanism. Send 500 USDC, earn 500 base points then we apply your current level multiplier.

Sign up: 100 Soulbound Points the moment you mint your Soulbound ID.

Referrals: 100 Soulbound Points for every new member who joins through your referral link.

Daily Streak: One month of daily use generates 140 Soulbound Points, then 10 a day until you break the streak

Soulbound levels and multipliers

Your level is based on your total point balance, which includes both on-chain (claimed) and unclaimed points. Your level updates in real time as you earn.

Multipliers apply going forward from the moment you tier up, not retroactively.

Carbon (0 points): 1x multiplier.
Cyan (1,000 points): 1x multiplier.
Bronze (10,000 points): 1.25x multiplier. This is the big one: Bronze unlocks claims.
Silver (100,000 points): 1.5x multiplier. Serious member territory.
Gold (1,000,000 points): 2x multiplier.
Diamond (10,000,000 points): 3x multiplier. The top tier.

The multiplier applies to every award type: transfers, sign-up bonus, referrals, daily login, everything.

As you level up, you earn faster across the board.

Claiming your Soulbound Points on-chain

Once you hit Bronze (10,000 total points including unclaimed and on-chain), you unlock the ability to mint your SBP on-chain. This is the claim gate. Below Bronze, your points accumulate as unclaimed rewards but can’t be claimed as tokens yet.

When you’re ready, claim from your profile page. Soulbound Points are standard crypto tokens. The claim transaction costs just fractions of a cent on the Arbitrum network.

Why claim? Once your points are on-chain, you own them in your wallet. You can transfer them to your primary wallet, hold them, or do whatever you want with them. They’re yours.

You must send at least one Soulbound Transfer between every claim in order to qualify to claim your points on-chain.

Your claimed and unclaimed balances both count toward your tier, so there’s no rush to claim the moment you hit Bronze.

Your level reflects combined claimed and on-chain balances, so if you purchase Soulbound Points on an exchange, or your friend sends you some, your level will reflect in real time.

Sending Soulbound Points to another wallet

After minting, your Soulbound Points sit in the wallet you used on the platform. If you want to move them to a different wallet you can do a standard transfer through any crypto wallet.

Sending or recieving points from another wallet will impact the membership level of both, as the level is calculated from on-chain data in real time.

The global leaderboard is based only on lifetime points earned by your Soulbound ID.

The Soulbound Points (SBP) contract address is verified on Arbiscan (below). Add it as a custom token in MetaMask, Rainbow, or whatever wallet you use, and your balance shows up like any other token.

Soulbound Points address (SBB) : 0x559677B6F22f5Ab32D8a185836be25Deb725B274

What sets Soulbound Points apart:

Every single points claim requires a valid Soulbound ID, proof your on-chain activity has advanced since your last claim, and a signed approval from our platform matching your exact cumulative earned total.

No activity, no points. No exceptions. Not even for us. There is no admin mint function, no airdrop function, no batch grant.

Once claimed, soulbound points are like any other crypto token. Transfer them, hold them, send them to your primary wallet. We can’t freeze them, claw them back, or blacklist your address.

There’s no code for any of that. ~200 lines of Solidity, MIT license, immutable on Arbitrum with no proxy or upgrade path.

You can read the full source on GitHub or check the verified contract on Arbiscan.

Quick reference

Supported tokens: ETH, USDC, DAI, WBTC

Transfer fee: 1% charitable/personal, (2% commercial disabled at launch)

Network fee: 0.25% for platform operations and privacy matrix

Redemption: Free, no gas cost, no wallet or account needed

Points earning: 1 SBP per 1 DAI or equivalent sent, plus sign-up and referral bonuses

Tier multipliers: Carbon 1x, Cyan 1x, Bronze 1.25x, Silver 1.5x, Gold 2x, Diamond 3x

Soulbound Points on-chain claim: Available from your profile page once you reach Bronze (10,000 total points), standard ERC-20 on Arbitrum

Contracts: Contracts are all open source and verified on Arbiscan.
Soulbound ID: 0xaF0Ce4f1175595a668eb19F97fb20a2D5fC353eD
Soulbound Deposits: 0xe8D294F3fff2A5CB34D15eCdEF34A53b01f5A462
Soulbound Redemptions: 0x5F5a08fFFE8071410f3ECe2FCC40D81B457b28ce
Soulbound Points: 0x559677B6F22f5Ab32D8a185836be25Deb725B274

Soulbound Finance is pre-launch permissionless protocol on the Arbitrum network, it is available globally outside regulated jurisdictions (US/UK/EU).

If you’re reading this, you’re early. Start here: soulbound.finance

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.