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 Deployments doc lists Base as the only mainnet row with a mainnet relayer (proxy 0x064A…dCFf), and the Web App doc names Base as its only network. The implementation is a Sourcify match identical to blanksquare-monorepo@5dad5a07 contracts/Shielder.sol. Unit: the proxy, implementation and four linked libraries. Excluded: HyperEVM (listed with a testnet relayer), Base and Arbitrum Sepolia, and the older v2 deployments (Aleph Zero EVM, Arbitrum) in shielding-dapp.
Offered everywhere except the countries listed. Checked 2026-10-09. Not scored.
From Annex 3 of the Shielder Service terms (4 Nov 2025), which also bars Russian-occupied territories of Ukraine (Ukraine itself is not listed), sanctioned persons and politically exposed persons, and limits use to personal, non-commercial use. Section 6.2 points to "Annex no. 1" for the list while Section 22.15 points to Annex 3; the list is in Annex 3. The terms bind use of the official apps; the Shielder contract has no address or country check, so the protocol is callable from anywhere through the SDK. The apps were offline on 2026-10-09.
Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
A 2-of-5 Safe owns the Shielder and can pause it, which stops deposits and withdrawals alike. The Safe has no modules or guard, but there is no timelock, and we found no public list of the signers. Pause is global; there is no per-address blacklist in the contract. Scored 1: a multisig role that misses the timelock and signer-disclosure conditions.
Evidence (4)4 verified
Verified
onlyOwner can upgrade (_authorizeUpgrade), pause and unpause, set deposit and withdraw fee bps and the fee receiver, and replace the anonymity-revoker public key; newAccount, deposit and withdraw are all whenNotPaused (L216, L274, L392, L441, L545, L598), so a pause also stops exits. There is no per-address blacklist.
The owner is a Safe 1.4.1 with threshold 2 of 5 owners (0x4Ca7…2397, 0xEfD1…d425, 0x6b02…4D73, 0x428B…453f, 0x07A8…fc76); getModulesPaginated(0x1,10) returns no modules and the guard slot is zero. No timelock sits between the Safe and the proxy.
Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
A payer deposits and later withdraws to any payee address by calling the Shielder directly; no relayer, signer or API is needed, and the SDK ships a direct-withdraw method. The address is published in the docs and the source is public and verified. Payment model: there is no shielded transfer to another account in this contract version, so a payment is a withdraw to the payee's address. We sent no transaction. The owner Safe can still pause the contract (C1).
Evidence (4)3 verified · 1 documented
Verified
withdrawNative and withdrawERC20 (L584-L645) are external with no caller check; the relayer address and fee are only parameters bound into the proof commitment (L687-L698), and a fee of 0 skips the relayer transfer. depositNative and depositERC20 (L383-L476) are open to any caller.
The SDK's withdrawManual sends the withdraw transaction to the Shielder directly from the user's own account, documented as the path for when the relayer is not available.
Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Settlement needs only the Shielder, a client-side prover and an RPC. The relayer is optional (withdrawManual), and its code is public. The official hosted relayer did not resolve in DNS on 2026-10-09, which leaves the direct path as the working one. Judgment call: as with Tornado Cash, withdrawing without a relayer needs gas in the withdrawing account and weakens privacy (P3); the cell measures settlement dependence, so 3.
Evidence (2)2 verified
Verified
The SDK takes an injected viem publicClient (any RPC), a cryptoClient (local WASM prover) and a relayerUrl string; chain state is read from contract events through that RPC (chain/contract.ts L550-L560), so no indexer or hosted API is involved.
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
The settlement contract is neutral. Edge filtering is set out in the terms (country list, sanctioned persons, PEPs, a reserved right to geo-block), not in code or a versioned repo document, and the official apps that would enforce it are closed and now offline, so we could not see what they did. The direct contract path bypasses any app-level filter. The docs also describe an anonymity revoker and a "Shielder Guard" (description marked work in progress). Scored 1: edge filtering disclosed in documents only.
Evidence (2)1 verified · 1 documented
Verified
The withdraw path checks version, amount, fee, Merkle root, nullifier and proof only; no address or country check exists in the contract. A grep of crates/shielder-relayer for sanction, blocklist, chainalysis and country finds nothing.
Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
We found no enumeration of supported Base mainnet tokens in public code or docs, and no statement to users about issuer freeze powers (USDC is held by the pool) or Base's sequencer and forced-inclusion assumptions. The pool held about 0.078 ETH and 48.2 USDC at our block. Scored 0: not enumerated.
Evidence (2)2 verified
Verified
depositERC20 accepts any token address; the contract has no token list.
Does the deployed bytecode match public source, and can a third party rebuild it? O1
2 Partial
Best evidence: VerifiedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Every settlement contract has public verified source: partial Sourcify matches plus explorer verification for the implementation and libraries, and an explorer similar-match for the standard ERC1967 proxy. No full match and no rebuild attempted. Scored 2.
Evidence (1)1 verified
Verified
Sourcify returns match (partial) for the implementation and for the four linked libraries (0x37aA…eb94, 0xd03d…37dC, 0x04eb…c0Fb, 0x152D…B6e), and no record for the proxy 0x064A…dCFf; Basescan shows the implementation and libraries as Source Code Verified and the proxy as an ERC1967Proxy Similar Match.
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
2 Partial
Best evidence: VerifiedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Contracts, circuits, SDK, relayer and deploy scripts are public, and no indexer is needed. The frontend that served Base mainnet (app.blanksquare.io) and the mobile app were not traced to public source; the public shielding-dapp does not configure Base mainnet. Judgment call: 2, everything public except the live app.
Evidence (1)1 verified
Verified
The monorepo holds contracts, circuits, relayer, TEE prover and scheduler, CLI and deploy scripts (scripts/), and ts/ holds the SDK and WASM crypto. shielding-dapp is a public frontend but configures only testnets and the older v2 deployments.
Can a stranger reach a working deployment from the README? O3
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Build and run documentation exists for the relayer, SDK and a quickstart app. Reproduction not attempted, so the score is capped at 1.
Evidence (1)1 verified
Verified
The relayer README gives native and Docker run steps and a configuration table; the root README gives setup steps and shielder-quickstart is a minimal SDK app.
Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Interfaces can be derived from verified source, and the docs describe the SDK, but no ABI file, API schema or payee export is committed. Judgment call: 1, as the interface record is source and hosted docs only.
Evidence (1)1 verified
Verified
NewAccount, Deposit and Withdraw events are defined in source; the SDK imports its ABI from ../_generated/abi, which is generated at build time and not committed. The relayer has no OpenAPI or equivalent schema in the repo.
Does the license actually let a third party fork, modify, and run it?
2 PartialPillar rating: weakest of 3 3 of 3 Partial or better
What would raise this pillar
Protection against relicensing reaching Strong: No CLA, or a CLA that does not permit unilateral relicensing, plus a written license-stability commitment in the repo.
No proprietary dependencies reaching Strong: A production deployment needs no proprietary plugin or hosted-only service.
Does every repository needed to run the product carry an OSI-approved license? F1
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Every listed repo, and every required component, carries an OSI licence (Apache-2.0, MIT, GPL-3.0 with an added Classpath permission). The closed web and mobile apps are not required to settle.
Evidence (1)1 verified
Verified
blanksquare-monorepo is Apache-2.0, and its NOTICE and README (L236-L242) state the circuits crate is GPL-3.0-only with Classpath exception; shielding-dapp and shielder-quickstart are MIT (GitHub license API).
Does a production deployment need a proprietary plugin or hosted-only service? F3
2 Partial
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
No proprietary plugin or hosted-only service is needed to deposit and withdraw. Judgment call: the code supports 3, but with no O3 reproduction we take 2.
Evidence (1)1 verified
Verified
The SDK's dependencies are viem, zod, comlink, async-mutex and the project's own crypto packages; it needs a user-supplied RPC and the relayer URL is optional for withdrawManual.
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 dependency. The apps ship PostHog on by default, disclosed in the privacy policy. Scored 1; the closed live builds were not inspected.
Evidence (2)1 verified · 1 documented
Verified
The public dapp initialises PostHog whenever the build sets PUBLIC_VAR_POSTHOG_KEY (envVarsSchema requires it), with in-memory persistence and an address-sanitising before_send hook; there is no opt-in toggle.
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
Through the SDK the protocol collects settlement data plus an anonymity-revoker ciphertext and MACs that let the revoker link an account's actions; the docs disclose this, but no legal basis is stated. The apps also collect IP, location and analytics data under the privacy policy. Scored 1: collection beyond settlement, disclosed in documents.
Evidence (2)1 verified · 1 documented
Verified
Account creation posts symKeyEncryption (the account key encrypted to the anonymity revoker's public key) and every action posts a MAC, beyond the amount, token and address that settlement needs.
What do calldata and events reveal about who paid whom for what? P3
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Onchain data shows who deposited and who received, and the exact amounts, but not which deposit funded which withdrawal. Amounts are arbitrary and in plaintext, so amount and timing matching can link payer and payee. The anonymity-revoker key holder (set by the owner Safe) can link every action of an account. Judgment call: 2, minimal linkage by design and documented, but not 3 because amounts are public and a designated party can deanonymise.
Evidence (2)1 verified · 1 documented
Verified
Deposit emits token, amount, note, MAC and memo (the depositor is the tx sender); Withdraw emits token, amount, withdrawalAddress, relayer, fee, MAC and memo. The proof hides which account a withdrawal spends from.
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
On the SDK path only the chosen RPC and, if used, the relayer see a request; the relayer sees the withdrawal address and the user's IP. The apps add PostHog and Reown/WalletConnect. Named in code and swappable in the SDK. Scored 2 (3 would need a package or trace).
Evidence (1)1 verified
Verified
The SDK contacts only the injected RPC client and the configured relayer URL (fee quote and relay).
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
Endpoints are configurable in SDK code; the public UI fixes them at build time and offers no setting. No indexer is needed. Scored 2.
Evidence (1)1 verified
Verified
The public dapp hardcodes relayer and fee-estimator URLs per chain; the SDK takes RPC client and relayer URL as config (factories.ts L30-L48), and no indexer exists.
Who can cause loss, lock users in, or change the rules?
1 WeakPillar rating: weakest of 6 3 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.
Audits and bug bounty reaching Partial: Audit pinned to a commit, resolutions not individually linked.
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
In the current code only a valid proof moves funds out, to the address bound in it. The escrow is upgradeable by a 2-of-5 Safe with no timelock, so the owner could deploy code that redirects funds. Upgradeability is visible in verified source. Scored 1: upgradeable escrow, disclosed.
Evidence (1)1 verified
Verified
Funds sit in the UUPS proxy between deposit and withdrawal; the implementation (Shielder.sol L22-L31, L155) lets the owner Safe upgrade it with no delay.
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
A 2-of-5 Safe can upgrade the Shielder at once; there is no timelock and we found no signer disclosure or notice channel. Scored 1: multisig admin, no timelock.
Evidence (1)1 verified
Verified
UUPS proxy (EIP-1967 admin slot zero; upgrade authorised by onlyOwner in the implementation); owner() is the Safe 0x9Dc4…2165, threshold 2 of 5, no modules, no guard.
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
The SDK leaves approval to the integrator; the public reference dapp approves the exact amount. That fits anchor 3, but a 3 needs a package or trace and we did not inspect the closed live app. Judgment call: 2.
Evidence (1)1 verified
Verified
The public dapp checks the allowance and, if short, approves exactly the shield amount to the Shielder.
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=3, C3=3, O3=1. The official web app and relayer are already offline, and the contract stays unpaused: an account holder can rebuild state from RPC events and withdraw with withdrawManual and the local prover (C2, C3). The owner Safe could still pause or upgrade (S1), so funds are safe from provider disappearance but not from provider action. There is no public frontend build for Base mainnet and no reproduction (O3=1). Judgment call: 2.
Evidence (1)1 verified
Verified
paused() is false at block 52371351, so withdraw is callable by anyone with a valid proof.
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
No secrets in the client and no webhooks; the bundled keys are publishable identifiers. Private Send hands a key to a TEE, which is opt-in. Scored 2 (3 needs a package or trace).
Evidence (1)1 verified
Verified
The dapp bundles only public variables (Reown project ID, PostHog key and host, OG image URL); the SDK has no API keys or webhooks and derives the shielder seed client-side.
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
One audit report, pinned to a commit before several contract changes that are now deployed; no per-finding fix links reviewed, and no bug bounty or SECURITY file found. Scored 1.
Evidence (2)1 verified · 1 documented
Verified
The audited commit is dated 2025-03-21; Shielder.sol later changed (caller commitment 2025-04-07, AR key setter 2025-04-17, protocol fees 2025-07-17), and the deployed code comes from blanksquare-monorepo@5dad5a07.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Security audits 1
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.
Shielder circuits (private zkOS-circuits at 491a0dd), Shielder.sol and Poseidon2 Solidity generator, and the Rust/TypeScript client SDK; the Halo2 verifier and the Poseidon2 circuit component were out of scope at 22e2f52f93 Commissioned as the Aleph Zero Shielder. Shielder.sol changed after the audited commit (caller commitment, AR key setter, protocol fees in April-July 2025), and the Base deployment comes from blanksquare-monorepo@5dad5a07.
Partly
1 medium, 3 informational; fixes linked to zkOS-monorepo pull requests
Compiled from: The README and crates/shielder-circuits/README of github.com/Cardinal-Cryptography/blanksquare-monorepo (both link one zkSecurity report), the Blanksquare docs (llms.txt and sitemap, no audits page), the zkOS-monorepo repo, a GitHub code search of the Cardinal-Cryptography org for audit, and reports.zksecurity.xyz. No other audit of the Shielder contracts, circuits, SDK, relayer or TEE prover was found. 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: 13 evidenced, 0 attested, 5 absent, 20 not applicable, 7 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
none
Protocol deposit and withdrawal fees both 0 bps on Base (contract cap 500 bps each)
protocolDepositFeeBps and protocolWithdrawFeeBps, settable at once by the owner Safe up to MAX_FEE_BPS 500; receiver is the owner Safe. Unchanged at every block sampled since deployment.
provider
payee
Relayer fee = network fee + optional pocket money + commission (default 15% of relay cost), in the withdrawn token
Set by whoever runs a relayer (shielder-relayer SERVICE_FEE_PERCENT); optional, since withdrawManual needs no relayer. The official Base relayer did not resolve on 2026-10-09.
network
payer
Base gas; sample 1,764,659 gas, about 0.0000106 ETH incl. L1 fee, for the last shield (2026-04-02)
Paid by the depositor, and by the withdrawer on the direct path; relayers fold it into their fee.
No withdrawal gas sample; public Base RPCs refuse log queries over the deployment's range, so only the last tree-changing transaction was located (by bisecting merkleTree() state).
Verified
protocolDepositFeeBps() and protocolWithdrawFeeBps() return 0 and protocolFeeReceiver() is the owner Safe 0x9Dc4…2165 at block 52380966; both fees also read 0 at blocks 33246477, 40000000 and 46000000.
The last transaction that changed the Shielder's Merkle tree (NewAccount log, block 44167109, 2026-04-02 09:52:45 UTC) used 1,764,659 gas at 0.006 gwei plus an L1 fee of 54,547,339,119 wei, about 0.0000106 ETH in total.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Custody model
Evidenced
Self-custody
Agrees with S1 (score 1). Only a valid proof moves funds out, to the address bound in it, and the terms say the service provider does not safekeep or control crypto-assets. The disclosed risk is that a 2-of-5 Safe can upgrade the escrow with no timelock and pause withdrawals.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Licences and registrations
Absent
Searched: the docs (llms.txt, FAQ, fraud protection, legal pages) and the archived terms and privacy excerpts; no licence is claimed. Not searched: the Panama Public Registry and Superintendency registers (interactive search), and the full PDF terms beyond the archived excerpts.
Documented
The Shielder Service terms (4 Nov 2025) describe a non-custodial service by Common Labs Inc. (Panama) and cite no licence, registration or regulator in the archived sections.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
First deployment
Evidenced
2025-07-23 (block 33246476): Shielder proxy 0x064A…dCFf created in tx 0xf63c3126…8045 by 0x9A3C…bebA, two transactions after the implementation 0xfFF4…8b53 (tx 0x1bc2f5ad…a6a8); unpaused in the same block.
Verified
Sourcify creation data for the implementation gives tx 0x1bc2f5ad1486353b4bc94c9b1dc7b603b192709f3bf731025f78a93f181ca6a8 in block 33246476 by 0x9A3CE7876beCF00e6467E7AE38e059Ee8c12bebA. The proxy has no Sourcify record; its deploy receipt (tx 0xf63c31263f7dc17c56862a7d763b4d24f1fd9e0f141e488d5d43401730068045, same block and sender) has contractAddress 0x064A…dCFf. Block 33246476 is dated 2025-07-23 14:51:39 UTC.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Operating entity
Evidenced
Common Labs Inc., PA
No company-register entry; the Panama Public Registry search is interactive and was not used. The code is written by Cardinal Cryptography (GitHub org); its relation to Common Labs is not stated.
Documented
Terms definition 22.18 names the service provider and its registered address in Panama City; section 19.1 sets Panama law.
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 security incident found in the docs or repository. Service status: on 2026-10-09 the web app and blanksquare.io returned Vercel DEPLOYMENT_NOT_FOUND and the Base relayer host did not resolve; no notice of the shutdown was found, so it is recorded here and in changes only as an observation, not a dated incident.
Verified
No published security advisories for Cardinal-Cryptography/blanksquare-monorepo.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Product changes affecting users
Evidenced
2025-07-23: Shielder proxy deployed with implementation 0xfFF4…8b53 (v0.1.1) and unpaused (tx 0x87a2b37d…53d7); owner the deployer EOA 0x9A3C…bebA, protocol fees 0. source
2025-07-28: Ownership transferred from the deployer EOA to the 2-of-5 Safe 0x9Dc4…2165 (OwnershipTransferred, block 33462649). source
2025-11-04: Current version of the Shielder Service terms (restricted-country annex, Panama law). source
2026-04-02: Last transaction that changed the Shielder's Merkle tree (a NewAccount); no tree change since, and the apps and relayer were offline on 2026-10-09. source
Upgrade and pause history comes from state sampling, not a full log scan (public Base RPCs refuse long log ranges), so an upgrade reverted between samples would be missed. The privacy policy is dated 25 July 2025.
Verified
State read at blocks 33246477, 40000000, 46000000 and 52380966 - the EIP-1967 implementation slot is 0xfFF4…8b53 throughout, fees 0 and paused false; owner() changes from 0x9A3C…bebA to the Safe at block 33462649 (bisected), whose OwnershipTransferred log is in tx 0x51ee17e5…63a9. merkleTree() nextFreeLeafId last changed at block 44167109 (bisected).
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: request limit reached
All Withdraw fields are non-indexed and in plaintext, so payouts are observable. The tree has not changed since 2026-04-02, so a 30-day window is expected to be empty. Not computed; Base log ranges need an archive RPC (RPC_8453).
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
No certification statement for Common Labs Inc. or Cardinal Cryptography in the docs or archived terms.
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?
N/A: falls to the institution 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
No SOC 2 or ISAE report or statement of availability found.
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
zkSecurity audited the contracts and circuits at zkOS-monorepo commit 22e2f52 (March 2025); the deployed Shielder.sol changed after that commit. No review of the relayer, TEE prover or apps is listed. 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
No penetration test of the relayer, TEE prover or apps found.
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?
N/A: falls to the institution 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)?
Absent
none of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✗ no security policy file; Cardinal-Cryptography/shielding-dapp ✗ no security policy file; Cardinal-Cryptography/shielder-quickstart ✗ no security policy file source 1 · source 2 · source 3
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)?
Unknown
No SECURITY file, disclosure page or patch timeline in the repositories, docs or archived terms.
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?
Absent
none of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✗ no scanning config or workflow step found; Cardinal-Cryptography/shielding-dapp ✗ no scanning config or workflow step found; Cardinal-Cryptography/shielder-quickstart ✗ no scanning config or workflow step found source 1 · source 2 · source 3
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)?
Unknown
No incident-notification commitment in the docs or archived terms excerpts.
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
No status page or post-mortem found; the apps and relayer went offline without a notice we could find.
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?
N/A: falls to the institution 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?
N/A: falls to the institution 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?
N/A: falls to the institution 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?
Evidenced
The relayer API takes unauthenticated JSON POSTs (quote_fees, relay); no OAuth, JWT or API key option exists in its configuration. The SDK otherwise talks only to a user-chosen RPC. source 1 · source 2
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
N/A: falls to the institution 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)?
N/A: falls to the institution implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?
N/A: falls to the institution 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?
N/A: falls to the institution 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?
N/A: falls to the institution 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?
Unknown
The apps' privacy policy (PDF, 25 July 2025) was not re-read in full; the archived excerpts list data categories and recipients but not retention periods. CROPS P2
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?
N/A: falls to the institution implied from the component list
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?
N/A: falls to the institution implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?
N/A: falls to the institution 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?
N/A: falls to the institution 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?
N/A: falls to the institution 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 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✗ no deployment configuration; Cardinal-Cryptography/shielding-dapp ✗ no deployment configuration; Cardinal-Cryptography/shielder-quickstart ✗ no deployment configuration source 1 · source 2 · source 3
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?
Absent
none of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✗ rules: required_signatures; Cardinal-Cryptography/shielding-dapp ✗ no branch rules visible (classic branch protection is not readable without push access); Cardinal-Cryptography/shielder-quickstart ✗ no branch rules visible (classic branch protection is not readable without push access) source 1 · source 2 · source 3
B9.2 CI runs on pull requests Does every pull request trigger automated checks?
Evidenced
some of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✗ 25 workflow file(s); Cardinal-Cryptography/shielding-dapp ✓ 4 workflow file(s); Cardinal-Cryptography/shielder-quickstart ✗ no .github/workflows source 1 · source 2 · source 3
B9.3 Tests run in CI Do the CI workflows run the test suite?
Evidenced
some of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✓ test command in a workflow; Cardinal-Cryptography/shielding-dapp ✓ test command in a workflow; Cardinal-Cryptography/shielder-quickstart ✗ test command in a workflow source 1 · source 2 · source 3
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?
B9.5 Versioned releases Are releases tagged with immutable semantic versions?
Evidenced
some of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✓ latest tags: v0.1.0, shielder-scheduler-tee-20251030-140127, shielder-scheduler-tee-20251017-120503; Cardinal-Cryptography/shielding-dapp ✓ latest tags: 1.0.5, 1.0.4, 1.0.3; Cardinal-Cryptography/shielder-quickstart ✗ no tags source 1 · source 2 · source 3
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?
Evidenced
all of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✓ 10 of 10 recent commits signed; Cardinal-Cryptography/shielding-dapp ✓ 10 of 10 recent commits signed; Cardinal-Cryptography/shielder-quickstart ✓ 5 of 5 recent commits signed source 1 · source 2 · source 3
B9.7 Changelog Is a changelog maintained with the code?
Evidenced
some of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✓ CHANGELOG file; Cardinal-Cryptography/shielding-dapp ✓ 4 release(s) with notes; Cardinal-Cryptography/shielder-quickstart ✗ no changelog or release notes source 1 · source 2 · source 3
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?
Evidenced
some of 3 repo(s): Cardinal-Cryptography/blanksquare-monorepo ✓ contribution section in README; Cardinal-Cryptography/shielding-dapp ✗ none found; Cardinal-Cryptography/shielder-quickstart ✗ none found source 1 · source 2 · source 3
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 views on the docs site (protocol overview, notes and accounts, relayers, anonymity revokers, client-side components, TEE proof delegation, SDK guides, deployments); infrastructure only as the relayer's Docker and configuration README. Not versioned with the code except the relayer README. source 1 CROPS O3
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?
Evidenced
Common Labs Inc., Panama (registered address in Panama City); terms under Panama law. Applies to the apps and Shielder Service, not to direct contract use. source 1
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?
Evidenced
An onchain fee switch exists (up to 5% per deposit and withdrawal, paid to the owner Safe) but is set to 0; relayer commission would accrue to the relayer's fee address. No other funding source is published. source 1
B11.3 Termination terms What happens to customer funds and data on termination by either side?
Evidenced
Common Labs may terminate the Shielder Service agreement immediately if the user is a Restricted Individual (other termination clauses not in the archived excerpts). Funds stay in the contract and can be withdrawn with the SDK's direct path while it is unpaused (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)?
Absent
No automated screening or AI in the payment path. The contract checks only proofs, nullifiers and amounts; the relayer has no sanctions, blocklist or analytics code. The anonymity revoker acts on a governance decision, not an automated one. CROPS C4
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
N/A: no such service
No AI component in the payment path (B12.1 absent).
Unit: the Base Shielder proxy 0x064A…dCFf and its implementation and libraries; all Base reads at block 52371351 (mainnet.base.org serves historical state). Status on 2026-10-09: blanksquare.io and app.blanksquare.io return Vercel DEPLOYMENT_NOT_FOUND, the Base relayer host does not resolve, and the Merkle tree's next free leaf has not moved since a block between 44,000,000 and 46,000,000 (about May 2026; 448 leaves in total). The contracts are live and unpaused, so we treat the rail as deployed but dormant. Operator: Common Labs Inc. (Panama) per the terms; code by Cardinal Cryptography. No transactions, app runs, traces or self-host attempts.