Appendix D: Bridge Evaluation

Note

This appendix evaluates Bridge as a candidate provider behind Capxul’s facades. It is the architecture-relevant summary of the full evaluation document (capxul-v2-bridge-platform-evaluation.md in the repository root). The full document includes pricing analysis, revenue modeling, and sales call preparation that are not included here.

What Bridge Is

Bridge is a multi-product stablecoin infrastructure platform owned by Stripe (acquired for $1.1B in late 2024). It is not a single-purpose fiat ramp. Bridge offers:

• Orchestration — fiat-to-crypto and crypto-to-fiat transfers, virtual accounts, liquidation addresses, prefunded accounts
• Cards — Visa-powered virtual cards with Apple Pay / Google Pay provisioning, non-custodial funding model
• Open Issuance — custom stablecoin issuance backed by BlackRock/Fidelity/Superstate reserves (not evaluated for launch — see full working document)
• Customers API — built-in KYC/KYB

How Bridge Maps to Capxul’s Facades

Capxul Facade	Bridge Product	Role	Notes
Fiat Ramp Facade	Orchestration (Transfers, Virtual Accounts, Liquidation Addresses)	Off-ramp and on-ramp provider	Implements the same provider interface as HoneyCoin. Liquidation addresses offer a simplified pattern (one setup per employee vs. per-transaction API calls).
Card Facade	Cards (Visa, virtual, push provisioning)	Card issuer	Non-custodial funding model available (“bring your own wallets”). 4337 smart account compatibility unconfirmed.
Verification Facade	Customers API (KYC/KYB)	Identity provider (optional)	Capxul prefers to keep Shufti Pro as the primary verification provider and pass attestation to Bridge. If Bridge requires its own KYC, dual verification is the fallback.

Fiat Ramp Facade Mapping

Bridge’s Orchestration product maps to the four fiat flows defined in Chapter 5:

Flows 1 & 4 (Employee/vendor off-ramp): Two patterns available:

• Per-transaction transfer: Capxul calls Bridge Transfers API → gets deposit address → session key sends USDC → Bridge pays fiat. Architecturally identical to the HoneyCoin pattern.
• Liquidation address: Each employee gets a persistent Bridge-generated address linked to their bank account. Session key sends USDC to the address. Bridge auto-forwards to the bank. One setup per employee, no per-transaction API cycle.

Flow 2 (Org off-ramp to fiat vendor): Same as Flows 1 & 4 but triggered by the Safe module. Bridge’s deposit address is added to the Zodiac Roles allowlist.

Flow 3 (Org on-ramp via virtual account): Bridge issues persistent USD, EUR, and MXN virtual accounts. Fiat deposits auto-convert to stablecoins on-chain. Key limitation: Bridge lists USD, EUR, and MXN accounts only. Local currency accounts (NGN, GHS, KES, UGX) are not confirmed. If only hard currencies, orgs cannot receive local-currency deposits.

Developer Fees

Bridge’s developer fee mechanism lets Capxul set a custom fee (percentage or flat) on every transfer. The fee is deducted from the transaction, held by Bridge, and distributed monthly. This is a built-in margin capture mechanism not currently available with HoneyCoin.

Prefunded Accounts

Bridge’s prefunded model enables instant off-ramp: Capxul or the org preloads a USD balance with Bridge. When an employee off-ramps, fiat pays out instantly from the prefunded balance. Crypto settlement happens asynchronously. Materially improves employee experience but requires liquidity float.

Card Facade Mapping

Bridge offers Visa-powered virtual cards — the primary reason for evaluating Bridge. See Card Facade for the full card architecture.

Non-custodial funding (Option A — preferred): Bridge’s documentation states cards can be funded from non-custodial wallets. The wallet grants Bridge’s card smart contract permission to spend tokens via approve(). At each card swipe, Bridge pulls stablecoins from the wallet. Critical question: does this work with ERC-4337 smart accounts on Base? Bridge’s examples show Solana addresses. EVM 4337 compatibility is unconfirmed.

Top-up funding (Option B — fallback): Employee transfers USDC to a Bridge-managed card wallet. Adds friction but works regardless of wallet type.

Org cards: Bridge must support multiple cards per organization with different spending limits, all drawing from the same funding source (the Safe). This is table stakes for corporate cards but must be confirmed.

Mobile wallets: Push provisioning to Apple Pay and Google Pay. Per-market availability must be confirmed (Apple Pay is available in Nigeria since 2023 and Kenya; Google Pay is more limited in West Africa).

Geographic Coverage — The Critical Question

Bridge lists Capxul’s target African markets (including Nigeria, Ghana, Kenya, Uganda) as “Restricted” (supported with additional monitoring). But Bridge’s documentation clarifies: “this table refers to where Bridge can onboard customers based on their residence, not where Bridge can support transactions.”

Onboarding support ≠ local currency payout support. For the first configured African markets, Capxul needs:

• NGN payouts to Nigerian bank accounts (GTBank, Access Bank, First Bank)
• KES payouts to M-Pesa
• GHS payouts to Ghanaian bank accounts and MTN MoMo
• UGX payouts to Ugandan bank accounts and MTN MoMo

If Bridge cannot deliver naira to a GTBank account, Bridge cannot replace local-rail providers for the core off-ramp flows in Africa. Bridge may serve Middle East and Latin America markets well (phase 2 of the expansion plan) — the multi-provider routing model (Chapter 1) handles this: Bridge for markets it covers, local-rail providers for Africa.

Caution

West Africa local rail support is the single most important question to resolve with Bridge. Everything else is secondary. If local payouts are not supported, Bridge’s role is limited to cards (if available in target markets) and non-African fiat ramps.

Identity Verification Interaction

Bridge has its own Customers API with built-in KYC/KYB. This intersects with Capxul’s strategic decision to own identity verification via Shufti Pro (see Chapter 11).

Preferred approach: Capxul verifies users with Shufti Pro, then registers them as pre-verified in Bridge’s system (attestation passthrough). Users verify once.

Fallback approach: Dual verification — Shufti Pro for Capxul platform access, Bridge’s own KYC for card/ramp operations. Worst UX but highest compliance coverage.

The question to resolve: Does Bridge accept external verification attestation, or does it require its own KYC flow for every user?

Evaluation Rubric

Criterion	Weight	Status
African local rail payouts (NGN, GHS, KES, UGX and beyond)	Critical	Unconfirmed
Card market availability (target African markets)	Critical	Unconfirmed
4337 smart account card compatibility (non-custodial funding on Base)	Critical	Unconfirmed
Multi-card org support (per-Safe, different limits)	High	Unconfirmed
KYC/KYB attestation passthrough	High	Unconfirmed
Fiat ramp API quality (transfers, virtual accounts, webhooks)	High	Likely strong (Stripe infrastructure)
Facade compatibility (sits behind provider abstraction)	High	Compatible (Transfers API maps to off-ramp interface)
Apple Pay / Google Pay in target markets	High	Unconfirmed

Recommendation

Adopt Bridge for cards + fiat ramp orchestration. Keep Shufti Pro for identity. Stay on USDC at launch.

• Cards are the net-new capability. No other evaluated provider offers cards + ramps from one platform.
• Fiat ramp: Bridge likely serves Middle East + Latin America (phase 2 markets). African markets are served by local-rail providers. Multi-provider routing handles the split.
• Identity: Shufti Pro remains primary. Bridge accepts attestation or dual verification as fallback.
• Platform stablecoin (pUSD via Open Issuance): deferred to Phase 2. See full working document for the strategic analysis.

Dependency Consideration

Bridge adds Stripe to the dependency stack. If Bridge provides fiat ramps, cards, and (later) issuance, Stripe touches a significant surface area. The facade architecture mitigates this: fiat ramps are behind the Fiat Ramp Facade (swappable), cards are behind the Card Facade (swappable). Only the platform stablecoin (if adopted) creates a hard dependency. At Scenario A (cards + ramps, no issuance), everything remains swappable.