Argyle covers US payroll. Cr3dentials covers everywhere people actually earn.
Banks, gig platforms, e-commerce stores, payment processors, creator dashboards, government identity portals, plus US payroll. One integration, one schema per use case, one cryptographically signed attestation per session.
Argyle has the deepest US payroll connector library available. If your product is US payroll only, that depth is hard to beat. Cr3dentials covers US payroll too, but extends to every other category of source data your underwriting might want: bank balances, gig earnings, merchant revenue, identity attributes, subscription tenure. Plus a privacy architecture that keeps raw data inside a hardware-attested enclave instead of in either party's servers.
What we verify
Six categories, one integration
Cr3dentials is platform-agnostic by architecture. Coverage spans every category of source data lenders actually underwrite against, not just payroll.
Banks
- Chase
- Bank of America
- Wells Fargo
- Citi
- Capital One
Plus European, African, and LATAM equivalents. Verifiable: average balance, balance-on-date, recurring deposit pattern, account ownership.
Payroll
- ADP
- Gusto
- Workday
- Paychex
- Rippling
Verifiable: gross monthly income, employer verification, YTD earnings, employment duration. The one category where Argyle is genuinely deeper.
Gig & freelance
- Uber
- Lyft
- DoorDash
- Instacart
- Upwork
- Fiverr
- TaskRabbit
Verifiable: trailing 30/60/90-day earnings, payout consistency, platform tenure. The income signal traditional underwriting cannot read.
Merchant & creator
- Stripe
- Shopify
- Square
- Etsy
- Amazon Seller
- Substack
- Patreon
Verifiable: trailing revenue, dispute rate, payout consistency.
Government identity
- gov.uk
- US state DMV portals
- National ID portals
Verifiable: age-over-threshold, residency, without revealing the underlying document.
Subscription & content
- Streaming platforms
- SaaS subscriptions
- Content platforms
Verifiable: active subscription status, account tenure, structured activity history.
Side by side
Cr3dentials vs Argyle
| Property | Cr3dentials | Argyle |
|---|---|---|
| Source platform categories covered | Six: banks, payroll, gig & freelance, merchant & creator, government identity, subscription & content. | Primarily one: US payroll and employment. |
| Geographic coverage | Global outside the EU. US, Nigeria, South Africa, LATAM, Southeast Asia. | Predominantly US-focused. Coverage outside the US is limited by connector availability. |
| What the partner receives | Only the fields defined in the integration-time schema. Booleans, raw values, or both. | The aggregated income or employment record returned by the source connector. |
| Data outside the partner's actual need | Never extracted. Schema enforcement runs inside the TEE, so anything not in the schema never leaves the enclave. | Returned by default. Filtering happens in your application code, after raw data has reached your servers. |
| Where raw user data lives | Only inside the hardware-attested enclave, briefly, then memory is wiped. | In the aggregator's infrastructure (typically retained for the session's lifecycle or beyond), and in the partner's servers. |
| Cryptographic provenance | zkTLS proof that the response came from the real source platform, unmodified, at the claimed time. | API trust only. The partner relies on the aggregator's representation of what the source returned. |
| Independently verifiable audit chain | GCP-signed attestation JWT plus published workload image digest. Any third party can re-verify offline against Google's attestation root. | Not exposed. The partner trusts the aggregator's logs. |
| Onchain consumption | Attestations anchored via Ethereum Attestation Service. DeFi protocols and smart contracts can consume the proof directly. | No first-class onchain attestation path. |
| User installs anything | No (iframe-only flow inside the partner's app). | No (web-flow authentication). |
Which to choose
Pick the one that fits the use case
Both products solve income verification but for different buyers. Argyle's strengths are real; so are ours. Here is how to tell which one belongs in your stack.
US payroll, deep connector library
Your product originates US-domiciled credit against payroll income, and your risk team has signed off on an aggregator retaining raw account data on your behalf. The breadth of Argyle's US employer integrations within payroll is the strongest reason to pick them.
- US-only or US-first product
- Income or employment verification is the primary use case
- Compliance posture accepts an intermediary holding raw records
- Pre-built connector depth for US payroll providers is the deciding factor
Anything beyond US payroll
Your underwriting needs signal from sources Argyle doesn't connect to, or your buyer base extends past the US. Bank balances, gig earnings, merchant revenue, identity attributes, creator dashboards, and subscription tenure are all in scope, plus US payroll where you need it.
- Bank, gig, merchant, identity, or creator-platform data (not just payroll)
- Operating in Nigeria, South Africa, LATAM, Southeast Asia, or globally
- Onchain underwriting that needs a portable, offline-verifiable attestation
- Compliance posture requires hardware-enforced data minimization
What makes us structurally different
Three things you also get with Cr3dentials
Coverage is the headline reason most teams pick Cr3dentials. These three architectural properties are what their compliance and risk teams keep around for.
01
Schema enforced in hardware, not in code
The verification schema is agreed at integration and built into the workload running inside a Google Cloud Confidential Space enclave (Intel TDX or AMD SEV-SNP). Cr3dentials operators cannot widen the schema at runtime, and an attacker who fully compromises Cr3dentials production infrastructure still cannot read anything outside it.
02
Source credentials never leave the user's browser
The verification flow runs in a cross-origin iframe loaded from a Cr3dentials-controlled origin. The TLS handshake is between the user's browser and the real source platform, and Cr3dentials servers see only encrypted traffic. The aggregator model, by contrast, terminates the user's session inside the aggregator's infrastructure.
03
Independently verifiable, offline
Every attestation includes a GCP-signed JWT tied to the published workload image digest. A regulator, auditor, or downstream lender can re-verify the chain against Google's attestation root years later, without contacting Cr3dentials. Aggregator outputs are vendor claims. Cr3dentials outputs are independently checkable evidence.
FAQ
Common questions
Does Cr3dentials cover the same US payroll platforms Argyle does?
Cr3dentials covers the major US payroll platforms including ADP, Gusto, Workday, Paychex, and Rippling, and goes wider into banks, gig platforms, merchant dashboards, and government identity portals. Argyle's US payroll connector depth is genuinely ahead in raw breadth within that one category, which is why we list it as a reason to pick Argyle if US payroll is your entire use case. If your verification need is broader than payroll, or you operate outside the US, that breadth advantage doesn't apply to your buyer profile.
Aren't you just hiding the data Argyle returns? What's structurally different?
The difference is who sees the raw response. In an aggregator architecture, the aggregator's servers see the full source response while extracting fields for your application, and your application sees whatever the aggregator returns. In Cr3dentials' architecture, the encrypted zkTLS proof is opened only inside a hardware-attested enclave, the schema evaluator extracts only the agreed fields, and memory is wiped. Cr3dentials' own operators cannot read the underlying data either. That is a property of the hardware boundary, not a policy.
Can Argyle integrate with my onchain protocol?
Argyle does not offer a first-class onchain attestation path. If you're building DeFi underwriting or any protocol that consumes verification onchain, you typically end up bridging Argyle outputs via an off-chain oracle, which reintroduces the trust assumption Argyle's own servers were already a single point of. Cr3dentials anchors attestations via Ethereum Attestation Service, so smart contracts can verify directly without an oracle intermediary.
How long does integration take compared to Argyle?
Cr3dentials integration is two API calls plus a webhook: initiate session, embed iframe, receive attestation. The one-time setup is defining your verification schemas with us at integration. Runtime never re-declares fields. Most partners are live in days, not weeks. The schema-at-integration model is also what produces the audit guarantee: the partner cannot quietly widen the data they receive over time.
How do we independently verify Cr3dentials isn't over-sharing?
Three checks, all offline. (1) Verify the Cr3dentials signature on the attestation against our published public key. (2) Verify the embedded GCP attestation JWT against Google's public attestation root, which proves the workload ran in real Intel TDX or AMD SEV-SNP hardware. (3) Compare the workloadImageDigest against the SHA-256 of our published enclave container image. If all three pass, the running enclave was provably the published code, not a modified version that might have logged anything.
See it on your own data
Bring a representative source platform and the schema your underwriting actually needs. We'll wire up a verification session against your environment.