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 card top-up contract is the only onchain component. Its Ethereum deployment 0x6fC79dDD... (TransparentUpgradeableProxy, Sourcify exact match) emits CardTopup events continuously from block 16810662 to a top-up at block 26074697 (28 Sep 2026), found via the CardTopup topic on eth.blockscout.com. Excluded: Base (an unverified, non-proxy contract with the same address and the same CardTopup event; no event in the last 5,000 blocks read), Arbitrum (no code at that address, no CardTopup event in 240,000 blocks) and Solana, which the SDK also supports.
Offered only in the countries listed. Checked 2026-10-09. Not scored.
The Terms and Conditions (last updated 01.07.2026) are the only customer terms Holyheld publishes, and their scope clause covers users resident in or located in Switzerland; s9.2 adds that the Platform is not provided where its use would violate local law. Holyheld markets the membership as being for "global payments" (SEPA, ACH, SWIFT), but no first-party page lists other countries, and no terms for other jurisdictions are published, so the more restrictive reading (Switzerland only) is used. The card itself is not given a separate country list. Membership is by invitation, reviewed per applicant.
Conversion. The token is converted into a fiat balance at top-up; card spend comes from that fiat balance.
Fiat-backed stablecoin. An issuer holds the reserves and can freeze balances at the token contract. Value depends on the issuer redeeming at par. Censorship Resistance records whether that freeze power is disclosed.
The card spends a fiat e-money balance, not a token. A top-up is a sale of USDC to Holyheld: the Terms say USDC is the only crypto-asset Holyheld supports for its exchange service, and the card is defined as the instrument that enables that sale and the use of the resulting fiat Funds balance (e-money such as EUR or USD, held by the licensed partner). Other tokens can reach a top-up only through third-party smart-contract integrations, which swap them before the USDC sale. The address is Ethereum USDC from the sample top-up; Holyheld's site also names Arbitrum, Base and Solana, where the native USDC of each chain would apply, but the hosted token list was not read.
Checked 2026-10-12
Evidence (3)1 verified · 2 documented
Verified
A sample card top-up moves 3,474.158634 USDC from the payer straight to Holyheld wallet 0x6D2d1659..., through the top-up proxy.
Terms s8.6 name USDC as the only crypto-asset Holyheld supports for its exchange service; other crypto-assets may be used only through third-party smart-contract integrations.
checked 2026-10-12 · source unchanged at weekly re-read 2026-10-19
Documented
The Terms define the Card as the instrument that enables the sale of crypto-assets and the use of the resulting fiat Funds balance through the debit-card infrastructure.
checked 2026-10-12 · source unchanged at weekly re-read 2026-10-19
Censorship Resistance
Who can block valid use, and can users route around them?
0 FailsPillar rating: weakest of 5 0 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.
Settle without the provider reaching Weak: Partial (for example settle but not refund or withdraw), or 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-07
The top-up contract has a pause (setPaused, pauseOperation) and an emergencyTransfer, and the role that controls them (DEFAULT_ADMIN_ROLE, which also administers TRUSTED_PAUSER_ROLE) is held by a single EOA. There is no multisig and no timelock. The implementation is unverified, so the exact scope of each function cannot be read from source; the selectors are present in the deployed bytecode. On the card side, the Terms let Holyheld suspend service and account access.
Evidence (3)2 verified · 1 documented
Verified
hasRole(DEFAULT_ADMIN_ROLE, 0xa1391419CC2fEc5235161d7A6Deb988cB9A1d043) returns true; that address has no code (EOA), is the proxy deployer, and is the admin of TRUSTED_PAUSER_ROLE (getRoleAdmin returns 0x00). The only other RoleGranted event since deployment gives TRUSTED_EXETUTOR_ROLE to EOA 0x4C18D1aF4261DBb9E497E3DD883024e5eb51272b; no RoleRevoked events.
The deployed implementation bytecode contains the selectors for setPaused(bool) 0x16c38b3c, pauseOperation() 0xc9d07020, emergencyTransfer(address,address,uint256) 0x1e84c725 and setCardSettleAddress(address) 0x4b0dea4d, matching the top-up ABI shipped in @holyheld/sdk 4.1.5; paused() reads false.
Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Card payments to merchants settle offchain through the card issuer and network. The only onchain step, the top-up into the card balance, requires a Holyheld backend signature (the signature check is switched on) and a receiver code issued by the Holyheld API. Nobody can settle a card payment by calling the contract directly.
Evidence (2)2 verified
Verified
backendSignatureCheck() (0xc52a188d) returns true, and the latest top-up (tx 0x34972db6...2472a, block 26074697) called CardTopupPermitSigned (0xd88a0d43), which carries a backend signature argument.
Before a top-up the SDK fetches the receiver tag code for the holytag from the Holyheld API (getTagTopUpCode); the contract addresses themselves come from the API at init.
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-07
Every top-up needs the Holyheld API (configuration, quotes, receiver code, backend signature), and the card itself needs the issuer and network. None of it is public, there is no self-host path and no fallback. Closed, single-vendor.
Evidence (2)2 verified
Verified
The SDK hardcodes apicore.holyheld.com, apiassets.holyheld.com and apiview.holyheld.com as its service base URLs; the constructor (src/sdk.ts) passes them to every service with no override option.
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-07
Sanctions, PEP and wallet screening are disclosed in the privacy policy and run in Holyheld's closed backend and its vendors. Whether the settlement contract itself filters cannot be shown, because its implementation is unverified, and the screening cannot be bypassed (C2 = 0). Disclosed in docs only, so 1.
Evidence (2)1 verified · 1 documented
Verified
The top-up implementation is not verified on Sourcify or Etherscan, so whether it filters addresses cannot be read from source.
The privacy policy says Holyheld screens identity data against sanctions and PEP lists and screens blockchain data through third-party wallet and transaction screening providers.
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-07
Supported tokens exist only in a hosted API response, and no document lists them with their issuers' freeze powers. The sample top-up used USDC, whose issuer can blacklist addresses; that is not stated to users. Not enumerated, so 0.
Evidence (2)1 verified · 1 documented
Verified
init() loads the EVM and Solana network configuration (tokens, contract addresses) from the Holyheld API (/v4/external/client/references); no token list is in the repo.
Holyheld's own site text says the list of supported stablecoins and networks keeps changing and names networks (Ethereum, Arbitrum, Base, Solana) but no tokens or issuer freeze powers.
Does the deployed bytecode match public source, and can a third party rebuild it? O1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Only the stock OpenZeppelin proxy and ProxyAdmin are verified. The implementation that holds the top-up logic, roles and pause is unverified everywhere checked, and no contract source is public. Some contracts verified, so 1.
Evidence (2)2 verified
Verified
Sourcify v2 reports exact_match for the proxy (OpenZeppelin TransparentUpgradeableProxy) and for ProxyAdmin 0xaf3d7e4cbB718Ec026d88B330dd68abBbDC6E5C3; the implementation in the EIP-1967 slot, 0x1Fd0FB3F9931a820cE63d6f4caefeA30EE18A94a, has no Sourcify match.
Etherscan shows no verified source for the implementation (the code tab offers "Verify and Publish"), and eth.blockscout.com reports is_verified false.
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The public part is the SDK source, and it cannot even be built from the repo because its core library is private. Contracts, backend, app and indexer are closed. Judgment call: this is a client shell that cannot run without private services (0), rather than "SDK only" (1).
Evidence (2)2 verified
Verified
The SDK builds against @holyheld/web-app-shared 4.3.21, which is not on the public npm registry (npm view returns 404) and supplies every API service and the contract ABIs.
The SDK is a client for three hosted Holyheld APIs; the holyheld org's other repos (erc1271, erc6492, gaelogrus, gointernals, BRRR, a web3-modal wrapper, a yearn-exporter fork) contain no contracts, backend, app or indexer for the card.
Can a stranger reach a working deployment from the README? O3
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
There is nothing to self-host: no contracts, backend or app are public, and the README only explains installing the client SDK. No path, so 0. Reproduction not attempted.
Evidence (1)1 verified
Verified
The README covers npm install and links hosted docs; it has no build, deployment, contract address or backend instructions.
Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-07 12 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-07
No ABI, event schema, API schema or data export is versioned in a repo. The holyheld.com/documentation link in the README returns 404. Judgment call: an ABI embedded in a minified npm bundle is not a documented interface, so 0.
Evidence (1)1 verified
Verified
The repo tree at this commit has no ABI files, event schemas, OpenAPI spec or export code; the top-up ABI exists only inside the compiled npm bundle (dist/index.js of @holyheld/sdk 4.1.5).
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-07
The only public repo is source-available (BUSL-1.1), and the contracts, backend, app, issuer and network are closed. A closed required component cannot be forked, so 0.
Evidence (1)1 verified
Verified
The SDK is Business Source License 1.1 (Licensor Holyheld Labs; additional use grant excludes hosted or embedded use competitive with Holyheld; change to GPL-2.0-or-later after four years).
Can the provider unilaterally relicense future versions, and has it committed not to? F2
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
No CLA and no commitment; the license has not changed since the first commit. That is the anchor for 2. It scores relicensing risk only; the license itself is BUSL (see F1).
Evidence (1)1 verified
Verified
LICENSE has one commit in its history (f2ca8cb, "Initial commit", 2023-10-27); the repo has no CLA, CONTRIBUTING or .github directory and no license-stability statement.
Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The SDK ships no third-party analytics library in its dependencies, but it sends first-party audit telemetry (wallet address, transfer data) to Holyheld on by default. The Holyheld app is closed and the privacy policy discloses cookies and tracking. Present, on by default, disclosed in docs, so 1.
Evidence (2)1 verified · 1 documented
Verified
sendAudit posts event data with the user's wallet address and operation id to the Holyheld audit API; the off-ramp flows call it at each step with no opt-out. Sentry breadcrumbs from the bundled library are routed to the integrator's logger (L99-L107), not to Sentry.
Does the flow collect anything beyond addresses, amounts, token, and chain? P2
1 Weak
Best evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Card use requires full KYC and screening beyond settlement needs. It is disclosed in the privacy policy, not in code or a versioned repo document, so 1.
Evidence (1)1 documented
Documented
The privacy policy lists identity, government ID, sanctions/PEP status, credit-reference and blockchain screening data, collected through KYC partners.
What do calldata and events reveal about who paid whom for what? P3
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-07 12 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Every top-up publishes a per-account receiver code next to the payer's address, so all top-ups to one Holyheld account can be linked onchain, and all top-ups visibly go to a single Holyheld wallet. I found no user-facing disclosure of this. Judgment call: the receiver code is a payee tag; with no disclosure found, this takes the lower anchor (0) rather than 1.
Evidence (1)1 verified
Verified
The sample top-up passes receiver code 0x5bd0f55e...979b1f as the last calldata argument; the CardTopup event (in the SDK bundle ABI) emits the payer account (indexed), token, amounts and _receiverHash, and USDC moves straight from payer 0x9D4BCa30F4De569e66eC01d7bb567F1D592933c0 to Holyheld wallet 0x6D2d1659B23C81Caf9DC59930609217AE65b866a.
Which third parties see a request during a payment, and can they be swapped out? P4
1 Weak
Best evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
KYC vendors, screening vendors and the card issuer and network all see payment or identity data. They are disclosed in the privacy policy (some only by category) and cannot be swapped. Disclosed in docs only, so 1.
Evidence (1)1 documented
Documented
Names Sumsub and Idenfy for identity verification and unnamed wallet and transaction screening providers, credit-reference and anti-fraud agencies.
Can RPC and indexer URLs be changed, and is the indexer code public? P5
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
RPC follows the integrator's wallet client, but the Holyheld API, which serves balances, quotes and configuration, is hardcoded and its code is closed. Hardcoded, so 0.
Evidence (1)1 verified
Verified
API and indexer endpoints (apicore, apiassets, apiview .holyheld.com) are constants with no override; RPC goes through the integrator's own wallet client.
Who holds funds between payer and payee, and can the provider redirect them? S1
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
A top-up sells the user's tokens to Holyheld: they go straight to a Holyheld EOA, and the card balance is fiat at the issuing partner. A single admin EOA can change the settle address. The provider holds the funds and can redirect them, so 0. Judgment call: the sale is disclosed, which alone would fit 1, but the redirect power sets 0.
Evidence (3)2 verified · 1 documented
Verified
The receiver of the sample top-up's USDC (tx 0x34972db6...2472a) has no code, so it is an EOA controlled by Holyheld.
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-07
The observed default is a permit with an expiry for slightly more than the top-up amount. That is a bounded allowance, not exact-amount. The approve fallback's amount is set inside the private library and cannot be checked. Judgment call: 2 (bounded) rather than 3, because the permit exceeds the amount and the fallback is unverifiable.
Evidence (2)2 verified
Verified
The sample top-up of 3,474.158634 USDC carries an EIP-2612 permit for 3,647.866565 USDC (about 5% above the amount) to spender 0x6fC79dDD... with deadline 0x6aba3040; no standing approve transaction was needed.
The SDK picks between permit, Permit2 and approve flows via the private library; the allowance amount comes from that library, so the default for approve-only tokens is not visible in public source.
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-07 12 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Derived: S1 = 0 (funds held by Holyheld, redirectable), C2 = 0 (no direct path), C3 = 0 (closed single-vendor API), O3 = 0 (nothing to self-host). A card balance can be spent or withdrawn only through Holyheld and its partner. Tokens never topped up stay in the user's own wallet, but that is outside the rail.
Evidence (1)1 verified
Verified
Topped-up funds leave the user's wallet for a Holyheld EOA (S1); the card balance exists only at the issuing partner.
Are secrets kept out of client bundles and are webhooks signed and verified? S5
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The SDK is built for the browser and authenticates with a partner API key, so the key ships to the client; no scoping, rotation or webhook verification is documented in the repo. Judgment call: what the key authorises is not documented, so it may be a publishable ID; with no evidence that it is scoped, this takes the lower anchor.
Evidence (1)1 verified
Verified
The reference browser example reads the API key from VITE_HOLYHELD_SDK_API_KEY, which Vite inlines into the client bundle, and passes it to the SDK, which sends it as X-Api-Key on every request.
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
? No evidence
Sets the pillar rating
UnreviewedAssessed by AI research agent (seed), 2026-10-07
No checkable evidence settles this yet, so it counts as 0.
Security audits 0
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.
No published audit report was found.
Compiled from: holyheld.com (the homepage says Holyheld is PCI DSS Level 1 compliant and undergoes "independent security audits yearly"; no report is linked, and PCI DSS is not a code audit), the holyheld GitHub organisation including hh-v1-sdk (no audits/ folder), web searches for Holyheld audits by Hacken, Quantstamp, PeckShield, CertiK and MixBytes, and the Sherlock and Guardian report repositories. Sherlock's repo holds a deprecated 2023 Holyheld coverage agreement but no Holyheld audit report. No audit of the card top-up contract (whose implementation is unverified) is published. 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: 11 evidenced, 0 attested, 9 absent, 0 not applicable, 25 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
1% off-ramp (stablecoin to fiat) and 1% on-ramp transfers
Individual pricing page; Terms clause 13 lets Holyheld change fees at any time with notice on the platform.
cashout
payer
outgoing SEPA 1 EUR, same-day ACH 1 USD, wire 20 USD, FedNow and Faster Payments 0
Individual pricing page.
provider
none
membership CHF 0 a year (individual)
Individual pricing page; membership is by invitation. No card issuance, card FX or ATM fees are published.
network
payer
gas and any swap costs on the top-up transaction
Terms clause 8.10 make the user responsible for fees to complete the transaction; the SDK's gasless options were not assessed.
Card fees (issuance, FX on non-base-currency spend, ATM) are not published on holyheld.com or in the Terms. Business pricing differs: CHF 500 a year, 0.5% ramp fees, wire 10 USD, SEPA 0 EUR. Whether the top-up into the card balance (CROPS S1) carries the 1% off-ramp fee is not stated.
Documented
Holyheld individual pricing page (accounts, transfers and ramp fees).
SRO membership is AML supervision, not a banking, payment or e-money licence. The card and e-money account come from a "licensed payment-instrument issuer" that the Terms, privacy policy, pricing and FAQ pages do not name, so its licence and regulator could not be checked. The pricing page also states PCI DSS Level 1, which is not a licence.
Documented
FINMA SRO member search for "Holyheld" (client-rendered; result read in a browser and archived) lists Holyheld Labs AG, Zug, financial intermediary, SRO VQF.
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
Cash-out options
Evidenced
Where
Method
Partner
Fee
Limits
everywhere offered
card withdrawal
Unnamed licensed card issuer
not published
Card spend at merchants from the fiat balance created by a top-up (the schema has no card-spend value); limits not published.
everywhere offered
bank transfer
Holyheld's e-money partners (personal IBAN)
1% off-ramp; SEPA 1 EUR, ACH 1 USD, wire 20 USD
Not published.
ALL means every country in the availability list (CH only, the scope of the published Terms). ATM withdrawal is not documented. Fees are from the individual pricing page (see fees).
Documented
Terms definition of Card (debit card issued by the partnered payment-instrument issuer).
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
First deployment
Evidenced
2023-03-12 (block 16810662): Card top-up proxy 0x6fC79dDD...3d13 (TransparentUpgradeableProxy) on Ethereum
Read on an archive-capable public RPC (eth.drpc.org) because ethereum-rpc.publicnode.com refuses historical state without a token.
Verified
eth_getCode for the proxy returns 0x at block 16810661 and the proxy bytecode at 16810662 (2023-03-12 08:09:47 UTC); creation tx 0x05a9db2b...0e10 from deployer EOA 0xa1391419CC2fEc5235161d7A6Deb988cB9A1d043, which emits the first Upgraded event.
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
Security incidents
Unknown
Absence of a found incident is not evidence that none occurred.
No incident notice, status page or post-mortem was found on holyheld.com (sitemap including guides and case studies, legal pages, FAQ) or in the hh-v1-sdk repository.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
2023-08-18: Top-up proxy implementation upgraded to 0x177ad381...760d (block 17940103). source
2023-11-16: Top-up proxy implementation upgraded to 0x4ba2c617...e3a9 (block 18582243). source
2024-07-11: Top-up proxy implementation upgraded to 0xef84faa1...0972 (block 20281063). source
2025-09-16: Top-up proxy implementation upgraded to 0xa7dd4d0a...daab (block 23373807). source
2026-04-02: Top-up proxy implementation upgraded to the current, unverified 0x1Fd0FB3F...A94a (block 24794076). source
2026-07-01: Terms and Conditions and Privacy Policy updated (last update 01.07.2026). source
Verified
The proxy has emitted seven Upgraded(address) events (topic 0xbc7cd75a...2d3b), one at deployment (block 16810662) and six later upgrades listed here; upgrades go through ProxyAdmin 0xaf3d7e4c... whose owner is EOA 0xa1391419... (CROPS research log).
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
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
Top-ups into the card balance are logged as CardTopup events on the listed Ethereum proxy, so they can be separated from ordinary transfers. This counts value moved into card balances, not card spend. Not yet 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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
Holyheld's homepage says it is PCI DSS Level 1 compliant and undergoes independent security audits yearly. That is a card-data standard, not a SOC 2 or ISAE report, and no report or attestation of compliance is offered.
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?
Unknown
No audit or independent code review of the top-up contract or the backend was found (CROPS S6 unknown); the deployed implementation is unverified.
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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 1 repo(s): holyheld/hh-v1-sdk ✗ no security policy file source 1
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 first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?
Absent
none of 1 repo(s): holyheld/hh-v1-sdk ✗ no scanning config or workflow step found source 1
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)?
Evidenced
Holyheld will notify the Swiss FDPIC and, where required, affected users of a data security breach where legally required; no notification time is stated. source 1
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?
Unknown
No public status page or post-mortem was found on holyheld.com (sitemap, legal pages, FAQ).
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?
Evidenced
Authenticator-app MFA protects all accounts and sensitive actions. source 1
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
Evidenced
The SDK authenticates integrators with a Holyheld API key; the reference browser example ships it client-side (CROPS S5). Scoping and rotation are not documented. CROPS S5
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B5.4 Export controls If an API exports data, does it limit volumes and log exports?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?
Evidenced
Personal data is kept while the account exists and then deleted or de-identified once no longer needed, subject to legal retention of transaction and account records; no period is stated (see CROPS P2 for what is collected). source 1 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?
Evidenced
Holyheld Labs AG is the controller under the Swiss FADP; ID verification partners Sumsub and Idenfy supply verification data. The card issuer's role is not stated. DPIA availability not found. source 1
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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 1 repo(s): holyheld/hh-v1-sdk ✗ no deployment configuration source 1
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 1 repo(s): holyheld/hh-v1-sdk ✗ no branch rules visible (classic branch protection is not readable without push access) source 1
B9.2 CI runs on pull requests Does every pull request trigger automated checks?
Absent
none of 1 repo(s): holyheld/hh-v1-sdk ✗ no .github/workflows source 1
B9.3 Tests run in CI Do the CI workflows run the test suite?
Absent
none of 1 repo(s): holyheld/hh-v1-sdk ✗ test command in a workflow source 1
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
all of 1 repo(s): holyheld/hh-v1-sdk ✓ latest tags: 4.1.5, 4.1.4, 4.1.3 source 1
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?
Absent
none of 1 repo(s): holyheld/hh-v1-sdk ✗ 4 of 10 recent commits signed source 1
B9.7 Changelog Is a changelog maintained with the code?
Evidenced
all of 1 repo(s): holyheld/hh-v1-sdk ✓ CHANGELOG file source 1
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?
Absent
none of 1 repo(s): holyheld/hh-v1-sdk ✗ none found source 1
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?
Evidenced
Holyheld Labs AG, Zug, Switzerland (CHE-207.939.735) for the platform; the card and e-money account are contracts with an issuer partner the Terms do not name. 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
Customer fees. Individual membership is CHF 0 a year with 1% on-ramp and off-ramp fees and per-transfer fees; business membership is CHF 500 a year with 0.5% ramp fees. source 1 · source 2
B11.3 Termination terms What happens to customer funds and data on termination by either side?
Evidenced
Holyheld may suspend, terminate or deactivate an account, including partner card services, at any time without notice, justification or liability. A user may close the account, including after a terms change within the 60-day notice period. Treatment of remaining balances is not stated. source 1 · source 2
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)?
Evidenced
Automated fraud monitoring is listed as a feature; whether it uses AI and whether it can decline payments is not stated. source 1
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
Eligibility: the public SDK repo holyheld/hh-v1-sdk (BUSL-1.1) and the Sourcify-verified top-up proxy on Ethereum make this a card provider, not an incumbent, although the logic contract is unverified. The top-up proxy address is not in the SDK source (it comes from the API at init); it was found by searching the CardTopup event topic 0x9ceec115... on eth.blockscout.com. Onchain reads pinned to Ethereum block 26139997 (backendSignatureCheck at 26140011). Holyheld now markets itself as an invitation-only membership for accounts and payments; the Terms still define the card. The README's documentation link (holyheld.com/documentation) returns 404.
