Unaudited, unvetted, experimental. Do not use as a reference. AI-researched ratings that may be wrong; not advice or a statement of fact about any provider. Full disclaimer
Pending review. 1150 of 1150 ratings not yet checked by a human. Do not rely on unreviewed ratings.
Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: The card settles inside the Payy zk-rollup ("transactions are settled privately on Payy Network", Payy Card docs), and that rollup's state, USDC escrow and exits are enforced by RollupV1 proxy 0x367C1eAF... on Ethereum (polybase/payy 2f95947 eth/README.md#L142-L170, Mint migration Polygon -> Ethereum at L185). The rollup is not an EVM chain with its own RPC, so its L1 contract is the unit. Excluded: the legacy Polygon rollup 0x4cbb5041... (0 USDC at Polygon block 95103541) and the Payy Network EVM L2 (testnet only in @payy/client).
Conversion. The token is sold for fiat when a payment is authorised.
Fiat-backed stablecoin. An issuer holds the reserves and can freeze balances at the token contract. Value depends on the issuer redeeming at par. Censorship Resistance records whether that freeze power is disclosed.
The balance is held as private USDC notes on the Payy Network zk-rollup, backed by Circle USDC escrowed in the rollup contract 0x367C1eAF... on Ethereum (the address above is that escrowed token). The Terms name USDC as the only Supported Digital Asset today. When the card is used, Payy pushes USDC from the Payy Network to Rain, which converts it to fiat for the merchant. The Terms also let the user pick a USD Wallet balance as the Preferred Spending Currency instead, in which case spend comes from fiat; that option is not a token and is not listed.
Checked 2026-10-12
Evidence (3)1 verified · 2 documented
Verified
The deploy script pins the rollup token to Circle USDC 0xA0b86991... on Ethereum.
Terms s2.6 say a Supported Digital Asset (currently USDC) chosen as Preferred Spending Currency is transferred to Rain and converted to fiat when the card is used.
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.
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
Onchain, a 2-of-4 Safe with undisclosed signers, no modules, no guard and no timelock owns the rollup. It can stop settlement (remove the prover or verifier) and can rewrite the state root outright. Payy's own EOA is the only prover, so it can also leave any transaction out of a block. Off-chain, the Terms let Payy restrict an individual's access without notice, and card use can be suspended with immediate effect. Judgment call: the onchain role alone would score 1 (multisig, no timelock, undisclosed signers), but the documented per-user restriction without notice meets anchor 0.
Evidence (4)3 verified · 1 documented
Verified
The owner can add or remove provers, add or remove ZK verifiers, add burn substitutors and overwrite the state root with setRoot (L264-L266); only a prover can call verifyRollup (L314-L322), so removing provers or verifiers halts all settlement. This file is identical to the Sourcify source of the deployed implementation.
Owner Safe (v1.3.0) getThreshold() = 2 with 4 EOA owners (0x54e22ad9..., 0x111e5feA..., 0xCa1Df6eD..., 0xAF657A8F...); getModulesPaginated(0x1,10) returns no modules and the guard slot is zero; no timelock sits in front of it and the signers are not disclosed anywhere I found.
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
Merchants are paid by Visa and the issuer off-chain. On the rollup, a card debit is a note handed to Payy's closed backend, and only Payy's prover can put any transaction into a block on Ethereum. Neither payer nor payee can complete a card payment by calling the contracts directly.
Evidence (2)2 verified
Verified
verifyRollup is onlyProver and also requires validator signatures over the new root; burns (withdrawals) execute only inside verifyRollup. mint() (L619-L648) is public, so deposits are direct, but nothing else is.
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
A card payment needs Payy's closed backend and app, Rain, an unnamed U.S. issuer and Visa. None of these is public or has a fallback. The rollup node and prover code is public, but the deployed contract accepts blocks only from Payy's prover, so there is no fallback there either.
Evidence (2)1 verified · 1 documented
Verified
The workspace declares rain-http, rain-interface, rain-provider and sumsub-* crates, but none of those directories (nor the guild backend server) exist in the public tree; the public repo is a Copybara-filtered export (README.md#L128-L134).
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
The settlement contract has no address or country filter. Sanctions and region screening exists: it is disclosed in the privacy policy and Terms and visible as KYC rejection reasons in public code, but it runs in closed services, and with C2 at 0 there is no way around it. Judgment call: the screening logic and its list sources are not public, so I took 1 (the Gnosis Pay precedent) rather than 2.
Evidence (2)1 verified · 1 documented
Verified
KYC rejection reasons include Sanctions, Sanctioned, Blacklist, Blocklist, Pep and WrongUserRegion; the checks themselves run in the closed backend and vendors. A search of RollupV1.sol, pkg/node and pkg/rpc for sanctions lists, blocklists or geo-IP found none.
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
The token (USDC) and chain (Ethereum) are enumerated in code and onchain. The Terms, privacy policy and card docs do not mention Circle's freeze powers. They also do not say that the Payy rollup has a single Payy-run prover and no forced-inclusion path. Enumerated in code, assumptions not stated, so 2.
Evidence (2)2 verified
Verified
The deploy script pins the rollup token to Circle USDC 0xA0b86991... on Ethereum (and native USDC on Polygon for the legacy deployment).
Rollup usdc() returns this token; USDC blacklister() = 0x0A06BE16275B95a7d2567fBdAE118b36C7DA78F9 and pauser() = 0x4914f61d25e5C567143774B76EdbF4D5109a8566, so Circle can freeze the rollup's escrow or a withdrawal recipient.
Does the deployed bytecode match public source, and can a third party rebuild it? O1
2 Partial
Best evidence: VerifiedChecked 2026-10-07 12 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The proxy, the implementation, the ProxyAdmin and the owner Safe are exact matches on Sourcify. The live ZK verifier is only a partial match. The repo has a Hardhat deploy script but no recorded build that reproduces the deployed bytecode. Partial match plus no reproducible build gives 2.
Evidence (2)2 verified
Verified
Sourcify v2 reports exact_match for the RollupV1 implementation, the proxy 0x367C1eAF..., the ProxyAdmin 0xfE455baC... (runtime exact) and the owner Safe; the Sourcify RollupV1.sol is byte-identical to eth/contracts/rollup3/RollupV1.sol at 2f95947.
getZkVerifier(0x0701c58c...) - the key used by the latest verifyRollup - returns HonkVerifier 0x14DACD53..., which Sourcify lists as match (partial), not exact_match.
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The contracts, circuits, rollup node, aggregator and prover are public. The wallet app that holds keys and funds card debits is closed, and so is the card, ramps and KYC backend. Typed client bindings exist, but there is no published API schema. Judgment call: this is more than "SDK or contracts only", but both the frontend and the backend of the card path are closed, so 1.
Evidence (2)2 verified
Verified
The Payy app package holds only assets, build scripts and generated ts-rs type bindings; no app source. The repo also lacks the guild backend, Rain and Sumsub providers declared in Cargo.toml.
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
Build docs exist for the rollup stack. Reproduction not attempted. A self-hosted node cannot settle against the deployed contract, which accepts only Payy's prover, and the card path needs closed services.
Evidence (1)1 verified
Verified
README gives prerequisites, a dev container and docker compose profiles for eth, node and prover.
Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The ABIs and event schemas are in the repo. Backend routes appear only implicitly, through a Rust client, and there is no API schema and no export. Judgment call: between 1 and 2, so I took the lower; a typed client is not an API schema.
Evidence (2)2 verified
Verified
Event definitions (RollupVerified, Minted, Burned, MintAdded, verifier/prover events) are in source and compiled ABIs are committed under eth/artifacts.
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
The repo was MIT until March 2026, when an internal sync removed the LICENSE and left the code unlicensed. That is a prior relicensing event, so 0. MIT grants on code published before c4d2c902 still stand.
Evidence (2)2 verified
Verified
Up to commit 9e57964 (2025-01-09) the repo carried an MIT License (Copyright 2022-2024 Polybase Labs); commit c4d2c902 (2026-03-25, a Copybara sync from the internal repo) removed it.
Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1
1 Weak
Best evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The policy discloses diagnostics and performance collection. The app source is closed, so the SDKs in use and their defaults cannot be checked, and no trace was run. Judgment call: disclosed and presumed on by default, so 1. It could be 0 if the app ships undisclosed SDKs, which I cannot see.
Evidence (1)1 documented
Documented
Privacy Policy (last updated 6 May 2024) discloses automatic metrics and performance collection and push tokens.
Does the flow collect anything beyond addresses, amounts, token, and chain? P2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The regulated card requires full KYC. The fields are disclosed in the docs and visible in code, but no legal basis is given in the repo. Disclosed beyond settlement needs, so 1.
Evidence (2)1 verified · 1 documented
Verified
The KYC struct carries name, DOB, address, nationalities, ID documents, phone and email; no legal basis is stated.
What do calldata and events reveal about who paid whom for what? P3
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
A card purchase is a shielded send inside the rollup. Ethereum sees only state roots and a proof, so nothing public links a cardholder to a purchase, a merchant or an amount. Deposits and withdrawals do expose an EVM address and an amount, which bridging needs. The design is a privacy pattern (UTXO notes, nullifiers, link-based sends). Judgment call: I did not observe how Payy funds Rain onchain. If that leg exists it carries Payy's aggregate, not a user's notes, so I scored 3. The privacy is against the public, not against Payy: the backend receives the note for each card debit, which falls under P2 and P4. The card-specific Polygon deposit addresses mentioned in the FAQ are outside the rollup and were not assessed.
Evidence (4)3 verified · 1 documented
Verified
The UTXO circuit's only public inputs are four note commitments and five message fields, and messages are all zeros except for mints and burns; owners, values and counterparties of a send are private witnesses.
L1 events carry only the block height and root (RollupVerified), and mint or burn amounts with the bridging EVM address (MintAdded, Burned); no payee, merchant or invoice field exists.
A sample verifyRollup from prover 0x5343B904... posts an aggregate proof, old and new roots and mint or burn messages; the Transfer logs it emits are burns to withdrawal addresses only.
Which third parties see a request during a payment, and can they be swapped out? P4
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Each card payment is seen by Visa, the issuer, Rain and Payy's backend. Vendors are named in code and the Terms, but nothing is swappable by user config, and no trace was run. 1.
Evidence (2)1 verified · 1 documented
Verified
The provider enum names Alfred, Manteca, Payy, Rain, Sumsub, Cybrid and Stripe; choosing among them happens in the closed backend.
Who holds funds between payer and payee, and can the provider redirect them? S1
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
User funds are notes inside a rollup whose escrow is an upgradeable proxy. The Payy owner Safe can overwrite the state root or swap the verifier, which means it can redirect funds. A card debit also hands a note to Payy's backend, which then funds Rain. The provider can redirect funds, so 0.
Evidence (2)2 verified
Verified
All bridged USDC sits in the rollup proxy (710.75 USDC at this block); EIP-1967 implementation slot = 0x7d8837b5..., so the escrow is upgradeable.
setRoot(bytes32) is onlyOwner and replaces the state root with no proof; together with addProver and addZkVerifier, the owner can mint itself notes and burn the escrow.
Who can change the contract code, and with how much notice? S2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
A 2-of-4 Safe can upgrade the rollup instantly through the ProxyAdmin. The same Safe can also swap the ZK verifier through addZkVerifier, which is an upgrade in effect. Signers are undisclosed and nothing documents a notice channel. Multisig admin, no timelock, so 1.
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
No standing allowance exists in the card path. Deposits support exact-amount, expiring EIP-3009 authorisations, and card debits are funded one note at a time. Judgment call: this design meets anchor 3, but the app that chooses between mint and mintWithAuthorization is closed and no package or trace is available, so 2.
Evidence (2)2 verified
Verified
mintWithAuthorization pulls the exact deposit value through USDC receiveWithAuthorization (EIP-3009) with validAfter/validBefore; mint() needs a prior ERC-20 approve.
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Chain of reasoning. S1 = 0: funds sit in an upgradeable escrow controlled by Payy. C2 = 0: only Payy's prover can process any transaction, withdrawals included. C3 = 0: the card needs closed services. O3 = 1: self-hosting is unproven, and a self-hosted node could not settle anyway. If Payy's prover stops, no withdrawal can execute. Funds depend on provider liveness, so 0.
Evidence (2)2 verified
Verified
Burns are paid only from verifyBurn, which runs inside the onlyProver verifyRollup; the contract has no forced-exit or escape-hatch function.
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
? No evidence
Sets the pillar rating
UnreviewedAssessed by AI research agent (seed), 2026-10-07
No checkable evidence settles this yet, so it counts as 0.
Security audits 4
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.
Shared component: Safe smart account v1.3.0 (GnosisSafe, GnosisSafeL2 and handlers), the version of the rollup's 2-of-4 owner Safe at 767ef36bba Owner Safe 0x230Dfb03... proxies the canonical GnosisSafeL2 v1.3.0 singleton 0x3E5c6364... (slot 0 read 2026-10-13). Retrospective review of the shipped 1.3.0 code.
Yes
1 low (getModulesPaginated skips a module between pages), 1 informational
Shared component: Safe smart account v1.3.0 (GnosisSafe, GnosisSafeL2, base managers, handlers), the version of the rollup's owner Safe at 767ef36bba Review window 20-29 July 2026, tag v1.3.0-libs.0.
Shared component: Gnosis Safe v1.3.0 contracts (initial audit), the version of the rollup's owner Safe at 4bfc0c8519 Superseded by the May 2021 final audit; changes up to 9b305a0f were checked.
Partly
No issues found
Compiled from: The Payy wallet FAQ (docs.payy.network), which says "the important parts of Payy's code have been audited" but links no report; the polybase/payy repo tree (no audits/ folder; one GitHub security advisory, GHSA-fhxc-63vg-9gwr, for the aggregation circuit); web searches for Payy and Polybase audits across Zellic, Veridise, Least Authority, Spearbit, Hacken and Halborn; and the docs/ audit folder of github.com/safe-fndn/safe-smart-account for the owner Safe. No audit of RollupV1, the Noir/Halo2 circuits or the node is published. The September 2026 exploit postmortem cites a Spearbit incident report; that is incident analysis, not an audit, and is not listed. Audits of the Barretenberg toolchain that generates the HonkVerifier are not logged here. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.
Operational and procurement
Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.
Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 13 evidenced, 1 attested, 4 absent, 0 not applicable, 27 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.
Group A: operational facts
Fees
Evidenced
Component
Paid by
Amount
Basis
card
none
No application, transaction, top-up or monthly fees
Payy Card docs feature table; the Terms let Payy change fees at any time without notice.
fx
payer
Visa rate plus 1% bank fee on non-USD purchases
Payy Card docs usage notes (set bank fee to 1% in the Visa calculator).
provider
payer
No transaction fee for the USDC-to-fiat conversion, but a spread may be included
Terms of Service section 2.6.18; the referenced Pricing and Fees Disclosures were not found.
The ATM fee (private beta) and any physical-card fee are not stated; the Light Up physical card is sold out.
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
Provider-custodial
Judgment call. Payy says it is non-custodial and the note keys sit on the user's device, but the S1 finding (score 0) shows funds at rest in an upgradeable rollup escrow whose owner Safe can overwrite the state root, and S4 (score 0) shows every withdrawal needs Payy's prover. Unlike Exa and MetaMask Card, the provider controls the funds at rest, not only a spend path, so provider_custodial; a reviewer may prefer hybrid.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Licences and registrations
Unknown
The Terms say cards are issued by Rain through issuing partners licensed in their jurisdictions; the card docs say only "U.S.-based" issuer. No issuer name, regulator or licence number is given in any first-party document, so no register could be checked. payy.link states Payy is not a regulated bank.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Cash-out options
Evidenced
Where
Method
Partner
Fee
Limits
everywhere offered
card withdrawal
Rain and a U.S.-based issuer, Visa
none from Payy; Visa rate plus 1% on non-USD
Card spend at merchants (the schema has no card-spend value); spending limited to the wallet balance; some foreign online merchants reject U.S.-issued cards.
everywhere offered
atm
Rain and a U.S.-based issuer, Visa
not stated
Contactless ATM withdrawals in private beta, on request to support.
No bank withdrawal is documented; bank deposits are offered from the U.S. and Argentina only. Payy publishes no country list (no availability block), so ALL here means wherever the card is issued.
Documented
Payy Card docs, Features table (ATM access) and usage notes.
Dates the Ethereum rollup only. Payy ran earlier on a Polygon rollup (0x4cbb5041..., now empty; the repo documents a Polygon to Ethereum mint migration), which was not dated.
Verified
Creation tx 0x8d002955...8abd from 0x6B96F1A8D65eDe8AD688716078B3DD79f9BD7323 at block 24475975 (2026-02-17 10:32:35 UTC, Blockscout); eth_getCode returns 0x at block 24475974 and runtime code at 24475975 (read via eth.drpc.org, since publicnode refuses archive reads).
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Operating entity
Evidenced
Zeplo, Inc. (d/b/a Payy), US · 6772334
The number's register is not stated; it has the form of a Delaware file number and the Terms are performed in Delaware, but the Delaware search is CAPTCHA-protected, so the state is not recorded.
Documented
Terms of Service name Zeplo, Inc. d/b/a Payy as the contracting party.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Security incidents
Unknown
Absence of a found incident is not evidence that none occurred.
No incident disclosure found on payy.link, docs.payy.network or in polybase/payy (no SECURITY.md or post-mortem at 2f95947). The reverted addProver and mint calls of 30 Sep 2026 noted in the CROPS log changed no state and are not an incident.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Product changes affecting users
Evidenced
2026-02-17: RollupV1 deployed on Ethereum; the repo documents a mint migration from the Polygon rollup. source
2026-03-25: MIT LICENSE removed from polybase/payy (commit c4d2c902); RollupV1.sol is UNLICENSED. source
The Polygon to Ethereum migration date is taken from the Ethereum deployment; the repo README gives no date.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Volume transacted (verified only)
Not observable
Card debits are private UTXO note transfers inside the Payy rollup; the L1 contract sees only state roots and proofs, so card spends cannot be separated from other transfers or valued from chain data. Payy's funding of Rain happens off this contract.
UnreviewedAssessed by AI research agent (operational), 2026-10-09
Group B: institutional due diligence
Control
State
What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?
Unknown
No ISO 27001 statement for Zeplo, Inc. (Payy) found in docs.payy.network (llms.txt index, card page, FAQ), payy.link, the Terms of Service or the Privacy Policy.
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 hosting or support organisation certification found.
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?
Unknown
No SOC 2 or ISAE report or statement of availability found.
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?
Attested
Payy says the important parts of its code have been audited; no report, auditor or date is published (CROPS S6 unknown). source 1
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?
Unknown
No penetration-test report or attestation found.
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?
Unknown implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?
Absent
none of 1 repo(s): polybase/payy ✗ no security policy file source 1
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?
Unknown implied from the component list
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?
Evidenced
all of 1 repo(s): polybase/payy ✓ no scanning config or workflow step found source 1
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?
Unknown
The Terms of Service and Privacy Policy contain no security or data-incident notification commitment; the policy promises notice only of material policy changes.
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?
Unknown implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?
Unknown implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?
Unknown
No status page or post-mortem found on payy.link or docs.payy.network.
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?
Evidenced
No login, username, email or password; the wallet key is generated and stored on the device, with optional cloud backup and a recovery phrase. There is no account-level MFA. source 1
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?
Unknown implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?
Unknown implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?
Unknown implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?
Unknown implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?
Unknown implied from the component list
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
Unknown implied from the component list
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?
Unknown implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?
Unknown implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?
Unknown implied from the component list
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?
Unknown implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?
Evidenced
Users can delete their account in the app; no retention period is stated, and Payy stores the network public key address but not the private key. Card KYC data is collected for the card programme (CROPS P2); its retention by Rain or the issuer is governed by Rain's privacy policy, not read. source 1 CROPS P2
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?
Evidenced
The Privacy Policy is issued by Zeplo, Inc. for Payy and refers card data to Rain's privacy policy; it does not name controller and processor roles or mention a DPIA. source 1
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?
Unknown implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?
Unknown implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?
Unknown implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?
Unknown implied from the component list
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?
Absent
none of 1 repo(s): polybase/payy ✗ no deployment configuration source 1
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?
Evidenced
all of 1 repo(s): polybase/payy ✓ rules: deletion, non_fast_forward, creation, update, required_linear_history, copilot_code_review, code_quality, pull_request, required_status_checks source 1
B9.2 CI runs on pull requests Does every pull request trigger automated checks?
Evidenced
all of 1 repo(s): polybase/payy ✓ 2 workflow file(s) source 1
B9.3 Tests run in CI Do the CI workflows run the test suite?
Evidenced
all of 1 repo(s): polybase/payy ✓ test command in a workflow source 1
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?
Evidenced
all of 1 repo(s): polybase/payy ✓ 10 of 10 recent commits signed source 1
B9.7 Changelog Is a changelog maintained with the code?
Evidenced
all of 1 repo(s): polybase/payy ✓ 9 release(s) with notes source 1
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?
Evidenced
all of 1 repo(s): polybase/payy ✓ contribution section in README source 1
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?
Evidenced
docs.payy.network publishes a privacy architecture (privacy layer, PrivacyBridge, privacy vault) for the Payy Network EVM L2, which the CROPS seed excluded as not live for the card. The live Ethereum rollup v1 and the card path (wallet, guild backend, Rain) have no architecture document. source 1
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?
Evidenced
Zeplo, Inc. d/b/a Payy (registration number 6772334 stated on payy.link; office at 169 Madison Avenue, New York; terms performed in Delaware). The card is issued by Rain through issuing partners; Rain's issuing bank is not named. The Delaware register search is behind a CAPTCHA and was not used. source 1 · source 2
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?
Unknown implied from the component list
B11.3 Termination terms What happens to customer funds and data on termination by either side?
Evidenced
Payy may terminate access immediately and without notice for non-compliance "or for any reason"; card use can be restricted, suspended or terminated with immediate effect, with notice and reasons unless unlawful. No statement on funds on termination beyond user control of the wallet; withdrawals depend on Payy's prover (CROPS S4 = 0). source 1 CROPS S4
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?
Unknown implied from the component list
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
Scored the live Payy rollup v1 on Ethereum from polybase/payy at 2f95947; onchain reads are pinned to Ethereum block 26139204. The public repo is a Copybara export without the wallet app, guild backend, or Rain and Sumsub providers. The last verifyRollup before the pinned block was on 2026-09-24 (block 26046439), and the escrow held 710.75 USDC. The ToS is a Google Doc that renders client-side, so its text is archived. P5 and S5 are unknown (app and backend closed). S6 is unknown: the FAQ says "the important parts of Payy's code have been audited" (provider claim), but I found no report.
