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
No checkable evidence settles this yet, so it counts as 0.
Jupiter Card
incumbent No public chain settlementdocs.jup.ag
Incumbent rails have no public chain settlement and no public code. They are scored with the same rubric as every other row. Their low ratings show the verifiability gap between rails whose behaviour can be inspected and rails whose behaviour must be trusted; that gap is the point of the comparison, not a claim that the incumbent is unsafe.
At a glance
- Category
- Incumbent baseline
- Chain
- Off-chain
- CROPS tally
- 0 of 23 hold up · 13 no evidence
- Settles in
- USDC, USDT
- Security audits
- 1 published
- Offered
- 51 countries
- Last edited
- 2026-10-13 · History
- Censorship ResistanceWeakest: Admin pause or freeze powers; Settle without the provider; Reliance on hosted services; Token and chain freeze risks disclosed
- OpenWeakest: Contracts verified onchain; Whole stack published; Can be self-hosted; Interfaces and data export
- FreeWeakest: Open-source licences; Protection against relicensing; No proprietary dependencies
- PrivacyWeakest: Tracking and analytics; Payments linkable onchain; Endpoints can be changed
- SecurityWeakest: Who can upgrade the code; Token approval scope; Funds safe if provider disappears; Secrets and webhook handling; Audits and bug bounty
Holds up 0
Nothing rated Partial or Strong.
Falls short 10
Not yet evidenced 13
- Admin pause or freeze powers
- Token and chain freeze risks disclosed
- Contracts verified onchain
- Can be self-hosted
- Interfaces and data export
- Protection against relicensing
- Tracking and analytics
- Payments linkable onchain
- Endpoints can be changed
- Who can upgrade the code
- Token approval scope
- Secrets and webhook handling
- Audits and bug bounty
Where it is offered
Offered only in the countries listed.
Jupiter's docs list where the Jupiter Card is "actively offered", by country of residence (not citizenship). Bangladesh and Nigeria are on the list but marked "on pause until further notice", so they are left out. United States: only residents of the 31 listed states (Alabama, Alaska, Arkansas, California, Colorado, Connecticut, Florida, Hawaii, Illinois, Indiana, Iowa, Kansas, Kentucky, Maine, Massachusetts, Michigan, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, New York, North Carolina, Oklahoma, Pennsylvania, South Carolina, Texas, Utah, Virginia, West Virginia, Wyoming). Two issuers: DCS for residents of Australia, Japan, Malaysia, the Philippines, Singapore, South Korea, Taiwan, Thailand and Vietnam; Rain elsewhere. The docs add that residents of unlisted countries are reviewed case by case during KYC. No Jupiter Spend terms of service or cardholder agreement was found, so there is no prohibited-country list.
Listed countries (51): Antigua & Barbuda, Argentina, Australia, Bahamas, Barbados, Belize, Bolivia, Brazil, Cayman Islands, Colombia, Costa Rica, Côte d’Ivoire, Dominica, Dominican Republic, Ecuador, Egypt, El Salvador, Ghana, Grenada, Guatemala, Guyana, Honduras, Japan, Kenya, Malaysia, Mexico, Morocco, New Zealand, Pakistan, Panama, Paraguay, Peru, Philippines, St. Kitts & Nevis, St. Lucia, St. Vincent & Grenadines, Senegal, Singapore, South Africa, South Korea, Suriname, Taiwan, Thailand, Trinidad & Tobago, Turks & Caicos Islands, Uganda, United Arab Emirates, Uruguay, Vietnam, Zambia, United States
Evidence (2)2 documented
- Documented
The Jupiter Card docs list supported countries of residence and supported US states, and name the issuer for each region.
- Documented
The list marks Bangladesh as paused; Nigeria is marked the same way further on.
Settlement token
What the balance is held in and debited from. Shown as context; it does not change any rating.
| Token | Class | Issuer | Contract |
|---|---|---|---|
| USDC Default | fiat-backed stablecoin | Circle | |
| USDT | fiat-backed stablecoin | Tether |
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.
USDC is the base asset. The Solana deposit address takes USDC or USDT directly; tokens from Ethereum, Base, Arbitrum, Sui, BSC and Robinhood Chain arrive through Universal Deposit and are converted to USDC, and Send to Spend in Jupiter Mobile swaps any other token into USDC. Deposits are not converted to USD on arrival (the app only displays a USD balance); with a Rain-issued card they stay onchain as collateral and purchases settle over Visa in fiat. The DCS (Asia-Pacific) card's settlement mechanics are not documented separately.
Evidence (3)3 documented
- Documented
The Jupiter Card page says USDC and USDT deposits are not converted to USD on arrival and stay onchain as collateral with a Rain card.
- Documented
The Spend page names USDC as the base deposit asset and says other tokens are converted to USDC.
- Documented
Purchases settle over Visa in fiat.
Censorship Resistance
Who can block valid use, and can users route around them?
Pillar rating: weakest of 5
0 of 5 Partial or better · 2 no evidence
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.
- Token and chain freeze risks disclosed reaching Weak: Enumerated in docs only.
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
Merchants are paid by the issuer over Visa. No contract path for payer or payee is documented or published.
Evidence (1)1 documented
- Documented
The Jupiter Card page says deposits fund a USD-denominated Spend balance and purchases settle over Visa in fiat through the issuer (Rain or DCS by country).
Reliance on hosted services
Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3
Every card payment needs Jupiter's closed Spend backend plus Rain or DCS and Visa. None is public and there is no fallback. Closed and single-vendor per user (each user gets one issuer, assigned by country).
Evidence (1)1 documented
- Documented
Risks & Security lists Rain and DCS (card), Noah (off-ramp and remittance) and DCS (QR Pay) as the partners each product runs through.
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
Geographic and KYC gating is disclosed in the docs; where and how it runs (Jupiter backend, SumSub, issuer) is not inspectable, and it cannot be bypassed because there is no direct path (C2 = 0). Disclosed in docs only, so 1.
Evidence (1)1 documented
- Documented
The card page lists supported countries and US states, says eligibility is by country of residence and reviewed during KYC; the FAQ says some merchant categories are declined for compliance and risk reasons.
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
The weekly re-check found that a recorded fact changed. This rating counts as unknown until a reviewer re-checks it.
Tokens and chains are listed in docs only, with no statement of issuer freeze powers or sequencer assumptions for Arbitrum and Base. 1.
Evidence (1)1 documented
- DocumentedDrift
Deposit tokens and chains are enumerated on the card page and the Fees & Limits page; neither states the USDC or USDT issuers' freeze powers or any L2 sequencer assumption.
Open
Is the whole stack visible?
Pillar rating: weakest of 4
0 of 4 Partial or better · 3 no evidence
What would raise this pillar
- Contracts verified onchain reaching Weak: Some contracts verified.
- Whole stack published reaching Weak: SDK or contracts only.
- Can be self-hosted reaching Weak: Docs exist; reproduction not attempted, or failed with blockers listed.
- Interfaces and data export reaching Weak: Documented only.
Contracts verified onchain
Does the deployed bytecode match public source, and can a third party rebuild it? O1
No checkable evidence settles this yet, so it counts as 0.
Whole stack published
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
No part of the card stack is public. The Solana-pay repos in jup-ag are unrelated forks. 0.
Evidence (1)1 documented
- Documented
The card stack is Jupiter's app and backend plus partner services; none of the 202 repositories in github.com/jup-ag relates to Spend or the card (searched names and descriptions for spend, card, global, pay, rain, kyc, offramp).
Can be self-hosted
Can a stranger reach a working deployment from the README? O3
No checkable evidence settles this yet, so it counts as 0.
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
No checkable evidence settles this yet, so it counts as 0.
Free
Does the license actually let a third party fork, modify, and run it?
Pillar rating: weakest of 3
0 of 3 Partial or better · 1 no evidence
What would raise this pillar
- Open-source licences reaching Weak: Source-available (BUSL, SSPL, ELv2, Commons Clause, custom) on a critical repo.
- Protection against relicensing reaching Weak: CLA permits relicensing; commitment exists in docs.
- No proprietary dependencies reaching Weak: Documented that production needs a hosted service with no open alternative.
Open-source licences
Does every repository needed to run the product carry an OSI-approved license? F1
Required components are closed, so 0.
Evidence (1)1 documented
- Documented
The product runs on Jupiter's closed app and backend and on partner programmes; no repository needed to run it is public.
Protection against relicensing
Can the provider unilaterally relicense future versions, and has it committed not to? F2
No checkable evidence settles this yet, so it counts as 0.
No proprietary dependencies
Does a production deployment need a proprietary plugin or hosted-only service? F3
The product cannot run without proprietary hosted services. 0.
Evidence (1)1 documented
- Documented
The card cannot work without Jupiter's Spend service and the Rain or DCS card programme.
Privacy
What can an observer learn, and did the user knowingly choose it?
Pillar rating: weakest of 5
0 of 5 Partial or better · 3 no evidence
What would raise this pillar
- Tracking and analytics reaching Weak: Present, on by default, disclosed in docs.
- Payments linkable onchain reaching Weak: Invoice IDs or payee tags in events, disclosed.
- Endpoints can be changed reaching Weak: Documented workaround.
Tracking and analytics
Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1
No checkable evidence settles this yet, so it counts as 0.
Data collected beyond payment
Does the flow collect anything beyond addresses, amounts, token, and chain? P2
KYC data beyond settlement needs is collected and its legal purpose is stated, but only in hosted docs; no privacy policy for Jupiter Spend was found. Documented cap, so 1.
Evidence (1)1 documented
- Documented
Global ID verification requires an identity document, phone number, liveness check, personal information and a questionnaire, plus proof of address in APAC; verification data is handled by SumSub and a Global ID cannot be deleted once created.
Payments linkable onchain
What do calldata and events reveal about who paid whom for what? P3
No checkable evidence settles this yet, so it counts as 0.
Third parties in the payment flow
Which third parties see a request during a payment, and can they be swapped out? P4
The third parties that see a card payment (issuer, Visa, SumSub, Noah for withdrawals) are named in docs and are not swappable; each user gets one issuer by country. No trace was run. Present, disclosed in docs only, so 1.
Evidence (1)1 documented
- Documented
The Spend overview names SumSub for identity verification; Risks & Security names Rain, DCS and Noah for card, QR Pay, off-ramp and remittance.
Endpoints can be changed
Can RPC and indexer URLs be changed, and is the indexer code public? P5
No checkable evidence settles this yet, so it counts as 0.
Security
Who can cause loss, lock users in, or change the rules?
Pillar rating: weakest of 6
0 of 6 Partial or better · 4 no evidence
What would raise this pillar
- Who can upgrade the code reaching Weak: Multisig admin, no timelock.
- Token approval scope reaching Weak: Unbounded by default, disclosed.
- Funds safe if provider disappears reaching Weak: Funds retrievable only through a documented manual contract call.
- Secrets and webhook handling reaching Weak: Secrets in client with a disclosed mitigation.
- Audits and bug bounty reaching Weak: Audit report only (documented tier cap).
Who holds funds in transit
Who holds funds between payer and payee, and can the provider redirect them? S1
Between deposit and merchant, funds are held by Jupiter's partners, which is disclosed. The Rain "onchain collateral" statement could not be checked, because no collateral address or program id is published. Provider-held, disclosed, so 1.
Evidence (1)1 documented
- Documented
Deposits go to a per-user Spend deposit address and credit a USD balance; with a Rain card the docs say the stablecoins stay onchain as collateral, but no address or contract is published.
Who can upgrade the code
Who can change the contract code, and with how much notice? S2
No checkable evidence settles this yet, so it counts as 0.
Token approval scope
How large an allowance does the SDK ask users to grant, and for how long? S3
No checkable evidence settles this yet, so it counts as 0.
Funds safe if provider disappears Derived
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4
Derived: custody is with partners (S1 = 1), there is no direct settlement path (C2 = 0), every service is closed and single-vendor (C3 = 0), and nothing can be self-hosted. The only documented exit is a partner-run, region-dependent bank withdrawal, so funds depend on the provider and its partners being live. 0.
Evidence (1)1 documented
- Documented
The FAQ says withdrawals from the card balance go to a bank account via Noah, are region-dependent, are not possible for USDT deposits, and refunds on Rain cards cannot be withdrawn; no crypto withdrawal path is documented.
Secrets and webhook handling
Are secrets kept out of client bundles and are webhooks signed and verified? S5
No checkable evidence settles this yet, so it counts as 0.
Audits and bug bounty
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
No checkable evidence settles this yet, so it counts as 0.
Security audits 1
Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.
| Date | Auditor | Type | Scope | Covers deployed code | Findings |
|---|---|---|---|---|---|
| 2025-02-11 | Sherlock | Audit contest | Shared component: Rain EVM collateral contracts v2 (Beacon, Collateral, Coordinator, Factory), private best-efforts contest at 6f578d5b9cLogged because Rain issues the card outside APAC and the docs say Rain-card deposits stay onchain as collateral. Rain publishes no collateral address for this card and deposits are Solana-first, so these EVM contracts may not hold Jupiter Card collateral. The Rain repo is private; contest ran 2-8 December 2024. | Unknown | 0 high, 2 medium (statement payoff rounding; missing Chainlink min/max answer check) |
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: 14 evidenced, 3 attested, 0 absent, 0 not applicable, 28 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
| Component | Paid by | Amount | Basis |
|---|---|---|---|
| card | payer | No annual fee; physical card $13.13 plus shipping; Claynosaurz virtual card $25 | Fees & Limits; card orders non-refundable. |
| network | payer | Deposit: none on Solana; Ethereum, Base, Arbitrum, Sui: higher of $0.30 or 0.02% plus gas | Fees & Limits; minimum deposit $3 ($10 on Ethereum). |
| fx | payer | 1% on non-USD (Rain cards); 1.8% (DCS cards) | Fees & Limits; set by the issuer. |
| cashout | payer | ATM (Rain only): $1 + 0.65%, plus $0.30 + 1% if non-USD; $0.60 balance inquiry or decline | Fees & Limits; DCS cards have no ATM access. |
| cashout | payer | Bank payout via Noah: fixed + variable per corridor, e.g. ACH $2 + 0.05%, SEPA $1 + 0.10%, SWIFT $30 + 0.05% | Fees & Limits, Payout Fees; may change. |
| limit | none | DCS: $50,000/day, $990,000/year; Rain: no limit | Fees & Limits, Spending Limits. |
No USD payment fee. Remittance deposits by bank transfer also carry fees (e.g. ACH $2 + 0.05%). The standard virtual card price is not listed.
- Documented
Jupiter Spend Fees & Limits, physical card.
- Documented
Fees & Limits, deposit note.
- Documented
Fees & Limits, card fees and regional differences.
- Documented
Fees & Limits, ATM withdrawal (Rain).
- Documented
Fees & Limits, Payout Fees table.
Custody model
Provider-custodial
Agrees with S1 (1): Spend balances are managed by the issuing partners. The Rain "onchain collateral" claim has no published address and is not used.
Licences and registrations
| Entity | Country | Regulator | Licence | Register |
|---|---|---|---|---|
| Nimbus LLC d/b/a Third National (Rain) partner | United States | Not named in any document | Licensed lender and money transmitter; Visa-authorized card issuer (as stated by Rain) Issuer for Rain cards outside the nine DCS countries (Jupiter names only "Rain"). |
Attested only. Jupiter names "Rain" and "DCS" without entities or licences; DCS and Noah were not identified in any register. FDIC BankFind lists no institution named Third National or Nimbus; NMLS blocked scripted access; the Puerto Rico OCIF check could not be reached.
- Documented
Jupiter Spend, Risks & Security.
- Documented
Rain privacy policy, Entity Roles and Data Flows: describes Nimbus LLC, doing business as Third National, without naming a regulator, state or licence number.
- Documented
FDIC BankFind institutions API, run 2026-10-09: the closest matches for "Third National" are other banks (Fifth Third Bank, N.A. and inactive banks); a search for NAME:Nimbus with ACTIVE:1 returns 0 institutions. NMLS Consumer Access returned HTTP 403 to a scripted request and was not bypassed; the Puerto Rico OCIF licence check (concesionarios.ocif.pr.gov) failed the TLS handshake.
Cash-out options
ATM and bank rows exclude the DCS countries; bank rows also exclude Pakistan and Panama (no EUR or USD off-ramp). A Solana wallet withdrawal also exists for some cards; it is not a cash-out.
- Documented
Jupiter Card, Card Issuers.
- Documented
Fees & Limits.
- Documented
Fees & Limits, Withdrawals, with the restricted-region table.
First deployment
No dated launch announcement or effective-dated terms found (docs undated; jup.ag legal and blog paths 404; the public jup-ag/docs repo holds no Spend pages).
Operating entity
Contracting entity for Spend not documented: the interface Terms name "Jupiter" at a Grand Cayman address under Panama law, and the privacy policy names Block Raccoon S.A. (Panama); neither mentions Spend (see B11.1).
Security incidents
- 2026-09-28: Rain platform: unexpected card declines and API issues for some partners, 18:53 to 19:35 UTC; root cause still under investigation. Rain-wide; which programmes were affected is not stated. funds lost: unknown source
- 2026-06-25: Rain platform: elevated API error rates for 3h32m, caused by an expired encryption certificate. funds lost: unknown source
- 2026-06-03: Rain platform: partial outage affecting card authorizations for 9 minutes, attributed to operating-system patching at a partner. funds lost: unknown source
- 2026-05-05: Rain platform: elevated card declines for 3h10m from a partial outage at its payment processor. funds lost: unknown source
- 2026-01-02: Rain platform: elevated card declines for 1h15m from an incident in the processor rules engine; Rain stated funds were safe. funds lost: no source
Absence of a found incident is not evidence that none occurred.
No Spend incident report found in the docs or on status.jup.ag. Entries are Rain platform incidents (Rain-issued cards only); not stated which programmes were affected.
- Documented
Rain status incident 2026-09-28.
status.rain.xyz/issues/2026-09-28-api-issues-unexpected-declines
- Documented
Rain status incident 2026-06-25.
- Documented
Rain status incident 2026-06-03.
- Documented
Rain status incident 2026-05-05.
status.rain.xyz/issues/2026-05-05-elevated-authorization-declines
- Documented
Rain status incident 2026-01-02.
status.rain.xyz/issues/2026-01-02-payementology-rules-declines
Product changes affecting users
Spend docs carry no dates; no changelog found.
Volume transacted (verified only)
Incumbent: the provider file lists no contracts, so there is nothing a volume spec could be computed over; card settlement runs offchain through the issuer and Visa.
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 Jupiter Spend. Jupiter's security page lists audits of its onchain programs only; Rain lists SOC 2 Type II and PCI DSS; nothing found for DCS or Noah. |
| 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 | |
| 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? | Attested | Jupiter states nothing for Spend. Partner (Rain, for Rain-issued cards): SOC 2 Type II and PCI DSS, reports available to partners on request; not read. Jupiter's docs name Rain as issuer outside the nine DCS countries, so Rain's statements cover Rain-issued cards only; nothing was found for DCS or Noah. source 1 · source 2 |
| 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 | Jupiter says Rain-card deposits stay onchain as collateral; Rain says its contracts are independently audited before launch and per chain. No report linked and no collateral program identified (CROPS S6 unknown). Jupiter's published audits cover its own onchain programs, not Spend. source 1 · source 2 |
| B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available? | Attested | Partner (Rain): penetration test summary available to partners through its trust center. Nothing from Jupiter, DCS or Noah. Jupiter's docs name Rain as issuer outside the nine DCS countries, so Rain's statements cover Rain-issued cards only; nothing was found for DCS or Noah. source 1 |
| B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months? | Evidenced | Partner (Rain): code peer-reviewed and automatically scanned before production; no cadence. Nothing from Jupiter for Spend. Jupiter's docs name Rain as issuer outside the nine DCS countries, so Rain's statements cover Rain-issued cards only; nothing was found for DCS or Noah. source 1 |
| 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)? | Unknown | |
| 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 | |
| B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically? | Unknown | |
| Incident reporting and continuity | ||
| B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)? | Evidenced | No Jupiter commitment found. Partner (Rain): documented incident response plan keeping partners informed; no time stated. Jupiter's docs name Rain as issuer outside the nine DCS countries, so Rain's statements cover Rain-issued cards only; nothing was found for DCS or Noah. source 1 |
| B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule? | Unknown | |
| B3.3 Recovery plan Is there an approved and tested recovery plan for the service? | Unknown | See CROPS S4 (0): the only documented exits are partner-run withdrawals. |
| B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents? | Evidenced | Jupiter's status page (status.jup.ag) covers the website and trading APIs, not Spend or the card. Partner (Rain): status.rain.xyz with incident history; no post-mortems found. Jupiter's docs name Rain as issuer outside the nine DCS countries, so Rain's statements cover Rain-issued cards only; nothing was found for DCS or Noah. 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? | Evidenced | Global ID sign-in by an emailed verification code or a Google or Apple account; no password and no separate second factor. Unfreezing a DCS-issued card asks for an SMS code. source 1 |
| B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts? | Unknown | |
| B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly? | Unknown | |
| 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 | |
| B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)? | Unknown | |
| API and integration | ||
| B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls? | Unknown | No Spend API is documented; Jupiter's developer APIs cover trading only. |
| 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 | |
| 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 | |
| B5.4 Export controls If an API exports data, does it limit volumes and log exports? | Unknown | |
| 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? | Evidenced | Jupiter interface privacy policy: encryption in transit and at rest, access controls and NDAs. Partner (Rain): encryption in transit and at rest, PCI DSS. Observed: jup.ag refuses TLS 1.1 and accepts TLS 1.2. No data classification; no Spend-specific policy. source 1 · source 2 · source 3 |
| 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 | |
| B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination? | Evidenced | A Global ID cannot be deleted once verified; identity documents are held by SumSub, not Jupiter. The interface privacy policy keeps data as long as needed for its purposes; Rain keeps card records five years or longer after closure. No Spend-specific retention schedule. 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? | Evidenced | Block Raccoon S.A. (Panama) is controller for interface data; Spend is not mentioned. SumSub handles verification; Nimbus LLC (Third National) is controller for Rain card issuance. No DPIA statement. source 1 · source 2 |
| B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent? | Unknown | |
| Logging and monitoring | ||
| B7.1 Audit logging Are account changes, logins and activity on important records logged and retained? | Unknown | |
| B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms? | Evidenced | Partner (Rain): security events monitored centrally; no SIEM or endpoint detection named. Jupiter: some merchants are dynamically restricted by fraud and risk monitoring. Jupiter's docs name Rain as issuer outside the nine DCS countries, so Rain's statements cover Rain-issued cards only; nothing was found for DCS or Noah. source 1 |
| 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 | |
| B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden? | Unknown | |
| Engineering practice in public repositories | ||
| B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes? | Unknown | |
| B9.2 CI runs on pull requests Does every pull request trigger automated checks? | Unknown | |
| B9.3 Tests run in CI Do the CI workflows run the test suite? | Unknown | |
| B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)? | Unknown | |
| B9.5 Versioned releases Are releases tagged with immutable semantic versions? | Unknown | |
| B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed? | Unknown | |
| B9.7 Changelog Is a changelog maintained with the code? | Unknown | |
| B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released? | Unknown | |
| Architecture documentation | ||
| B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used? | Evidenced | Logical view only: the docs map each Spend product to its partner (card: Rain or DCS; off-ramp and remittance: Noah; QR Pay: DCS) and describe deposits and balances. No infrastructure or integration architecture. source 1 |
| Commercial and financial | ||
| B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction? | Evidenced | No Jupiter Spend terms are public. The interface Terms of Use name "Jupiter" with a registered address in Grand Cayman under Panama law; the privacy policy names Block Raccoon S.A. (Panama) as controller; neither mentions Spend. Card terms with Rain or DCS are not published. source 1 · source 2 |
| B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source? | Evidenced | Only fee revenue is documented (FX, ATM, physical card, deposit processing, payout fees). No funding statement or financial statements for Spend. source 1 |
| B11.3 Termination terms What happens to customer funds and data on termination by either side? | Evidenced | Jupiter may disable interface access at any time; Spend users are bound by partner terms. Card balances can leave only through the Send routes (Solana wallet or Noah bank transfer, not for every card); DCS-card balances cannot be withdrawn; Rain-card refunds cannot be withdrawn. A Global ID cannot be deleted. source 1 · source 2 |
| AI components | ||
| B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)? | Evidenced | Yes: merchants may be dynamically restricted by fraud, abuse or risk monitoring systems, and Rain uses automated fraud, sanctions and transaction monitoring. Machine learning is not stated. source 1 · source 2 |
| B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented? | Evidenced | Only Rain's override path (human review where law grants it). Nothing from Jupiter. source 1 |
Scope of assessment
Components in the payment path
| Component | Role | Public | Licence | Operator | Required |
|---|---|---|---|---|---|
| Jupiter app (Spend tab) and Global ID account (email, Google or Apple sign-in) | frontend | No | proprietary | Jupiter | Yes |
| Jupiter Spend backend and per-user deposit address | backend | No | proprietary | Jupiter | Yes |
| Rain card programme (issuer outside APAC; collateral claimed onchain) | card-issuer | No | proprietary | Rain (Signify Holdings, Inc.) | Yes |
| DCS card programme (issuer for nine APAC countries) | card-issuer | No | proprietary | DCS | No |
| Visa card network | card-network | No | proprietary | Visa | Yes |
| SumSub identity verification (Global ID) | kyc | No | proprietary | Sumsub | Yes |
| Noah off-ramp (card balance to bank) | other | No | proprietary | Noah | No |
Repositories
None found. Absence of public code is itself a finding.
Contracts
None listed.
Assessor notes
Eligibility: no verified contract and no public repository needed to run the card, so type is incumbent. Searched 2026-10-07: docs.jup.ag (llms.txt index; Spend overview, Jupiter Card, Risks & Security, Fees & Limits, FAQ); github.com/jup-ag (202 repos; none for Spend, card, Global ID or Rain); jupiter.global and jup.ag for terms or privacy pages (404); Rain's GitHub org SignifyHQ, whose collateral-contract-integration-examples repo has Solana IDLs (v2.00-2.05) but no mainnet program id, and whose Android SDK test fixtures name only a devnet program (A7oUtbpm..., absent on mainnet). The docs say Rain-card deposits stay onchain as collateral; if Rain or Jupiter publishes the collateral program or a user's collateral account, re-assess as type card. Deposits are also accepted on Ethereum, Sui, Arbitrum and Base. Card Map was not used.