Unaudited, unvetted, experimental. Do not use as a reference. AI-researched ratings that may be wrong; not advice or a statement of fact about any provider. Full disclaimer
Pending review. 1150 of 1150 ratings not yet checked by a human. Do not rely on unreviewed ratings.
Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: The core repo's deployments page (privacy-pools-core@d494b63e docs/docs/deployments.md L9-L17) lists only Ethereum mainnet, and the website's chainData.ts (privacy-pools-website@7df41112 L129-L142) lists mainnet first with 14 pools behind Entrypoint 0x6818…6b46. Onchain, the ETH pool's nonce is 6071 deposits at block 26153374. Unit: the Entrypoint proxy and the ETH, USDC and USDT pools (most deposits). Excluded: the 11 other mainnet pools (same code), the OP/BSC/Arbitrum Entrypoint 0x4419…d15E, Starknet and testnets.
Offered everywhere except the countries listed. Checked 2026-10-09. Not scored.
The 0xbow terms bar Cuba, North Korea, Iran, Syria and the Russian-occupied regions of Crimea, Donetsk and Luhansk (in UA, not listed as a whole country), and say the list may change. The contracts have no geographic check, so anyone can deposit and ragequit, but private withdrawal depends on passing 0xbow's ASP screening, which the terms say may exclude sanctioned or high-risk addresses. We did not inspect the hosted site for an IP geoblock.
Who can block valid use, and can users route around them?
0 FailsPillar rating: weakest of 5 1 of 5 Partial or better
What would raise this pillar
Admin pause or freeze powers reaching Weak: Role held by a multisig that misses one of those conditions (no timelock, undisclosed signers, bypass modules), or the constraints are documented only.
Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Two roles can stop or block settlement. The ASP postman, a single EOA, posts the association root; a deposit whose label is not in the latest root cannot be withdrawn privately, so the postman can exclude individual deposits without notice. Its only remaining exit is ragequit, which returns funds to the original depositor, not to a payee. OWNER_ROLE, held by a 2-of-4 Safe with no modules, guard or timelock, can wind down a pool (stopping deposits) and upgrade the Entrypoint. Scored 0: an EOA holds a role that can target individual deposits. The 0xbow terms describe this screening (see C4).
Evidence (4)4 verified
Verified
withdraw() requires the proof's ASP root to equal ENTRYPOINT.latestRoot() (L59); Entrypoint.updateRoot (Entrypoint.sol L93-L104) is onlyRole(ASP_POSTMAN), so the postman decides which deposit labels can be withdrawn privately. windDownPool (L256-L261, OWNER_ROLE) permanently stops deposits; ragequit (PrivacyPool.sol L132-L150) stays open to the original depositor.
Entrypoint.hasRole(ASP_POSTMAN, 0x1f4F…E187) returns true at block 26153374; the address has no code (an EOA) and sent the latest updateRoot tx 0x6298b96d…ec83. RoleGranted logs show the postman role granted to this EOA and to the owner Safe only; the EOA's OWNER_ROLE was revoked at block 22169228.
OWNER_ROLE (windDownPool, registerPool, removePool, upgrade) is held by Safe 0xAd7f…7159 (v1.4.1), threshold 2 of 4 owners, no modules (getModulesPaginated empty), guard slot zero, no timelock; one owner is an EIP-7702-delegated account.
Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
A payer deposits and a note holder withdraws by calling public contracts, with no 0xbow API or relayer; addresses and ABIs are in the repo and SDK. But a private withdrawal to a payee succeeds only if 0xbow's ASP has already put the deposit's label in the latest root. Without that, the only direct path is ragequit back to the depositor. Judgment call: 1 (partial). The refund path is fully direct, and the payout path is a direct call that depends on a prior provider approval, which C2 treats like a provider signature.
Evidence (2)2 verified
Verified
deposit() and relay() on the Entrypoint have no caller restriction; relay pays RelayData.recipient and feeRecipient with a fee capped by maxRelayFeeBPS, so a user can relay their own withdrawal with fee 0. PrivacyPool.withdraw (PrivacyPool.sol L110-L129) can also be called directly with processooor = msg.sender.
The ETH pool's ENTRYPOINT() is 0x6818…6b46 and dead() is false at block 26153374; its Sourcify source matches PrivacyPool.sol at d494b63e apart from a trailing newline.
Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Relayers are optional and their code is public, and the ASP tree data is on IPFS under the CID posted onchain. The ASP approval itself is a required, closed, single-vendor service: only 0xbow's postman can add a deposit to the root that withdrawals must prove against. Scored 0.
Evidence (2)2 verified
Verified
The ASP "controls which deposits can be privately withdrawn" and interacts with the Entrypoint via authorized postmen; no ASP service code exists in github.com/0xbow-io (8 repos listed).
Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Filtering sits in the settlement contracts by design: the pool accepts a private withdrawal only for deposits the ASP has approved. It is disclosed in the versioned terms and ASP docs, but the screening criteria and data vendors are not named, and the private path cannot bypass it; only ragequit (to the depositor) does. Judgment call: anchor 0 is for filtering in the contracts without disclosure, and this is disclosed, so 1.
Evidence (2)2 verified
Verified
The terms say 0xbow checks whether a wallet is high-risk or on a sanctions list, that each deposit undergoes due diligence, that 0xbow may remove any address at any time, and that non-whitelisted users may withdraw only to their deposit address.
Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Tokens and pools are enumerated in code and onchain. We found no statement in the repos or terms that USDC and USDT can freeze a pool or the Entrypoint, which would lock every deposit in that pool. Ethereum L1 has no sequencer. Scored 2: enumerated in code, assumptions not stated.
Evidence (2)2 verified
Verified
Each pool is enumerated with chain, pool address, asset address, scope and deployment block; the Entrypoint's PoolRegistered events list the same 14 mainnet pools.
USDC isBlacklisted() is false for the USDC pool and the Entrypoint, and USDT isBlackListed() is false for the USDT pool and the Entrypoint, at block 26153426; both issuers can blacklist.
Does the deployed bytecode match public source, and can a third party rebuild it? O1
! Under review
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 todayDrift
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The weekly re-check found that a recorded fact changed. This rating counts as unknown until a reviewer re-checks it.
Every settlement contract in scope is verified on Sourcify as a partial match, and the Sourcify sources equal the repo files at d494b63e and at the audited commits apart from a trailing newline. We did not rebuild the bytecode. Scored 2: partial match.
Evidence (2)2 verified
VerifiedDrift
Sourcify returns match (partial) for the Entrypoint proxy and implementation, the ETH, USDC and USDT pools and both verifiers; the implementation slot of the proxy reads 0x15e3…1a2c at block 26153374.
The Foundry profile pins solc 0.8.28 with bytecode_hash none and cbor_metadata false, which is why Sourcify can only give a partial match; deploy scripts are in packages/contracts/script.
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Contracts, circuits, SDK, relayer, deploy scripts and frontend are public. The ASP backend (screening and root posting) and the ASP API are closed. Judgment call: the API has no published schema document, but its endpoints and response types are committed in the frontend client, which we accept as the schema for 2.
Evidence (2)2 verified
Verified
The core repo holds circuits, contracts with deploy scripts, the relayer and the SDK; privacy-pools-website holds the frontend.
Can a stranger reach a working deployment from the README? O3
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Build and deploy documentation exists for contracts, relayer and website. A self-hosted deployment would still need its own ASP, for which no code is published. Reproduction not attempted, so capped at 1.
Evidence (1)1 verified
Verified
Build and deploy steps (env setup, keystore import, forge scripts) are documented; the relayer README covers self-hosting and the website README covers pnpm install and env config.
Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
ABIs and event schemas are in the repo, and the ASP API's shape is in the frontend client (see O2). We found no payee export in a non-proprietary format; account state is rebuilt from the user's mnemonic and chain data. Scored 2.
Evidence (1)1 verified
Verified
Event schemas (Deposited, Withdrawn, Ragequit, PoolDied) are in the interfaces, and ABIs for the Entrypoint and pool are in packages/sdk/src/abi.
Does every repository needed to run the product carry an OSI-approved license? F1
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The contracts, circuits, SDK and relayer are Apache-2.0. The ASP service, which a private withdrawal requires, is closed, so F1 is 0 by rule. The website is non-commercial CC BY-NC 4.0, which is not an OSI licence; it is not required.
Evidence (2)2 verified
Verified
privacy-pools-core (contracts, circuits, SDK, relayer) is Apache-2.0.
The website is licensed CC BY-NC 4.0 ("You may not use the material for commercial purposes without explicit permission"), although its package.json says MIT.
Can the provider unilaterally relicense future versions, and has it committed not to? F2
! Under review
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days agoDrift
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The weekly re-check found that a recorded fact changed. This rating counts as unknown until a reviewer re-checks it.
No CLA and no licence-stability commitment. The core repo was relicensed from MIT to Apache-2.0 before mainnet launch, both permissive. Judgment call: the anchor names any prior relicense event as 0; this one did not restrict users, but we follow the anchor and take the lower score.
Evidence (1)1 verified
VerifiedDrift
The root LICENSE was MIT (Wonderland, 2024) at the initial commit and was replaced with Apache-2.0 in 6ae88dbe (2025-02-17); packages/contracts/LICENSE changed MIT to Apache-2.0 in 3efc7e7b (2025-02-18). There is no CLA or CONTRIBUTING file in the repo.
Does a production deployment need a proprietary plugin or hosted-only service? F3
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The pools, SDK and circuits run without proprietary code, but private withdrawal needs an ASP, and only 0xbow's closed one exists for this deployment. A fork could deploy its own Entrypoint with its own postman, but would have to write the ASP. Scored 1: documented that production needs a hosted service with no open alternative.
Evidence (1)1 verified
Verified
The docs state that withdrawals require a valid ASP root and that the ASP provides inclusion data; no ASP implementation is published.
What can an observer learn, and did the user knowingly choose it?
1 WeakPillar rating: weakest of 5 3 of 5 Partial or better
What would raise this pillar
Tracking and analytics reaching Partial: Present, off by default, opt-in visible in code.
Data collected beyond payment reaching Partial: Additional fields are either optional and clearly optional in code, or legally required, limited to that requirement, and disclosed with their legal basis in code or a versioned repo document.
Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The SDK has no analytics. The website loads Google Analytics on every page by default, and Sentry error reporting, sanitised and with tracing and replay off. The privacy policy discloses automated collection. Scored 1: present, on by default, disclosed.
Evidence (2)2 verified
Verified
The root layout always mounts GoogleAnalytics with NEXT_PUBLIC_GA_ID or the hardcoded fallback G-D177C1SMBP; src/instrumentation-client.ts L5-L18 initialises Sentry with default integrations off and a sanitising beforeSend; package.json also lists @vercel/analytics.
Does the flow collect anything beyond addresses, amounts, token, and chain? P2
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The protocol needs only settlement data, and the ASP screens the public deposit address. The website and 0xbow collect more (analytics, device data, marketing), disclosed only in the privacy policy, which does not limit collection to a legal requirement. Scored 1.
Evidence (2)2 verified
Verified
The policy lists name, email, phone, location, device data and AML/CFT due-diligence information as data 0xbow may collect, and uses device data for product analytics and marketing.
What do calldata and events reveal about who paid whom for what? P3
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The chain shows who deposited and how much, and who received and how much, but not which deposit funded which withdrawal. There is no memo or invoice field. Amounts are arbitrary, not fixed denominations, so an unusual amount withdrawn in full can be matched to its deposit; partial withdrawals and round amounts reduce that. The ASP sees nothing beyond the chain. Judgment call: amount matching depends on user choices and is noted here, not scored; on what the code reveals, 3.
Evidence (1)1 verified
Verified
Deposited emits depositor, commitment, label, value and precommitment hash; Withdrawn emits processooor, value, spent nullifier and new commitment; the proof hides which commitment the nullifier spends.
Which third parties see a request during a payment, and can they be swapped out? P4
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
In the website flow, 0xbow's ASP API, Envio, Alchemy (RPC and prices), a third-party relayer and Google Analytics see requests. All are named in code; the RPC is user-configurable, the ASP and HyperSync endpoints are env-configurable, and relayers are a choice. On the SDK path only the user's RPC and an IPFS gateway are needed. Scored 2.
Evidence (1)1 verified
Verified
Mainnet defaults are relayers fastrelay.xyz and api.clkd.xyz, an Alchemy RPC, an Envio HyperSync proxy for events, and the ASP URL from NEXT_PUBLIC_ASP_ENDPOINT_NON_TEST (src/config/env.ts L40-L49).
Can RPC and indexer URLs be changed, and is the indexer code public? P5
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The RPC is configurable in the UI and SDK. The indexer (ASP API) is configurable only via env, and its code is not public. Scored 2.
Evidence (1)1 verified
Verified
The website has a per-chain custom RPC field; the ASP and HyperSync URLs come from env at build time; the SDK takes rpcUrl in its config (packages/sdk/src/core/data.service.ts).
Who can cause loss, lock users in, or change the rules?
1 WeakPillar rating: weakest of 6 4 of 6 Partial or better
What would raise this pillar
Who holds funds in transit reaching Partial: Escrow contract with a provider role bounded by a timelock and a documented exit.
Who can upgrade the code reaching Partial: Multisig admin with a timelock, but the timelock is shorter than the user exit, signers are undisclosed, or no notice channel is named.
Who holds funds between payer and payee, and can the provider redirect them? S1
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Funds sit in non-upgradeable pools that no role can sweep, so 0xbow cannot redirect them. But release to anyone other than the depositor depends on the ASP postman (an EOA, no timelock), and relayed withdrawals and ERC20 deposits pass through the upgradeable Entrypoint. Judgment call: anchor 2 needs the provider role over release to sit behind a timelock, which it does not, so 1.
Evidence (2)2 verified
Verified
Pool funds leave only through withdraw (to the processooor bound into the proof context) or ragequit (to the original depositor); no admin function moves pool funds. Relayed withdrawals pass through the Entrypoint, which forwards to RelayData.recipient.
Who can change the contract code, and with how much notice? S2
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The pools and verifiers cannot be upgraded. The Entrypoint, through which every deposit and relayed withdrawal passes and which supplies the ASP root the pools check, is upgradeable by a 2-of-4 Safe with no timelock; it was upgraded once in May 2025. A malicious upgrade could not take funds already in the pools, but could stop withdrawals except ragequit, redirect relayed withdrawals, or pull tokens users have approved to it. Signers are not disclosed. Scored 1: multisig admin, no timelock.
Evidence (2)2 verified
Verified
Entrypoint is a UUPS proxy; _authorizeUpgrade is onlyRole(OWNER_ROLE) (Entrypoint.sol L308). hasRole(OWNER_ROLE, Safe 0xAd7f…7159) = true; Upgraded events show implementations 0xdd8a…d4c1 (block 22153713) then 0x15e3…1a2c (block 22540812).
How large an allowance does the SDK ask users to grant, and for how long? S3
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
ERC20 deposits approve the exact amount, so the code meets anchor 3. Judgment call: the frontend is not a distributed package and we ran no trace, so we cap at 2.
Evidence (1)1 verified
Verified
The website approves exactly the deposit value to the Entrypoint, zeroing a partial allowance first; the SDK's approveERC20 (packages/sdk/src/core/contracts.service.ts L378-L398) approves the amount the caller passes.
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Derived from S1=1, C2=1, C3=0, O3=1. If 0xbow disappears, the latest root stays in place: deposits already in it can still be withdrawn privately, and every depositor can ragequit directly from the immutable pool, with no 0xbow service. New deposits could no longer be approved, so private settlement stops. A payee holding a note for an unapproved deposit cannot recover it; only the depositor can. Scored 2: funds retrievable through a verified direct path; settlement stops.
Evidence (1)1 verified
Verified
The ETH pool is not a proxy (implementation slot zero) and its ragequit (PrivacyPool.sol L132-L150) checks only the depositor and a ragequit proof, not the Entrypoint or ASP.
Are secrets kept out of client bundles and are webhooks signed and verified? S5
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Account secrets come from a mnemonic generated and kept client-side. There are no webhooks or merchant API keys. The website bundles an Alchemy RPC key, which grants only RPC quota, and keeps the HyperSync and ASP keys server-side. Judgment call: 2 for the bundled RPC key.
Evidence (1)1 verified
Verified
NEXT_PUBLIC_ALCHEMY_KEY ships to the browser in RPC URLs; HYPERSYNC_KEY and ASP_API_JWT are server-only (getServerEnv) and used by the /api/hypersync-rpc proxy.
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The deployed Entrypoint implementation equals Entrypoint.sol at the audited commit 238e3594, and the pool sources equal the files at the audited final commit 532eaa8e, apart from a trailing newline. Oxorio links fix commits for its findings. There is no live bounty programme with scope, so not 3. Scored 2.
Evidence (2)2 verified
Verified
Oxorio's contracts audit pins initial commit 2d4627ba and final commit 532eaa8e and links fix commits per finding (e.g. 016a949f, L213); entrypoint_upgrade_audit_oxorio.md pins 238e3594; circuits and Auditware reports sit in the same folder.
Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.
Entrypoint upgrade adding used-precommitment tracking (the Entrypoint implementation deployed in May 2025). at 238e359405 S6 shows the deployed Entrypoint implementation 0x15e3…1a2c equals Entrypoint.sol at this commit.
Yes
No critical or major; 1 warning and 1 info, both acknowledged
Entrypoint, PrivacyPool, State and the simple and complex pool implementations. at 532eaa8ed1 Initial commit 2d4627ba, final 532eaa8e. The deployed pools match the final commit (S6); the Entrypoint it reviewed was replaced in May 2025 by the version in the upgrade audit.
Partly
No critical; 2 major (1 fixed, 1 acknowledged); warnings and info fixed, acknowledged or marked no issue
Entrypoint, PrivacyPool, State, pool implementations, Constants and ProofLib. at f0b8fe5e7b The report is undated; it was added to the repo on 2025-03-19 and the audited commit is from 2025-02-14. It links that commit in a defi-wonderland fork that no longer resolves; the commit exists in 0xbow-io/privacy-pools-core. The contracts changed afterwards with Oxorio's fixes.
Partly
3 medium (mitigated, partially mitigated, acknowledged), 3 low; no critical
Withdrawal, commitment and Merkle tree circuits (circom). at 8da36d5e21 The circuit sources are unchanged between the audited final commit and the assessed commit d494b63e, and the verifiers were generated in March 2025 after the trusted setup; we did not check that the deployed verifier keys derive from these circuits.
Unknown
No critical or major; warnings and info fixed, acknowledged or marked no issue
Compiled from: The audit/ folder of github.com/0xbow-io/privacy-pools-core (four reports) and its SECURITY.md, the 0xbow-io GitHub organisation, the privacy-pools-website repo, and web searches for further reports. Launch coverage names Audit Wizard, Auditware's product, which matches the Auditware report below. Oxorio's entrypoint-upgrade report is the audit of the May 2025 fix that followed the deposit-pause incident. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.
Operational and procurement
Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.
Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 16 evidenced, 0 attested, 4 absent, 4 not applicable, 21 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.
Group A: operational facts
Fees
Evidenced
Component
Paid by
Amount
Basis
provider
payer
Vetting fee 0.5% of each deposit (vettingFeeBPS = 50) on the ETH and USDC pools; 0 on the USDT pool
Entrypoint assetConfig per asset, set by OWNER_ROLE (0xbow Safe) with no timelock and no event-free path (PoolConfigurationUpdated). Terms state 0.5% and that it may change at 0xbow's discretion; fees accrue in the Entrypoint and only OWNER_ROLE can withdraw them.
provider
payee
Relay fee set by the relayer, deducted from the withdrawal; onchain cap 10% (maxRelayFeeBPS 1000)
Optional; only on withdrawals relayed through the Entrypoint. Each relayer sets fee_bps in its config (example config 500-1000); the Entrypoint reverts above the per-asset cap.
limit
none
Minimum deposit 0.01 ETH (ETH pool); 25 USDC; 25 USDT
assetConfig minimumDepositAmount, set by OWNER_ROLE.
network
payer
Ethereum gas for deposit; gas for withdrawal paid by the payee or by the relayer (recovered through the relay fee)
Network fee, not set by the protocol.
The USDT pool's vetting fee reads 0 onchain although the terms state 0.5%; the contract value is what is charged. ETH vettingFeeBPS was briefly set to 500 (5%) on 2025-11-23 and back to 50 on 2025-11-27 (see changes).
VerifiedDrift
Entrypoint assetConfig at block 26153723: ETH (0xEeee…EEeE) pool 0xF241…C9fB, min 0.01 ETH, vettingFeeBPS 50, maxRelayFeeBPS 1000; USDC pool 0xb419…ce86, min 25 USDC, 50, 1000; USDT pool 0xe859…4572, min 25 USDT, 0, 1000.
relay() reverts if relayFeeBPS exceeds maxRelayFeeBPS, deducts the relay fee from the withdrawn amount and pays it to the feeRecipient chosen in the relay data; deposit (L320-L340) deducts vettingFeeBPS before the pool deposit; withdrawFees (L264-L272) is onlyRole(OWNER_ROLE).
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Custody model
Evidenced
Self-custody
Judgment call. Agrees with the S1 finding that no role can sweep or redirect pool funds and the depositor can always ragequit; the ASP's control over private release (why S1 is 1) is a release dependency, not custody, so self_custody rather than hybrid.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Licences and registrations
Absent
Absent means no licence is claimed or cited anywhere 0xbow publishes. No regulator register (e.g. FinCEN MSB) was searched by entity name because the place of incorporation of 0xbow Limited is not stated.
Verified
The Terms of Use (556 lines) name 0xbow Limited as the counterparty and Delaware law, and describe the ASP due diligence and vetting fee; they cite no licence, registration or regulator (searched for licen, regulat, registered, money transmit). The privacy policy and 0xbow.io were searched the same way with no result.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Cash-out options
N/A: falls to the institution
Token-to-address rail. The payee receives ETH or tokens at an address it controls; converting them to local currency is outside the protocol.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
First deployment
Evidenced
2025-03-29 (block 22153714): ETH pool (PrivacyPoolSimple) 0xF241…C9fB created in tx 0x6e3e14d7…cf75; the Entrypoint proxy was created one block earlier (22153713, tx 0x4987385c…776c).
Verified
Sourcify creation data gives tx 0x6e3e14d7bcdfa838a8f7918de81d7b233e40d3afd493a864285fad8b360bcf75 at block 22153714 (deployer EOA 0x1f4F…E187, via a factory, so the receipt has no contractAddress); block 22153714 is dated 2025-03-29 UTC.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Operating entity
Unknown
The terms name "0xbow Limited" (also "Oxbow Ltd.") as maintainer and counterparty, with Delaware governing law, but no place of incorporation or company number; the privacy policy, SECURITY.md, 0xbow.io and the GitHub org (no company field) give none. Recorded as unknown because the schema needs a jurisdiction; see B11.1 for the named counterparty.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Security incidents
Evidenced
Absence of a found incident is not evidence that none occurred.
No post-mortem found in the core repo, docs or 0xbow.io. Audit findings fixed before launch (Oxorio, see S6) are not incidents.
Verified
No published security advisories for 0xbow-io/privacy-pools-core.
2025-05-24: ETH pool configuration set to vetting fee 50 bps, max relay fee 100 bps; minimum deposit raised to 0.1 ETH the same day. source
2025-07-14: ETH pool max relay fee raised from 100 to 500 bps. source
2025-11-23: Ten pools reconfigured in one transaction; ETH pool minimum lowered to 0.01 ETH, vetting fee set to 500 bps and max relay fee to 1000 bps. source
2025-11-27: ETH pool vetting fee set back to 50 bps. source
2025-12-15: USDC pool vetting fee set from 0 to 50 bps. source
Fee and minimum changes are made by OWNER_ROLE without a timelock or prior notice found. No governance proposals exist; the transactions are the primary source.
Verified
Upgraded and PoolConfigurationUpdated logs on the Entrypoint from block 22153712 to latest (via rpc.mevblocker.io); dates from block headers. Upgraded at 22153713 and 22540812; PoolConfigurationUpdated at 22553626, 22553907, 22919769, 23864776 (10 pools), 23892246, 24020649.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Volume transacted (verified only)
Unknown
not computed on 2026-10-19: eth_getLogs: Archive requests require a personal token. Get one at: https://www.allnodes.com/publicnode
Withdrawals reveal amount and recipient onchain (only the link to the deposit is hidden), so private payouts are observable at pool level. Not computed; the maintainer runs scripts/volumes.mjs.
UnreviewedAssessed by AI research agent (operational), 2026-10-09
Group B: institutional due diligence
Control
State
What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?
Unknown implied from the component list
B1.2 ISO 27001, hosting and support organisation Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?
Unknown implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?
Unknown implied from the component list
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?
Evidenced
Oxorio audited the contracts (final commit 532eaa8e) and the Entrypoint upgrade (238e3594); deployed sources match. Circuits and Auditware reports are in the same folder. See CROPS S6. CROPS S6
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?
Unknown implied from the component list
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?
Unknown implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?
Evidenced
some of 2 repo(s): 0xbow-io/privacy-pools-core ✓ security policy file: SECURITY.md; 0xbow-io/privacy-pools-website ✗ no security policy file source 1 · source 2
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?
Absent
none of 2 repo(s): 0xbow-io/privacy-pools-core ✗ no scanning config or workflow step found; 0xbow-io/privacy-pools-website ✗ no scanning config or workflow step found source 1 · source 2
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?
N/A: no such service implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?
N/A: no such service implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?
Unknown implied from the component list
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?
N/A: no such service implied from the component list
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?
Unknown implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?
Unknown implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?
Unknown implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?
N/A: no such service implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?
Unknown implied from the component list
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
Unknown implied from the component list
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?
Unknown implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?
Unknown implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?
Unknown implied from the component list
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?
Unknown implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?
Evidenced
No fixed retention period; personal data kept "for the period of time needed for legitimate business purposes", longer where law requires. Deletion on request, with residual copies in backups removed over time. Cross-reference CROPS P2. source 1
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?
Evidenced
The privacy policy calls 0xbow a data processor in general and a data controller for EU residents under GDPR. No DPIA is mentioned. The two roles are stated inconsistently in the same document. source 1
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?
Unknown implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?
Unknown implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?
Unknown implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?
Unknown implied from the component list
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?
Absent
none of 2 repo(s): 0xbow-io/privacy-pools-core ✗ no deployment configuration; 0xbow-io/privacy-pools-website ✗ no deployment configuration source 1 · source 2
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?
Evidenced
some of 2 repo(s): 0xbow-io/privacy-pools-core ✗ no branch rules visible (classic branch protection is not readable without push access); 0xbow-io/privacy-pools-website ✓ rules: required_signatures, pull_request, required_status_checks, deletion, non_fast_forward source 1 · source 2
B9.2 CI runs on pull requests Does every pull request trigger automated checks?
Evidenced
all of 2 repo(s): 0xbow-io/privacy-pools-core ✓ 8 workflow file(s); 0xbow-io/privacy-pools-website ✓ 3 workflow file(s) source 1 · source 2
B9.3 Tests run in CI Do the CI workflows run the test suite?
Evidenced
all of 2 repo(s): 0xbow-io/privacy-pools-core ✓ test command in a workflow; 0xbow-io/privacy-pools-website ✓ test command in a workflow source 1 · source 2
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?
Evidenced
some of 2 repo(s): 0xbow-io/privacy-pools-core ✓ coverage tooling referenced; 0xbow-io/privacy-pools-website ✗ coverage tooling referenced source 1 · source 2
B9.5 Versioned releases Are releases tagged with immutable semantic versions?
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?
Evidenced
all of 2 repo(s): 0xbow-io/privacy-pools-core ✓ 10 of 10 recent commits signed; 0xbow-io/privacy-pools-website ✓ 10 of 10 recent commits signed source 1 · source 2
B9.7 Changelog Is a changelog maintained with the code?
Evidenced
all of 2 repo(s): 0xbow-io/privacy-pools-core ✓ 6 release(s) with notes; 0xbow-io/privacy-pools-website ✓ CHANGELOG file source 1 · source 2
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?
Evidenced
some of 2 repo(s): 0xbow-io/privacy-pools-core ✗ none found; 0xbow-io/privacy-pools-website ✓ contribution section in README source 1 · source 2
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?
Evidenced
Logical and integration architecture (contracts, ZK, ASP layers; deposit, withdrawal and ragequit flows; SDK and relayer reference) in the core repo docs. No infrastructure view of the hosted ASP. source 1
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?
Evidenced
0xbow Limited (terms also say "Oxbow Ltd."); governing law and exclusive venue Delaware, JAMS arbitration. Place of incorporation not stated. source 1 · source 2
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?
Evidenced
Onchain fee switch. The vetting fee (0.5% on ETH and USDC deposits) accrues in the Entrypoint and is withdrawable by OWNER_ROLE (0xbow's Safe). No other funding source is published. source 1 CROPS C1
B11.3 Termination terms What happens to customer funds and data on termination by either side?
Evidenced
0xbow may terminate access to the website and functionalities at any time without limit; vetting fees are non-refundable. Funds stay in the immutable pools and the depositor can always ragequit without 0xbow (CROPS S4). source 1 CROPS S4
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?
Unknown
The ASP's vetting is closed. 0xbow.io says the ASP "continuously monitors transactions" and conducts "Know Your Transaction", and the terms describe a due diligence process, but no source says whether it is rule-based, vendor-supplied or uses AI. No ASP code is published.
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
Unit: Ethereum Entrypoint 0x6818…6b46 with the ETH, USDC and USDT pools; 11 further mainnet pools (USDS, sUSDS, DAI, wstETH, WBTC, USDe, USD1, frxUSD, wOETH, fxUSD, BOLD) use the same contracts and are not scored separately. Reads at block 26153374 via publicnode (blacklist reads at 26153426); event history via rpc.mevblocker.io, which served full-range eth_getLogs. The deployments doc lists implementation 0xdd8a…d4c1, superseded by 0x15e3…1a2c in May 2025. The latest ASP tree (CID bafybeibshlh…fb3a) was retrievable from public IPFS gateways. No transactions, UI runs, traces or self-host attempts.
