Introducing Clean SDK: Private, Screened Transactions on AztecGeneral

Introducing Clean SDK: Private, Screened Transactions on Aztec

Jul 30, 2026 · Updated Jul 30, 2026

Clean SDK is available now. Build your own app, routing private transactions through Aztec via Clean SDK, without running your own identity, screening, or bridging infrastructure.

We launched Shield, a private, accountable bridge between Ethereum and Aztec, a decentralized L2 where privacy is programmable per app and proofs run on the user's device.

Shield is an important piece of infrastructure, live on Aztec v5 mainnet. But it's one app with one frontend, and many more can be built. The bigger story for developers is Clean SDK, human.tech's programmable privacy toolkit: add private, screened transactions to your app without running your own identity, screening, or bridging infrastructure. Shield is the first app built on Clean SDK.

What Clean SDK is

Aztec makes privacy programmable at the contract level, with encrypted private state and proofs that settle to Ethereum. Contracts there are written in Noir, Aztec's language for zero-knowledge programs. Every contract on Aztec runs under zero-knowledge proving, and each one decides how much of its state stays private.

Clean SDK is a TypeScript client for three things human.tech already runs:

  • The Noir contracts on Aztec, the token bridge and minter proxy, audited and already deployed at fixed addresses the SDK carries.
  • The Solidity contracts on Ethereum, the portal and swap router, whose ABIs ship in the package.
  • Our attestation backend, which issues the attestations each deposit needs. Proof of Innocence covers the on-chain side, the wallet address itself. Proof of Personhood and Proof of Clean Hands cover the off-chain side, the person behind it. The identity infrastructure powering them has issued 51.5M credentials to 2.18M verified identities.

You write the app, the rest is already deployed. Your app calls Clean SDK, a TypeScript package that is free to integrate. Behind it: the Noir token bridge and minter proxy already deployed on Aztec at fixed addresses the package carries, the Solidity portal and swap router on Ethereum with their ABIs shipped in the package, and the attestation backend, which covers Proof of Innocence on the wallet and Proof of Personhood or Proof of Clean Hands on the person, verified on-chain, single-use and expiring. Audited by Nethermind, Hexens and Halborn.

What your app gets from integrating Clean SDK

Building private, screened transfers yourself means a KYC vendor contract, a sanctions data subscription, a personhood system your users complete, including the zero-knowledge circuits underneath, and then auditing each of them. Integrating Clean SDK means depending on our deployment and our attestation service instead.

Every transaction through the SDK clears two checks, one on-chain and one off-chain:

  • Are these funds coming from a sanctioned address? Proof of Innocence is the on-chain check. It screens the wallet address against 23 sanctions sources, including OFAC, FATF, FinCEN, Interpol, and PEP lists, at both ends of the transfer, entry and exit.
  • Is a real, verified person behind it? The off-chain check, and the amount decides how strong it is.
    • Under $1,000: Proof of Personhood via Human Passport confirms a unique human.
    • At $1,000 and up: Proof of Clean Hands verifies identity itself, our ZK KYC and AML flow built on a government ID.

Contracts on both chains verify each attestation, so the checks are enforced on-chain rather than in your app, and each one is single-use and expires. The components underneath are audited separately: Nethermind Security on the bridge contracts (NM-0756), Hexens on the Clean Hands ZK circuits, and Halborn on Human Network's threshold cryptography.

Accountable by construction, private by default. Both checkpoints, entry and exit, run the same checks: Proof of Innocence screens the depositing wallet against 23 sanctions, watchlist and PEP sources, and a real, unique person is proven by Proof of Personhood (Human Passport) under $1,000 or Proof of Clean Hands above it. Audited by Nethermind, Hexens and Halborn.

Human Passport, up to $1,000

Human Passport scores a user from credentials they already hold, called Stamps: accounts, on-chain history, and other verifiable proofs. Shield requires a score above 20, and a wallet with real on-chain history can reach that from its own activity, so a crypto-native user often clears the bar without submitting anything. A government-ID Stamp is one route to a qualifying score rather than a requirement. Passport covers deposits up to $1,000 per wallet, counted cumulatively.

Docs: docs.passport.human.tech

Proof of Clean Hands, above $1,000

Proof of Clean Hands is our ZK KYC and AML flow, and it applies above that $1,000 line. The user completes a government-ID check once, using a passport, driver's license, residence permit, visa or voter card, with a liveness scan matched against the document, and is screened against sanctions and PEP lists. That leaves them holding a credential issued by Human ID and valid for a year. Each deposit then proves in zero knowledge, using a VOLE-based proving system, that they hold that credential. The document itself is never shown to your app or written on-chain. The same proof also shows that the underlying identity data was encrypted to a designated observer, so what is disclosed later, and under what conditions, is fixed at the moment the credential is issued rather than negotiated afterwards. If those conditions are ever met, an on-chain contract authorizes the decryption, which is carried out through the Human Network, whose operators hold the key shares and reshare them each epoch. Today the authority to trigger it is a single approved decryptor; decentralizing that authority is on the roadmap below.

Docs: docs.human.tech/proof-of-clean-hands. Users verify at id.human.tech.

Public and private state, set per leg

Each leg of a transfer runs in one of two modes, public or private. Public is transparent on both chains. Private shields balances and activity on Aztec; the Ethereum deposit and withdrawal stay public either way.

Two modes and what each one shields. The Ethereum deposit and withdrawal are public in both modes; private mode shields balances and history on Aztec. Both modes are screened the same way at entry and exit.

Entry and exit are independent, so your users can enter publicly and exit privately, or keep either end consistent. Your app decides what visibility to offer; the SDK doesn't force a single answer.

Aztec's own Inside an Aztec Transaction walks through what the private half of a transaction does on the user's device.

Clean tokens

In private mode, USDC arrives on Aztec as cUSDC. The clean designation records how it got there: the holder cleared Proof of Innocence and the personhood check at the bridge.

The designation doesn't travel with the token yet. The check happens at the bridge, not on every transfer afterwards, so a clean token can reach an Aztec account that has never been checked. A holder can also move cUSDC from public into private state on Aztec directly, which the token allows without a check.

That second point is why both modes are screened the same way at the bridge. Public mode looks like the lower-risk path, but value sitting in public state can move into private state afterwards, so a lower bar on the public side would be simple to route around. The same $1,000 line applies either way.

Closing this means the token standard carrying the rules itself, which is on the roadmap below.

Gas on Aztec, handled for your users

Aztec charges gas in Fee Juice rather than ETH. Clean SDK converts part of the deposit into Fee Juice and lands it in the user's Aztec wallet, so nobody has to source it separately. Aztec's how gas works on Aztec covers the mechanism.

Public and private Fee Juice are not interchangeable. The SDK's fuelType defaults to public, and public fuel names the recipient's Aztec address on-chain, so a private transfer has to use private fuel or it exposes the recipient it was meant to hide.

Fee Juice can also be bought on its own. The same call, with fuel carved out of almost the whole spend, is a top-up rather than a transfer that happens to include gas. Shield exposes it as its own Fee Juice page, so anyone can use it to get gas on Aztec. It is still a deposit, so it needs the same attestation and counts toward the same limits.

Public fuel takes an optional recipient, which lands the Fee Juice in an Aztec account other than the one bridging. Fee Juice is non-transferable, so that is the only way to fund someone else's account.

Shield is the live proof

If you want to see what Clean SDK can build before you install anything, use Shield. It moves USDC between Ethereum mainnet and Aztec, screens every transaction in both directions, and runs both modes, live now as an Aztec v5 launch partner.

Every privacy and compliance function Shield performs comes from Clean SDK: the screening, the proofs, the bridging, the mode selection. What Shield adds on top is product, its own frontend, onboarding, limits and recovery. Keep that split in mind when you plan your own integration. For the full mechanics, read how Shield works.

Try Shield at shield.human.tech.

Testnet access at testnet.shield.human.tech.

Clean SDK Quickstart

npm install @human.tech/clean.sdk

The core export of @human.tech/clean.sdk is HumanTechBridge, a class that wraps the full flow: SIWE authentication, bridging from Ethereum to Aztec, withdrawing back to Ethereum, and the attestations that gate each step. You instantiate it with a deployment and your RPC endpoints, and it handles the attestation and screening calls for you. The screening thresholds come from the attestation service rather than your config.

The developer guide has the full API reference: initialization, the bridge calls, attestations, events and error handling.

Roadmap

Clean SDK is tied to the Ethereum and Aztec route today, but it can be multichain in the future. The direction is to meet apps where they already are: an app on another chain routes the private part of its flow through Aztec and back out, without relocating its users or its liquidity. Aztec stays where the privacy happens, and moving there is not strictly required to benefit from its encrypted state and client-side proofs.

Then there's the token standard. Today the checks run only at the bridge; the plan is to build them into the token itself, so its rules travel with it. A token that carries its own rules can move only between accounts that have passed the checks, stay monitored and revocable after it is issued, and be gated when it moves from public into private state. Once the token enforces that itself, screening follows the asset the whole way, and the two modes no longer have to be treated the same.

Decryption decentralizes too. Today one approved party can decrypt a record. The plan is to share that power across multiple parties, and to put the rules for when a record can be opened into public contracts. Then both what opens a record and who can open it live in code anyone can read, instead of resting with one party.

Before any of that, there's housekeeping: fewer signatures per transfer, smoother recovery when one is interrupted, and stability under real usage. UI changes are already in flight.

Start building

The SDK is free to integrate, and we're still filling out the developer guide. If you're building on Aztec, tell us what you're making: [email protected]. Ship on Clean SDK and we'll co-market the launch with you.

Developer tools and SDKs for privacy-focused apps are part of what we build at human.tech. Clean SDK is the newest one.

About human.tech

Holonym Foundation builds human.tech, the proofs that let a service know it is dealing with a real, unique person, and know nothing else. Used by governments, protocols and platforms. Its ecosystem includes Human Passport, Wallet as a Protocol (WaaP), Human Network, the Clean SDK, and Shield, the first application built on the Clean SDK. human.tech's products enable developers and users to prove personhood, preserve privacy, and build accountable digital systems using zero-knowledge technology.

Subscribe to our newsletter

Latest from our blog