Companion documents:
PANA-2026-CORR-001— Rafael (USA Diaspora · Uniteller leg) · pendingPANA-2026-CORR-002— Yoselin (LATAM ACH leg) · pendingPANA-2026-CORR-003— Alex (On-Chain leg) · this document
Method: TransactionFeed rows where transactiontype IN ('LiquidationAddress', 'Alchemy', 'ExternalCrypto') and status NOT IN ('Failed', 'Cancelled'). User country attributed via bankapplication.countrycode (most recent). Window: last 6 months unless stated. Reproducible at /api/metabase/alex-validation.
TL;DR
Alex is real and DR dominates the on-chain corridor (60% of users, 68% of volume). The growth trajectory cannot be claimed yet — blockchain transaction recording only began ~Feb 2026, with March 2026 the first reliable month. Three-leg thesis still holds directionally, but the on-chain leg needs ≥2–3 more months of recording before sustained acceleration is provable.
Three caveats to flag explicitly:
- Recording start (CTO confirmed 2026-04-28): blockchain transactions began appearing in
transactionfeedonly around February 2026, with reliable data from March onwards. Pre-March numbers in this document are artifacts of instrumentation, not actual user counts. The "450× over 9 months" framing in earlier drafts has been replaced. - Within DR on-chain activity, the data shows three distinct transactiontype buckets:
Alchemy(2,361 users),LiquidationAddress(515 users),ExternalCrypto(502 users). The pure "Banco Popular off-ramp" pattern most likely maps to theLiquidationAddressslice (~515 users) — but final attribution depends on confirming what each transactiontype represents semantically. See Section 5 + assumption note. - Latest 30d shows volume softening (−29% MoM). Cannot be interpreted yet — only one full reliable month (March) and one partial (April) exist.
transactionfeed began registering blockchain transactions only ~February 2026. Data prior to that is under-counted for on-chain activity. Growth comparisons across that boundary are not interpretable. Sections 1, 2, 4 below report figures that include the under-counted period — they hold directionally (DR is unambiguously #1) but absolute month-over-month deltas pre-March are unreliable. Section 3 has been rewritten to reflect this.
1 · Dominicans dominate on-chain absolutely
Top countries by on-chain users, last 6 months:
| # | Country | Users | Txns | Volume |
|---|---|---|---|---|
| 1 | 🇩🇴 Dominican Republic | 2,513 | 33,215 | $6.92M |
| 2 | 🇨🇴 Colombia | 424 | 3,232 | $650k |
| 3 | 🇬🇹 Guatemala | 311 | 2,420 | $374k |
| 4 | 🇲🇽 Mexico | 284 | 2,386 | $361k |
| 5 | 🇭🇳 Honduras | 237 | 2,137 | $449k |
| 6 | 🇧🇴 Bolivia | 124 | 1,484 | $632k |
| 7 | 🇦🇷 Argentina | 27 | 391 | $125k |
| 8 | 🇨🇦 Canada | 19 | 1,184 | $45k |
| 9 | 🇪🇸 Spain | 35 | 480 | $32k |
| 10 | 🇪🇨 Ecuador | 18 | 278 | $34k |
2 · DR concentration
- 60% of all on-chain users are Dominican (2,513 of 4,190)
- 68% of all on-chain volume is Dominican ($6.92M of $10.13M)
This is the "unfair advantage" — DR isn't just #1, DR is two-thirds of the entire crypto corridor.
3 · DR on-chain users — first months of reliable recording
transactionfeed not yet capturing blockchain activity (per CTO 2026-04-28). The "450× growth" framing from earlier drafts has been retired.
4 · Caveat — latest 30d shows possible softening
| Window | Users | Txns | Volume |
|---|---|---|---|
| Last 30d (Mar 28 – Apr 27) | 1,234 | 6,435 | $1.19M |
| Prior 30d (Feb 26 – Mar 28) | 1,310 | 8,270 | $1.67M |
Volume −29% MoM, users −6%. This comparison should not be treated as a real signal yet for two reasons:
- The "Prior 30d" window (Feb 26 – Mar 28) sits right at the recording-start boundary — Feb data is partially under-counted (per CTO note), so the prior-30d figure is itself unreliable.
- April is truncated at day 27 (3 days short of full month).
5 · Pattern breakdown — DR on-chain activity by transactiontype
5.1 · Real data (BigQuery, last 6 months)
DR users grouped by TransactionFeed.transactiontype:
| transactiontype | Users | Txns | Volume |
|---|---|---|---|
Alchemy | 2,361 | 28,250 | $5.34M |
LiquidationAddress | 515 | 2,806 | $844k |
ExternalCrypto | 502 | 2,159 | $733k |
↑ These numbers are pulled directly from TransactionFeed with no interpretation applied. They are factually correct.
5.2 · Likely behavior mapping ASSUMPTION — pending CTO confirm
Based on industry conventions and Pana's existing query annotations, my working interpretation of each transactiontype is:
| transactiontype | Likely behavior | Confidence |
|---|---|---|
Alchemy | Crypto purchases via Alchemy Pay (on-ramp: fiat → crypto) | Medium — based on Alchemy Pay being a known on-ramp provider in Web3, not on internal Pana docs |
LiquidationAddress | External crypto received → auto-converted to fiat in user's Pana wallet (off-ramp inflow — the "Alex" pattern) | High — "liquidation address" is a standard term and the Pana code labels this as "Crypto Deposit (Liquidation)" |
ExternalCrypto | Crypto sent OUT to an external wallet (debit, on-chain send) | High — Pana code labels this as "Crypto Sent (External)" |
Alchemy = on-ramp purchases has not been validated against Pana's internal product docs or with CTO. If Alchemy turns out to be something else (e.g., crypto routed via Alchemy infrastructure regardless of direction), the off-ramp count could be materially larger than 515 users. Final attribution should be confirmed with CTO before locking the narrative.
5.3 · Reading (under the assumption above)
If the working interpretation holds, the bulk of DR on-chain activity is users buying crypto via Alchemy (~2,361 users), not the off-ramp pattern the CEO described. The pure "Alex" off-ramp pattern (receive external crypto → convert to fiat → bank deposit) maps to ~515 users / $844k volume — significant, but a subset.
6 · What this validation does NOT cover
This document scopes only the on-chain (Alex) leg of the three-leg corridor thesis. The other two legs need separate validation queries:
- "Banco Popular Dominicano dominates the off-ramp" — the destination bank name is not exposed in the
paymenttable fields accessible to the dashboard. CTO redirected this question to @Jose Javi Asilis (Slack#data-discussions); will confirm whether destination bank lives inpayment.jsonmetadata or a separate table. In flight. - Rafael (USA diaspora) leg —
CORR-001— this validation does NOT cover Rafael. His Pana app is registered withcountrycode = 'US'(CFSB bank), so the country attribution puts him in US, not DO. Validating Rafael requires a different query: Uniteller payments destined to DR (not user nationality). - Yoselin (LATAM ACH earner) leg —
CORR-002— the CEO's claim ("Dominicans are #1 nationality in Global, 35,185 signups, ~20% of all Global") has not been independently re-validated against BigQuery in this doc. It needs its own query: Global signups grouped by nationality, with monthly trend, to confirm both the 35,185 figure and the ~20% share. Until then, that number is sourced from the CEO doc, not from this validation.
7 · Open questions (CTO follow-up status, 2026-04-28)
| Question | Status | Detail |
|---|---|---|
| Country attribution field | Refining | Currently using bankapplication.countrycode. CTO clarified that TaxResidence.countryCode is more authoritative for residence; nationality (which can be multiple) lives in the document type within bankapplication. Plan: re-run validation with TaxResidence after the meeting; expected delta is small for Globals (Pana app country usually = residence) but material for US-resident Dominicans (Rafael leg, see CORR-001). |
| Destination bank for off-ramp | In flight | Pinged @Jose Javi Asilis in #data-discussions. Will validate "Banco Popular dominates" claim once schema is confirmed. |
| TransactionFeed completeness for blockchain | In flight | Pinged @Luisi De Leon in #data-discussions. Confirming whether transactionfeed.transactiontype IN ('LiquidationAddress','Alchemy','ExternalCrypto') is exhaustive, or whether payment rows with paymenttype='Crypto' and providertype='Blockchain' need to be unioned in. |
| Canonical TPV definition (related, not blocking this doc) | Tabled | CTO suggested moving the signed-vs-ABS / auth-mirror exclusion discussion to #data-discussions. Doesn't block CORR-003. Headline TPV in product dashboard remains ops-aligned for continuity. |