Payment Rails CROPS Dashboard
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.

Gnosis Pay

cardGnosis ChainG Assessed on Gnosis Chain (chain 100)gnosispay.com

Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: Gnosis Chain is the only chain the web app supports (gnosispay/ui src/wagmi.ts#L23 at 7fc844b: chains [gnosis]) and the Terms define the Safe as deployed to Gnosis Chain. Unit: the post-June-2026 account architecture pinned in account-kit 5.1.1 (9366073, src/deployments.ts#L56-L67) and a live account found from a Spend event at block 48629267. Excluded: pre-incident Safes and mastercopies, and the partner card programs that replace the consumer card after 20 Dec 2026.

At a glance

Category
Cards
Chain
Gnosis ChainGGnosis Chain
CROPS tally
10 of 23 hold up
Settles in
EURe, GBPe, USDC.e
Security audits
19 published
Offered
37 countries
Last edited
2026-10-13 · History
  1. Censorship Resistance0 FailsWeakest: Admin pause or freeze powers; Settle without the provider; Reliance on hosted services
  2. Open1 WeakWeakest: Can be self-hosted
  3. Free0 FailsWeakest: Open-source licences; Protection against relicensing; No proprietary dependencies
  4. Privacy1 WeakWeakest: Tracking and analytics; Data collected beyond payment; Third parties in the payment flow
  5. Security1 WeakWeakest: Who holds funds in transit; Audits and bug bounty

Where it is offered

Offered only in the countries listed. Regions: EEA. Checked 2026-10-09. Not scored.

The Terms (Eligibility) require residence in the EEA or in a "Non-EEA Supported Country" listed in the Eligible Countries FAQ. That FAQ lists all 30 EEA states plus Argentina, Bolivia, Brazil, Colombia, Mexico, Switzerland and the United Kingdom. Residents of French overseas territories are not served. Product variants: EEA residents contract with Gnosis P. Tech (Portugal) and Monavate's EEA entity, everyone else with Gnosis Pay Co Ltd and Monavate Limited (UK); the supported stablecoin is GBPe in the UK, EURe in the EEA and Switzerland, and USDCe elsewhere. The same FAQ also says the card does not work for transactions made from 22 sanctioned or high-risk locations, including Crimea (a region of Ukraine), Russia, Belarus, Iran, North Korea, Venezuela and Zimbabwe. The Terms also exclude sanctioned persons and residents of countries sanctioned by the US, UN, UK or EU. The consumer card and web app close at 23:59 UTC on 20 December 2026 (closure notice of 21 September 2026); partner programmes set their own eligibility rules.

Listed countries (7): Argentina, Bolivia, Brazil, Switzerland, Colombia, United Kingdom, Mexico

Evidence (3)3 documented
  1. Documented

    Eligible Countries for Gnosis Pay (help centre, linked from Terms section 2) lists 37 supported countries of residency and 22 locations where card use is prohibited.

    help.gnosispay.com/articles/1662387556

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    Terms of Service section 2 (Eligibility) require residence in the EEA or a Non-EEA Supported Country listed in the Eligible Countries FAQ, and exclude residents of countries sanctioned by the US, UN, UK or EU.

    help.gnosispay.com/articles/2178874711

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  3. Documented

    Closure notice dated 21 September 2026; the card and web app stop at 23:59 UTC on 20 December 2026, and partner card programmes will have their own eligibility rules.

    help.gnosispay.com/articles/1452055581-formal-notice-closure-of-the-gnosis-pay-web-app-and-card-21-september-2026

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Settlement token

What the balance is held in and debited from. Shown as context; it does not change any rating.

TokenClassIssuerContract
EURe Defaultfiat-backed stablecoinMonerium0xcB44…C56E explorer · Sourcify
GBPefiat-backed stablecoinMonerium0x5Cb9…7108 explorer · Sourcify
USDC.efiat-backed stablecoinCircle (bridged from Ethereum to Gnosis Chain)0x2a22…76F0 explorer · Sourcify

Conversion. The token is sold for fiat when a payment is authorised.

One token per region, not a user choice: the Terms define Supported Funds as GBPe for UK users, EURe for users in Switzerland or the EEA, and USDC.e (Circle USDC bridged to Gnosis Chain) for other supported countries, all on Gnosis Chain. EURe is marked default as the EEA variant. Each card spend moves the token from the user's Safe to Gnosis Pay's settlement Safe at authorisation (sample spend in S1), and Gnosis Pay settles the card network in fiat; the fees page describes this as 1:1 stablecoin usage. The UI's EURe entry also lists the Monerium v2 contract 0x420CA0f9... as a jumper address; the address above is the one the card's Roles scope transfers. The consumer card closes on 20 December 2026.

Checked 2026-10-12

Evidence (3)1 verified · 2 documented
  1. Verified

    The card UI enumerates the three card currencies by address on Gnosis Chain - EURe 0xcB444e90... (jumper 0x420CA0f9...), GBPe 0x5Cb90739..., USDCe 0x2a22f9c3....

    gnosispay/ui · src/constants/currencies.ts

    commit 7fc844b4bb · checked 2026-10-12 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    Terms of Service definitions set the Supported Funds per region (GBPe in the UK, EURe in Switzerland and the EEA, USDCe elsewhere), each only on Gnosis Chain, and define USDCe as Circle USDC bridged to Gnosis Chain at 0x2a22f9c3....

    help.gnosispay.com/articles/2178874711

    checked 2026-10-12 · source unchanged at weekly re-read 2026-10-19

  3. Documented

    The fees page says card purchases debit the stablecoin 1:1 with the purchase amount.

    help.gnosispay.com/articles/6104401027

    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
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.
  • Settle without the provider reaching Weak: Partial (for example settle but not refund or withdraw), or documented only.
  • Reliance on hosted services reaching Weak: Intermediaries required, only documented, no public code.

Admin pause or freeze powers

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

Funds at rest cannot be frozen: the account Safe has no guard, its only modules are the user's Delay and Roles modifiers, and Gnosis Pay holds no key over them. Card settlement is different. Every card spend is Spender.spend(), which only an enabled delegate can call, and the one delegate is EOA 0x9c48bc73... A single EOA can stop or selectively withhold settlement, which meets anchor 0 on its own. The delegate list is controlled by spender Safe 0x896a695d... It is 2-of-3, its three EOA signers are not named in any document I found, it has no guard, and there is no timelock (the documented user exit is 3 minutes). It misses every anchor-2 condition. Module check (red team R7): the spender Safe's only module is the spender modifier itself (avatar = target = owner = the Safe). Through it, one delegate key can make the Safe call execTransactionWithRole on any account it names. The inner payload is fixed to token.transfer(receiver, amount), the modifier's generic exec functions are emptied, and changing delegates, owners or settings still needs 2 signatures. On user accounts the payload is limited by each account's Roles scope, read from the setup events (see S1): one token, receiver = settlement Safe 0x4822521E..., amount within the daily allowance. So the module does bypass the 2-of-3 threshold, but only to pull up to each account's remaining allowance into Gnosis Pay's settlement Safe. Separately, the Terms let Gnosis Pay block an individual card on Monavate's instruction. The EOA-held delegate (verified) and the card-block power (documented) each meet anchor 0.

Evidence (10)8 verified · 2 documented
  1. Verified

    Account setup swaps the Safe owner to 0x...02, enables only the Roles and Delay modifiers, and hands Roles ownership to a Bouncer; no pause, freeze or blacklist function is configured anywhere in the account.

    gnosispay/account-kit · src/entrypoints/accounts-actions/accountSetup.ts

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Spender modifier owner() is the Gnosis Pay spender Safe 0x896a695d5cCDd21F9e3Bb18307a558befCCb8428 (2-of-3 EOAs, no timelock), which can enable or disable the delegate keys that execute every card spend; its only enabled delegate is EOA 0x9c48bc73841FD98456cB52f8A28580266d74d4df.

    0x5f07…3F8a on gnosisscan.io

    0x5f07…3F8a explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    Spender Safe getThreshold() = 2 with owners 0x2FD460fD9aE6d71ee3231DfB827B85FCeC31Fa4f, 0x09Ab2E7F1E40D2Becc7da265f147aA7aaDd3d141, 0x9F7dfAb2222A473284205cdDF08a677726d786A0 (all EOAs, no code at block 48629765); I found no document naming who holds these keys.

    0x896a…8428 on gnosisscan.io

    0x896a…8428 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Verified

    Spender Safe getModulesPaginated(0x1,10) returns exactly one module, 0x5f07734E2B9C4dE6f9C32253d485741800da3F8a (the spender modifier, whose avatar(), target() and owner() are all this Safe); isModuleEnabled(0x5f07...) = true.

    0x896a…8428 on gnosisscan.io

    0x896a…8428 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  5. Verified

    Spender Safe guard slot 0x4a204f62...c34c8 is zero (no transaction guard); fallback handler slot holds the Safe 1.3.0 CompatibilityFallbackHandler 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4. No timelock contract sits between the Safe and the spender modifier.

    0x896a…8428 on gnosisscan.io

    0x896a…8428 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  6. Verified

    Spender modifier getModulesPaginated(0x1,10) returns one delegate, 0x9c48bc73841FD98456cB52f8A28580266d74d4df; isModuleEnabled(0x9c48...) = true. Any one enabled delegate can call spend() with no Safe signature.

    0x5f07…3F8a on gnosisscan.io

    0x5f07…3F8a explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  7. Verified

    The spend delegate 0x9c48bc73... has no code and nonce 0 at block 48629765, so it is a single EOA key that signs offchain; spends are submitted by relayer EOA 0x90830Ed558f12D826370DC52E9D87947A7F18De9.

    0x9c48…d4df on gnosisscan.io

    0x9c48…d4df explorer · Sourcify · block 48629765 · checked 2026-10-07

  8. Verified

    setUp sets avatar = target = owner; execTransactionFromModule and execTransactionFromModuleReturnData are overridden with empty bodies; spend() (moduleOnly) makes the target Safe call account.execTransactionWithRole(asset, 0, transfer(receiver, amount), Call, roleKey, true), with account, receiver, amount and roleKey chosen by the delegate.

    gnosispay/account-kit · contracts/Spender.sol

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  9. Documented

    Terms of Service say that if Monavate tells Gnosis Pay not to fund a card transaction from the Safe, or to block the card, Gnosis Pay will act on it without liability; elsewhere they let Gnosis Pay suspend services or account access with or without notice.

    help.gnosispay.com/articles/2178874711

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  10. Documented

    Terms of Service document the user exit delay as 3 minutes on non-card transactions from the Safe (the Delay modifier cooldown, 180 s onchain).

    help.gnosispay.com/articles/2178874711

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Settle without the provider

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

A merchant (payee) is paid through Visa and the issuer offchain; onchain, the only settlement step is a spend() that requires a Gnosis Pay delegate signature and is relayed by a Gnosis Pay relayer. Neither payer nor payee can complete a card payment by calling the contracts directly. The user's own withdrawal path is direct (see S4), but that is exit, not settlement.

Evidence (2)2 verified
  1. Verified

    spend(asset, account, receiver, amount, roleKey) is moduleOnly, so only a delegate enabled by the Gnosis Pay spender Safe can move funds to the settlement receiver; source is identical to the Sourcify exact match for mastercopy 0x7a592baE57b8cd45688F9Eb81ce4A622E7E37cB7.

    gnosispay/account-kit · contracts/Spender.sol

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Sample card spend tx 0xf99c9e1c...a300cb was submitted by relayer EOA 0x90830Ed558f12D826370DC52E9D87947A7F18De9 to the spender modifier (selector 0x8a320255) and moved EURe from account Roles modifier 0xd69693CA... to settlement Safe 0x4822521E....

    0x5f07…3F8a on gnosisscan.io

    0x5f07…3F8a explorer · Sourcify · block 48629267 · checked 2026-10-07

Reliance on hosted services

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

The card flow requires Gnosis Pay's closed backend (authorisation, spend delegate, relayer) plus the issuer Monavate and Visa. None of it is public or has a fallback. Single-vendor and closed for the payment path.

Evidence (3)2 verified · 1 documented
  1. Verified

    The frontend defaults its API client to api.gnosispay.com (overridable by VITE_GNOSIS_PAY_API_BASE_URL); no public implementation of that API exists in any gnosispay repo.

    gnosispay/ui · src/main.tsx

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    The Spend section requires a signature from the spend delegate configured in the Gnosis Pay Spender Safe and a relayer to submit it.

    gnosispay/account-kit · README.md

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Documented

    Closure notice names Monavate (EMI) as card issuer and Gnosis Pay as program manager and card management platform; the card stops working at 23:59 UTC on 20 December 2026.

    help.gnosispay.com/articles/1452055581-formal-notice-closure-of-the-gnosis-pay-web-app-and-card-21-september-2026

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Neutral settlement, disclosed filtering

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

Re-assessed against the revised anchor. The settlement contracts are neutral: Spender.spend() and the Roles scope contain no address list or geographic check. Edge filtering exists. The Terms exclude people on UN, EU, US or UK sanctions lists and residents of sanctioned countries, and forbid VPNs used to get around this; screening runs in Sumsub and the closed backend. That disclosure is in the hosted Terms only. Neither the frontend code nor the versioned docs repo describes the screening or names its list source. The card path has no direct route (C2 = 0), so the filtering cannot be bypassed. Anchor 1 ("edge filtering is disclosed in docs only") fits. A 2 would need disclosure in code or a repo document, and a 3 would also need a bypass and public required components. Note: which spends are executed is decided offchain by the delegate key (see C1), so the contracts are neutral but the settlement step as a whole is not.

Evidence (5)4 verified · 1 documented
  1. Verified

    The KYC route hands the user to a Sumsub integration URL fetched from the Gnosis Pay API; eligibility screening runs in the closed backend. A search of src/ for sanctions lists, IP geolocation or address blocklists found none.

    gnosispay/ui · src/pages/Kyc.tsx

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    SUPPORTED_COUNTRIES lists 32 EEA/UK/CH country codes; it is defined but not referenced elsewhere in src/ at this commit (shipping uses SUPPORTED_SHIPPING_COUNTRIES at L1615-L1634).

    gnosispay/ui · src/constants.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    spend() has no address list, country or screening check; the only onchain conditions on a card spend are the per-account Roles scope (token, receiver = settlement Safe, amount within allowance), read from the Roles setup events cited under S1.

    gnosispay/account-kit · contracts/Spender.sol

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Verified

    The versioned docs repo describes the Sumsub KYC step for card orders but says nothing about sanctions or country screening or its list source; a grep of the repo for sanction, countries, geolocation and blocked found no screening disclosure.

    gnosispay/docs · onboarding-flow.mdx

    commit b0b8c668d0 · checked 2026-10-07

  5. Documented

    Terms of Service eligibility excludes persons on UN, EU, US or UK sanctions lists and residents of sanctioned countries, and forbids VPNs or mixers to circumvent restrictions.

    help.gnosispay.com/articles/2178874711

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Token and chain freeze risks disclosed

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-07

Tokens and chain are enumerated in code. Each one carries an issuer freeze: Monerium's blacklist validator can ban addresses for EURe and GBPe, and the bridged USDC contract has a blacklister and pauser. Neither the Terms nor the docs tell cardholders about these powers. Gnosis Chain is an L1 with no sequencer, which is also not stated. Enumerated in code, assumptions not stated, so 2.

Evidence (4)3 verified · 1 documented
  1. Verified

    Supported tokens enumerated in code - EURe 0xcB444e90D8198415266c6a2724b7900fb12FC56E (v2 0x420CA0f9...), GBPe 0x5Cb9073902F2035222B9749F8fB0c9BFe5527108, USDC.e 0x2a22f9c3b484c3629090FeED35F17Ff8F88f76F0, all on Gnosis Chain.

    gnosispay/ui · src/constants/currencies.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Monerium EURe v2 validator() = 0xfE74A522768547be33A3ad40B999381d57f238A0, a BlacklistValidatorUpgradeable proxy (Sourcify exact match on impl 0x614fcc5b...) exposing ban/unban; EURe owner() is Monerium Safe 0x8001EA269cb9715Bf7acFf89c664ffC134A519ec (3-of-6), UUPS-upgradeable; GBPe v2 0x8E34bfEC... uses the same validator.

    0x420C…3430 on gnosisscan.io

    0x420C…3430 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    Bridged USDC (Gnosis) blacklister(), pauser() and owner() all return 0x458cd345B4C05e8DF39d0A07220feb4Ec19F5e6f (a Safe, threshold 3).

    0x2a22…76F0 on gnosisscan.io

    0x2a22…76F0 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Documented

    Terms define EURe and GBPe as Monerium e-money tokens and USDCe as Circle USDC bridged to Gnosis Chain, but say nothing about issuer freeze, ban or burn powers.

    help.gnosispay.com/articles/2178874711

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Open

Is the whole stack visible?

1 WeakPillar rating: weakest of 4
3 of 4 Partial or better

What would raise this pillar

  • Can be self-hosted reaching Partial: Reproducible with minor undocumented steps, recorded.

Contracts verified onchain

Does the deployed bytecode match public source, and can a third party rebuild it? O1

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-07

Every mastercopy that holds logic is verified on Sourcify, five of six as exact matches; Roles is a partial match. The minimal-proxy instances delegate to those verified mastercopies. Spender.sol and Bouncer.sol at the pinned commit are byte-identical to the Sourcify sources (apart from a trailing newline). There is no documented script that rebuilds the deployed bytecode from a pinned commit, and Roles is partial, so 2.

Evidence (3)3 verified
  1. Verified

    Sourcify v2 reports exact_match for the Spender (0x7a592b...), Delay (0x22d903...), Safe 1.3.0 (0xd9Db27...), ModuleProxyFactory (0x0000...a236) and Bouncer (0x4d5803...); Roles mastercopy 0x732B9E... is match (partial, not exact).

    0x7a59…7cB7 on repo.sourcify.dev

    0x7a59…7cB7 explorer · Sourcify · block 48629765 · checked 2026-10-07

  2. Verified

    Per-account Roles, Delay and Spender instances are EIP-1167 minimal proxies (runtime code 0x363d3d37...5af43d82803e903d91602b57fd5bf3 pointing at the mastercopies) and are not themselves on Sourcify; the spender and settlement Safes are not on Sourcify either.

    0xd696…bA29 on gnosisscan.io

    0xd696…bA29 explorer · Sourcify · block 48629765 · checked 2026-10-07

  3. Verified

    SDK pins the Delay, Roles and Spender mastercopy addresses checked above.

    gnosispay/account-kit · src/deployments.ts

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Whole stack published

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-07

Public: SDK, contracts, the full web app frontend (with Dockerfile and deploy workflows), a PSE demo backend, and docs. Closed: the Gnosis Pay API, card-transaction indexer, delay relay and spend service. The API schema is published (hosted OpenAPI plus a committed generated client). This is "everything except the backend, with the API schema published".

Evidence (2)2 verified
  1. Verified

    The frontend generates its API client from the published OpenAPI spec at https://api.gnosispay.com/api-docs/spec.json; the generated client is committed under src/client.

    gnosispay/ui · package.json

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    SDK and Gnosis Pay contracts (Spender, Bouncer) are public; the gnosispay org lists account-kit, ui, docs, pse-react-native and siwe-demo-app, and no backend, indexer, relayer or spender-service repository.

    gnosispay/account-kit · contracts

    commit 9366073768 · checked 2026-10-07

Can be self-hosted

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-07

Re-assessed against the revised anchor: a 3 needs a recorded attempt or a deploy script with a recorded successful test payment, and a 2 needs a recorded reproduction. Build docs exist for the frontend and SDK. Reproduction not attempted. Known blockers from the README alone: a working deployment needs a Gnosis Pay-issued PSE app id and the hosted Gnosis Pay API. No deploy script in any gnosispay repo completes a test card payment, and one could not, because the spend delegate, relayer, issuer and network are closed. Stays 1.

Evidence (1)1 verified
  1. Verified

    README lists env vars (PSE relay route, PSE app id from Gnosis Pay partner registration, API base URL, RPC URL) and build commands; contract addresses live in account-kit src/deployments.ts.

    gnosispay/ui · README.md

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Interfaces and data export

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-07

ABIs, event definitions and an API schema (generated from OpenAPI) are in repos. The only export is a cardholder-side CSV of card transactions; there is no payee (merchant) export, because merchants are paid through Visa. Judgment call: the payee-export requirement is not met, so 2.

Evidence (3)3 verified
  1. Verified

    ABIs for spender, delay, roles and moduleProxyFactory are committed under scripts/abi, including the Spend event definition.

    gnosispay/account-kit · scripts/abi/spender.json

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Types generated from the Gnosis Pay OpenAPI spec by @hey-api/openapi-ts (header at L1, baseUrl api.gnosispay.com at L4) are versioned in the frontend repo (4626 lines).

    gnosispay/ui · src/client/types.gen.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    The cardholder can export card transactions as CSV.

    gnosispay/ui · src/utils/csvDownloadUtils.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Free

Does the license actually let a third party fork, modify, and run it?

0 FailsPillar rating: weakest of 3
0 of 3 Partial or better

What would raise this pillar

Open-source licences

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

Contracts, SDK and frontend all carry OSI licences (Apache-2.0, MIT, LGPL-3.0). Two non-critical repos, docs and pse-react-native, have none. F1 is now scored against the component inventory, not only the listed repos. A card payment cannot complete without closed, proprietary components: the Gnosis Pay API and authorisation backend, the spend delegate signer, the relayer, Monavate, Visa and Sumsub. A closed required component cannot be forked, so F1 is 0. On the public repos alone this would have been 2.

Evidence (4)4 verified
  1. Verified

    account-kit is Apache License 2.0.

    gnosispay/account-kit · LICENSE

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    ui is MIT (Copyright 2025 Gnosis Pay).

    gnosispay/ui · LICENSE

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    zodiac-modifier-delay is LGPL-3.0; zodiac-modifier-roles (820e5bc9) and safe-smart-account (f8fc2f2e) are also LGPL-3.0.

    gnosisguild/zodiac-modifier-delay · LICENSE

    commit 221382ead4 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Verified

    The docs repo tree at this commit (47 files) has no LICENSE file and the Readme names none; pse-react-native at 9446024d has no LICENSE either.

    gnosispay/docs · Readme.md

    commit b0b8c668d0 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-12

Protection against relicensing

Can the provider unilaterally relicense future versions, and has it committed not to? F2

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-07

Gnosis Pay's own repos have no CLA and no commitment (that alone would be 2). The Delay and Roles modifiers that gate every account are maintained under a Gnosis CLA that permits relicensing, and there is no license-stability commitment. Judgment call: I could not establish whether Gnosis Pay counts as a Gnosis affiliate under that CLA, so I took the lower anchor (0). Deployed mastercopies are immutable, so the risk applies to future versions only.

Evidence (2)2 verified
  1. Verified

    CLA Assistant enforces the Gnosis CLA (github.com/gnosis/CLA), which grants Gnosis a perpetual, sublicensable copyright license to contributions; zodiac-modifier-roles and zodiac carry the same workflow.

    gnosisguild/zodiac-modifier-delay · .github/workflows/cla.yml

    commit 221382ead4 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    account-kit and ui have no CLA, CONTRIBUTING or license-stability statement; account-kit had no LICENSE until commit c3ca5372 (2025-10-16, Apache-2.0).

    gnosispay/account-kit · README.md

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

No proprietary dependencies

Does a production deployment need a proprietary plugin or hosted-only service? F3

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-07

The core product, card payments, cannot run without Gnosis Pay's proprietary backend and partner credentials, and without the issuer (Monavate) and Visa. The onchain account works on its own for holding and withdrawing, but not as a payment rail.

Evidence (2)2 verified
  1. Verified

    Running the frontend needs a PSE app id obtained by registering as a Gnosis Pay partner and the Gnosis Pay API (prod by default).

    gnosispay/ui · README.md

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Card spends need the delegate configured in the Gnosis Pay Spender Safe.

    gnosispay/account-kit · README.md

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Privacy

What can an observer learn, and did the user knowingly choose it?

1 WeakPillar rating: weakest of 5
2 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.
  • Third parties in the payment flow reaching Partial: Third parties present, named in code, swappable by config.

Tracking and analytics

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-07

A third-party support widget (Pylon) is on by default in the web app and receives identity plus the Safe address; the privacy policy discloses analytics (Google) and support partners. No analytics or error-reporting SDK appears in the frontend manifest. No trace was run, so what the Pylon script collects at runtime is unconfirmed. Judgment call: Pylon is a support SDK, not analytics, but it is a third-party script loaded on every page; treated as present, on by default and disclosed generically, so 1.

Evidence (3)2 verified · 1 documented
  1. Verified

    The Pylon chat widget script from widget.usepylon.com is injected on every page load with no opt-in.

    gnosispay/ui · index.html

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Once identified, the app passes the user's email, name and Safe address to Pylon. package.json has no Sentry, PostHog, Mixpanel, Amplitude or GA dependency.

    gnosispay/ui · src/hooks/usePylonIdentity.tsx

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Documented

    Privacy and Cookies Policy discloses Google analytics and advertising cookies on its Platforms, and support partners who receive account data.

    help.gnosispay.com/articles/7638555831

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Data collected beyond payment

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-07

Re-assessed against the revised anchor. Full KYC is required for the regulated card: identity documents, a biometric photo, source of wealth and expected spending, collected through Sumsub. The privacy policy discloses each category and gives a legal basis for each purpose: the contract, a legitimate interest in enabling the regulated partner's KYC and AML checks, and explicit consent for biometrics. The partner docs repo and the frontend show the KYC step. Anchor 2 now credits legally required collection disclosed with its legal basis, but only when that disclosure is in code or a versioned repo document. Here the legal basis appears only in the hosted policy, so the documented cap of 1 applies. Judgment call: the policy also covers processing beyond the KYC and AML requirement, namely marketing data, analytics and advertising cookies, and legitimate-interest use of transaction and device data to improve and market the product. The cookie and marketing items are consent-based. I read the whole as collection disclosed in a policy (1) rather than undisclosed or beyond-requirement collection (0). A stricter reading of the legitimate-interest uses would give 0.

Evidence (4)2 verified · 2 documented
  1. Verified

    Onboarding requires completing Sumsub KYC before the card flow; the reason (regulated card) is visible in the flow.

    gnosispay/ui · src/pages/Kyc.tsx

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    The versioned partner docs describe the mandatory Sumsub KYC step before a card order, but state no legal basis for it and do not limit the fields collected.

    gnosispay/docs · onboarding-flow.mdx

    commit b0b8c668d0 · checked 2026-10-07

  3. Documented

    Policy lists name, nationality, home address, IP address, date and place of birth, ID and proof-of-address documents, biometric data, source of wealth, expected card spending and signing-wallet addresses; Sumsub is the named KYC provider. It states a legal basis per purpose, including explicit consent for biometrics.

    help.gnosispay.com/articles/7638555831

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Documented

    KYC and transaction records are kept 5 years after account closure.

    help.gnosispay.com/articles/7752555767-what-happens-to-your-data

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Payments linkable onchain

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-07

No merchant or order data goes onchain. Every card purchase is still a public transfer from one long-lived Safe to one well-known settlement address, so anyone can read a cardholder's spending amounts and timing and identify the Safe as a Gnosis Pay card. There are no fresh addresses or privacy patterns. This is minimal linkage that is documented, so 2.

Evidence (3)2 verified · 1 documented
  1. Verified

    The Spend event emits asset, account (the user's Roles modifier), receiver and amount; there is no merchant, MCC or invoice field.

    gnosispay/account-kit · contracts/Spender.sol

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Sample spend shows an EURe Transfer from the user's Safe 0xE27aa566... to the fixed settlement Safe 0x4822521E... (5 EURe) plus the Spend event.

    0x5f07…3F8a on gnosisscan.io

    0x5f07…3F8a explorer · Sourcify · block 48629267 · checked 2026-10-07

  3. Documented

    Help article says onchain transactions stay visible on Gnosis Chain and show fund movement but not merchant names or card-level detail.

    help.gnosispay.com/articles/7752555767-what-happens-to-your-data

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Third parties in the payment flow

Which third parties see a request during a payment, and can they be swapped out? P4

1 Weak

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-07

A card payment is seen by Visa, Monavate and Gnosis Pay's backend, which are disclosed in docs and not swappable. In the web app, WalletConnect and Pylon are named in code but hardcoded; only the RPC and API base URL are configurable. No trace was run. Third parties are present and disclosed but not swappable by config, so 1.

Evidence (4)2 verified · 2 documented
  1. Verified

    WalletConnect projectId is hardcoded via RainbowKit; RPC transport is configurable.

    gnosispay/ui · src/wagmi.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    The Pylon widget URL and app id are hardcoded, with no config switch.

    gnosispay/ui · index.html

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Documented

    Policy names Sumsub (KYC), Google (analytics/ads), and card, distribution and support partners.

    help.gnosispay.com/articles/7638555831

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Documented

    Legal page states the card is issued by Monavate pursuant to licence by VISA Europe Limited.

    help.gnosispay.com/articles/6763083779-legal-documents-and-fees

    checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Endpoints can be changed

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-07

The RPC and API endpoints are configurable through build-time env only, not in the UI. Onchain history uses the configured RPC directly. The card-transaction indexer is closed, so 2.

Evidence (2)2 verified
  1. Verified

    RPC URL comes from VITE_GNOSIS_RPC_URL (env only); onchain transfer history is read by getLogs over that same RPC (src/utils/fetchErc20Transfers.ts).

    gnosispay/ui · src/wagmi.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    The API (card-transaction data source) base URL is env-configurable via VITE_GNOSIS_PAY_API_BASE_URL, but its implementation is not public.

    gnosispay/ui · src/main.tsx

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Security

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

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-07

At rest, funds sit in the user's own Safe and Gnosis Pay cannot redirect them. The Roles setup events (now read onchain, not only from SDK code) show that the only role member is the spender Safe. Its only permission is EURe.transfer to settlement Safe 0x4822521E..., within the daily allowance, with no delegatecall. Only the user's Safe can change that allowance, through the Bouncer. When a card payment happens, funds move into the Gnosis Pay-held 2-of-10 settlement Safe and reach the merchant offchain through Monavate and Visa. A provider-held wallet disclosed in code scores 1. Module check (red team R7): one delegate EOA can call spend() through the spender Safe's module without the 2-of-3 threshold. Nothing onchain ties a pull to a card authorisation, so a single compromised or misused delegate key could move up to each account's remaining daily allowance into the settlement Safe. Judgment call: the destination is fixed to the disclosed settlement Safe and the amount is capped, so I read this as provider custody in flight (1), not as the provider being able to redirect funds (0).

Evidence (5)5 verified
  1. Verified

    Sample account Safe has threshold 1 with sole owner 0x...02 (unusable sentinel), and only the Delay 0x91Def2b0... and Roles 0xd69693CA... modifiers are enabled.

    0xE27a…8cD8 on repo.sourcify.dev

    0xE27a…8cD8 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Settlement receiver is a Gnosis Pay Safe (proxy to Safe L2 1.3.0) with getThreshold() = 2 and 10 owners.

    0x4822…72EE on gnosisscan.io

    0x4822…72EE explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    The spending role is scoped to token.transfer with recipient EqualTo the configured receiver and amount WithinAllowance; Roles ownership then passes to a Bouncer that only forwards setAllowance from the Safe.

    gnosispay/account-kit · src/entrypoints/accounts-actions/accountSetup.ts

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Verified

    GNOSIS_PAY_SETTLEMENT_ADDRESS = 0x4822521E6135CD2599199c83Ea35179229A172EE is disclosed in code.

    gnosispay/ui · src/constants.ts

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  5. Verified

    The sample account's Roles setup tx (block 46534712) emits EnabledModule(0x896a...8428), AssignRoles(0x896a...8428, [keccak("SPENDING_ROLE")], [true]), ScopeTarget(EURe 0xcB444e90D8198415266c6a2724b7900fb12FC56E), and ScopeFunction(selector 0xa9059cbb transfer, conditions [Matches calldata; param 0 EqualTo 0x4822521E...72EE; param 1 WithinAllowance keccak("SPENDING_ALLOWANCE")], ExecutionOptions 0 = no value, no delegatecall). Every later log from this Roles instance up to block 48629267 is ConsumeAllowance (topic 0x90355d54...), so the scope has not changed.

    0xd696…bA29 on gnosisscan.io

    0xd696…bA29 explorer · Sourcify · block 46534712 · checked 2026-10-07

Who can upgrade the code

Who can change the contract code, and with how much notice? S2

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-07

Re-assessed against the revised anchor, which now asks for modules and guards to be read. Gnosis Pay has no upgrade key over any contract that holds or gates user funds. The account Safe has no guard. Its only modules are Delay and Roles, and the Roles scope read from the setup events allows no delegatecall and no call other than EURe.transfer to the settlement Safe. Only the user, through their own Delay queue, can change the Safe's masterCopy. The Delay, Roles and Spender instances are EIP-1167 minimal proxies with no upgrade path, and Roles ownership sits with a Bouncer that only forwards setAllowance from the Safe. This is the "non-upgradeable" branch of anchor 3, so the admin-Safe conditions do not apply. Judgment call: the spender Safe (2-of-3, one module, no guard) and the settlement Safe (2-of-10, no module, no guard) are ordinary Safe proxies whose owners could change their code. That would not widen access to user accounts, because the Roles scope binds whatever code the spender Safe runs, and funds already in the settlement Safe are provider custody, scored under S1 (1). Token contracts are upgradeable by their issuers (EURe and GBPe are UUPS under a Monerium 3-of-6 Safe); that is covered in C5. The June 2026 incident was handled by issuing new Safes and new mastercopies (account-kit commit f4b92878), not by upgrading in place.

Evidence (4)4 verified
  1. Verified

    Account Safe proxy slot 0 (masterCopy) = Safe 1.3.0 singleton 0xd9Db270c...; only the Safe itself can change it, and its sole owner is the 0x...02 sentinel, so a change has to come from the user's own Delay queue.

    0xE27a…8cD8 on repo.sourcify.dev

    0xE27a…8cD8 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Account Safe guard slot 0x4a204f62...c34c8 is zero, and getModulesPaginated(0x1,10) returns only Delay 0x91Def2b0... and Roles 0xd69693CA...; the Roles scope (S1, setup events) allows only EURe.transfer to the settlement Safe with no delegatecall, so no module can change the Safe's masterCopy except the user's own Delay queue.

    0xE27a…8cD8 on repo.sourcify.dev

    0xE27a…8cD8 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  3. Verified

    Delay instance runtime code is the EIP-1167 minimal proxy to 0x22d903fd... (non-upgradeable), and its owner() is the account Safe; Roles 0xd69693CA... (to 0x732B9E9f...) and Spender 0x5f07734E... (to 0x7a592baE...) are also EIP-1167.

    0x91De…3723 on gnosisscan.io

    0x91De…3723 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  4. Verified

    Roles owner() = Bouncer 0x4d5803A0... whose from = account Safe, to = Roles, selector = 0xa8ec43ee (setAllowance) - so Gnosis Pay cannot re-scope the role.

    0xd696…bA29 on gnosisscan.io

    0xd696…bA29 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Token approval scope

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

There is no ERC-20 approval. Instead, a Roles allowance lets Gnosis Pay's spender pull up to a daily limit, which the user sets and the UI caps at 8000. It refills every period, applies to one token and transfer() only, and is locked to the settlement receiver; the setup events cited under S1 confirm that scope onchain. The revised anchor 2 names exactly this case ("a bounded allowance by default, capped or refilling, limited to one receiver"), so this is 2 without a judgment call. It is not 3 because it is neither exact-amount nor expiring. Note (red team R7): a single delegate key can draw on this allowance without the spender Safe's 2-of-3 threshold (see C1).

Evidence (2)2 verified
  1. Verified

    allowances(keccak256("SPENDING_ALLOWANCE")) returns refill 2700e18, maxRefill 2700e18, period 86400 s, balance 2695e18 - a 2700 EURe per day cap for the spender.

    0xd696…bA29 on gnosisscan.io

    0xd696…bA29 explorer · Sourcify · block 48629765 · checked 2026-10-07

  2. Verified

    Setup grants a refilling allowance (refill per period), scoped to one token, transfer() only, and one receiver; no ERC-20 approve is used.

    gnosispay/account-kit · src/entrypoints/accounts-actions/accountSetup.ts

    commit 9366073768 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Funds safe if provider disappears Derived

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-07

Re-assessed against the revised anchor 2, which needs a verified user withdrawal path that works without the provider. Chain of reasoning: (1) by S1, funds at rest stay in the user's Safe. (2) By S2, Gnosis Pay holds no key over the account, and the Roles scope (setup events) gives its spender Safe only a capped EURe transfer to the settlement Safe, not setTxNonce or any other Delay or Safe call, so it cannot block a queued withdrawal. (3) The user's own EOAs are the Delay modules. They can queue any Safe transaction directly, and anyone can execute it after the 180 s cooldown, using public, Sourcify-matched code (Delay.sol at 515737f). The public MIT frontend's /withdraw route does the same without any Gnosis Pay API call. (4) By C2 = 0 and C3 = 0, card settlement stops if Gnosis Pay disappears. (5) By O3 = 1, self-hosting the frontend is unproven, but the direct contract path does not need it. Funds already pulled into the settlement Safe for in-flight card payments stay with Gnosis Pay. While the delegate is live it can pull up to the remaining daily allowance during the cooldown. "Funds retained and retrievable through a verified direct path, settlement stops" = 2. The earlier judgment call about reading S4 as a strict minimum of S1, C2 and C3 is no longer needed under the revised anchor. The closure notice (cards end 20 Dec 2026, withdrawals kept) is this scenario in practice.

Evidence (3)3 verified
  1. Verified

    Delay txCooldown() = 180 s, txExpiration = 1800 s; the user's EOA 0x701Fb746... is an enabled module, so the user can queue any Safe transaction and anyone can execute it after cooldown.

    0x91De…3723 on gnosisscan.io

    0x91De…3723 explorer · Sourcify · block 48629765 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    execTransactionFromModule (moduleOnly) queues and executeNextTx (public) runs it after cooldown; this file matches the Sourcify source for mastercopy 0x22d903fd... except for a trailing newline.

    gnosisguild/zodiac-modifier-delay · contracts/Delay.sol

    commit 515737f67b · checked 2026-10-07

  3. Verified

    The public MIT frontend's /withdraw route has the user's own wallet send the Delay enqueue transaction directly, with no Gnosis Pay API call, and AuthGuard lets the route through without login.

    gnosispay/ui · src/components/WithdrawFundsForm.tsx

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Secrets and webhook handling

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-07

No secrets are shipped to the browser, and webhook signatures are asymmetric with verification code in the repo. Key scoping and rotation are not documented in any repo I read. Judgment call: missing scoping and rotation evidence keeps this at 2, not 3.

Evidence (2)2 verified
  1. Verified

    Webhooks are signed with Ed25519 (X-Webhook-Signature plus a timestamp), the public key comes from the API, and reference verification code is at L115-L140.

    gnosispay/docs · webhooks/getting-started.mdx

    commit b0b8c668d0 · checked 2026-10-07

  2. Verified

    The partner mTLS client cert and key live server-side in the PSE backend demo; the browser bundle carries only publishable ids (WalletConnect projectId, Pylon app id, PSE app id).

    gnosispay/ui · pse-backend-demo/.env.template

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Audits and bug bounty

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-07

The Safe, Delay and Roles code that holds and gates funds has published audits, though none is pinned to the deployed commits. No audit was found for Gnosis Pay's own Spender or Bouncer contracts, no bug bounty is in any gnosispay repo, and I found no public post-mortem for the June 2026 incident. Documented tier caps this at 1. Judgment call: 1 applies to the fund-holding modules; Gnosis Pay's own code on its own would score 0.

Evidence (2)2 verified
  1. Verified

    Roles v2.1 audits (G0 Group and Omniscia, 2023) are published in the Roles repo; the Delay module audit is dated Sep 2021 (zodiac-modifier-delay audits/), and Safe 1.3.0 audits are in safe-smart-account docs/. Cited as the committed report file (the PDF text cannot be quote-checked); it remains an audit report only.

    gnosisguild/zodiac-modifier-roles · packages/evm/docs/Audit03_RolesV2_1_Nov2023_Ominiscia.pdf

    commit 820e5bc975 · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Frontend ships a per-Safe list (status lost / not_lost, balance_if_not_hacked_usd) from the June 2026 security incident; account-kit commit f4b92878 (2026-06-03) replaced all three modifier mastercopies.

    gnosispay/ui · public/safe-recovery-data.csv

    commit 7fc844b4bb · checked 2026-10-07 · source unchanged at weekly re-read 2026-10-19

Security audits 19

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.

DateAuditorTypeScopeCovers deployed codeFindings
2026-08-17NethermindSecurity reviewNM-0993 review of Safe Smart Account v1.3.0 (shared Safe component): GnosisSafe, GnosisSafeL2, proxies and factory, base managers, handlers and libraries (1,068 LoC). at 767ef36bba
Commit 767ef36 (v1.3.0-libs.0) is 12 commits after the v1.3.0 tag and changes only libraries, tests and tooling, so GnosisSafe.sol matches the v1.3.0 singleton 0xd9Db270c... used by the account Safes. The fixes went into v1.4.0, so the deployed v1.3.0 code keeps the reported behaviour. Initial report 2026-08-07.
Yes1 low (getModulesPaginated skips one module between pages), 1 informational; fixed in v1.4.0, not in v1.3.0
2026-07CertoraAuditSecurity assessment of Safe Smart Account v1.3.0 (shared Safe component), all core contracts, proxies, handlers and libraries; reviewed 2026-07-20 to 2026-07-29. at 767ef36bba
Same commit as the Nethermind NM-0993 review; the core contracts match the v1.3.0 release.
Yes1 low, 2 informational; all acknowledged, none fixed
2026-06-12Côme du CrestSecurity reviewZodiac signature patch review (shared Zodiac component): patched Delay modifier v1.1.1 (0x824175b9...6df01) and Roles modifier v2.1.1 (0xf2964ce6...b283d5) on Gnosis Chain, checking the fix to SignatureChecker._isValidContractSignature (unchecked staticcall success).
Prepared for Gnosis Ltd after the June 2026 incident. The Gnosis Pay mastercopies are different deployments: Delay 0x22d903fd... has runtime bytecode identical to the audited 0x824175b9... except the metadata hash (read 2026-10-13), but Roles 0x732B9E9f... differs in length from the audited 0xf2964ce6..., so its match is unconfirmed.
PartlyConfirms the patch fixes the EIP-1271 signature-check vulnerability; relies on earlier audits for the rest of the code.
2024-06-13Ackee BlockchainAuditMonerium smart contracts v2.0.0 (shared EURe/GBPe token component): the V2 token, validator and frontend contracts.
Final report 2024-05-16. Gnosis Pay spends EURe through the v2 contracts; we did not check whether the live implementation matches the audited v2.0.0 code.
Unknown2 high (validator rules bypass, token frontend impersonation), 1 medium, plus low and warning findings; fix reviews 2024-05-23 and 2024-06-13
2024-03-01Ackee BlockchainAuditMonerium smart contracts v1.2.1 (shared EURe/GBPe token component); report revision 2.1 extends the 2023 v1.1.0 review.
Covers the v1 token contracts, which the v2 contracts replaced.
NoRevision 1.0 lists 5 medium plus low and warning findings; revisions 2.0 and 2.1 (Feb-Mar 2024) review the v1.2.x changes
2023-11-06OmnisciaAuditZodiac Roles modifier v2.1 (shared Zodiac component): changes in zodiac-modifier-roles PR #206 since the May 2023 audit, for contracts in the original scope. at 6a7fb909a1
Revisions run from 2023-09-25 to 2023-11-06 (final revision 4d851d2a84). The Gnosis Pay mastercopy is Roles v2.1.x, rebuilt after the June 2026 signature-checker patch, so the audited v2.1 code is only part of what is deployed.
Partly
2023-11G0 GroupAuditZodiac Roles modifier v2.1 (shared Zodiac component): all Solidity files in packages/evm/contracts. at d4b6539bdb
Covers v2.1.0; the deployed mastercopy includes the June 2026 SignatureChecker patch, which this report predates.
Partly1 minor (usability), fixed at a19c0ebd
2023-08-22Ackee BlockchainAuditMonerium smart contracts v1.1.0 (shared EURe/GBPe token component).
Final report 2023-07-04 with fix reviews to 2023-08-22. Covers the v1 contracts, which v2 replaced.
No5 medium (access control, renounce ownership, weak ownership, unchecked return values, decimals validation) plus low and warning findings
2023-05-09OmnisciaAuditZodiac Roles modifier v2 (shared Zodiac component): BufferPacker, Core, Consumptions, Decoder, Integrity, MultiSendUnwrapper, Packer, Periphery, PermissionLoader and the rest of packages/evm/contracts. at 23b782f781
Covers Roles v2.0; superseded by v2.1, which was audited separately.
NoAll findings reported as dealt with after the revision at 916e3ac17f.
2023-04G0 GroupAuditZodiac Roles modifier v2 (shared Zodiac component): all Solidity files in packages/evm/contracts. at 5d218a4b6b
Covers Roles v2.0; superseded by v2.1.
NoMedium and lower issues; all fixed or addressed by c824d7b2.
2023-02G0 GroupAuditZodiac Modifier update (shared Zodiac component): contracts/core/Modifier.sol, the base contract of the Delay and Roles modifiers. at 2ddb81b9daUnknownNo issues found.
2021-09G0 GroupAuditZodiac Delay modifier (shared Zodiac component): contracts/Delay.sol. at bde282125e
Covers the 2021 Delay.sol. The deployed Delay mastercopy (v1.1.x) adds later changes, including the 2023 Modifier update and the 2026 SignatureChecker patch.
Partly1 critical (reentrancy in executeNextTx), 2 major and smaller issues; all fixed by 808dfda6
2021-09G0 GroupAuditZodiac core library (shared Zodiac component): all contracts in gnosis/zodiac, including ModuleProxyFactory, Module, Modifier and FactoryFriendly. at 67a0956e2b
Not checked whether the ModuleProxyFactory at 0x000000000000aDdB...a236 was built from the audited code.
UnknownMinor optimisation issues; all fixed by c7aea1be.
2021-05G0 GroupAuditGnosis Safe v1.3.0 final review (shared Safe component): all Solidity files in safe-contracts. at ad6c7355d5
The v1.3.0 tag is 6 commits after ad6c735 and changes only an example guard, so this covers the v1.3.0 singleton used by the account Safes.
YesNo issues; one note on the example ReentrancyTransactionGuard.
2021-04G0 GroupAuditGnosis Safe v1.3.0 initial review (shared Safe component): all Solidity files in safe-contracts. at 4bfc0c8519
Initial pass on a pre-release commit; changes up to 9b305a0 were checked and the final May 2021 report covers the release.
PartlyNo issues; gas and style notes only.
2020-05-04G0 GroupAuditGnosis Safe v1.2.0 gas validation adjustment (shared Safe component): GnosisSafe.sol and ModuleManager.sol. at 271921f4b3
Covers v1.2.0, superseded by the v1.3.0 singleton the accounts use.
No1 medium (EIP-150 gas overhead lets relayers force failures); fixed
2019-11-11G0 GroupAuditGnosis Safe v1.1.0 security review, amended with the v1.1.1 changes (shared Safe component): base, common, handler, interfaces, libraries and proxies. at 1a9e5ce768
Amended report covering changes up to 2df0b2e0 (v1.1.1); the unamended v1.1.0 version is docs/Gnosis_Safe_Audit_Report_1_1_0.pdf. Superseded by v1.3.0.
No
2019-02-27Runtime VerificationFormal verificationFormal verification of the GnosisSafe contract v1.0.0 (shared Safe component).
Covers v1.0.0, superseded by v1.3.0. Runtime Verification verified the EVM bytecode rather than the Solidity source.
NoFindings include an execTransaction reentrancy, ISignatureValidator gas and refund abuse, and missing contract-existence checks.
2018-07Alexey AkhunovAuditGnosis Safe contracts audit (interim report and iteration 2) with a symbolic-execution appendix (shared Safe component), pre-v1.0.0. at 942968d66a
The report is undated; the date is when it was committed to the Safe repo (2018-07-04). Changes up to 898cc896 were checked with symbolic execution (docs/Gnosis_Safe_Symbolic_Execution.pdf). Superseded by later versions.
No

Compiled from: All gnosispay repos (account-kit, ui, docs, safe-contracts, pse-react-native; no audit report, and GitHub code search for "audit" finds none), so Gnosis Pay's own Spender modifier and Bouncer have no published audit. Shared components listed in this file: the docs/ folder of safe-global/safe-smart-account (reports for v1.0.0 to v1.3.0 are listed; v1.4.x and v1.5.0 reports are left out because the account Safes run the v1.3.0 singleton), the audits folders of gnosisguild/zodiac-modifier-delay, gnosisguild/zodiac and gnosisguild/zodiac-modifier-roles (packages/evm/docs), and monerium/smart-contracts audits/ for the EURe token. No public post-mortem of the June 2026 incident 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: 21 evidenced, 0 attested, 2 absent, 1 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
ComponentPaid byAmountBasis
cardpayerno transaction fee on purchases; spends debit stablecoin 1:1Gnosis Pay fee and limits article (legacy help centre); Gnosis Pay may change fees with notice under Terms section 17.
fxpayerVisa exchange rate, no Gnosis Pay mark-upSame article; the rate is Visa's.
cardpayercard order free; replacement 4.99 EURe/GBPe/USDCeSame article; the Terms allow an Admin Fee for physical cards shown at order time.
cashoutpayerATM free for 5 withdrawals or 200 EURe/GBPe/USDCe a month, then 2% per withdrawalSame article (ATM fair usage policy); ATM operators may add their own charges.
limitnonespend 8,000 a day, 5,000 per transaction; ATM 500 a day, 250 per withdrawal (EURe/GBPe/USDCe)Same article.
networkpayerno gas on card spends; gas (xDAI) on onchain transfers from the SafeSame article and Terms (third-party charges).

Consumer card fees as published for the programme that closes at 23:59 UTC on 20 December 2026; partner card programmes set their own fees. Monerium charges for IBAN redemption were not checked.

  1. Documented

    Fee and limits article (Understanding Your Card's Fees and Limits), linked from the Terms (section 7) as the Fee Schedule and kept published for reference after the closure notice.

    help.gnosispay.com/articles/6104401027

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    Terms of Service section 7, Charges; Monavate fees under the cardholder terms are third-party charges.

    help.gnosispay.com/articles/2178874711

    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

Hybrid: self-custody with a provider-controlled spend path

Funds sit in the user's own Safe; card spends are pulled through a Gnosis Pay-controlled spend path bounded by a daily allowance to a fixed settlement address (S1 = 1).

Evidence shared with CROPS: S1 item 1, S1 item 3, S1 item 5

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Licences and registrations

Evidenced
EntityCountryRegulatorLicenceRegister
UAB Monavate partnerLithuaniaBank of LithuaniaElectronic money institution licence (non-limited activity) · LB002139
E-money issuance, card issuing and acquiring, payment transactions, cash withdrawals; valid from 2022-03-31
register
Monavate Ltd partnerUnited KingdomFinancial Conduct AuthorityAuthorised Electronic Money Institution · 901097
Issue e-money and provide payment services; authorised since 04/11/2020
register

Both licences are held by the issuer partner; Gnosis Pay itself holds none and describes itself as a technical services provider. The Bank of Lithuania register records an enforcement measure against UAB Monavate dated 2025-11-25: a EUR 270,000 fine for breaches of the AML/CTF law and of e-money institution governance and safeguarding rules. EURe and the IBAN service come from Monerium, an e-money institution regulated in Iceland (CROPS context); not checked in a register here.

  1. Documented

    Bank of Lithuania register entry for UAB Monavate (company code 305628001), authorisation code LB002139, e-money institution licence valid from 2022-03-31; also lists a sanction of 2025-11-25 (fine EUR 270,000) under the AML/CTF law and e-money and safeguarding rules.

    www.lb.lt/en/sfi-financial-market-participants/uab-monavate

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    FCA Register firm page for reference 901097 (client-rendered; text read in a browser and archived), Companies House number 12472532.

    register.fca.org.uk/s/firm

    checked 2026-10-09

  3. Documented

    Closure notice names which Monavate entity issues the card for EEA and for UK and other non-EEA cardholders.

    help.gnosispay.com/articles/1452055581-formal-notice-closure-of-the-gnosis-pay-web-app-and-card-21-september-2026

    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
WhereMethodPartnerFeeLimits
everywhere offeredcard withdrawalMonavate (issuer), Visanone from Gnosis Pay; Visa FX rateCard spend at merchants (the schema has no card-spend value); 8,000 a day, 5,000 per transaction. Card stops at 23:59 UTC on 20 December 2026.
everywhere offeredatmMonavate (issuer), Visa5 withdrawals or 200 a month free, then 2%500 a day, 250 per withdrawal; ends with the card on 20 December 2026.
EU, Switzerlandbank transferMonerium (EURe issuer, SEPA)not stated by Gnosis PayEUR cards only; funds leave the Safe onchain to the user's own wallet, which Monerium redeems to a SEPA account. Continues after the card closes.

ALL means every country in the availability list (EEA, CH, GB, AR, BO, BR, CO, MX). The withdrawal page for moving assets out of the Safe onchain stays open after 20 December 2026. No cash agents.

  1. Verified

    IBAN via Monerium for users in the EU and Switzerland; it operates independently of the GP Safe.

    gnosispay/docs · on-off-ramps/iban-integration.mdx

    commit b0b8c668d0 · checked 2026-10-09

  2. Documented

    Fee and limits article covering purchases, ATM withdrawals and limits.

    help.gnosispay.com/articles/6104401027

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  3. Documented

    Help centre article on the Monerium IBAN off-ramp.

    help.gnosispay.com/articles/5556167633-getting-money-to-a-bank-account

    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-12-13 (block 31420289): Gnosis Pay settlement Safe 0x4822521E...72EE on Gnosis Chain (receiver of every card spend, CROPS S1)

Dates the settlement address scored in CROPS. The spend-path modifiers in use today were redeployed after the June 2026 incident (account-kit f4b92878); earlier settlement or spender addresses, if any, were not traced.

  1. Verified

    Settlement Safe has code size 0 at block 31420288 and 171 at 31420289 (2023-12-13 11:44:00 UTC); creation tx 0x74f6c12f...8ec2 from 0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2 (Safe proxy factory).

    0x4822…72EE on gnosisscan.io

    0x4822…72EE explorer · Sourcify · block 31420289 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Operating entity

Evidenced

Gnosis Pay Co Ltd, GB · 14919639 · register

Recorded entity is the non-EEA contracting party, checked in Companies House. EEA residents contract with Gnosis P. Tech, Unipessoal Lda (Portugal, 517 666 898, per the Terms; not checked in a Portuguese register). The card itself is a contract with Monavate.

  1. Documented

    Companies House, GNOSIS PAY CO LTD., active, registered office 12 New Fetter Lane, London EC4A 1JP.

    find-and-update.company-information.service.gov.uk/company/14919639

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    Terms of Service section 1 name Gnosis Pay Co Ltd (non-EEA residents) and Gnosis P. Tech, Unipessoal Lda (EEA residents, Portugal 517 666 898).

    help.gnosispay.com/articles/2178874711

    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

Evidenced
  • 2026-06-03: Security incident; users migrated to new Safes and all three modifier mastercopies replaced (account-kit f4b92878). Gnosis Pay's help centre confirms the incident and keeps a withdraw-legacy page for funds left in pre-incident Safes; no cause or loss figure is published. funds lost: unknown source

Absence of a found incident is not evidence that none occurred.

No public post-mortem was found; funds_lost is unknown although the frontend's recovery list carries a balance_if_not_hacked field. The date is the account-kit commit date; Gnosis Pay gives the month only.

Evidence shared with CROPS: S6 item 2

  1. Documented

    Help centre article on the June 2026 incident (recovery instructions only).

    help.gnosispay.com/articles/8765952539-recovering-funds-after-the-2026-security-incident

    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

Product changes affecting users

Evidenced
  • 2025-12-01: Revised Terms of Service (published 18 November 2025) take effect for existing customers. source
  • 2026-09-21: Consumer card programme closes: card and web app stop at 23:59 UTC on 20 December 2026; withdrawals remain open; dispute support ends 12 June 2028; Gnosis Pay moves to partner card programmes. source
  1. Documented

    Closure notice dated 21 September 2026.

    help.gnosispay.com/articles/1452055581-formal-notice-closure-of-the-gnosis-pay-web-app-and-card-21-september-2026

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    Terms of Service header with publication and effective dates.

    help.gnosispay.com/articles/2178874711

    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)

Not observable

Card spends settle as EURe (or GBPe, USDCe) transfers from each user Safe to one settlement Safe; the transfer event carries no card data, and spends cannot be separated from ordinary transfers to that address without the provider's records.

The consumer card stops on 20 December 2026.

UnreviewedAssessed by AI research agent (operational), 2026-10-09

Group B: institutional due diligence

ControlStateWhat 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
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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
Published audits cover the Safe, Delay and Roles code that holds funds (CROPS S6); no independent review of Gnosis Pay's own Spender or Bouncer contracts, backend or app was found.
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 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)?
Absentnone of 6 repo(s): gnosispay/account-kit ✗ no security policy file; gnosispay/ui ✗ no security policy file; gnosispay/pse-react-native ✗ no security policy file; gnosisguild/zodiac-modifier-delay ✗ no security policy file; gnosisguild/zodiac-modifier-roles ✗ no security policy file; safe-global/safe-smart-account ✗ no security policy file
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
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?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✗ no scanning config or workflow step found; gnosispay/ui ✓ dependabot config present; gnosispay/pse-react-native ✗ no scanning config or workflow step found; gnosisguild/zodiac-modifier-delay ✗ no scanning config or workflow step found; gnosisguild/zodiac-modifier-roles ✗ no scanning config or workflow step found; safe-global/safe-smart-account ✗ no scanning config or workflow step found
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
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 first-party statement found in the documents listed in the research log (Operational 2026-10-09).
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?
EvidencedPublic status page at status.gnosispay.com (Upptime, open source in gnosispay/gnosispay-uptime) and a formal closure notice. No post-mortem for the June 2026 security incident was found; the help centre article on it gives recovery steps only.
source 1 · source 2 · source 3
Identity and access (operator side)
B4.1 MFA for end users
Can or must end users protect accounts with multi-factor authentication?
EvidencedSign-in is a Sign-In with Ethereum signature from the wallet that owns the Safe, exchanged for a JWT; no separate second factor is documented. Funds at rest also need that wallet's signature plus the Delay cooldown.
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?
EvidencedSign-In with Ethereum (SIWE) issues a JWT sent as a Bearer token; partner SIWE domains must be whitelisted.
source 1
B5.2 API authentication, server to server
Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
EvidencedPartners get a Partner ID and an App ID from the Partners Dashboard; the App ID authenticates a mutual-TLS connection for Partner Secure Elements. Webhooks are Ed25519-signed (CROPS S5). Key scoping and rotation are not documented.
source 1
CROPS S5 · 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)?
EvidencedJWT validity is set per sign-in between 1 and 24 hours (ttlInSeconds); anything above 2 hours exceeds the partner's 120-minute cap. Expired tokens need a new signed SIWE message.
source 1
B5.4 Export controls
If an API exports data, does it limit volumes and log exports?
Unknown
Cardholders can export card transactions as CSV (CROPS O4); no export limits or export logging were found.
CROPS O4
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?
EvidencedNo separation is stated: the privacy policy lists system administration, operation and testing as a purpose for all categories of personal data.
source 1
B6.3 Data retention and deletion on termination
What is retained, for how long, and is customer data removed on termination?
EvidencedIdentification, biometric, contact, financial, transaction, device and support data kept up to 7 years for partner and legal obligations (privacy policy); KYC and transaction records 5 years after closure per the data article (CROPS P2). After the card closes, dispute and chargeback support runs to 12 June 2028 and Monavate keeps transaction records for the legally required period.
source 1 · source 2
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?
EvidencedController is Gnosis P. Tech, Unipessoal Lda (Lisbon) for EEA residents and Gnosis Pay Co Ltd (London) for non-EEA residents; KYC is run by Sumsub as a service provider. 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?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✗ no deployment configuration; gnosispay/ui ✓ deployment configuration: Dockerfile.pse-backend; gnosispay/pse-react-native ✗ no deployment configuration; gnosisguild/zodiac-modifier-delay ✗ no deployment configuration; gnosisguild/zodiac-modifier-roles ✗ no deployment configuration; safe-global/safe-smart-account ✗ no deployment configuration
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
Engineering practice in public repositories
B9.1 Default branch protected
Does the default branch require reviews and passing checks, with no direct pushes?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ rules: deletion, non_fast_forward, required_linear_history, pull_request; gnosispay/ui ✗ no branch rules visible (classic branch protection is not readable without push access); gnosispay/pse-react-native ✗ no branch rules visible (classic branch protection is not readable without push access); gnosisguild/zodiac-modifier-delay ✗ no branch rules visible (classic branch protection is not readable without push access); gnosisguild/zodiac-modifier-roles ✗ no branch rules visible (classic branch protection is not readable without push access); safe-global/safe-smart-account ✗ no branch rules visible (classic branch protection is not readable without push access)
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.2 CI runs on pull requests
Does every pull request trigger automated checks?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ 2 workflow file(s); gnosispay/ui ✓ 8 workflow file(s); gnosispay/pse-react-native ✗ 1 workflow file(s); gnosisguild/zodiac-modifier-delay ✓ 2 workflow file(s); gnosisguild/zodiac-modifier-roles ✓ 3 workflow file(s); safe-global/safe-smart-account ✓ 2 workflow file(s)
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.3 Tests run in CI
Do the CI workflows run the test suite?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ test command in a workflow; gnosispay/ui ✓ test command in a workflow; gnosispay/pse-react-native ✗ test command in a workflow; gnosisguild/zodiac-modifier-delay ✗ test command in a workflow; gnosisguild/zodiac-modifier-roles ✓ test command in a workflow; safe-global/safe-smart-account ✓ test command in a workflow
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.4 Coverage reported
Is test coverage measured and reported (the partner expects 85%)?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✗ coverage tooling referenced; gnosispay/ui ✗ coverage tooling referenced; gnosispay/pse-react-native ✗ coverage tooling referenced; gnosisguild/zodiac-modifier-delay ✓ coverage tooling referenced; gnosisguild/zodiac-modifier-roles ✓ coverage tooling referenced; safe-global/safe-smart-account ✓ coverage tooling referenced
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.5 Versioned releases
Are releases tagged with immutable semantic versions?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ latest tags: v5.1.1, v5.1.0, v5.0.1; gnosispay/ui ✗ no tags; gnosispay/pse-react-native ✓ latest tags: v1.0.7, v1.0.6, v1.0.5; gnosisguild/zodiac-modifier-delay ✓ latest tags: v1.1.0, v1.0.1; gnosisguild/zodiac-modifier-roles ✗ latest tags: zodiac-roles-sdk-v4.1.3, zodiac-roles-sdk-v4.1.2, zodiac-roles-sdk-v4.1.1; safe-global/safe-smart-account ✓ latest tags: v1.5.0, v1.5.0-base, v1.4.1
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.6 Signed tags or commits
Are release tags or recent commits cryptographically signed?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ 10 of 10 recent commits signed; gnosispay/ui ✓ 10 of 10 recent commits signed; gnosispay/pse-react-native ✗ 2 of 10 recent commits signed; gnosisguild/zodiac-modifier-delay ✗ 2 of 10 recent commits signed; gnosisguild/zodiac-modifier-roles ✓ 10 of 10 recent commits signed; safe-global/safe-smart-account ✓ 10 of 10 recent commits signed
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.7 Changelog
Is a changelog maintained with the code?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ 7 release(s) with notes; gnosispay/ui ✗ no changelog or release notes; gnosispay/pse-react-native ✗ no changelog or release notes; gnosisguild/zodiac-modifier-delay ✓ 2 release(s) with notes; gnosisguild/zodiac-modifier-roles ✓ 10 release(s) with notes; safe-global/safe-smart-account ✓ CHANGELOG file
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
B9.8 Contribution and branching model documented
Does the README or contribution guide state how changes are proposed, reviewed and released?
Evidencedsome of 6 repo(s): gnosispay/account-kit ✓ contribution section in README; gnosispay/ui ✗ none found; gnosispay/pse-react-native ✗ none found; gnosisguild/zodiac-modifier-delay ✓ CONTRIBUTING file; gnosisguild/zodiac-modifier-roles ✓ CONTRIBUTING file; safe-global/safe-smart-account ✗ none found
source 1 · source 2 · source 3 · source 4 · source 5 · source 6
Architecture documentation
B10.1 Architecture documentation
Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?
EvidencedIntegration and part of the logical architecture are documented in the public docs repo (SIWE auth, partner model, PSE, webhooks, and the Safe with Delay, Roles and Bouncer modules); infrastructure architecture is not published.
source 1
Commercial and financial
B11.1 Contracting entity
Which legal entity would an institution contract with, and in which jurisdiction?
EvidencedPlatform agreement: Gnosis Pay Co Ltd (England and Wales, 14919639) for non-EEA residents or Gnosis P. Tech, Unipessoal Lda (Portugal, 517 666 898) for EEA residents. Card agreement: Monavate (UAB Monavate for EEA, Monavate Ltd for UK and non-EEA), with Gnosis Pay as technical services provider and programme manager.
The Portuguese entity was not checked in a Portuguese company register.
source 1 · source 2 · source 3
B11.2 Funding of ongoing operation
How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?
Unknown
No first-party statement found in the documents listed in the research log (Operational 2026-10-09).
B11.3 Termination terms
What happens to customer funds and data on termination by either side?
EvidencedThe consumer card and web app end at 23:59 UTC on 20 December 2026; the cardholder agreement then ends, refunds and chargeback rights survive, and assets stay in the user's self-custodial Safe with a withdrawal page kept open. Card closure or suspension otherwise follows Monavate's cardholder terms.
source 1
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)?
AbsentThe privacy policy states that no automated decision making is used.
Gnosis Pay's own statement. Screening by Sumsub and by the issuer Monavate is outside this statement and was not found described.
source 1
B12.2 AI controls documented
If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
N/A: no such service
B12.1 is absent on the provider's own statement, so there is no AI control to document.

Scope of assessment

Components in the payment path

ComponentRolePublicLicenceOperatorRequired
User account Safe (Safe v1.3.0 proxy)contractsYesLGPL-3.0User (self-custodial; owner swapped to 0x...02 sentinel)Yes
Zodiac Delay modifier (per account)contractsYesLGPL-3.0User's account Safe (Gnosis Guild code)Yes
Zodiac Roles v2 modifier and Bouncer (per account)contractsYesLGPL-3.0User's account Safe (Gnosis Guild code; Bouncer from account-kit)Yes
Spender modifier (account-kit Spender.sol)contractsYesApache-2.0Gnosis Pay (owned by spender Safe 0x896a...8428)Yes
Gnosis Pay spender Safe (2-of-3) and settlement Safe (2-of-10)contractsYesLGPL-3.0Gnosis PayYes
Monerium EURe token (default card currency; GBPe same issuer)contractsYesApache-2.0MoneriumYes
account-kit SDK (account setup)sdkYesApache-2.0Gnosis PayNo
Gnosis Pay web appfrontendYesMITGnosis PayNo
Gnosis Pay API and card authorisation backendbackendNoproprietaryGnosis PayYes
Spend delegate signer (EOA 0x9c48...4d4df)signerNoproprietaryGnosis PayYes
Spend relayer (EOA 0x9083...18De9)relayerNoproprietaryGnosis PayYes
Card-transaction indexer and delay relayindexerNoproprietaryGnosis PayNo
Monavate (card issuer, e-money institution)card-issuerNoproprietaryUAB Monavate (EEA) / Monavate Ltd (UK, non-EEA)Yes
Visa card networkcard-networkNoproprietaryVisaYes
Sumsub KYCkycNoproprietarySum and Substance LtdYes
Pylon support widgetotherNoproprietaryPylonNo
WalletConnect relay (via RainbowKit, hardcoded projectId)otherNoproprietaryWalletConnect / ReownNo
PSE card-details service (partner secure elements)apiNoproprietaryGnosis PayNo

Repositories

Contracts

RoleAddressSource verified
Spender modifier mastercopy (account-kit 5.1.1)0x7a59…7cB7 explorer · Sourcifysourcify
Zodiac Delay modifier mastercopy (account-kit 5.1.1)0x22d9…1ef0 explorer · Sourcifysourcify
Zodiac Roles v2 modifier mastercopy (account-kit 5.1.1)0x732B…Bd2f explorer · Sourcifysourcify
Safe v1.3.0 singleton used by account Safes0xd9Db…9552 explorer · Sourcifysourcify
Zodiac ModuleProxyFactory0x0000…a236 explorer · Sourcifysourcify
Spender modifier instance (EIP-1167) for card spends0x5f07…3F8a explorer · Sourcifynone
Gnosis Pay spender Safe (2-of-3), owner of spender modifier0x896a…8428 explorer · Sourcifynone
Gnosis Pay settlement Safe (2-of-10), card spend receiver0x4822…72EE explorer · Sourcifynone
Sample user account Safe (proxy)0xE27a…8cD8 explorer · Sourcifysourcify
Sample account Delay modifier instance (EIP-1167 proxy)0x91De…3723 explorer · Sourcifynone
Sample account Roles modifier instance (EIP-1167 proxy)0xd696…bA29 explorer · Sourcifynone
Sample account Bouncer (Roles owner)0x4d58…F562 explorer · Sourcifysourcify

Assessor notes

Migrated 2026-10-07 to the post-red-team rules (components, quotes, rechecks, R7 module read on the spender Safe). Scored the post-incident (June 2026) account architecture from account-kit 5.1.1 at 9366073 and a live account found from a Spend event at block 48629267; all onchain reads are pinned to Gnosis block 48629765. The card side (issuer Monavate, Visa, KYC, card freeze) is documented tier only, from the Terms, the privacy policy and the closure notice. Gnosis Pay is ending its consumer card and web app at 23:59 UTC on 20 Dec 2026 (the withdraw path stays) and moving to partner card programs, which may use different terms and setups. The homepage privacy and legal links return 404; the live legal pages are at help.gnosispay.com/articles.