Blockchain strategy — análisis SSI on-chain y tokenización Açaí

Campo	Valor
Status	Implemented-Phase-1 (2026-05-31)
Autor	blockchain-architect (agente)
Pregunta del producto	”¿Puedo aprovechar blockchain para la wallet SSI y para los tokens Açaí?”
Fase 1 entregada	2026-05-30 · 11 sub-PRs (BCS-01..08 + BCS-15 + BCS-QA + BCS-W5) · Polygon Amoy testnet pre-launch
Fase 2 Açaí tokenización	DEFERRED — 0 de 3 triggers cumplidos, re-evaluar cuando T1/T2/T3 se aproximen
Re-evaluar si	(i) regulación COL define cripto-activos de utilidad, (ii) emerge consumer real de VCs portables off-bjungle, (iii) primer cliente Tier-2 OIDC con use case Web3

Resumen ejecutivo (TL;DR)

El usuario hizo dos preguntas. Las respuestas honestas:

1. ¿Blockchain para el wallet SSI? Sí, pero solo el caso “off-chain + hash on-chain” y solo en Fase 1 piloto. Los demás casos (DID portability completa, soulbound tokens, on-chain identity completo) son NO por ahora — el modelo Modelo C ya entrega 80% del valor “SSI portable” y el 20% restante no tiene mercado verificado en Colombia 2026.

• VC notarization (hash batch en L2): SÍ por fases. Resuelve un threat concreto (bjungle compromised silently re-emite VCs falsas con timestamps backdateados). Costo: ~USD 0.72-1.20/mes en gas (anchor batch cada 4h, status list updates) + USD 5-10/mes storage IPFS+Arweave. Ver sección Facturación por evento del wallet bjungle para desglose evento por evento.
• Revocation registry público on-chain: SÍ por fases, lazo con el anterior. Mismo merkle root.
• DID portability did:web → did:ion / did:plc: NO por ahora. Marketing-driven, sin RP que lo pida.
• Soulbound tokens (SBT) para Web3 RPs: NO por ahora. Mercado Colombia 2026 es marginal; reabrir cuando aparezca un primer cliente concreto.

2. ¿Blockchain para Açaí? NO tokenizar todavía. El postgres ledger interno actual es la decisión correcta para el estadio del producto. Pasar a ERC-20 hoy introduce 3-6 meses de regulación + UX degradado + costo operacional sin demanda verificada.

Si en 12-18 meses aparece (a) demanda explícita de portabilidad, (b) opinión legal favorable de SuperFinanciera sobre activos virtuales de utilidad, y (c) un segundo operador externo dispuesto a aceptar Açaí cross-tenant, evaluar el modelo híbrido (d): ledger interno por default + withdraw opcional a ERC-20 L2 (Polygon o Base) bajo custodia MPC.

Lo único que SÍ recomiendo arrancar ahora es la Fase 0 del roadmap (decisiones legales + benchmarking de costos), porque no requiere código y desbloquea las decisiones de los próximos 12 meses.

Actualización 2026-05-30 v4 (a pedido del usuario “evalua fase2”): la evaluación profunda confirma que 0 de 3 triggers se cumplen y agrega una tercera opción intermedia C: anchoring del Açaí ledger en el mismo merkle root de Fase 1 (USD 8k-14k incremental, sin activar PSAV/SARLAFT, resuelve 75% del valor con ~15% del costo de tokenización). Ver §“Evaluación profunda Fase 2 (2026-05-30 v4)”.

---

Contexto

El monorepo digital-jungle cerró Fase 3 (feat/bmonkey-wallet-ssi-foundation, commit 3c1179e, 2026-05-30) con:

• Wallet SSI Modelo C híbrido (Secure Enclave + E2EE backup futuro) — claves del usuario en device, bjungle issuer + custodio del backup encriptado. ADR fundacional wallet-modelo-c.
• VCs JWT-VC firmadas con KMS RS256, DID did:web:bmonkey.bjungle.com, JWKS publicado vía OIDC bridge (ADR-003).
• Açaí como postgres ledger distribuido entre platform.acai_balances / platform.acai_ledger (tenants) y bmonkey.user_acai_balance / bmonkey.user_acai_ledger (usuarios). Split 20/7/5 ejecutado atómicamente vía outbox pattern (ADR data-dividends).

El producto madura. La pregunta del usuario es honesta: ¿hay aquí un caso real para blockchain, o es solo hype?

Este ADR responde por separado para cada sub-caso, con veredicto explícito, threat model concreto, y costos cuantificados con datos 2026 (donde no hay dato fresco, lo marco).

Esto NO es smart contract design

Este ADR no escribe smart contracts. La regla dura del agente blockchain-architect es: si la decisión es “sí”, proponer un sub-sprint con backend-dev + security + un auditor externo. Aquí solo se evalúa el caso de negocio y la arquitectura macro.

---

Pregunta 1 — Wallet SSI on-chain

Cuatro sub-casos. Evalúo cada uno con la misma plantilla: amenaza concreta que mitiga, opción on-chain mínima, costo cuantificado, veredicto.

1.a · Anclaje (notarization) de VCs

Pregunta: ¿Conviene publicar hashes de VCs emitidas en una chain pública para que cualquier verificador pueda probar “este VC existía en esta fecha” sin consultar a bjungle?

Amenaza concreta que mitiga:

Hoy, el JWT-VC firmado con la KMS key de bjungle prueba que alguien con acceso a esa KMS key firmó ese VC. No prueba cuándo. Si:

1. Un atacante compromete la KMS de bjungle (o un insider malicioso opera la KMS),
2. Emite un VC con iat: 2024-01-01 para un wallet_id que controla,
3. Y lo presenta en un RP en 2026,

el RP no puede distinguir ese VC fraudulento de uno auténtico de la misma fecha. El JWKS sigue verificando bien (la firma es genuina). El timestamp lo eligió el atacante.

Anclar sha256(JWT-VC) en una chain pública resuelve esto: el hash queda en bloque B con timestamp T_block. Cualquier verificador puede probar que ese VC existía antes de T_block. Un VC emitido fraudulentamente hoy con iat: 2024-01-01 no tendrá hash en ningún bloque anterior a hoy → detectable.

Quién es el atacante:

• Insider de bjungle con acceso a KMS (alta cualificación, baja probabilidad pero alto impacto).
• Atacante externo que compromete IAM de la cuenta AWS de bjungle.
• bjungle mismo bajo orden judicial irregular (caso “el regulador exige re-emisión backdateada”). Este caso es el más interesante: anclaje on-chain protege al usuario incluso del issuer.

Opción mínima on-chain:

Batch merkle tree. Cada N horas (ej. cada 4h o cuando se acumulen K VCs):

1. Computar root = merkle(sha256(vc_1), sha256(vc_2), ...).
2. Publicar root como tx en una L2 pública (Polygon PoS o Base).
3. Almacenar el merkle path por VC en verifiable_credentials.anchor_proof jsonb.

Cuando un verificador quiere probar el anchoring de un VC específico, recibe (vc_jwt, merkle_path, tx_hash, l2_block) y verifica off-chain contra el root registrado en el bloque.

Costos cuantificados:

Chain	Costo por tx (publish root)	Frecuencia recomendada	Costo mensual
Polygon PoS	~USD 0.005-0.02 (datos 2025-Q4, necesita validación fresca)	6/día	~USD 1-4/mes
Base (L2 OP-stack)	~USD 0.01-0.05	6/día	~USD 2-9/mes
Arbitrum One	~USD 0.02-0.10	6/día	~USD 4-18/mes
Ethereum L1	~USD 2-10	6/día	~USD 360-1800/mes (descartado)

Para un volumen estimado inicial de 100-500 VCs/día (~10k-15k/mes), un batch de 4h captura ~20-100 VCs/batch. Polygon PoS sale ~USD 1-4/mes total.

Beneficios secundarios:

• Habilita el caso “bjungle desaparece” parcialmente: aunque el JWKS de did:web muere si el dominio expira, el hash anclado prueba que el VC existió. Combinado con archive copies del JWKS (Arweave, archive.org), un verificador puede reconstruir la cadena de confianza.
• Habilita verificación offline + asincrónica (el RP no depende de bjungle estar online cuando verifica).
• Diferenciador comercial real: “tus VCs están anchored on-chain” es mensaje vendible vs Stripe Identity / Persona.

Riesgos / contras:

• Privacidad: el hash on-chain no revela claims, pero la frecuencia y timing de emisión sí filtra metadata (X VCs/hora). Para volumen bajo es identificable. Mitigación: padding con hashes dummy.
• Operación: requiere un wallet de bjungle con MATIC/ETH en custodia para pagar gas. Sumar a la infra: monitor de balance, alarmas, plan de top-up automático.
• Reversibilidad: una vez anchored, no se desancla. Si una VC se revocó, el hash sigue ahí (lo cual es el punto — pero hay que pensarlo).

Veredicto: SÍ, por fases. Es el caso más sólido. Resiste threat concreto que el modelo actual no resiste. Costo trivial (USD <10/mes). Roadmap explícito en §Roadmap.

1.b · DID portability (did:web → algo más fuerte)

Pregunta: Hoy did:web:bmonkey.bjungle.com está acoplado a la empresa. Si bjungle.com deja de responder DNS, el DID muere. ¿Migrar a un DID method más portable?

Opciones evaluadas:

Método	Anchoring	UX	Portabilidad	Veredicto
did:web (actual)	DNS + HTTPS	trivial	mala (depende del dominio)	status quo
did:key	ninguno (la clave es el DID)	trivial	total, pero no rotable	NO — pierde rotación de claves
did:ion	Bitcoin (sidetree)	complejo, requiere ION node o gateway	buena	NO ahora — complejidad alta
did:ethr	Ethereum L1	medio	buena pero gas-paying	NO — costo prohibitivo
did:plc	placeholder centralizado (Bluesky AT)	trivial	buena pero centralizado	NO — solo cambiamos quién centraliza
did:pkh	account-bound (Eth/Sol wallet)	requiere wallet on-chain del usuario	total	NO — fuerza Web3 al usuario

Análisis honesto:

La promesa “SSI portable” del Modelo C hoy es parcial. Sí — las claves del usuario viven en su device. Pero las VCs están firmadas por did:web:bmonkey.bjungle.com. Si el dominio muere, el verificador no puede resolver el DID al JWKS → la firma no se puede verificar → la VC pierde valor.

¿Cuánto vale resolver esto?

• Si un RP necesita verificar una VC mientras bjungle está vivo (99.99% de los casos hoy): nada. did:web resuelve perfectamente.
• Si bjungle desaparece: en teoría las VCs ya entregadas siguen vivas si el RP archivó el JWKS antes. En la práctica, los RPs no archivan JWKS. Mejor opción es publicar el JWKS en IPFS + Arweave + anclar el CID on-chain. Es un sub-caso de §1.a, no requiere cambiar el DID method.

El caso real donde did:web falla: bjungle es comprado por una empresa que cambia el dominio (bmonkey.bjungle.com → wallet.acquirer.com). Las VCs viejas firmadas con el DID viejo se rompen salvo que mantengamos el dominio viejo como redirect. Esto se soluciona con transición planificada (anuncio + ventana de re-issuance + soporte dual de ambos DIDs en JWKS por 12-24 meses), no con un DID method más fancy.

Veredicto: NO migrar a otro DID method ahora. El costo (complejidad de implementación de ION o equivalente, UX degradado, dependencia de chain externa) supera el beneficio. Lo que sí hacemos:

1. Archive del JWKS en IPFS + Arweave (sub-caso de §1.a). Costo: USD 0.1/mes Arweave + costo de pinning IPFS.
2. Anclar el JWKS rotation on-chain con el mismo merkle root del §1.a. Cuando bjungle rota la KMS, publica el nuevo kid en el batch.
3. Documentar el exit path explícito: “si bjungle quiebra/vende, el plan es X” — esto es un compromiso público que algunos RPs lo valoran más que un DID method exótico.

Re-evaluar cuando:

• Un RP enterprise diga “no integro con did:web por riesgo de continuidad”.
• Aparezca un consortium IdP (eIDAS, Ssi-aries) que exija did:ion o did:ebsi para federación.
• El equipo tenga bandwidth para operar un sidetree node sin descuidar el roadmap principal.

1.c · Revocation registry público on-chain

Pregunta: ¿Publicar la status list de VCs revocadas on-chain para que cualquier RP verifique revocación sin pegarle al issuer?

Estado actual:

Hoy bmonkey no tiene status list publicada. La revocación de una VC se materializa via wallet_grants.revoked_at (revocación del grant, no de la VC) y eventualmente con un endpoint GET /v1/wallet/credentials/{vc_id}/status (no implementado todavía, en el horizonte del wallet).

La pregunta es: ¿esa status list debería ser on-chain?

Análisis:

W3C tiene la spec Status List 2021 (ahora W3C VC Status List): una bitstring grande comprimida donde cada bit es el status de un VC (revocado / no). La status list se publica en una URL HTTPS estable, los verificadores la cachean. Es off-chain por design y funciona bien.

¿Qué agrega on-chain? Censorship resistance + auditabilidad pública. Si bjungle “olvida” publicar la revocación de una VC para favorecer a alguien, on-chain queda evidencia. Es el mismo argumento que §1.a (anclaje), pero aplicado a la lista de status en lugar de a las VCs individuales.

Opción mínima:

El root del bitstring de status (hash determinista del bitstring vigente) se publica en el mismo batch on-chain del §1.a. Cuando se revoca una VC:

1. Flip del bit en el bitstring off-chain.
2. Próximo batch publica el nuevo root.

Latencia: la revocación tarda hasta batch_interval (4h) en ser auditable on-chain. Suficiente para el threat model — un atacante que controla bjungle no puede revocar selectivamente VCs y ocultarlo más de 4h sin que el merkle root pierda continuidad.

Costo incremental: cero, es un par de bytes adicionales en el mismo batch del §1.a.

Veredicto: SÍ, ata-do al sub-caso §1.a. No incrementa costo, sí incrementa el valor del anchoring. Va al mismo sprint.

1.d · Soulbound tokens (SBT) para Web3 RPs

Pregunta: ¿Emitir un NFT no-transferible (ERC-5192 / ERC-5114) que ate un wallet Ethereum del usuario al wallet bjungle, útil para protocolos Web3 que quieran “este wallet on-chain está KYCeado por bjungle”?

Cuándo tiene sentido este caso:

Solo si hay demanda real de protocolos DeFi/Web3 en LATAM que quieran KYC reusable. Hoy 2026, el mercado en Colombia/LATAM:

• DeFi LATAM es marginal en volumen (USD <100M TVL para todas las chains combinadas).
• Compliance Web3 lo dominan players globales (Quadrata, Coinbase Verify, Worldcoin).
• Ningún cliente actual de bjungle ha pedido este caso.

Costo de implementación (rough):

• Smart contract ERC-5192 (soulbound) + verifier off-chain — 3-4 semanas + audit externo (USD 15-25k para una audit creíble).
• Custodia de keys del minter — MPC o KMS (operación nueva).
• Mainnet deploy + verifier service — ~USD 200-500/mes infra + gas variable por mint.

Veredicto: NO ahora. Caso de uso especulativo, mercado verificado pequeño, costo de entrar significativo. Re-evaluar cuando:

• Aparezca un primer cliente concreto (no hipotético) que diga “necesito SBT KYC”.
• O cuando alguno de los protocolos DeFi de LATAM (ej. Notus, Lemon, Bitso) anuncie KYC reusable.

Mientras tanto, NO se invierte un peso en este caso.

---

Pregunta 2 — Tokenización Açaí

Cinco modelos. Mismo formato.

2.a · Mantener postgres ledger (status quo)

Estado actual:

• platform.acai_balances / platform.acai_ledger (Açaí por tenant, modelo “encargado del tratamiento” del operador).
• bmonkey.user_acai_balance / bmonkey.user_acai_ledger (Açaí del usuario final, modelo “data dividend” 5/32).
• Outbox pattern + worker para consistencia cross-DB.
• Pricing fijo (OperationKYC: 80, etc.) hardcoded en acai_pricing.go.

Pros del status quo:

• Cero costo de gas.
• Cero costo regulatorio (es ledger interno de un servicio SaaS, no es activo virtual a ojos de SuperFinanciera).
• Transaccional con el resto del schema (mismo Postgres, tx única para grant + crédito).
• UX trivial (el usuario ve un número, no maneja keys).

Contras:

• Açaí no es portable fuera de bjungle. Si el usuario quiere “cobrar” sus Açaí, depende de que bjungle implemente redemption.
• No hay transparencia pública del supply total (cuántos Açaí existen, quién los tiene). Solo bjungle lo sabe.
• Dependiente de uptime de bjungle. Si bjungle quiebra, los Açaí desaparecen.

Veredicto: status quo correcto para Fase actual del producto. El modelo “loyalty interno” cubre el caso de uso publicado en data-dividends (5 Açaí al usuario por aprobación, redimible). Tokenizar sin demanda concreta es solucionismo.

2.b · ERC-20 sobre L2 (Polygon / Base / Arbitrum)

Análisis:

Convertir Açaí en token ERC-20 fungible on-chain. El usuario tiene un wallet on-chain (custodial o non-custodial) y bjungle mintea/quema según operaciones.

Cosa importante de entender: El momento en que Açaí pasa de “puntos de loyalty interno” a “token fungible transferible entre wallets externos”, cambia su tratamiento regulatorio:

• Decreto 1547/2022 colombiano define “activo virtual” como representación digital de valor con potencial de uso como medio de cambio. Açaí tokenizado podría caer ahí.
• SARLAFT aplica: bjungle pasaría a ser entidad obligada a reportar UIAF sobre operaciones cripto.
• DIAN: cada movimiento del usuario es potencialmente un evento gravable.
• Si Açaí flota libre y tiene mercado secundario, podría caracterizarse como instrumento financiero — territorio SuperFinanciera Circular Externa.

Costo operacional:

Item	Costo
Smart contract ERC-20 + audit	USD 15-30k one-time
Mainnet deploy (Polygon/Base)	USD 0.50-5
Gas por transfer usuario	USD 0.001-0.05 (L2)
Gas por mint/burn bjungle	USD 0.001-0.05 (L2)
Mantenimiento contract + monitoring	USD 1-2k/mes
Cumplimiento SARLAFT (reporting, KYT)	USD 5-15k setup + ongoing
Custodia (si custodial)	USD 0.5-2k/mes según provider
Auditoría legal (SuperFinanciera filing)	USD 10-30k one-time

Total Year-1: USD 50-100k + ~USD 15-30k/year ongoing. Muy distinto del USD <10/mes del §1.a.

Comparación de L2s:

L2	Costo tx	Adopción LATAM	Liquidez	Veredicto
Polygon PoS	USD 0.001-0.01	alta (Bitso, Lemon, Mercado Pago testing)	alta	favorito si tokenizamos
Base (Coinbase)	USD 0.01-0.05	media (más enterprise)	media	alternativa enterprise
Arbitrum One	USD 0.02-0.10	media	alta	overkill para este caso
Optimism	USD 0.02-0.10	media	alta	similar a Arbitrum
zkSync Era	USD 0.05-0.20	baja	media	NO (poca tracción LATAM)
BNB Chain	USD 0.05-0.20	media (alto en cripto retail)	alta	NO (governance opaca, reputación regulatoria)
Solana	bajo (~USD 0.001)	alta retail	alta	NO ERC-20 — modelo distinto (SPL token)

Cuándo SÍ vale la pena:

Solo si al menos 2 de 3:

1. Un segundo operador externo (no tenant del ecosistema actual) acepta Açaí como pago de servicios. Sin esto, no hay portabilidad real — solo un wrapper caro del ledger interno.
2. Hay opinión legal explícita que clasifica Açaí como “activo virtual de utilidad sin expectativa de retorno”, no como security. Esto requiere asesoría legal especializada (no es “lo vemos después”).
3. El producto ha cruzado mass adoption — >100k usuarios activos, >USD 1M/mes en débitos. Volumen suficiente para amortizar el ongoing.

Hoy ninguna de las 3 se cumple.

Veredicto: NO ahora. Re-evaluar cuando las 3 condiciones se aproximen. La decisión hoy es mantener el ledger interno (§2.a).

2.c · Stablecoin pegado a COP

Pregunta: ¿Y si Açaí no flota — está pegado 1:1 a COP (o a USD)?

Análisis:

Açaí no es stablecoin per se — es token de utilidad. Su valor está fijado por bjungle al pricing publicado (60 COP/Açaí aprox). Atarlo formalmente a COP via mecanismo de minting/burning controlado tiene 2 caminos:

1. Pegged sin colateral fiat real: bjungle declara “1 Açaí = 60 COP” y honra redemption a esa tasa. Esto es exactamente lo que ya hace internamente — solo agregaría el wrapper on-chain sin ganar nada material.
2. Colateralizado 1:1 con fiat real: bjungle debe mantener reservas COP equivalentes al supply circulante. Esto entra en territorio de e-money / dinero electrónico — regulación SuperFinanciera SEDPE (Sociedades Especializadas en Depósitos y Pagos Electrónicos), Ley 1735/2014. Requiere licencia, capital mínimo, reportes, supervisión continua.

Veredicto: NO. El path 1 no aporta nada sobre §2.a. El path 2 requiere convertir bjungle en SEDPE, lo cual es un cambio de modelo de negocio mayor que no es el negocio actual. El negocio es identidad reusable + compliance — no pagos.

Si en el futuro el negocio incluyera procesar pagos cripto, evaluar integrar stablecoins existentes (USDC, USDT, COPm de Mercado Pago si emerge) en lugar de emitir uno propio.

2.d · Modelo híbrido — ledger interno + on-chain bridge opcional

Descripción:

• Por default todo en postgres (status quo §2.a).
• Endpoint nuevo POST /v1/wallet/me/acai/withdraw que el usuario invoca para mintear ERC-20 en su wallet on-chain. Quema balance interno + emite tx mint.
• Endpoint POST /v1/wallet/me/acai/deposit que recibe burn signature de wallet on-chain y crédita balance interno.
• Solo el usuario que pide withdraw paga gas (o bjungle absorbe como fee redemption).
• La mayoría de Açaí se queda en el ledger interno.

Pros:

• Preserva UX simple para mayoría (el balance interno sigue siendo “el principal”).
• Habilita portabilidad opcional para usuarios power que quieren mover Açaí off-bjungle.
• Costo controlado: bjungle solo paga gas si subsidia withdraws.

Contras:

• Misma carga regulatoria que §2.b una vez existe el bridge (Açaí off-bjungle = activo virtual).
• Complejidad UX: el usuario tiene que entender dos balances (interno + on-chain).
• Custodia decision: ¿el withdraw va a un wallet del usuario (non-custodial) o a un wallet custodiado por bjungle por delegación del usuario (Fireblocks/MPC)?

Veredicto: Modelo correcto si en el futuro tokenizamos. Pero solo activar cuando las condiciones de §2.b se cumplan. No es Fase 1.

2.e · Custodia (transversal a 2.b/2.c/2.d)

Si en el futuro tokenizamos en cualquier forma, la decisión de custodia es la más crítica desde el punto de vista UX y regulatorio.

Modelo	UX	Soberanía usuario	Riesgo regulatorio bjungle	Veredicto si tokenizamos
Custodial puro (bjungle holds all keys)	óptimo	nula	máximo (custodian de activos virtuales)	NO — multiplica regulación
Non-custodial estricto (usuario maneja seed phrase)	terrible	máxima	mínimo (bjungle no toca keys)	NO — UX inaceptable para mass-market COL 2026
MPC (split keys via Fireblocks/Web3Auth/Lit)	bueno	parcial	medio	favorito — balance UX + soberanía
Passkey-derived + ERC-4337 / EIP-7702	bueno	alta	bajo a medio	favorito futuro — encaja con Modelo C ya implementado

El path interesante a largo plazo es passkey-derived smart accounts (ERC-4337): la passkey que ya está en el Secure Enclave del usuario (Modelo C) firma la account abstraction wallet. UX similar a custodial, pero las claves están en el device del usuario. Habilita gasless tx (bjungle paga gas como meta-tx) sin sacrificar soberanía.

Veredicto: si tokenizamos, MPC como primer paso, ERC-4337 con passkey como evolución.

---

Threat model resumido

Atacante	Vector	Mitigación con blockchain	Mitigación sin blockchain
Insider bjungle con acceso KMS	Re-emite VC backdateado	Anchoring §1.a previene (no hay hash anterior on-chain)	Auditoría interna + segregation of duties (insuficiente)
Atacante externo compromete cuenta AWS	Re-emite VCs, borra evidencia	Anchoring §1.a previene + revocation registry §1.c	Backups inmutables + audit log (mitiga parcial)
bjungle bajo orden judicial irregular	Forzado a re-emitir backdateado	Anchoring §1.a previene	Imposible sin tercero externo
bjungle desaparece (quiebra, compra)	VCs y Açaí se vuelven inútiles	Anchor + IPFS/Arweave del JWKS preserva verificabilidad VC. Tokenización Açaí preservaría balance solo si fue movido on-chain a tiempo.	Exit policy + commitments públicos (mitigación social, no técnica)
Atacante roba wallet on-chain del usuario	Drena Açaí ERC-20 (si tokenizado)	Multi-sig / social recovery (complejo)	N/A — no aplica al ledger interno
Atacante quiere correlacionar usuario entre RPs	Mira chain pública de mints/transfers	EMPEORA con tokenización — chain pública filtra metadata	Pairwise sub en OIDC (ya documentado en ADR-003)

Conclusión del threat model: Anchoring (§1.a, §1.c) gana en casi todos los vectores. Tokenización (§2.b/d) introduce nuevos vectores (privacidad en chain pública) que el ledger interno no tiene.

---

Cost model consolidado (reescrito 2026-05-30 v3 · línea por línea · sources verificables)

Re-escritura completa del cost model

La v1 de esta sección presentaba rangos (USD 15-30k Fase 0, USD 70-100/mes Fase 1) sin desglose línea por línea. El usuario solicitó claridad quirúrgica antes de aprobar Fase 0. Esta v3 reescribe todo el modelo con:

1. Granularidad item por item (categoría, vendor, tier, costo unitario, volumen asumido).
2. Marcaje explícito por source: [VERIFIED 2026] (link a página de vendor), [ESTIMATED] (extrapolación con justificación), [NEEDS-VALIDATION] (cotización pendiente con vendor o asesor).
3. Tres escenarios de volumen (bajo / medio / alto) con totales independientes.
4. Tres horizontes (Año 1, Año 2-3, Steady state) con totales independientes.
5. Decisión de costos para Fase 0 al final (3 opciones presupuestales: mínimo viable / recomendado / completo).

Toda referencia a “USD 70-100/mes” o “USD 15-30k” en versiones previas del documento queda obsoleta. Este cost model es el vigente.

Supuestos de volumen (todos los items siguen estos números)

Variable	Bajo	Medio	Alto
VCs emitidos / mes	1.000	10.000	100.000
VCs emitidos / día	~33	~333	~3.333
Anchors batch (intervalo)	cada 24h (1 tx/día = 30/mes)	cada 4h (6 tx/día = 180/mes)	cada 1h (24 tx/día = 720/mes)
Status list updates (revocaciones)	~1% mensual → reuses mismo batch (no costo extra)	~1% mensual → reuses mismo batch	~1% mensual → reuses mismo batch
Operadores OIDC conectados	1-3 tenants	5-15 tenants	20-50 tenants
Archive JWKS (Pinata + Arweave)	~1 MB total acumulado año 1	~5 MB total acumulado año 1	~50 MB total acumulado año 1
Tamaño calldata por anchor tx	32 bytes merkle root + 32 bytes status root + ~50 bytes metadata = ~115 bytes	ídem	ídem

Notas de los supuestos:

• 100 VCs/mes (~3/día) no justifica batches cada hora — saturan los anchors con merkle trees de 3 hojas. Cada 24h es lo adecuado.
• 100k VCs/mes saturaría batches cada 24h (>3.000 VCs/batch — merkle tree de 12 niveles, ~5 KB proof por VC). Cada 1h baja a ~140 VCs/batch.
• Los 3 escenarios cubren: piloto (1k = clientes Tier-1 actuales), tracción (10k = expansión LATAM), masivo (100k = bjungle como infraestructura compartida de identidad COL).
• Revocaciones se acoplan al batch del anchor (mismo tx publica ambos roots) → costo incremental cero (consistente con §1.c del ADR).

Fase 0 — Discovery + legal + benchmarking (4-6 semanas · sin código)

Propósito: desbloquear decisiones de los próximos 18 meses. Sin Fase 0 ejecutada, no se justifica Fase 1.

#	Categoría	Item específico	Costo unitario	Volumen asumido	Costo total	Source / data quality
F0-1	legal	Abogado fintech COL (activos virtuales + Ley 2200/2022 + PSAV registry) — opinión escrita inicial	COP 1.750.905 = ~USD 440 (concepto jurídico Conalbos 1 SMMLV) + retainer	20-40 horas concepto + 2 consultas verbales	USD 3.000-6.000	[VERIFIED 2026] Conalbos tarifas referencia (no obligatorias): consulta verbal 50% SMMLV = ~USD 220, escrita 1 SMMLV = ~USD 440. Especialista crypto-COL típicamente cobra 2-4× por hora. [NEEDS-VALIDATION] firmas Cecamagán, ATH21, Ferrer-Bonsoms, Navas&Cusi para cotización formal.
F0-2	legal	Abogado data privacy (Ley 1581 + hash anchoring on-chain = ¿dato personal?) — concepto jurídico	similar al anterior	15-25 horas + 1 concepto	USD 2.000-4.000	[VERIFIED 2026] mismo Conalbos. [NEEDS-VALIDATION] habilitación SIC.
F0-3	legal	Abogado SARLAFT-cripto (qué reportes UIAF activa cada modelo evaluado: anchoring vs tokenización) — workshop + concepto	1 workshop 4h + concepto	1 sesión + 1 documento	USD 1.500-3.000	[VERIFIED 2026] Sumsub blog SARLAFT 2026 referencia marco; tarifas [NEEDS-VALIDATION] con firma especialista.
F0-4	dev time	Discovery con 3-5 RPs potenciales (tenants actuales + futuros Tier-2/3 OIDC) — 3-5 workshops + mockups + síntesis	1 dev senior × 1 semana	1 sprint discovery	USD 2.000-2.700	[ESTIMATED] basado en salario senior Go LATAM USD 8-10.5k/mes (= ~USD 2.000-2.625/semana).
F0-5	dev time	Benchmarking técnico (sandbox Polygon Amoy testnet, deploy de tx de prueba, mediciones reales gas + latencia + finality, 1 spike de proof concept publicando merkle root)	1 dev senior × 1.5 semanas	1 sprint	USD 3.000-4.000	[ESTIMATED] mismo baseline salarial.
F0-6	dev time	Documentación final Fase 0 (ADR-008-legal separado, decisión escrita con chain elegida, custody decision, presupuesto Fase 1 cotizado, kick-off plan)	1 dev senior × 0.5 semanas	0.5 sprint	USD 1.000-1.500	[ESTIMATED] mismo baseline.
F0-7	consultoría	Consultor cripto-COL (1 entrevista 2-4h + revisión documento legal + segunda opinión sobre chain elegida)	tarifa hora ~USD 150-300	4-8 horas	USD 600-2.400	[NEEDS-VALIDATION] con consultor independiente (LinkedIn) o boutique blockchain LATAM.
F0-8	ops	Infra de sandbox (RPC testnet Polygon Amoy free tier Alchemy + Pinata free tier + 1 wallet testnet con MATIC faucet)	$0	6 semanas	USD 0	[VERIFIED 2026] Alchemy free tier 30M CU/mes; Pinata free tier 1 GB + 10 GB bandwidth + 500 archivos.
Total Fase 0					USD 13.100-23.600	one-time

Notas Fase 0:

• El rango USD 13k-24k es menor que el rango v1 (USD 15-30k) porque desglosó las suposiciones — los conceptos legales en COL son más baratos de lo que el v1 sugería. La incertidumbre real está en F0-1/F0-2/F0-3 (cotizaciones formales con firmas especialistas).
• Si el usuario consigue 2-3 cotizaciones formales con firmas COL antes de aprobar Fase 0, el rango se cierra a ±10%. Recomendación: cotizar con 3 firmas (Cecamagán + ATH21 + Ferrer-Bonsoms o Navas&Cusi) y promediar.
• Fase 0 NO requiere infra de pago, NO compra MATIC real, NO firma contratos vendor. Es 100% reversible.

Fase 1 — Anchoring + revocation registry · Polygon PoS

Decisión arquitectónica que reduce costos drásticamente:

No hay smart contract custom en Fase 1. El anchor tx publica (merkle_root_vcs, merkle_root_status_list, metadata) como calldata de una tx normal a una dirección sentinel (ej. la propia EOA de bjungle). Esto elimina la auditoría externa (USD 15-30k) porque no hay código a auditar — solo se firma una tx con bytes. Suficiente para el threat model del §1.a/§1.c.

Implicación: la audit smart contract solo aparece en Fase 2 si se tokeniza Açaí. Fase 1 corre con security review interno (agente security ya disponible, costo cero adicional).

Fase 1 · Costos one-time (implementación, 4-6 semanas)

#	Categoría	Item específico	Bajo	Medio	Alto	Source / data quality
F1-1	dev time	Backend Go: BatchScheduler + MerkleBuilder + ChainClient + tests	2 sem × USD 2.0k/sem = USD 4.000	2.5 sem × USD 2.3k/sem = USD 5.750	3 sem × USD 2.6k/sem = USD 7.800	[ESTIMATED] salario senior Go LATAM USD 8-10.5k/mes (Howdy, Tecla, Mismo 2026).
F1-2	dev time	Migration vc_anchor_batches + vc_anchor_proofs + helpers SECURITY DEFINER + endpoint GET /v1/vc/{vc_id}/anchor	1 sem	1 sem	1.5 sem	[ESTIMATED] mismo baseline.
F1-3	dev time	Status list 2021 bitstring + endpoint GET /v1/vc/status-list + integración al batch	1 sem	1 sem	1 sem	[ESTIMATED].
F1-4	dev time	Archive JWKS (cron diario IPFS pin Pinata + upload Arweave + CID en batch)	0.5 sem	0.5 sem	1 sem	[ESTIMATED].
F1-5	dev time	Frontend wallet PWA + portal admin: surface “VC anchored on-chain” + verificación pública	1 sem	1 sem	1.5 sem	[ESTIMATED].
F1-6	dev time	Documentación pública + actualización ADRs + sitio website con verificación externa demo	0.5 sem	0.5 sem	0.5 sem	[ESTIMATED].
F1-7	dev time	Security threat model focal (security agent — interno) + threat model de re-org + monitoring de balance del wallet ops	0.5 sem	0.5 sem	1 sem	[ESTIMATED] interno, sin auditoría externa porque no hay smart contract.
F1-8	custody	Setup wallet de operaciones (1 EOA en Polygon, custody KMS AWS — provisión + IAM + firmador Go) — AWS KMS soporta ECC_SECG_P256K1 nativamente	USD 200 (config)	USD 400 (config + audit interna)	USD 800 (config + audit + redundancia regional)	[VERIFIED 2026] AWS KMS pricing: ECC_SECG_P256K1 soportada para Sign/Verify; key storage USD 1/mes.
F1-9	monitoring	Setup dashboards Prometheus + Grafana (ya en stack) + alertas balance + alertas tx failures	0.5 sem	0.5 sem	1 sem	[ESTIMATED] infra extra cero, solo dev time.
F1-10	audit	Smart contract audit	N/A (no hay contract)	N/A	N/A	[VERIFIED 2026] Sherlock 2026 reference: ERC-20 simple USD 5-20k, top tier (Trail of Bits, OpenZeppelin) USD 25k/eng-week. Aplicable solo si se decide contract custom — no es el caso en Fase 1.
Subtotal one-time F1			USD 14.000-17.000	USD 17.000-22.000	USD 27.000-34.000	dev time domina; rango refleja salario senior baseline → senior+

Fase 1 · Costos mensuales (steady state operativo)

#	Categoría	Item específico	Bajo (1k VCs/mes)	Medio (10k VCs/mes)	Alto (100k VCs/mes)	Source / data quality
F1-M1	gas	Anchor tx Polygon PoS (calldata ~115 bytes)	30 tx × USD 0.005 = USD 0.15/mes	180 tx × USD 0.005 = USD 0.90/mes	720 tx × USD 0.005 = USD 3.60/mes	[VERIFIED 2026] Polygon PoS gas USD 0.003-0.005/tx (PolygonScan avg-txfee + QuickNode gas tracker). Buffer 2× volatilidad → multiplicar por 2.
F1-M2	gas	Buffer volatilidad MATIC/POL (×2 sobre F1-M1)	USD 0.30/mes	USD 1.80/mes	USD 7.20/mes	[ESTIMATED] volatilidad histórica POL ±50% intra-año.
F1-M3	RPC	Plan RPC managed Polygon	Alchemy Free tier (30M CU/mes = ~1.1M requests con 27 CU/req avg) — sobra	Alchemy Pay-as-you-go USD 0.45/1M CU → ~USD 5-15/mes	Chainstack Growth USD 49/mes (20M req) o Alchemy ~USD 50-100/mes	[VERIFIED 2026] Alchemy: free 30M CU; PAYG USD 0.45/1M CU (300M+ cae a USD 0.40). Chainstack: USD 2.45-2.49/1M req, entry USD 49/mes.
F1-M4	indexer	Polling con Go worker (sin The Graph; events emitidos a EOA sentinel) — costo cero infra, solo overhead RPC ya contado	USD 0	USD 0	USD 0	[VERIFIED 2026] decisión arquitectónica: batches cada 1-24h NO requieren indexer real-time. Polling Go cada N min suficiente. The Graph free tier 100k queries (Subgraph Studio) si alguna vez se migra.
F1-M5	storage	IPFS pinning JWKS + status list	Pinata Free (1 GB + 10 GB bandwidth) — sobra	Pinata Picnic USD 20/mes (1 TB storage + 500 GB bw + 1M requests)	Pinata Picnic USD 20/mes (sigue sobrando para 50 MB)	[VERIFIED 2026] Pinata pricing: free 1 GB / 10 GB bw / 500 pins; Picnic USD 20/mes 1 TB. Alt: Filebase Starter USD 20/mes 800 GB. Alt: Web3.Storage Lite USD 10/mes 100 GB.
F1-M6	storage	Arweave archive JWKS (one-time upload por rotación KMS — esperada 1-2/año)	USD 0.50/año / 12 = USD 0.04/mes amortizado	USD 2/año / 12 = USD 0.17/mes amortizado	USD 20/año / 12 = USD 1.70/mes amortizado	[VERIFIED 2026] Arweave USD 6.35-8.00/GB one-time (200+ años). JWKS típico < 5 KB → trivial.
F1-M7	custody	AWS KMS key (1 key Polygon EOA + signing)	1 key × USD 1 + ~30 sigs × USD 0.15/10k = USD 1.00/mes	1 key × USD 1 + ~180 sigs = USD 1.00/mes	1 key × USD 1 + ~720 sigs = USD 1.01/mes	[VERIFIED 2026] AWS KMS: USD 1/key/mes storage + USD 0.15/10k asymmetric signs. Signs ECC_SECG_P256K1 entran en esa tarifa.
F1-M8	custody	Alternativa Fireblocks Essentials (NO recomendado para Fase 1 — pricing entry)	USD 699/mes	USD 699/mes	USD 699/mes (o tier Pro custom)	[VERIFIED 2026] Fireblocks Essentials USD 699/mes (Bitcoiniracompanies, XYZEO). Descartado para Fase 1 salvo justificación específica — KMS es 700× más barato.
F1-M9	monitoring	Dashboards Grafana + alertas (stack ya existe) + tiempo on-call	USD 0 infra + USD 0 (best-effort on-call)	USD 0 infra + USD 200/mes (on-call rotation 0.05 FTE × 1 dev)	USD 0 infra + USD 500/mes (on-call 0.1 FTE × 2 devs)	[ESTIMATED] FTE-equivalent senior Go LATAM USD ~10k/mes prorrateado.
F1-M10	ops	Top-up MATIC/POL al wallet ops (manual mensual o auto si balance < umbral)	USD 5/mes (cubre gas + buffer)	USD 25/mes	USD 100/mes	[ESTIMATED] buffer 3-5× del gas mensual + reservas.
Subtotal mensual F1			USD 7-10/mes	USD 30-60/mes	USD 115-220/mes	excluye Fireblocks (descartado); custodia = KMS

Conclusiones Fase 1:

• El costo dominante de Fase 1 es dev time one-time, no operación. Gas + RPC + storage = USD <10/mes en Bajo, USD <60/mes en Medio, USD <220/mes en Alto.
• AWS KMS es 700× más barato que Fireblocks para Fase 1 (1 wallet ops, low signing volume). Fireblocks solo se justifica en Fase 2 cuando hay tokenización + custodia de balances usuario.
• La decisión “no smart contract en Fase 1” ahorra USD 15-30k de audit y 4-8 semanas de tiempo. Es la decisión arquitectónica de mayor impacto en el cost model.

Fase 2 hipotética — Tokenización Açaí (anti-scope hoy · costos para informar futuro)

No es parte del presupuesto a aprobar ahora. Se documenta para que la decisión de Fase 1 no cierre opciones futuras y el usuario vea la magnitud del salto.

Fase 2 · One-time (Año 1 implementación, ~12 semanas)

#	Categoría	Item específico	Costo	Source / data quality
F2-1	legal	Opinión legal SuperFinanciera + filing PSAV registry + análisis Decreto 1547/2022 + Ley 2200/2022	USD 15.000-30.000	[NEEDS-VALIDATION] firma especialista; PSAV registry obliga a empresas activos virtuales registrar con SFC.
F2-2	legal	Cumplimiento SARLAFT setup (KYT integrations Chainalysis/Elliptic/TRM + manual + procedimientos UIAF)	USD 8.000-20.000 setup	[NEEDS-VALIDATION] Sumsub blog SARLAFT 2026 referencia; cotización con KYT vendor pendiente.
F2-3	smart contract	ERC-20 con extensiones (pausable, mintable controlled, freeze para SARLAFT, allowlist ERC-1404) — desarrollo	1 dev Solidity senior × 4 sem = USD 12.000-16.000	[ESTIMATED] tarifa Solidity LATAM senior similar Go senior con premium ~10% por escasez.
F2-4	audit	Smart contract audit externo — opciones:		[VERIFIED 2026] Sherlock 2026 reference + 7BlockLabs benchmarks.
		a) ERC-20 simple (Sherlock, mid-tier)	USD 5.000-20.000
		b) ERC-20 con extensiones (mid-tier Halborn, Hacken, ConsenSys Diligence)	USD 25.000-60.000
		c) Top-tier (Trail of Bits, OpenZeppelin)	USD 80.000-200.000 (USD 25k/eng-week, ~3-5 sem)
F2-5	audit	Re-audit pass (casi siempre necesario tras remediation)	USD 5.000-20.000	[VERIFIED 2026] Sherlock.
F2-6	custody	Wallet MPC infra (Fireblocks Essentials → Pro) — setup	USD 5.000-10.000 setup	[VERIFIED 2026] Fireblocks Essentials USD 699/mes; Pro [NEEDS-VALIDATION] contact sales.
F2-7	dev time	Bridge endpoints (mint/burn) + worker + Polygon ID o custom AllowList integration	1 dev × 6 sem = USD 12.000-16.000	[ESTIMATED].
F2-8	dev time	Tax reporting DIAN integration (custom o tier enterprise Koinly/ChainAnalysis)	USD 5.000-15.000 setup	[NEEDS-VALIDATION] Koinly enterprise / Chainalysis Reactor pricing solicitar quote.
F2-9	dev time	Frontend wallet + portal: balances duales (interno + on-chain), withdraw/deposit UI, transaction history	1 dev × 4 sem = USD 8.000-11.000	[ESTIMATED].
Total Fase 2 one-time			USD 95.000-198.000 (ERC-20 mid-tier audit) o USD 175.000-380.000 (top-tier audit)

Fase 2 · Mensual (steady state operativo)

#	Categoría	Item	Bajo (1k tx/mes)	Medio (10k tx/mes)	Alto (100k tx/mes)	Source
F2-M1	gas	Mint/burn/transfer Polygon	USD 10-50/mes	USD 100-500/mes	USD 1.000-5.000/mes	[VERIFIED 2026] gas POS USD 0.01-0.05 por transfer ERC-20 (más caro que F1-M1 porque smart contract execution).
F2-M2	custody	Fireblocks Pro/Essentials	USD 699/mes (Essentials)	USD 1.500-3.000/mes (Pro)	USD 3.000-8.000/mes (Pro+)	[VERIFIED 2026] Essentials + [NEEDS-VALIDATION] Pro.
F2-M3	KYT	KYT subscription (Chainalysis/Elliptic/TRM)	USD 1.000-3.000/mes	USD 3.000-8.000/mes	USD 8.000-20.000/mes	[NEEDS-VALIDATION] todos requieren contact sales.
F2-M4	legal	Compliance officer + abogado retainer	USD 2.000/mes	USD 4.000/mes	USD 8.000/mes	[ESTIMATED] tarifas COL fintech.
F2-M5	RPC	Plan Alchemy/Chainstack para volumen alto	USD 50/mes	USD 200/mes	USD 500-1.000/mes	[VERIFIED 2026].
F2-M6	reporting	DIAN/UIAF reporting (software + horas)	USD 500/mes	USD 1.500/mes	USD 3.000/mes	[ESTIMATED].
Subtotal mensual F2			USD 4.250-6.250/mes	USD 10.300-19.000/mes	USD 23.500-45.000/mes	sin contar dev mantenimiento ~0.3-1 FTE

Conclusión Fase 2:

• Fase 2 multiplica el costo operativo por 50-200× respecto a Fase 1. El driver no es la chain — es el compliance regulatorio (SARLAFT, KYT, custody MPC, legal ongoing).
• No tiene sentido financiar Fase 2 sin (a) opinión legal favorable explícita, (b) demanda verificada de tokenización, (c) volumen >USD 1M/mes débitos. El ADR original ya lo dice — este cost model lo confirma cuantitativamente.

Ongoing operacional Fase 1 — Año 1 vs Año 2-3 vs Steady state

Consolida F0 + F1 con horizonte temporal.

Año 1 (Fase 0 + Fase 1 implementación + ~10 meses operación)

Concepto	Bajo (1k VCs/mes)	Medio (10k VCs/mes)	Alto (100k VCs/mes)
Fase 0 one-time	USD 13.100-23.600	USD 13.100-23.600	USD 13.100-23.600
Fase 1 one-time	USD 14.000-17.000	USD 17.000-22.000	USD 27.000-34.000
Fase 1 mensual × 10 meses (post-deploy)	USD 70-100	USD 300-600	USD 1.150-2.200
Total Año 1	USD 27.170-40.700	USD 30.400-46.200	USD 41.250-59.800

Año 2-3 (Fase 1 producción + posible kick-off Fase 2 si triggers se cumplen)

Asumiendo Fase 2 NO se activa (es el caso esperado per ADR):

Concepto	Bajo	Medio	Alto
Fase 1 mensual × 24 meses	USD 168-240	USD 720-1.440	USD 2.760-5.280
Mejoras Fase 1 (segundo dev sprint: optimizaciones, dashboards adicionales, ADR-008 refresh)	USD 5.000-10.000	USD 5.000-10.000	USD 10.000-15.000
Total Año 2-3	USD 5.168-10.240	USD 5.720-11.440	USD 12.760-20.280

Si Fase 2 SÍ se activa en Año 2 (escenario alternativo): sumar USD 95k-380k one-time + USD 4.250-45.000/mes × meses operativos. Decisión separada con su propio ADR.

Steady state (todo Fase 1 operativo + crecimiento orgánico)

Concepto	Bajo	Medio	Alto
Fase 1 mensual operativo	USD 7-10/mes	USD 30-60/mes	USD 115-220/mes
Anualizado	USD 84-120/año	USD 360-720/año	USD 1.380-2.640/año
Buffer dev mantenimiento (0.05-0.1 FTE)	USD 6.000-12.000/año	USD 6.000-12.000/año	USD 12.000-24.000/año
Total steady state / año	USD 6.084-12.120/año	USD 6.360-12.720/año	USD 13.380-26.640/año

Lectura honesta: en steady state el costo operativo dominante es tiempo de developer mantenedor, no infra blockchain. La infra blockchain pura es USD 7-220/mes según volumen.

Top 5 items que dominan el costo (Año 1)

1. Fase 0 legal opinions (F0-1/2/3) — USD 6.500-13.000 (50% de Fase 0). Es lo que más necesita validación con quote real.
2. Fase 1 dev time backend (F1-1/2/3/4) — USD 9.000-12.500 (~70% de Fase 1 one-time). Sensible al salario senior asumido.
3. Fase 1 dev time frontend + docs (F1-5/6) — USD 1.500-3.000.
4. Fase 1 mensual operativo × 10 meses — USD 70-2.200 según escenario. Trivial relativo al one-time.
5. Buffer dev mantenimiento steady state — USD 6k-24k/año. Larger que la infra blockchain pura.

Items que requieren validación de cotización antes de cerrar presupuesto

Marcados [NEEDS-VALIDATION] arriba. Resumen:

Item	A quién cotizar	Impacto si falla la estimación
F0-1 abogado fintech COL	Cecamagán, ATH21, Ferrer-Bonsoms, Navas&Cusi	±USD 3.000 sobre Fase 0
F0-2 abogado data privacy	mismas firmas o boutique SIC	±USD 2.000 sobre Fase 0
F0-3 abogado SARLAFT	mismas firmas + Sumsub partnerlist	±USD 1.500 sobre Fase 0
F0-7 consultor cripto-COL	LinkedIn + boutique blockchain LATAM (Notus, KodexLabs)	±USD 1.800 sobre Fase 0
F2-1/2/4/5/6 Fase 2 (todo)	diferido hasta trigger Fase 2	N/A hoy

Sources verificables (todo en 2026)

Polygon gas + RPC:

• PolygonScan avg-txfee-usd chart · QuickNode Polygon Gas Tracker · Polygon Gas Station docs
• Alchemy Pricing · Alchemy Pay-as-you-go FAQ
• Chainstack pricing · Chainstack — Alchemy overview 2026 · Chainstack — best Polygon RPC providers 2026

Storage IPFS + Arweave:

• Pinata pricing · Filebase pricing · Web3.Storage pricing
• Arweave fees · Akord Arweave calculator

Custody:

• AWS KMS pricing · AWS KMS key-spec reference
• Fireblocks pricing · Bitcoiniracompanies — Fireblocks review 2026

Salarios LATAM 2026:

• Mismo Team — LATAM Software Engineer Salary Guide 2026
• Howdy — 2026 LATAM Software Engineer Cost Benchmarks
• Tecla — Backend Developer Salary Colombia
• Lemon.io — Software Developer Salary Colombia 2026

Audit smart contract (referencia Fase 2):

• Sherlock — Smart Contract Audit Pricing 2026
• 7BlockLabs — 2026 Smart Contract Audit Costs

Legal Colombia:

• Portafolio — Tarifas abogados Colombia 2026 · Conalbos Tarifas 2026 (LitiApp PDF)
• Sumsub — SARLAFT Colombia 2026 Guide
• AbogadoBlockchain — Regulación criptomonedas Colombia 2026

Indexer:

• Subgraph Studio pricing — solo si se decide indexer real-time en Fase 2.

---

Facturación por evento del wallet bjungle

Una de las confusiones más frecuentes al evaluar blockchain es asumir que cada evento del producto dispara una transacción. Para Fase 1 del anchoring eso es falso: la mayoría de eventos viven 100% en postgres + KMS y nunca tocan la chain. Solo el cron de batch anchor + status list update escriben.

Regla de oro

Polygon NO factura por usuario. Polygon factura por transacción que tu backend escribe a la chain. El cost model se diseña para que la gran mayoría de eventos del producto no toquen la chain en absoluto.

Tabla — qué evento factura y qué no (Fase 1, anchoring + status list)

Evento del wallet bjungle	¿Toca blockchain?	Frecuencia típica	Gas individual
Onboarding (KYC + emisión VC)	NO directo — el VC se hashea y se incluye en el próximo anchor batch	Cada onboarding	Cero
Login con passkey	NO — WebAuthn es local	Cada autenticación	Cero
Consent grant (operator pide claims)	NO — id_token firma con KMS RS256	Cada consent	Cero
OIDC token exchange (/token, /userinfo)	NO	Cada exchange	Cero
Grant revocado	NO directo — entra en próximo status list update	Cada revoke	Cero
Step-up passkey / face	NO — local + KMS	Cada step-up	Cero
Açaí debit/credit (movimiento ledger)	NO — postgres UPDATE (Fase 1: ledger interno)	Cada movimiento	Cero
🟢 Anchor batch cron (1 tx con merkle root de los VCs nuevos del periodo)	SÍ	6/día con anchor cada 4h	USD 0.003-0.005
🟢 Status list update (1 tx con nuevo root del bitstring)	SÍ	~1-2/día (depende de revocaciones)	USD 0.003-0.005

Cuenta concreta · 1.000 onboardings/mes + 10.000 autenticaciones/mes

Volumen supuesto:

• Onboardings/mes: 1.000 → 1.000 VCs nuevos para anclar
• Autenticaciones/mes: 10.000 → cero gas
• Anchor batches (cron cada 4h): 180/mes = 1 tx con merkle root cada uno
• Status list updates (asumiendo ~5% revocaciones del stock activo, batcheadas): ~30-60/mes

Gas total Polygon PoS:

Anchor batches:       180/mes × USD 0.003-0.005 = USD 0.54 - 0.90
Status list updates:   60/mes × USD 0.003-0.005 = USD 0.18 - 0.30
                                                  ─────────────────
TOTAL GAS MENSUAL:                                USD 0.72 - 1.20
TOTAL GAS ANUAL:                                  USD 8.64 - 14.40

< USD 15/año en gas con estos volúmenes. El gas NO es el cost driver del proyecto — el trabajo humano sí.

Insight clave · el gas es constante en magnitud independiente del volumen

El merkle root es siempre 32 bytes. Cabe el root de 1.000 VCs o el de 1.000.000 VCs en la misma tx. Solo escalás los batches si necesitás mayor frecuencia (cada 1h vs cada 4h):

Frecuencia de batch	Tx/mes	Gas/mes (Polygon PoS)
Cada 24h (1/día)	30	USD 0.09 - 0.15
Cada 4h (6/día)	180	USD 0.54 - 0.90
Cada 1h (24/día)	720	USD 2.16 - 3.60
Cada 15 min (96/día)	2.880	USD 8.64 - 14.40

Para anchoring de VCs, batches cada 1-4h son sobrados. Más frecuencia ≠ más valor porque el cliente igual espera el batch para verificar.

Açaí — cómo se factura en cada fase

Fase 1 (estado actual + lo que arrancamos)

CERO blockchain para Açaí. El ledger sigue siendo postgres (user_acai_balance, user_acai_ledger). El modelo 20/7/5 de dividendos opera exactamente como hoy. Ningún movimiento de Açaí dispara gas.

Evento Açaí	Implementación	Costo blockchain
Tenant llama POST /v1/screenings → débito	UPDATE user_acai_balance + insert ledger	Cero
Sistema otorga dividendo 20/7/5	UPDATE + insert	Cero
User gasta Açaí en servicio interno	UPDATE + insert	Cero
Tenant compra Açaí con fiat	Gateway de pago + ledger update	Cero
Auditoría de balance	SELECT con audit trail	Cero

Fase 2 hipotética (12-18 meses, si los 3 triggers se cumplen)

Si en Fase 2 decidimos tokenizar Açaí, hay 3 modelos posibles con costos muy distintos. La recomendación del agente es Modelo B híbrido.

Modelo A · ERC-20 puro on-chain (TODO movimiento es tx)

Cada mint, transfer y burn dispara una tx. Con los volúmenes ejemplo:

• Mints (welcome + KYC bonus): 1.000 onboardings × ~5 dividendos = 5.000 tx/mes
• Movimientos por uso (1 movimiento por auth): 10.000 tx/mes
• Dividendos diarios automáticos: ~1.000 tx/mes
• Total: ~16.000 tx/mes → USD 48-80/mes gas → USD 576-960/año

Modelo B · Híbrido ledger interno + bridge on-demand (RECOMENDADO)

• 99% de los movimientos de Açaí quedan en postgres (igual que Fase 1)
• Solo cuando user pide “withdraw mi Açaí a mi wallet propio” → 1 tx (mint ERC-20 + transfer)
• Cuando user deposit back → 1 tx (burn ERC-20 + credit interno)
• Asumiendo 5% de usuarios hacen withdraw 1× al mes = ~500 tx/mes
• Gas: USD 1.5-2.5/mes → USD 18-30/año

Modelo C · Solo dividendos importantes on-chain

• Los movimientos chicos (débitos por uso) quedan postgres
• Solo dividendos > umbral (ej. > 100 Açaí) se anclan on-chain como audit trail
• Asumir 100 dividendos/mes anclados = USD 0.30-0.50/mes → USD 4-6/año

Tabla resumen comparativa Fase 1 vs Fase 2 (hipotética)

Concepto	Fase 1 (Año 1)	Fase 2 Modelo B híbrido	Fase 2 Modelo A puro
Eventos del producto que tocan blockchain	Solo cron anchor + status list	Cron + withdraw/deposit	Todo movimiento Açaí
Tx/mes con tus volúmenes	180-240	~700	~16.000
Gas/mes Polygon PoS	USD 0.72 - 1.20	USD 1.50 - 2.50	USD 48 - 80
Gas/año	USD 8 - 14	USD 18 - 30	USD 576 - 960
% del cost stack total	< 0.1%	< 0.2%	~2-3%

Hallazgo no obvio sobre Polygon

Polygon PoS no cobra por lectura (queries via RPC: balances, eventos, transacciones históricas). Solo cobra por escritura (txs firmadas). Eso significa que verificar un VC anclado desde un RP cualquiera es gratis para el RP. El RP solo paga su propio RPC managed si lee mucho — y los free tiers de Alchemy/QuickNode son suficientes para verificación.

---

Evaluación profunda Fase 2 (2026-05-30 v4)

Esta sección reabre la pregunta de Fase 2 a pedido explícito del usuario

El ADR cerró Fase 2 como DEFERRED sujeto a 3 triggers (segundo operador externo, opinión SuperFinanciera favorable, >100k MAU). El usuario pidió: “evalua fase2” — esto es, re-evaluación profunda hoy con los datos frescos del producto y del mercado 2026, no en 12-18 meses.

Esta sección no decide por el usuario. Cierra con una pregunta única. La regla del agente sigue siendo: “What’s the failure of the current centralized design that blockchain actually fixes?” — si la respuesta es “ninguno material”, la recomendación es no tokenizar.

1 · Diagnóstico de los 3 triggers · estado al 2026-05-30

Trigger	Definición original	Estado real al 2026-05-30	Distancia
T1 · Segundo operador externo aceptando Açaí cross-tenant	Otro operador (no tenant del ecosystem actual) acepta Açaí como medio de pago, generando demanda real de portabilidad	El producto tiene 1 operador en producción (cashpaya migrada → bmonkey). El CODEOWNERS sólo lista grupos internos. tenant_operators es para empleados del mismo tenant, no para operadores externos. Cross-tenant Açaí hoy es 7 Açaí al tenant origen del KYC (intra-ecosistema).	No cumplido. Cero señales de un segundo operador externo en pipeline visible.
T2 · Opinión legal favorable SuperFinanciera + Decreto 1547 + Ley 2200	Concepto escrito de firma legal que clasifique Açaí tokenizado como activo virtual de utilidad sin ser security ni e-money	No iniciado. Este trabajo es Fase 0 (USD 13k-24k). En 2026-Q1 la Resolución DIAN 000240 ya obliga a PSAVs registrados con Banco República a reportar operaciones de usuarios colombianos; el PSAV Registry SFC está operativo en 2026 (ver referencias del addendum). Cualquier emisor de token cripto en Colombia hoy debe registrarse PSAV.	No cumplido. Y peor: el régimen 2026 endurecido vs 2024 — registro PSAV obligatorio antes de operar.
T3 · >100k MAU del wallet	Mass adoption suficiente para amortizar ongoing tokenizado	Volúmenes del usuario: 1.000 onboardings/mes + 10.000 autenticaciones/mes. MAU efectivo ≈ 5-10k (asumiendo cada usuario auth ~1-2/mes). 10x-20x por debajo del trigger.	No cumplido. Año 2 estimado (×2 volumen): 10-20k MAU. Año 3 (×5): 25-50k MAU. Trigger T3 no se cumple ni en Año 3 con los volúmenes proyectados.

Conclusión del diagnóstico: 0 de 3 triggers se cumplen. Y el régimen regulatorio COL 2026 (Resolución DIAN 000240 + PSAV Registry operativo) es más estricto que el supuesto en el ADR v3. Los 3 triggers no están “cerca” — están lejos por orden de magnitud.

¿Hay razón técnica/estratégica suficiente para adelantar igual?

• ¿La tokenización resuelve un threat que el ledger postgres no resuelve? No. El threat model del §“Threat model resumido” muestra que la tokenización empeora privacidad (chain pública filtra metadata) sin agregar mitigación nueva sobre el anchoring de Fase 1.
• ¿Hay demanda de mercado documentada? No. Cero menciones de “queremos Açaí transferible” en backlog, en consultas de clientes, en discovery con tenants actuales.
• ¿Hay ventaja competitiva inmediata? No. Stripe Identity / Persona / Trulioo no tienen tokens y siguen ganando enterprise sin ello. El diferencial de bjungle es el modelo 20/7/5 (data dividends al usuario), no el wrapper on-chain.
• ¿Estamos perdiendo optionality por esperar? No. La decisión Polygon PoS de Fase 1 (pendiente confirmación del usuario por el addendum v2) preserva la opción de tokenizar después con ERC-20 + ERC-4337 + EIP-7212 en el mismo chain. No hay lock-in que se cierre.

No hay razón técnica ni estratégica para adelantar Fase 2. Lo que sigue es la evaluación profunda de los 3 modelos, threat model SARLAFT, cost model con volúmenes reales y la alternativa no-blockchain, para que cuando los triggers se cumplan (12-24 meses adelante, escenario optimista) la decisión esté pre-cocinada.

2 · Análisis técnico profundo de los 3 modelos

Modelo A · ERC-20 puro on-chain (todo movimiento es tx)

Diseño:

• Smart contract ERC-20 con extensiones: Pausable (para freeze de emergencia SARLAFT), Mintable controlado (solo bjungle KMS o multi-sig), AllowList (ERC-1404 / ERC-3643 para SARLAFT compliance — solo wallets verificados pueden recibir), Freeze por wallet (orden judicial UIAF), distribution module para dividendos automáticos.
• Custodia: MPC obligatorio (no podemos custodiar private keys de 100k+ usuarios con KMS plano — el blast radius es inadmisible). Fireblocks Essentials USD 699/mes entry (4.000 wallets máx, 5 user accounts) — insuficiente para volumen alto, requiere Pro custom-quote.
• Migration: snapshot del estado de user_acai_balance + acai_balances → batch mint inicial al contrato → distribuir a wallets MPC del usuario.
• UX: cada operación (débito por consent, crédito por dividendo, transfer entre usuarios) dispara una tx firmada con la passkey del usuario (si ERC-4337) o vía Fireblocks (si MPC custodial). Delay 3-5s en Polygon PoS hasta confirmación. Status pending → confirmed visible en UI.

Volúmenes con supuestos del usuario:

Evento	Volumen mensual	Tx/mes en Modelo A
Mints onboarding (welcome + KYC + 3 dividendos iniciales)	1.000 × 5	5.000
Movimientos por autenticación (1 débito consent + 1 crédito split)	10.000 × 2	20.000
Dividendos diarios automáticos (cron por uso)	~30 × ~30 wallets activos/día	~900
Transfers usuario→usuario (estimado 5% wallets activos × 1 tx/mes)	~250	250
Total		~26.000 tx/mes

Costos one-time (2026, verificados):

Item	Costo
Smart contract ERC-20 + extensiones + distribution module (Solidity senior, ~6 sem)	USD 18.000-24.000
Auditoría externa — mid-tier (Halborn, Hacken, ConsenSys Diligence) ERC-20 + extensiones	USD 25.000-60.000 (Sherlock 2026 reference)
Auditoría externa — top-tier (Trail of Bits, OpenZeppelin)	USD 80.000-200.000 (USD 25k/eng-week × 3-5 sem)
Re-audit pass post-remediation	USD 5.000-20.000
Bridge service Go (escucha postgres outbox + mints/burns on-chain)	USD 12.000-16.000
Frontend wallet UI (withdraw/deposit/transfer + tx status + balance dual)	USD 8.000-12.000
KYT setup (Chainalysis KYT contact-sales, asumiendo tier inicial)	USD 8.000-15.000 setup
Legal Fase 0.5 — opinión específica token utility + PSAV registry filing	USD 20.000-40.000
Migration de balances actuales (snapshot + atomic mint + reconciliation)	USD 6.000-10.000
Documentación + comunicación al usuario + soporte ramp-up	USD 4.000-6.000
Total one-time mid-tier audit	USD 106.000-203.000
Total one-time top-tier audit	USD 161.000-343.000

Costos mensuales con volúmenes proyectados:

Item	Año 1 (26k tx/mes)	Año 2 (×2 = 52k tx/mes)	Año 3 (×5 = 130k tx/mes)
Gas Polygon PoS — ERC-20 transfer ~USD 0.0005-0.002 (gas trackers 2026)	USD 13-52/mes	USD 26-104/mes	USD 65-260/mes
Buffer volatilidad POL ×2	USD 26-104/mes	USD 52-208/mes	USD 130-520/mes
RPC managed (Alchemy/Chainstack)	USD 50/mes	USD 200/mes	USD 500-1.000/mes
Custody Fireblocks Essentials → Pro (Fireblocks pricing 2026)	USD 699/mes Essentials (límite 4.000 wallets — alcanza Año 1)	USD 1.500-3.000/mes Pro (custom quote >4.000 wallets)	USD 3.000-8.000/mes Pro+
KYT subscription (Chainalysis quote por volumen)	USD 1.000-3.000/mes	USD 3.000-8.000/mes	USD 8.000-20.000/mes
Compliance officer + abogado retainer	USD 2.000/mes	USD 4.000/mes	USD 8.000/mes
DIAN/UIAF reporting (software + horas)	USD 500/mes	USD 1.500/mes	USD 3.000/mes
Indexer (subgraph o polling Go)	USD 0-100/mes	USD 100-300/mes	USD 300-500/mes
On-call extendido a chain ops (0.1-0.3 FTE × salario senior LATAM)	USD 800-2.500/mes	USD 1.600-3.500/mes	USD 2.500-5.000/mes
Total mensual Modelo A	USD 5.088-9.808/mes	USD 11.978-23.815/mes	USD 25.495-46.280/mes
Anualizado	USD 61k-118k/año	USD 144k-286k/año	USD 306k-555k/año

Pros / contras Modelo A:

• ✅ Portabilidad total. Cualquier wallet on-chain compatible recibe Açaí sin pedir permiso a bjungle.
• ✅ Transparencia pública del supply, dividendos, distribuciones.
• ✅ Si bjungle quiebra, los Açaí siguen vivos on-chain (con la pubkey en MPC custodiada por usuario).
• ❌ Costo mensual mata el caso de negocio. Año 1 mínimo USD 5k/mes — vs ingreso del producto que está en órdenes de magnitud distintos.
• ❌ Privacidad empeora drásticamente. La chain pública correlaciona cada movimiento de cada usuario. Mitigación con stealth addresses (ERC-5564) suma complejidad sin resolver del todo.
• ❌ UX degradado en happy path. El usuario que solo quiere ver su balance ahora espera confirmación on-chain en cada operación.
• ❌ Cumplimiento SARLAFT requiere AllowList activa, lo cual contradice la promesa de “portable libremente” — solo wallets aprobados reciben.
• ❌ Si DIAN considera cada movimiento un evento gravable (15% ingreso ocasional si holding > 2 años, hasta 35% renta ordinaria si < 2 años), el usuario que reciba 5 Açaí en 1.000 movimientos al año tiene 1.000 eventos tributarios.

Veredicto Modelo A: Anti-recomendado. Costo prohibitivo (USD 60k-555k/año según horizonte y volumen) sin que ningún threat se cierre que no se cierre ya con el anchoring Fase 1 + ledger interno.

Modelo B · Híbrido (postgres ledger + bridge on-demand)

Diseño:

• Postgres ledger sigue siendo source of truth para 99% de los movimientos (exactamente como Fase 1 + 20/7/5).
• Smart contract ERC-20 + bridge contract con dos métodos privilegiados:
  • mint(user, amount) — solo el operator (cuenta multi-sig bjungle: 2-of-3 KMS+Fireblocks) puede llamar. Disparado cuando user invoca POST /v1/wallet/me/acai/withdraw.
  • burn(user, amount) — disparado al recibir signed transfer back. Crédito al ledger interno.
• UX dual-track:
  • Usuario default: no ve nada de chain. Su balance interno funciona idéntico a hoy. Cero gas. Cero passkey signing. Cero cambio de UX vs §2.a.
  • Usuario power: botón “Withdraw mi Açaí a mi wallet propio” en pantalla /wallet/me. Firma con passkey (si ERC-4337 wallet bjungle) o con wallet externo MetaMask (si elige no-bjungle). Recibe ERC-20 en su wallet on-chain.
• Custodia: el owner del bridge contract es un multi-sig 2-of-3 bjungle (no MPC custodial por usuario — el usuario que retira pasa a manejar sus propias keys o usa ERC-4337 con passkey). Esto reduce blast radius dramáticamente.

Volúmenes con supuestos del usuario (asumiendo 5% adopción withdraw mensual):

Evento	Volumen mensual
Movimientos internos (ledger postgres)	~31.000 (idéntico a Modelo A pero off-chain)
Withdraws on-chain (5% × ~5k usuarios activos × 1/mes)	~250 mints
Deposits back on-chain (estimado 20% del withdraw vuelve)	~50 burns
Tx/mes on-chain	~300

Costos one-time (2026, verificados):

Item	Costo
Smart contract ERC-20 + bridge contract + multi-sig operator (Solidity senior, ~5 sem)	USD 15.000-20.000
Auditoría externa — mid-tier ERC-20 + bridge	USD 25.000-50.000
Re-audit pass	USD 5.000-15.000
Bridge service Go (endpoints withdraw/deposit + worker watching chain events)	USD 10.000-14.000
Frontend wallet UI (withdraw/deposit + dual balance display + opt-in power user mode)	USD 6.000-9.000
KYT setup (más light que Modelo A — solo aplica a movimientos on-chain)	USD 5.000-10.000 setup
Legal Fase 0.5 — opinión specifica + PSAV registry	USD 15.000-30.000
Migration: solo se mintea on-chain bajo demanda (cero migration upfront)	USD 0
Multi-sig setup + procedures (Safe.global con 3 signers Fireblocks/KMS/hardware)	USD 1.500-3.000
Documentación + comunicación + soporte	USD 3.000-5.000
Total one-time Modelo B	USD 85.500-156.000

Costos mensuales:

Item	Año 1 (300 tx/mes)	Año 2 (×2)	Año 3 (×5)
Gas Polygon PoS — mint/burn ~USD 0.005-0.02 (smart contract execution más caro que transfer simple)	USD 1.50-6/mes	USD 3-12/mes	USD 7.50-30/mes
Buffer volatilidad POL ×2	USD 3-12/mes	USD 6-24/mes	USD 15-60/mes
RPC managed Alchemy	USD 0 (free tier) - 50/mes	USD 50-100/mes	USD 100-200/mes
Custody — Safe.global multi-sig (gratuito) + AWS KMS 3 keys	USD 5-10/mes	USD 5-10/mes	USD 5-10/mes
KYT subscription light tier	USD 500-1.500/mes	USD 1.000-3.000/mes	USD 2.000-5.000/mes
Compliance officer (parcial, 0.2 FTE — el grueso lo absorbe el equipo existente)	USD 1.000/mes	USD 2.000/mes	USD 4.000/mes
DIAN/UIAF reporting (solo sobre tx on-chain)	USD 200/mes	USD 500/mes	USD 1.500/mes
On-call extendido (0.05-0.1 FTE)	USD 400-800/mes	USD 800-1.500/mes	USD 1.000-2.000/mes
Total mensual Modelo B	USD 2.108-3.428/mes	USD 4.364-7.146/mes	USD 8.627-12.800/mes
Anualizado	USD 25k-41k/año	USD 52k-86k/año	USD 103k-154k/año

Threat model específico Modelo B:

• bjungle comprometido → mints fraudulentos: si un atacante obtiene 2 de las 3 keys del multi-sig (Fireblocks + KMS + hardware HSM offline), puede mintear Açaí ilimitado on-chain. Mitigación: monitoring de eventos Minted con alerting si > umbral por hora; pausable contract con call de emergencia desde un tercer signer offline.
• Bridge service comprometido: el atacante hace withdraws no autorizados. Mitigación: el endpoint POST /v1/wallet/me/acai/withdraw exige step-up token de la passkey del usuario (mismo patrón del wallet step_up_tokens de migration 0014). No basta con bypassear el bridge — hay que comprometer al usuario también.
• Race condition withdraw + transfer interno: usuario debita balance interno por consent + simultáneo pide withdraw. Mitigación: lock optimista en user_acai_balance (mismo patrón que el outbox de migration 0009).
• Replay del withdraw on-chain: el bridge usa nonce monotónico por wallet, mismo patrón ERC-2612 / EIP-712.

Pros / contras Modelo B:

• ✅ Preserva UX 99% (status quo del Modelo C híbrido del wallet, sin gas, sin signing on-chain en happy path).
• ✅ Habilita portabilidad real para el 5% que la quiere.
• ✅ Costo mensual 10× menor que Modelo A (USD 2k-3k/mes Año 1 vs USD 5k-10k/mes).
• ✅ Convergencia natural con ERC-4337 + EIP-7212 + passkey (ver §5).
• ❌ Sigue activando régimen PSAV + SARLAFT desde el momento que existe el bridge. El régimen aplica al issuer del token, no a la frecuencia de transferencias.
• ❌ Dual-balance UX agrega complejidad cognitiva (“¿por qué tengo 100 Açaí internos y 5 on-chain?”).
• ❌ El argumento “Açaí cross-tenant portable” hoy no tiene demanda (T1 = no cumplido) — el bridge sin demanda externa es withdraw a vacío.

Veredicto Modelo B: Es el modelo correcto SI se decide tokenizar, pero no hoy — los 3 triggers no se cumplen y el costo anual (USD 25k-154k según año) es injustificable sin demanda.

Modelo C · Solo dividendos importantes on-chain (audit trail public)

Diseño:

• ERC-20 no fungible per se — el contrato emite solo eventos DividendIssued(user, amount, source) para movimientos > umbral (ej. > 100 Açaí en un evento dado).
• No hay supply circulante on-chain. No es activo virtual transferible. Es registro auditable público de dividendos importantes, similar a un Merkle log pero usando un contrato para emitir eventos indexables.
• Custodia: trivial — solo bjungle multi-sig firma los eventos. El usuario nunca interactúa con la chain.
• UX: idéntica al Modelo C status quo. El “agregado” es que el usuario puede compartir un link público (“aquí está mi historial de dividendos verificable en Polygonscan”) cuando quiere probar a un tercero que recibió X Açaí de bjungle.

Volúmenes con supuestos del usuario:

Evento	Volumen mensual
Eventos > umbral (ej. > 100 Açaí — solo grandes dividendos)	~100
Tx/mes on-chain	~100 (más eventos por tx si batched, podría bajar a ~30)

Costos one-time:

Item	Costo
Smart contract event-emitter (mucho más simple — sin ERC-20 transferable)	USD 5.000-8.000
Auditoría externa — light tier (Sherlock simple ~USD 5k-10k, no necesita top-tier porque no hay assets en juego)	USD 5.000-10.000
Bridge service Go (mismo outbox pattern, agrega un publisher Go al contrato)	USD 4.000-6.000
Frontend wallet — agregar link público “ver mi historial verificable”	USD 2.000-3.000
KYT setup — no aplica (no hay activo virtual transferible)	USD 0
Legal Fase 0.5 — opinión simple (“audit log público ≠ token”)	USD 5.000-10.000
Multi-sig + documentación	USD 1.000-2.000
Total one-time Modelo C	USD 22.000-39.000

Costos mensuales:

Item	Año 1 (100 tx/mes batched 1/día)	Año 2-3
Gas Polygon PoS — event emit ~USD 0.005	USD 0.15-0.50/mes	USD 0.30-2/mes
RPC managed (free tier sobra)	USD 0/mes	USD 0-50/mes
Custody multi-sig + KMS	USD 5/mes	USD 5/mes
Compliance officer (mínimo, este modelo no activa SARLAFT)	USD 0-500/mes	USD 0-1.000/mes
On-call (0.02 FTE)	USD 200/mes	USD 400/mes
Total mensual Modelo C	USD 205-705/mes	USD 405-1.450/mes
Anualizado	USD 2.5k-8.5k/año	USD 5k-17k/año

Pros / contras Modelo C:

• ✅ Resuelve el caso “auditabilidad pública” del Açaí ledger (audit trail verificable por terceros).
• ✅ Cost stack 10× menor que Modelo B, ~30× menor que Modelo A.
• ✅ Probablemente NO activa régimen PSAV (no hay activo virtual transferible). Esto requiere validación legal específica — pero el argumento es defendible.
• ✅ Compatible 100% con el ledger postgres actual + modelo 20/7/5.
• ❌ No resuelve portabilidad — el usuario sigue dependiendo de bjungle para canjear sus Açaí.
• ❌ Valor incremental sobre el anchoring de Fase 1 es marginal. Fase 1 ya anchora hashes de VCs — agregar Açaí dividends al mismo merkle root es ~0 incremental cost.

Veredicto Modelo C: Interesante pero redundante con Fase 1. Si lo que buscamos es auditabilidad pública del ledger Açaí, lo correcto es incluir el ledger Açaí en el merkle root anclado por Fase 1 (ver §6 Alternativa anchoring). No requiere smart contract ni PSAV separado.

3 · Threat model SARLAFT específico tokens utility en Colombia 2026

Régimen	Aplicabilidad a Modelo A/B (tokenización)	Aplicabilidad a Modelo C (event-only)	Aplicabilidad a anchoring ledger (alternativa §6)
Decreto 1297/2023 + PSAV Registry SFC (operativo 2026)	SÍ aplica. Açaí tokenizado = activo virtual de utilidad. bjungle como emisor debe registrarse PSAV antes de operar. Argumento “token de loyalty” es defendible pero requiere concepto escrito de SFC. Riesgo de rechazo del filing real (asesoría legal: 40-60% probabilidad de éxito en primer filing sin precedente).	Probablemente NO aplica. No hay activo virtual transferible — solo registro de eventos. Necesita concepto escrito legal “audit log público no es PSAV”.	No aplica. Hash es solo prueba de existencia. SuperFinanciera 2023-2024 emitió concepto similar para timestamping.
SARLAFT Circular Básica Jurídica SFC	SÍ aplica si PSAV. Reportes UIAF de operaciones sospechosas obligatorios. KYT integration obligatoria (Chainalysis o equivalente). Manual de procedimientos + oficial cumplimiento dedicado.	No aplica si modelo se acepta como audit log.	No aplica.
Resolución DIAN 000240 (vigente 2026)	SÍ aplica si PSAV. Reporte trimestral a DIAN de operaciones de usuarios COL incluyendo balances, transfers, withdraws. Equivalente al reporting de Binance/Bitso desde 2025.	No aplica si no hay activo virtual.	No aplica.
DIAN tributación criptoactivos (Concepto Unificado 2023 + actualizaciones 2026)	Sí impacta al usuario final. Cada Açaí recibido es renta ordinaria (hasta 35% marginal). Holding > 2 años = ingreso ocasional 15%. El producto debe emitir certificados tributarios al usuario — operativamente complejo.	No aplica — no son activos del usuario en sentido tributario.	No aplica.
Ley 1581 datos personales + concepto SIC sobre hash on-chain	El hash on-chain del balance de un usuario + metadata de movimientos es correlacionable con la identidad si el atacante tiene contexto. Concepto SIC pendiente. Riesgo regulatorio medio.	Bajo riesgo. Solo se publica (amount, source, timestamp). No hay user identifier directo on-chain — opcional emitir un pseudo-id rotativo.	Bajo riesgo. Hash de un VC no revela claims. Lo trata el ADR original §1.a privacidad.
Ley 2200/2022 + Proyecto de Ley 510/2025 fintech-cripto	Marco evolutivo. Holland & Knight reporta proyecto 510/2025 buscando regular específicamente PSAVs. Régimen aún más estricto esperado 2026-2027.	Posible aplicación si el proyecto define “registro on-chain de actividad” como sub-categoría — pero hoy no.	No esperado que aplique.

Lectura del threat model: Modelo A y Modelo B activan régimen PSAV completo (Registry + SARLAFT + KYT + DIAN trimestral + tributación al usuario). Esto NO es un “veremos después” — el cumplimiento debe arrancar antes del go-live. Tiempo estimado del filing PSAV: 6-12 meses según firmas COL. Costo legal Fase 0.5 (USD 15k-40k) es subestimación si el filing requiere iteraciones.

Modelo C y la alternativa anchoring (§6) probablemente no activan régimen PSAV — pero requieren concepto escrito legal explícito antes de hacer claim público.

4 · Cost model Fase 2 consolidado por modelo · 3 años

Resumen one-time

Modelo	One-time (mid-tier audit)	One-time (top-tier audit)
A · ERC-20 puro	USD 106.000-203.000	USD 161.000-343.000
B · Híbrido	USD 85.500-156.000	USD 140.500-296.000 (raro justificar top-tier para B)
C · Event-only	USD 22.000-39.000	N/A (light tier audit suficiente)

Resumen mensual con crecimiento (1k onboardings + 10k auths/mes baseline)

Modelo	Año 1 / mes	Año 2 (×2) / mes	Año 3 (×5) / mes
A · ERC-20 puro	USD 5.088-9.808	USD 11.978-23.815	USD 25.495-46.280
B · Híbrido	USD 2.108-3.428	USD 4.364-7.146	USD 8.627-12.800
C · Event-only	USD 205-705	USD 405-1.450	USD 1.000-3.000 (extrap.)

Resumen anualizado total con horizonte 3 años (one-time + ops × 36 meses)

Modelo	Año 1 (one-time + 10 meses ops)	Año 2 (12 meses ops)	Año 3 (12 meses ops)	Total 36 meses
A · mid-tier audit	USD 156k-301k	USD 144k-286k	USD 306k-555k	USD 606k-1.142k
B · híbrido	USD 106k-190k	USD 52k-86k	USD 103k-154k	USD 261k-430k
C · event-only	USD 24k-46k	USD 5k-17k	USD 12k-36k	USD 41k-99k

Comparación honesta: Fase 2 Modelo B (recomendado si se tokeniza) cuesta USD 261k-430k acumulado 3 años. Comparado con:

• Anchoring puro Fase 1 Año 1 (ADR v3): USD 27k-46k.
• Anchoring Fase 1 + extender a Açaí ledger (§6 alternativa): USD 30k-55k Año 1.

Fase 2 Modelo B es 6-10× más caro que extender el anchoring para cubrir Açaí. ¿Compra 6-10× más valor? Solo si hay demanda real de portabilidad on-chain. Hoy: no.

5 · UX deep-dive con Modelo C híbrido del wallet bjungle + ERC-4337 + EIP-7212

El wallet bjungle (Modelo C híbrido — Secure Enclave + passkey) tiene una ruta de convergencia con Web3 que debe documentarse porque cambia cualitativamente la propuesta:

Estado actual del wallet:

• Passkey WebAuthn registrada en wallet_passkeys (migration 0010).
• Firma con P-256 ECDSA (Secure Enclave iOS / StrongBox Android), no Ed25519.
• Atestación AppAttest + Play Integrity.
• Step-up flow con step_up_tokens (migration 0014) para operaciones destructivas.
• E2EE backup attestation (migration 0015) — el plan Modelo C real.

Lo que cambia con Polygon + EIP-7212 + ERC-4337:

EIP-7212 (P-256 precompile) está LIVE en Polygon PoS hoy (Corbado 2026, Stackup passkeys WebAuthn). Significa: la wallet bjungle puede convertirse en una smart account on-chain que firma transacciones con la misma passkey que ya usa para login. ZeroDev’s Kernel passkey module y Safe Passkeys son implementaciones de referencia.

Flow Modelo B híbrido con ERC-4337 + passkey:

1. Usuario abre PWA → ve balance Açaí (postgres ledger, idéntico a hoy).
2. Usuario tap “Withdraw mi Açaí a mi wallet propio”.
3. PWA prepara UserOperation (formato ERC-4337) con calldata transfer(user_wallet, amount).
4. PWA pide al usuario firmar el UserOperation con su passkey (Touch ID / Face ID).
5. Secure Enclave devuelve firma P-256 + WebAuthn authenticatorData + clientDataJSON.
6. PWA envía UserOperation firmada al bundler (Pimlico/Stackup/Coinbase).
7. Bundler arma la tx EntryPoint → la wallet smart account valida la firma P-256 vía EIP-7212 precompile → ejecuta el transfer.
8. Bjungle paga el gas como paymaster (similar a meta-transactions). El usuario nunca toca POL/MATIC.
9. UI muestra “Withdraw confirmado” en ~5s. Balance interno bajó, balance on-chain subió.

Por qué esto importa:

• El usuario nunca maneja seed phrase. La passkey ES la account on-chain.
• Si el usuario pierde el device, recovery via E2EE backup attestation (migration 0015) recupera la passkey → recupera la smart account on-chain. El plan recovery 48h ya documentado se extiende naturalmente al wallet on-chain.
• bjungle como paymaster permite cobrar gas vía Açaí (el usuario quema 2 Açaí, bjungle paga 0.001 POL). El UX es Web2.

Costo incremental de implementar passkey + ERC-4337 + EIP-7212 sobre Modelo B base:

Item	Costo
Smart account contract (modificar wallet Solidity para validateUserOp con verificación P-256 + EIP-7212)	USD 4.000-7.000
Auditoría incremental del módulo passkey (no es contract nuevo, es función nueva en wallet)	USD 5.000-15.000
Bundler/paymaster setup (Pimlico USD ~50-200/mes contract + 1 day integration)	USD 2.000-3.000 setup + USD 100-300/mes ongoing
Frontend WebAuthn → UserOperation pipeline (PWA + React Native si applica)	USD 6.000-10.000
Backend Go orchestration (firma del paymaster con KMS, gas accounting Açaí → POL)	USD 3.000-5.000
Total incremental	USD 20.000-40.000 + USD 100-300/mes

Decisión: ERC-4337 + EIP-7212 + passkey es el path natural si y solo si Fase 2 Modelo B se activa. NO es un trabajo standalone — solo tiene sentido cuando hay un wallet on-chain que firmar. Si Fase 2 nunca se activa, este sub-caso (BCS-14 del DEFERRED) muere con él.

6 · Alternativa no-blockchain · Anchoring del Açaí ledger en el mismo merkle de Fase 1

Esta es la alternativa más fuerte que el ADR v3 subestimó.

Diseño:

• Fase 1 ya publica un merkle root cada 4h con hashes de VCs emitidos.
• Extender el merkle para incluir también hashes de movimientos del Açaí ledger (user_acai_ledger + acai_ledger). Cada movimiento se incluye como sha256(wallet_id || delta || reason || ref_id || occurred_at).
• El merkle root publicado en Polygon PoS pasa a probar dos cosas: (a) qué VCs existían, (b) qué movimientos Açaí existían.
• Endpoint público GET /v1/acai/proof/{ledger_id} devuelve el merkle path para que un tercero verifique sin confiar en bjungle.
• API verificable: cualquier RP puede llamar GET /v1/acai/balance/{wallet_id}?proof=true y recibir {balance, signed_proof, merkle_root, l2_tx_hash}.

Costo incremental sobre Fase 1:

Item	Costo
Extender merkle builder Go para incluir Açaí ledger	USD 3.000-5.000
Endpoint público /v1/acai/proof/{ledger_id} + docs	USD 2.000-3.000
Frontend: surface “anchored balance” en wallet PWA	USD 1.000-2.000
Legal: concepto escrito “anchoring de ledger ≠ activo virtual”	USD 2.000-4.000
Total incremental sobre Fase 1	USD 8.000-14.000 one-time
Mensual incremental	USD 0-2/mes adicional (mismo batch, ~5-10% más bytes calldata)

¿Qué resuelve esta alternativa?

Caso	Modelo B tokenización	Anchoring ledger
Auditabilidad pública del Açaí	✅ Sí	✅ Sí (vía merkle proof)
Usuario prueba a tercero “bjungle me pagó X Açaí en fecha Y”	✅ Sí	✅ Sí (signed proof verificable contra root on-chain)
Detección de re-issuance fraudulenta backdateada del Açaí	✅ Sí	✅ Sí
Bjungle desaparece → Açaí sigue siendo verificable	⚠️ Solo lo retirado	✅ Sí (proofs vivos eternamente)
Portabilidad real (Açaí en otra wallet on-chain)	✅ Sí	❌ No
Mercado secundario / DeFi composability	✅ Sí (si emerge)	❌ No
Cumplimiento PSAV / SARLAFT / DIAN reporting cripto	⚠️ SÍ activa	✅ NO activa (audit log)
UX usuario default	✅ Igual (Modelo B híbrido)	✅ Igual
Costo 3 años acumulado	USD 261k-430k	USD 35k-60k

Lectura honesta: Anchoring del ledger Açaí resuelve 6 de los 8 casos de uso del Modelo B tokenizado, a ~7× menos costo y sin activar régimen PSAV. Los 2 casos que NO resuelve (portabilidad real + DeFi composability) son exactamente los que requieren los triggers T1 + T2 + T3 del ADR original — y esos triggers no se cumplen.

¿Es esto “el 80% del valor con 5% del costo”? En este caso, es el 75% del valor con ~15% del costo. La regla “80/5” se cumple en orden de magnitud.

7 · Decisión final · veredicto del agente

Recomendación: Opción B intermedia — arrancar el anchoring del Açaí ledger como upgrade de Fase 1, NO tokenizar.

Razones (en orden de importancia):

1. 0 de 3 triggers se cumplen. No hay segundo operador externo (T1). No hay opinión legal (T2 — y el régimen 2026 con Resolución DIAN 000240 + PSAV Registry operativo es más estricto que el supuesto en ADR v3). No hay >100k MAU (T3 — los volúmenes proyectados ni siquiera lo alcanzan en Año 3).
2. No hay threat que la tokenización resuelva que el anchoring no resuelva igual o mejor. Anchoring del ledger cubre auditabilidad, censura del issuer, persistencia post-bjungle. Tokenización agrega solo “portabilidad on-chain” — sin demanda verificada.
3. Modelo B (recomendado si se tokeniza) cuesta USD 261k-430k acumulado 3 años. Anchoring del ledger cuesta USD 35k-60k acumulado 3 años. El delta de USD 200k-370k no compra valor proporcional.
4. Activación PSAV / SARLAFT / DIAN reporting trimestral es un compromiso operativo permanente. Una vez se inicia, no se da marcha atrás sin daño reputacional. La asimetría costo-beneficio favorece no iniciar hoy.
5. El anchoring del ledger preserva 100% de la optionality de Fase 2. Si en 18-24 meses los triggers se cumplen, la tokenización Modelo B se activa encima del anchoring sin desperdicio. El anchoring no cierra ninguna puerta.
6. El ERC-4337 + EIP-7212 + passkey path es genuinamente atractivo a 2-3 años — pero solo emerge si Fase 2 se activa. Reservarlo como BCS-14 DEFERRED es correcto.

Lo que NO se hace:

• A) Recomendación SÍ, arrancar Fase 2 ahora — rechazada. Triggers no cumplidos, costo prohibitivo, valor sin demanda verificada.
• B) Recomendación NO, seguir DEFERRED puro — parcialmente correcta pero deja sin resolver el caso “auditabilidad pública del Açaí” que el anchoring sí puede cubrir.

Lo que SÍ se hace (recomendación C intermedia):

Extender Fase 1 (anchoring de VCs) para incluir el Açaí ledger en el mismo merkle root. Costo incremental USD 8k-14k one-time + USD 0-2/mes adicional sobre Fase 1. Resuelve auditabilidad sin abrir la caja de Pandora regulatoria.

Triggers actualizados (medibles) para reabrir Fase 2 tokenización:

Trigger viejo (ADR v3)	Trigger nuevo (medible v4)	Cómo se mide
Segundo operador externo	≥3 tenants externos firmaron LOI declarando “aceptaríamos Açaí cross-tenant si fuera portable”	LOI escrita, no conversación. Mide demanda real, no conjetura.
Opinión SuperFinanciera favorable	Concepto escrito de firma legal COL Tier-1 (Cecamagán, ATH21, Holland & Knight) + filing PSAV iniciado con SFC + respuesta inicial recibida	Documento concreto + radicado, no proceso.
>100k MAU	>30k MAU del wallet sustentado en 3 meses + >USD 1M/mes en débitos Açaí del ecosistema	MAU activo (auth ≥1 vez/mes) + volumen económico. Métricas observables desde el admin-console.

Señales que NO mirar (vanity metrics):

• “Otros wallets en LATAM tokenizan” — no es señal de demanda propia.
• “Polygon anuncia nueva feature X que facilita tokenización” — no cambia los triggers de demanda.
• “Hackathon o RFP gubernamental pide tokens” — no es producción.
• “Influencer cripto LATAM menciona bjungle” — ruido.
• Marketing-driven argumentos (“queda bien decir on-chain”) — la promesa pública sin demanda real degrada confianza.

Veredicto cerrado

Opción C intermedia · Anchoring extendido al Açaí ledger.

• USD 8k-14k one-time sobre Fase 1.
• USD 0-2/mes ongoing adicional.
• Resuelve auditabilidad pública del Açaí.
• NO activa régimen PSAV.
• Preserva 100% optionality para Fase 2 tokenización si triggers se cumplen en 18-24 meses.

Esta decisión actualiza el ADR-008 v3 sin invalidarlo: §2.a sigue siendo correcto (no tokenizar ahora), §“Anti-scope” sigue siendo correcto, los triggers se refinan a versiones medibles, y se agrega el work item BCS-15 al scope activo de Fase 1 — Anchoring del Açaí ledger.

Decisión aprobada 2026-05-30

El usuario aprobó la Opción C intermedia. BCS-15 entra al scope de Fase 1 como sub-PR paralelo. Scope efectivo de Fase 1:

1. BCS-01..08 — anchoring de VCs + status list (scope original)
2. BCS-15 — anchoring del Açaí ledger (mismo batcher, mismo ChainClient, merkle root incluye ambos: VCs nuevos y movimientos Açaí del periodo)

Total Fase 1 extendida con tus volúmenes (1k onboardings + 10k auths/mes):

• One-time: USD 14.000-34.000 + USD 8.000-14.000 (BCS-15) = USD 22.000-48.000
• Ongoing/mes: USD 7-220 + USD 0-2 (BCS-15) = USD 7-222

El roadmap original NO se retrasa porque BCS-15 reusa ~80% de la infra de BCS-01..08 (mismo chain_client, mismo merkle_batcher, mismo anchor_worker, mismo cron). La diferencia es que el merkle root incluye un segundo árbol (Açaí ledger entries) además del de VCs.

Status del ADR-008: Implemented-Phase-1 (Fase 1 entregada 2026-05-30 — ver §Fase 1 entregada al final del ADR).

---

Tres opciones presupuestales con scope ajustado. El usuario aprueba una.

Opción A · Mínimo viable (USD 13.100)

Solo lo esencial para no avanzar a ciegas legalmente.

• F0-1 abogado fintech COL (límite inferior, 20h concepto + consultas básicas): USD 3.000
• F0-2 abogado data privacy (límite inferior): USD 2.000
• F0-3 abogado SARLAFT (workshop solo): USD 1.500
• F0-4 discovery RPs (3 entrevistas, sin mockups): USD 2.000
• F0-5 benchmarking técnico (sandbox 1 sem, no spike completo): USD 3.000
• F0-6 documentación final: USD 1.000
• F0-7 NO contratado (consultor independiente diferido)
• Total: USD 12.500-13.100

Riesgo: los conceptos legales son al límite inferior; si la firma exige scope mayor, el rango se mueve. Sin F0-7, falta segunda opinión técnica externa.

Opción B · Recomendada (USD 18.000)

Balance entre robustez legal y dev time meaningful.

• F0-1 + F0-2 + F0-3 con scope completo (medium tier): USD 7.500
• F0-4 discovery 5 RPs con mockups: USD 2.300
• F0-5 benchmarking 1.5 sem con spike funcional desplegado en Amoy: USD 3.500
• F0-6 documentación final + ADR-008-legal separado: USD 1.300
• F0-7 consultor cripto-COL (4h sesión + revisión legal): USD 1.500
• Margen contingencia 10%: USD 1.700
• Total: USD 17.800-18.500

Riesgo bajo. Cubre Fase 0 con holgura sin exceder. Recomendada por el agente.

Opción C · Completa (USD 23.600)

Cobertura máxima. Justificada si bjungle quiere reducir 100% la incertidumbre antes de Fase 1 o si el sponsor pide pre-aprobación de auditoría externa.

• F0-1 + F0-2 + F0-3 con firma tier-1 + conceptos formales por escrito + workshops in-person: USD 13.000
• F0-4 discovery con 5 RPs + mockups + síntesis report: USD 2.700
• F0-5 benchmarking 1.5 sem + spike + comparativa Alchemy vs Chainstack vs QuickNode con métricas reales: USD 4.000
• F0-6 + ADR-008-legal + 2 ADRs adicionales (custody, monitoring): USD 1.500
• F0-7 consultor cripto-COL (8h + 2 sesiones + revisión doc): USD 2.400
• Total: USD 23.600

Riesgo: sobre-engineering de Fase 0 si después Fase 1 no se activa. Cubre escenarios de pivote.

Resumen ejecutivo de costos (los 3 totales clave)

Horizonte	Bajo (1k VCs/mes)	Medio (10k VCs/mes)	Alto (100k VCs/mes)
Fase 0 one-time (sin código)	USD 13.100-23.600 (3 opciones)	igual	igual
Año 1 total (F0 + F1 + 10 meses op)	USD 27.170-40.700	USD 30.400-46.200	USD 41.250-59.800
Steady state / mes (Fase 1 operativo)	USD 7-10/mes infra + USD ~500-1.000/mes dev mantenimiento	USD 30-60/mes infra + USD ~500-1.000/mes dev mantenimiento	USD 115-220/mes infra + USD ~1.000-2.000/mes dev mantenimiento
Steady state / año	USD 6.084-12.120/año	USD 6.360-12.720/año	USD 13.380-26.640/año

Lectura comparativa rápida:

• bhawk SaaS COL típico cuesta cientos a miles de USD/mes en infra. Fase 1 blockchain es <1% del TCO de stack en escenario Bajo y Medio.
• Auditoría externa de bhawk ya costó USD 5k+ (referencia interna ADR-007). Fase 0 legal está en el mismo orden de magnitud.
• NO es prohibitivo en ningún escenario, incluso Alto.

Recomendación del agente

Opción B (USD 18.000) para Fase 0 + Fase 1 con escenario Medio (10k VCs/mes).

Razones:

1. Opción B cubre la incertidumbre legal real sin sobre-engineering.
2. Escenario Medio es la proyección honesta a 12-18 meses (tracción esperada, no piloto ni hype masivo).
3. Año 1 total ~USD 30.400-46.200 + steady state USD 6.360-12.720/año es financeable como línea de R&D normal sin comprometer el roadmap principal.
4. El delta entre A y B (~USD 5k) compra 2-3× más certidumbre legal — buena inversión marginal.
5. Opción C es defendible si el sponsor exige cobertura máxima, pero no es necesaria.

---

Pregunta final al usuario:

¿Qué presupuesto aprobás para Fase 0?

A) Mínimo viable — USD 13.100 B) Recomendada — USD 18.000 (recomendación del agente) C) Completa — USD 23.600

Y secundariamente: ¿qué escenario de volumen es la proyección honesta a 12-18 meses para presupuestar Fase 1? Bajo (1k VCs/mes) / Medio (10k VCs/mes) / Alto (100k VCs/mes).

Con esas dos respuestas, el agente puede cerrar el cost model y el ADR pasa de Draft a Approved-Phase-0.

---

Roadmap por fases

Solo Fase 0 y Fase 1 son propuestas en este ADR. Fase 2+ son anti-scope hasta que se cumplan condiciones de re-evaluación.

Fase 0 — Decisiones legales y benchmarking (4-6 semanas, no requiere código)

Propósito: desbloquear las decisiones de las próximas fases sin invertir en implementación.

1. Engagement con abogado de protección de datos + experto regulatorio cripto-COL.

   • Pregunta: ¿anchoring de hashes de VCs en chain pública califica como tratamiento de datos personales bajo Ley 1581?
   • Pregunta: ¿Açaí tokenizado (incluso solo como wrapper opcional vía withdraw) requiere licencia SuperFinanciera o pasa como “punto de loyalty digital”?
   • Pregunta: ¿qué reportes UIAF/SARLAFT activa cada modelo?
   • Output: ADR-008-legal (separado de este).

2. Validación de costo Polygon/Base con datos frescos 2026-Q2.

   • Pedir cotización de gas con volumen estimado (10k VCs/mes).
   • Benchmark de 2-3 providers de MPC custody (Fireblocks, Cobo, Coinbase Custody).

3. Discovery con 3-5 RPs potenciales (tenants y futuros Tier-2/3 OIDC).

   • ¿Valoran anchoring on-chain? ¿pagarían premium por ello?
   • ¿Tienen casos de uso Web3 que motivarían SBT?
   • ¿Estarían dispuestos a aceptar Açaí cross-tenant?

Sin Fase 0 completa, NO arrancar Fase 1. Es 4-6 semanas a costo prácticamente cero pero desbloquea decisiones de los 18 meses siguientes.

Fase 1 — Anchoring + revocation registry (4-6 semanas tras Fase 0 luz verde)

Sprint con backend-dev + security + (opcional) auditoría externa light del merkle scheme.

Scope:

1. Migration 00XX_vc_anchor:

   • vc_anchor_batches (batch_id, merkle_root, l2_tx_hash, l2_block, anchored_at).
   • vc_anchor_proofs (vc_id, batch_id, merkle_path jsonb).
   • Helpers SECURITY DEFINER siguiendo patrón del repo.

2. Backend Go (bmonkey/backend/go-bmonkey-worker/internal/anchor/):

   • BatchScheduler — corre cada 4h, agrupa VCs issued_at > last_batch.
   • MerkleBuilder — computa root determinista.
   • ChainClient — publica root a Polygon vía RPC + firma con KMS-managed Polygon wallet o MPC.
   • ProofWriter — backfill vc_anchor_proofs post-confirmation.

3. Endpoint público:

   • GET /v1/vc/{vc_id}/anchor → devuelve {merkle_root, l2_tx_hash, l2_block, merkle_path} para verificación externa.
   • Adicionar al .well-known/openid-configuration el campo bjungle_anchor_chain con datos del chain usado.

4. Status list 2021:

   • Migration agregando bitstring + helper.
   • Endpoint GET /v1/vc/status-list (W3C compatible).
   • Hash del bitstring incluido en cada batch.

5. Archive del JWKS:

   • Cron diario que sube JWKS actual a IPFS (pin via Pinata) + Arweave.
   • CID y Arweave-ID escritos al batch on-chain.

6. Documentación pública:

   • Sección en website explicando “VCs anchored on-chain”, con ejemplo de verificación externa.
   • Update a wallet-modelo-c referenciando el anchoring como capa adicional.

7. Threat model focal (security agent):

   • Race condition: VC emitida pero aún no anchored (ventana de 4h).
   • Re-org del L2 (improbable en Polygon PoS post-checkpoint, pero documentar mitigación: esperar N confirmations antes de marcar batch como “anchored”).
   • Compromise del wallet on-chain de bjungle (puede publicar roots falsos) — mitigar con MPC + monitoring.

No incluye en Fase 1: smart contract custom (publicar root vía tx con data es suficiente), tokenización Açaí, DID method migration, SBT.

Chain de Fase 1 — decisión condicional al escenario (Addendum 2026-05-30 v2)

La recomendación original era Polygon PoS. Un addendum inicial cambió a Algorand sobreponderando la experiencia previa del usuario. Ese addendum fue reescrito tras feedback explícito: la experiencia previa es un factor entre varios, no el factor decisivo. Ver §Addendum 2026-05-30 v2 — matriz Polygon PoS vs Algorand al final del documento.

TL;DR del addendum: la respuesta depende del escenario a 3-5 años. Si bjungle nunca se expone al ecosystem Web3 (Escenario A), Algorand es ligeramente preferible. Si bjungle a 2-3 años quiere SBT, account abstraction con passkey, o integrar con Polygon ID / ONCHAINID (Escenario B), Polygon PoS gana de forma asimétrica. La decisión final requiere respuesta del usuario a la pregunta del cierre del addendum. Toda referencia a “Polygon” en §Fase 1 del Roadmap queda pendiente de confirmación hasta esa respuesta.

Fase 2+ — Anti-scope hasta condiciones de re-evaluación

Estos casos no se arrancan hasta que su trigger se materialice:

• Tokenización Açaí (§2.b/2.d/2.e): trigger = los 3 criterios de §2.b cumplidos + Fase 0 con luz verde legal.
• DID method migration (§1.b): trigger = RP enterprise lo exige o federación eIDAS.
• SBT (§1.d): trigger = primer cliente concreto Web3 LATAM.
• Smart contracts custom: trigger = volumen o feature lo requiere; nunca antes de auditoría externa.

---

Anti-scope (qué este ADR NO recomienda)

Explícitamente, no hacemos en este sprint:

1. No escribimos smart contracts. Si Fase 1 lo requiere, va a sub-sprint con auditoría externa.
2. No tokenizamos Açaí. Status quo del ledger interno.
3. No emitimos SBT. Sin mercado verificado.
4. No migramos did:web a otro DID method. Solo agregamos archive del JWKS.
5. No usamos L1 Ethereum. El costo mata el caso.
6. No usamos chains permissioned (Hyperledger, Besu) propias. No ganaríamos transparencia pública (que es el punto).
7. No usamos chains sin governance pública (cadenas “enterprise” cerradas son solo bases de datos con marketing).
8. No usamos algorithmic stablecoins. La historia de Terra/UST ya nos enseñó.
9. No hacemos ICO/IDO de Açaí. Sin consejo legal explícito, esto es asumir regulación de security.
10. No prometemos público “Açaí será token” sin haber pasado por la opinión legal.

---

DEFERRED — sub-PRs futuros (si Fase 1 luz verde)

Items que el ADR contempla pero entran como sub-PRs separados:

ID	Trabajo	Trigger
BCS-01	Migration vc_anchor_batches + vc_anchor_proofs	inicio Fase 1
BCS-02	BatchScheduler worker Go + tests	inicio Fase 1
BCS-03	ChainClient Polygon RPC + KMS Polygon wallet (custody decision pendiente)	inicio Fase 1
BCS-04	Endpoint GET /v1/vc/{vc_id}/anchor + docs públicas	inicio Fase 1
BCS-05	W3C Status List 2021 bitstring + endpoint	inicio Fase 1
BCS-06	Archive JWKS a IPFS + Arweave + CID en batch	inicio Fase 1
BCS-07	Frontend wallet PWA: surface “VC anchored on-chain” en UI	inicio Fase 1
BCS-08	Security threat model focal del anchoring + audit externo light	mid Fase 1
BCS-09	Engagement legal SuperFinanciera + abogado data protection	Fase 0 (sin código)
BCS-10	Discovery con RPs potenciales (3-5 entrevistas)	Fase 0 (sin código)
BCS-11	Tokenización Açaí design (ERC-20 L2 + MPC + bridge endpoints)	DIFERIDO — sin trigger todavía
BCS-12	DID method migration design	DIFERIDO — sin trigger todavía
BCS-13	SBT para Web3 RPs design	DIFERIDO — sin trigger todavía
BCS-14	ERC-4337 passkey-derived smart account (evolución futura del wallet)	DIFERIDO — sin trigger todavía
BCS-15	Anchoring del Açaí ledger (extensión Fase 1 — incluir movimientos Açaí en el merkle root junto con VCs)	✅ APROBADO 2026-05-30 — work item ACTIVO en scope Fase 1. USD 8k-14k one-time + USD 0-2/mes. Sub-PR paralelo a BCS-01..08, sin retrasar go-live.

---

Decisiones que el usuario (producto) debe tomar antes de avanzar

Este ADR queda en Implemented-Phase-1 (Fase 1 entregada 2026-05-30 — ver §Fase 1 entregada; Fase 2 sigue DEFERRED) hasta que el dueño de producto decida:

1. ¿Arranca Fase 0? (4-6 semanas, USD 13.100-23.600 según opción A/B/C — ver §Cost model consolidado v3 + §Decisión de costos para Fase 0). Cero código. Es prerequisito de todo lo demás.
2. ¿Quién es el sponsor de Fase 1 extendida? (4-6 semanas dev, USD 22.000-48.000 one-time = scope original USD 14-34k + BCS-15 USD 8-14k, según escenario volumen Bajo/Medio/Alto + USD 7-222/mes infra steady state — ver §Cost model). ¿bmonkey product? ¿plataforma? ¿Iniciativa cross-team?
3. Custodia del wallet on-chain de bjungle para Fase 1 — opciones:
   • KMS AWS managed (más simple, mismo provider que VC issuer, lock-in alto).
   • Fireblocks MPC (más seguro, costo USD ~6-12k/year tier mínimo).
   • Self-hosted MPC (más complejo, más control). Decisión recomendada: KMS AWS para Fase 1, evolucionar a MPC cuando crezca el blast radius.
4. L2 elegida — recomendación: Polygon PoS por costo + adopción LATAM. Confirmar con cotización fresca.
5. Política de claim público: ¿anunciamos “anchored on-chain” a clientes y website? Esto sube el valor percibido pero suma expectativa que debemos sostener.

---

Implicaciones para otros ADRs

• wallet-modelo-c: Fase 1 agrega anchoring como capa adicional. No cambia la decisión Modelo C — la complementa.
• data-dividends: Status quo confirmado. Açaí ledger interno sigue siendo la fuente de verdad.
• ADR-003 sign-in-with-bjungle: El claim bjungle_vc del id_token podría incluir el anchor_proof para que el RP verifique end-to-end. Sub-PR de Fase 1.
• ADR-007 bhawk-as-compliance-engine: Si bhawk se vende standalone, sus screening reports podrían anclarse on-chain por el mismo motivo que las VCs. Out-of-scope ahora pero consistente con la dirección.
• Roadmap ADRs futuros: este queda como ADR-008 (siguiente número libre tras ADR-007 cerrado). ADR-011 (federación eIDAS) y ADR-012 (selective disclosure BBS+) del catálogo pueden referenciarlo.

---

Referencias técnicas

• W3C Verifiable Credential Status List 2021: https://www.w3.org/TR/vc-status-list/
• ERC-5192 (Minimal Soulbound NFTs): https://eips.ethereum.org/EIPS/eip-5192
• ERC-4337 (Account Abstraction): https://eips.ethereum.org/EIPS/eip-4337
• EIP-7702 (Set EOA Account Code): https://eips.ethereum.org/EIPS/eip-7702
• Decreto 1547/2022 (Colombia, activos virtuales): https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/30043910
• Ley 2200/2022 (Colombia, fintech): https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=183094
• W3C VC Data Model 2.0: https://www.w3.org/TR/vc-data-model-2.0/
• Sidetree Protocol (did:ion): https://identity.foundation/sidetree/spec/

Referencias internas

• Wallet schema: bmonkey/backend/db-bmonkey/migrations/0005_wallet_global.up.sql
• VC issuer: bmonkey/backend/go-bmonkey-api/internal/service/vc_issuer.go
• Açaí pricing: platform/backend/go-platform-api/internal/domain/acai_pricing.go
• Açaí user ledger: bmonkey/backend/db-bmonkey/migrations/0007_user_dividends.up.sql
• Açaí tenant ledger: platform/backend/db-platform/migrations/0002_acai.up.sql

---

Este addendum reemplaza al addendum v1 (sesgado)

La versión v1 de este addendum (escrita el mismo día, antes que este) fue retirada por sesgo de confirmación: sobreponderó la experiencia previa del usuario con Algorand (25-50% de peso decisional asignado a “user prior experience”), exageró un delta de costos absoluto de ~USD 10/mes como decision driver, y subestimó el ecosystem EVM (EIP-5114 SBT, ERC-4337 account abstraction, EIP-7212 P-256 precompile, Polygon ID / ONCHAINID).

El usuario lo señaló: “no te sesgues si Polygon nos da beneficios no hay problema”. Tenía razón. Este addendum v2 es la reescritura honesta.

Addendum 2026-05-30 v2 · Matriz Polygon PoS vs Algorand (sin sesgo)

Campo	Valor
Status	Final — reemplaza al v1 (retirado por sesgo).
Trigger	Feedback del usuario al v1: la experiencia previa con Algorand es 1 factor entre varios, no el factor decisivo. Re-evaluación equilibrada solicitada.
Alcance	§Fase 1 (anchoring + revocation registry) + Fase 2/3 hipotéticas (SBT, account abstraction, tokenización Açaí). El veredicto NO tokenizar ahora no cambia; pero la chain elegida hoy condiciona qué herramientas estarán disponibles en 2-3 años.
Output esperado	Una pregunta concreta al usuario al final. La decisión final es del usuario; este addendum presenta opciones limpias.

Reconocimiento de errores del v1

Antes de la matriz, reconocer explícitamente qué se corrige:

1. Sesgo por preferencia personal: la experiencia previa del usuario es un factor real (reduce ramp-up de 1 dev × 2 semanas a 1-1.5 semanas), pero no es el factor decisivo a 5 años. Si el sistema lo mantienen 3-5 personas, el talent pool LATAM importa más que la curva del founder.
2. Sobreponderar costo absoluto pequeño: USD ~10/mes de diferencia es ruido contable para una empresa con TCO de stack en USD ~70-100/mes. No es decision driver.
3. Subestimar el ecosystem EVM (corrección detallada en la matriz): SBT estándar maduro (EIP-5114, EIP-5484, EIP-4973), ERC-4337 account abstraction con USD 180M+ gas sponsored acumulados a Q1 2026, EIP-7212 P-256 precompile LIVE en Polygon (lectura: passkey-driven account abstraction es producción real en Polygon hoy), Polygon ID y ONCHAINID convergiendo en EVM, Civic + Decentral Games hicieron SBT KYC on-chain en Polygon en marzo 2026 (caso adyacente directo a bjungle).
4. Subestimar talent pool: Solidity en LATAM tiene miles de devs; PyTeal/TEAL tiene docenas. AlgoKit 4.0 (H1 2026) mejora con TypeScript y Python 5.0, reduciendo el gap, pero no lo cierra para hiring a 5 años.
5. Sobreestimar finality como must-have: para batches cada 4h, los ~30 min de hard finality de Polygon PoS (vía checkpoint a Ethereum L1) son perfectamente aceptables. La “finality sub-5s” de Algorand es nice-to-have, no requisito.

Matriz comparativa (criterios ponderables por el usuario)

Dimensión	Polygon PoS (2026)	Algorand (2026)	Comentario honesto
Costo tx (publish merkle root)	USD 0.003-0.005	USD 0.0002-0.0005	Algorand ~10-20× más barato. Ambos triviales en absoluto. Diferencia no es decision driver.
Costo mensual Fase 1 (6 batches/día)	~USD 0.5-0.9	~USD 0.02-0.10	Delta ~USD 0.5/mes. < 1% del TCO mensual del módulo blockchain (USD ~70-100/mes con custodia + RPC + ops). Ruido.
Finality	Probabilística → hard finality ~30min vía checkpoint a Ethereum L1	Determinística ~3s	Algorand gana técnicamente. Para batches cada 4h, ambas son aceptables. No es show-stopper.
Data en tx sin smart contract	data field hasta ~128KB, costoso por byte	Note field 1KB nativo, barato	Algorand ergonómicamente mejor para Fase 1. Para Fase 1 ambas alcanzan con margen.
Talent pool LATAM (Solidity / Algorand)	Solidity: miles de devs (Colombia, Argentina, Brasil, México). Ecosystem maduro Web3 con presencia en universidades, bootcamps, hackathons.	PyTeal/TEAL: docenas de devs en LATAM. AlgoKit 4.0 (H1 2026) suma TypeScript + Python 5.0 — reduce el gap pero no lo cierra. Vitalpass entrenó equipo COL en su momento.	Polygon gana de forma estructural a 5 años. Para Fase 1 con 1 dev no es bloqueante; para mantener un sistema con 3-5 personas y rotación, es ventaja material.
Roadmap chain (5 años)	Polygon zkEVM sunset 2026 (Polygon Labs deprecó la beta). Foco corporativo en Polygon PoS + AggLayer + Polygon CDK. Polygon PoS entra “Gigagas” roadmap (target 100k TPS). PoS es el chain de largo plazo.	Algorand Foundation roadmap 2026 publicado: AlgoKit 4.0, Rocca Wallet, Project King Safety (calibrar incentivos económicos), expansión US, AVM 10 con ZK opcodes. Roadmap creíble. Treasury onchain transparente.	Empate funcional con matices: Polygon tuvo poda dolorosa (zkEVM sunset) — señal mixta (foco vs. lock-in roto). Algorand evoluciona dentro de su stack. Ambas tienen runway 5+ años.
Ecosystem para Fase 2/3 (SBT, AA, DID on-chain)	Asimétricamente fuerte: EIP-5114 / EIP-5484 / EIP-4973 SBT estándares maduros con implementaciones en producción. ERC-4337 account abstraction con ~USD 180M gas sponsored acumulados (Q1 2026), 78% de UserOps procesados por 3 bundlers (Pimlico, Stackup, Coinbase). EIP-7212 P-256 precompile LIVE en Polygon — passkeys (WebAuthn) firman tx on-chain nativamente. Civic + Decentral Games hicieron SBT KYC on-chain en Polygon (marzo 2026) — caso adyacente directo a bjungle. Polygon ID, ONCHAINID estandarizando identidad EVM. EBSI (UE) usa did:ebsi sobre EVM.	ASA (Algorand Standard Asset) nativo con freeze/clawback/whitelist built-in — atractivo para SARLAFT. AVM 10 soporta ZK opcodes. Pero ecosystem SBT/AA/DID on-chain en Algorand es mucho más pequeño. Rocca Wallet (Web2-style self-custody) en 2026, pero adopción wallet end-user mainstream sigue siendo MetaMask (no Pera/Defly).	Polygon gana de forma asimétrica para Escenario B. Para Escenario A es indiferente. Si en 2-3 años bjungle quiere ofrecer SBT a Web3 RPs, o account abstraction con passkey (alineado al Modelo C híbrido del wallet bjungle), o integrar con Polygon ID / ONCHAINID, el ecosystem EVM ya está construido. En Algorand habría que construirlo o portarlo.
Passkey + Account Abstraction (alineación con Modelo C híbrido bjungle)	EIP-7212 (P-256 precompile) en producción en Polygon. ERC-4337 + WebAuthn passkey = la wallet bjungle (Modelo C: Secure Enclave + E2EE backup) puede convertirse en smart account on-chain con la misma passkey que usa para login. Ruta natural.	Posible vía smart contract custom (TEAL) reimplementando P-256 verification (sin precompile). Ed25519 nativo de Algorand no encaja con WebAuthn (que usa P-256 ECDSA por defecto en passkeys). Gap técnico real.	Polygon gana de forma asimétrica si bjungle quiere converger wallet + smart account. Indiferente si jamás se considera.
Riesgo regulatorio del token nativo	MATIC/POL: digital asset, sin clasificación SEC definitiva (similar a otros L1/L2).	ALGO clasificado como digital commodity por SEC+CFTC (Mar-Apr 2026).	Algorand ligeramente mejor desde perspectiva institucional/abogadil, pero bjungle no compra ALGO ni MATIC para holdear — solo gas operacional. Riesgo regulatorio del token nativo no aplica a nosotros en este uso.
Compliance built-in para tokenización (Fase 2 hipotética Açaí)	ERC-20 + hooks (ERC-1404, ERC-3643) — código custom, audit USD 15-30k.	ASA con freeze/clawback/whitelist nativos — sin smart contract custom, audit USD 5-10k.	Algorand gana técnicamente para tokenización con SARLAFT obligations. Pero el ADR original dice NO tokenizar. Si jamás se tokeniza, este criterio no aplica.
DeFi composability (si Fase 2 token Açaí emerge)	Liquidez DeFi mainstream EVM. DEXs, lending, AMMs maduros.	DeFi Algorand << EVM en TVL y profundidad.	Polygon gana si emerge un caso DeFi. Pero el ADR original dice NO tokenizar.
Migration path / exit si la chain se discontinúa	EVM es el estándar de facto — cualquier L2 EVM (Base, Arbitrum, Optimism, zkSync, Polygon CDK chains) reescribe RPC endpoint, mismo Solidity, mismo tooling. Costo migración: bajo.	Migrar Algorand → otra chain Algorand-like: no existe (es un ecosystem propio). Migrar Algorand → EVM: reescribir TEAL → Solidity, reescribir cliente. Costo migración: alto.	Polygon gana de forma asimétrica para optionality. Si en 5 años Polygon PoS no es lo correcto, hay 10+ EVM chains como destino.
RPC managed / observabilidad	Alchemy/Infura/QuickNode — free tier disponible; growth USD 49+/mes. Polygonscan + The Graph para indexing.	Nodely free tier 6M req/mes (sobra). algorand-indexer oficial con Postgres backend — encaja con stack bjungle.	Empate funcional para Fase 1. Algorand indexer Postgres es ligera ventaja ergonómica para bjungle (todo el dominio vive en Postgres). No es decision driver.
Carbon footprint	PoS, baja huella.	Carbon-negative (offset Climate Trust).	Algorand marketing-friendlier. Marginal.
Toolchain Go (cliente para go-bmonkey-worker)	go-ethereum battle-tested.	go-algorand-sdk oficial mantenido.	Empate. Ambos buenos.
Adopción wallet Web3 mainstream end-user	MetaMask (universal), Rabby, Coinbase Wallet.	Pera Wallet, Defly. Rocca Wallet (2026) apunta a mainstream.	Polygon gana si Fase 2/3 expone wallet bjungle al ecosystem Web3. Indiferente para Fase 1 (anchoring no requiere wallet end-user).
Experiencia previa del usuario (founder)	Sin experiencia previa documentada. Ramp-up ~2 semanas.	Sí, declarada. Ramp-up ~1-1.5 semanas.	Factor real para Fase 1 piloto con 1 dev. Diluye a 5 años cuando el equipo crece a 3-5 personas. Peso decisional: 5-10%, no 25-50%.
Riesgo regulatorio LATAM (anchoring de hashes)	Anchoring de hashes ≠ activo virtual. SARLAFT/SuperFinanciera no aplica al hash on-chain.	Idéntico.	Empate completo. No hay diferencia regulatoria entre chains para nuestro caso.

Dos escenarios bien diferenciados (la decisión depende de esto)

El error del v1 fue asumir un único escenario. La decisión correcta depende de qué quiere ser bjungle a 3-5 años respecto al ecosystem Web3.

Escenario A · “Blockchain como herramienta interna”

bjungle nunca se expone al ecosystem Web3 directo. El chain se usa exclusivamente para:

• Publicar merkle roots de VCs emitidos (notarización).
• Publicar status lists 2021 (revocation registry público).
• Que un tercero pueda verificar “este VC existía” sin confiar en bjungle.

Lo que esto implica:

• No SBT.
• No account abstraction con passkey.
• No Polygon ID / ONCHAINID / EBSI integration.
• Açaí jamás se tokeniza (ledger Postgres for life).
• Wallet bjungle (Modelo C híbrido) jamás se convierte en smart account on-chain.
• RPs siempre consumen bjungle vía OIDC/API. Nunca via Web3 wallet.

Recomendación honesta para Escenario A: Algorand.

Razones:

1. Costo y simplicidad ligeramente mejores (note field 1KB nativo, sin necesidad de smart contract).
2. Indexer Postgres alineado al stack bjungle.
3. Finality determinística simplifica código del worker (un mitigation menos).
4. Experiencia previa del usuario reduce ramp-up.
5. Los downsides estructurales de Algorand (talent pool, ecosystem SBT/AA/DID) no aplican en este escenario porque nunca se va a usar nada de eso.

El delta vs Polygon en este escenario es real pero pequeño (~10-15% dev time, threat model marginalmente mejor). Ninguna decisión irreversible.

Escenario B · “Blockchain como surface area al ecosystem Web3”

bjungle a 2-3 años quiere (o podría querer) cualquiera de:

• SBT para que Web3 RPs consuman KYC de bjungle sin que bjungle sea el custodio (EIP-5114 / EIP-5484 / EIP-4973). Caso adyacente real: Civic + Decentral Games en marzo 2026 sobre Polygon.
• Account abstraction con passkey (ERC-4337 + EIP-7212) para que la wallet bjungle (Modelo C híbrido) sea también una smart account on-chain con la misma passkey que ya usa para login. Convergencia natural Modelo C + Web3.
• Polygon ID / ONCHAINID / EBSI: convergencia industria DID on-chain en EVM.
• DeFi composability si en algún momento Açaí pasa a tokenizarse y el caso de uso requiere mercado secundario (DEXs, lending).
• Web3 RPs estándar: MetaMask + WalletConnect, no Pera Wallet.

Recomendación honesta para Escenario B: Polygon PoS.

Razones (asimétricas, no marginales):

1. EIP-7212 P-256 precompile en producción en Polygon hoy — la ruta passkey → smart account ya existe. En Algorand habría que reimplementar verificación P-256 en TEAL.
2. Ecosystem SBT maduro en EVM — bjungle no inventa nada, consume estándares.
3. ERC-4337 con USD 180M+ gas sponsored acumulados (Q1 2026), bundler ecosystem productivo — infraestructura lista.
4. Talent pool a 5 años: Solidity LATAM = miles. PyTeal LATAM = docenas. El sistema lo mantiene un equipo, no el founder.
5. Migration optionality: si Polygon PoS no es lo correcto en 5 años, hay 10+ chains EVM como destino con el mismo código. Algorand → EVM es reescritura completa.
6. Polygon ID, ONCHAINID, EBSI: la industria de identidad on-chain converge en EVM.

El delta de USD ~0.5/mes en gas y los 3-5 días adicionales de ramp-up del founder no compensan romper la asimetría del ecosystem en Escenario B.

Veredicto honesto

Los dos escenarios apuntan a chains distintas. Esa es la verdad.

• Escenario A → Algorand (ventajas marginales pero reales).
• Escenario B → Polygon PoS (ventajas asimétricas, materiales).

No es honesto decir “ambas funcionan, elegí la que prefieras”. Tampoco es honesto decir “una gana absoluto”. La decisión depende del scope que bjungle decida tener a 3-5 años.

Si el usuario está indeciso entre escenarios, la regla de oro es: ¿cuál chain te deja más optionality si cambiás de opinión?

• Empezar en Algorand y migrar a Polygon → reescritura completa cliente + worker + custodia.
• Empezar en Polygon PoS y migrar a otra EVM (Base, Arbitrum, Polygon CDK chain) → reescribir RPC config, mismo Solidity, mismo tooling. Días, no semanas.
• Empezar en Polygon PoS y migrar a Algorand → posible pero asimétrico (perder ecosystem EVM que pesa más cada año).

Si el usuario es genuinamente indiferente entre A y B, la respuesta default conservadora es Polygon PoS — porque preserva la optionality de Escenario B sin sacrificar nada material en Escenario A (delta de USD <1/mes, dev time +3-5 días). El costo de “estar en EVM y no usar el ecosystem” es bajo. El costo de “estar en Algorand y necesitar EVM en 2 años” es alto.

Pero esto solo aplica si el usuario es genuinamente indiferente. Si Escenario A es la intención explícita, Algorand sigue siendo la mejor respuesta para Escenario A.

Pregunta única al usuario (decision gate)

¿Cuál escenario representa tu intención a 3-5 años para bjungle?

A) Blockchain solo como herramienta interna. Nunca SBT, nunca AA on-chain con passkey, nunca tokenización Açaí, nunca Web3 RPs. El chain solo anchora hashes; el producto vive 100% en el mundo OIDC/API tradicional.

B) Blockchain como posible surface area al ecosystem Web3. En 2-3 años podríamos querer SBT para Web3 RPs, account abstraction con passkey (alineado al Modelo C híbrido), integración con Polygon ID / ONCHAINID, o tokenización Açaí si SARLAFT lo permite.

C) No lo sé todavía; quiero preservar optionality.

Tu respuesta	Chain recomendada	Razón principal
A	Algorand	Note field 1KB + indexer Postgres + finality determinística + ramp-up menor. Ventajas marginales pero reales en un escenario donde los downsides de Algorand (ecosystem SBT/AA/DID) no aplican.
B	Polygon PoS	EIP-7212 P-256 precompile + ERC-4337 + EIP-5114 SBT + Polygon ID convergence + talent pool a 5 años + migration optionality EVM. Asimetría material que ~USD 10/mes y 3-5 días de ramp-up no compensan.
C	Polygon PoS (default conservador por optionality)	El costo de “estar en EVM y no usar el ecosystem” es bajo. El costo de “estar en Algorand y necesitar EVM” es alto. Polygon PoS preserva A y B; Algorand cierra B.

Hasta que el usuario responda, esta sección no tiene veredicto cerrado. El agente NO decide por el usuario. La recomendación de §Roadmap original “Polygon PoS” queda pendiente de confirmación; si el usuario responde A, se actualiza a Algorand. Si responde B o C, queda Polygon PoS.

Lo que NO cambia, responda lo que responda el usuario

Para evitar que esta decisión bloquee el resto del ADR:

• §1.a (anchoring SÍ): vigente, independiente de chain.
• §2.a (NO tokenizar Açaí ahora): vigente, independiente de chain.
• §3.a (NO emitir SBT ahora, deferred sin trigger): vigente, independiente de chain. Si en el futuro se activa SBT, Polygon es estructuralmente más sencillo, pero ese es un sub-ADR cuando emerja.
• §4.a (NO emitir stablecoin): vigente.
• §5.a (NO migrar did:web → did:ion ahora): vigente.
• Custodia del signing key: independiente de chain. Opciones (KMS AWS, Fireblocks, self-hosted) aplican a ambas. Decisión técnica de Fase 1 implementation, no de este addendum.
• Cost model ±USD 10/mes: irrelevante en ambos casos. TCO Fase 1 sigue siendo USD ~70-100/mes.
• Threat model: la diferencia “finality determinística vs ~30min hard finality” es marginal para batches cada 4h. Ambas chains satisfacen el threat model documentado.

Lo que el agente acepta haber hecho mal en v1

(Esto queda documentado deliberadamente para que el próximo agente / lector vea el patrón de sesgo y lo evite.)

1. Confirmation bias: al recibir un dato nuevo del usuario (“tengo experiencia previa con Algorand”), reordené la matriz para confirmar esa preferencia en lugar de re-evaluar honestamente. La experiencia previa del usuario es un dato relevante, no la answer.
2. Anchoring on small numbers: USD ~10/mes de delta lo presenté como “ventaja Algorand”. En un TCO mensual de USD ~70-100/mes y un sistema que va a vivir 5+ años, ese delta es ruido. Lo correcto es decir “indiferente en costo”.
3. Ignorar el ecosystem EVM: ni mencioné EIP-7212, ni ERC-4337, ni EIP-5114, ni Polygon ID, ni el caso Civic + Decentral Games (marzo 2026 — mes pasado). Eso es un agujero serio para un blockchain-architect agent.
4. Asumir un único escenario: presenté el caso como si bjungle ya hubiera decidido “Escenario A” cuando esa decisión nunca se tomó. El sesgo se filtró al asumir scope.
5. Hedging falso de neutralidad: dije “¿Y si fuera ‘indiferente’? Sería válido decirlo si el delta fuera cero. No es cero” — usando un delta cosmético para justificar una recomendación pre-cocinada.

Esto no anula los datos técnicos del v1 sobre Algorand (note field, indexer Postgres, ALGO commodity SEC, Vitalpass Colombia, Nubank, etc.). Esos datos siguen siendo correctos. Lo que estaba mal era el peso decisional asignado y la asunción de escenario único.

Referencias del addendum (data 2026)

Polygon ecosystem (relevante para Escenario B)

• Polygon zkEVM sunset 2026 + foco en PoS + AggLayer: Polygon Community Forum — Sunsetting zkEVM 2026 · Coinfomania — Nailwal CEO, deprecates zkEVM, refocuses on PoS + AggLayer + 100k TPS
• Polygon PoS fees 2026: PolygonScan avg gas + Polygon — predictable fees blog
• ERC-4337 account abstraction + USD 180M gas sponsored Q1 2026: Eco — Account Abstraction 2026 Guide · Hacken — ERC-4337 overview
• EIP-7212 P-256 precompile LIVE en Polygon: Corbado — Smart Wallets and Passkeys
• EIP-7702 (Pectra upgrade May 2025) — EOA con smart account features: Turnkey — From ERC-4337 to EIP-7702
• SBT estándares EIP-5114 / EIP-5484 / EIP-4973: ERC-5114 spec · Cyfrin — SBT EIP-5114 & EIP-5484
• Civic + Decentral Games — SBT KYC on-chain en Polygon (marzo 2026), caso adyacente directo a bjungle: CoinGecko — Soulbound Tokens overview

Algorand ecosystem (relevante para Escenario A)

• Algorand fees y note field: Algorand Developer Portal — Transaction Fees
• Algorand 2026 roadmap (AlgoKit 4.0 con TypeScript + Python 5.0, Rocca Wallet, AVM 10, Project King Safety): Gate News — Algorand 2026 Roadmap · Algorand.co — 2025 Roadmap Progress
• ALGO clasificado commodity SEC+CFTC 2026: Blockonomi — Algorand 2026 Milestones
• Vitalpass Colombia (precedente gobierno COL): PRNewswire — Vitalpass Colombia
• ASA vs ERC-20: Algorand — Ethereum to Algorand · AICerts — ASA vs ERC-20
• Nodely managed RPC pricing: Nodely Pricing

Identidad on-chain en EVM (relevante para Escenario B)

• Polygon ID, ONCHAINID, EBSI estandarizando DID/VC sobre EVM (lectura general de tracción ecosystem; cada uno con sus docs):
  • Polygon ID: polygon.technology/polygon-id
  • ONCHAINID: onchainid.com
  • EBSI (European Blockchain Services Infrastructure): ec.europa.eu — EBSI

---

Fase 1 entregada (2026-05-30)

Implementación cerrada del scope efectivo de Fase 1 extendida (9 sub-PRs BCS-01..08 + BCS-15 + BCS-QA + BCS-W5).

Componentes implementados

• ChainClient + KMS signer (BCS-01): wrapper de ethclient v1.13+ con firma AWS KMS ECC_SECG_P256K1, malleability fix EIP-2, V recovery con address match.
• MerkleBatcher dual root (BCS-02): VC root + Açaí root, keccak256 sorted-sibling, padding determinista (duplica último), property-based tests con rapid.
• Migrations (BCS-03 0025 + BCS-15 0027 + BCS-W5 0028): vc_anchor_batches, vc_anchor_leaves, bmonkey.vc_anchor_canonical_vc_jwt, bmonkey.vc_anchor_canonical_acai_entry, RLS deny-all + 13+ funciones SECURITY DEFINER.
• Anchor worker cron (BCS-04): cada 4h scan candidates → MerkleBatcher → submit → poll confirmation → audit. Feature flag BMONKEY_BLOCKCHAIN_ENABLED. Prometheus metrics bjungle_bmonkey_anchor_*.
• W3C Status List 2021 (BCS-05): bitstring 131072 bits, endpoint público /v1/wallet/status-list/{list_id} firmado JWT-VC RS256 (post BCS-W5 fix), gzip + base64url, 10 funciones SECURITY DEFINER.
• Archive IPFS Pinata (BCS-06): client + concurrent upload (errgroup). Arweave deferred (protocolo directo complejo, sin SDK Go oficial).
• Frontend wallet PWA + tenant-portal dashboard (BCS-07): AnchorBadge con 6 estados + modal proof, dashboard /compliance/anchors con 3 tabs (Resumen, Batches, Cómo verificar), snippet sorted-sibling correcto.
• Açaí ledger anchoring (BCS-15): segundo árbol del merkle, endpoints proof autenticado + público con cross-wallet protection.
• Tests (BCS-QA): 15 specs E2E (19+20) + 7 integration con testcontainers + smoke script.
• Security fixes (BCS-W5): keccak256 Go-side en worker, sorted-sibling snippet, rate limit endpoints públicos, StatusListCredential firmado.

Findings security cerrados

Severidad	ID	Estado
CRITICAL	DJ-PT-BCS-09/NEW-01 (hash mismatch SHA-256 vs keccak256)	CERRADO en BCS-W5
CRITICAL	DJ-PT-BCS-08 (snippet JS directional)	CERRADO en BCS-W5
HIGH	DJ-PT-BCS-10 (rate limit endpoints públicos)	CERRADO en BCS-W5
HIGH	DJ-PT-BCS-11 (StatusListCredential sin firma)	CERRADO en BCS-W5

Findings deferred a Fase 2 / Wave 6+

• DJ-PT-BCS-14 (Multi-RPC para VerifyAnchor): para mainnet
• DJ-PT-BCS-18 (EIP-1559 fee bumping): para mainnet
• DJ-PT-BCS-19 (Censorship detection): para mainnet
• NEW-02 (Distributed lock para worker en k8s multi-pod): para producción
• DJ-PT-BCS-16 (UNIQUE constraint en vc_anchor_leaves): defense-in-depth
• DJ-PT-BCS-22 (ETag/Last-Modified en status-list): refinamiento

Próximo paso operacional

1. Provisionar AWS KMS key alias/bjungle-bmonkey-anchor (ECC_SECG_P256K1, usage SIGN_VERIFY) en cuenta dev.
2. Registrar Alchemy API key para Polygon Amoy (free tier).
3. Setear env vars en docker-compose.yml para profile dev/staging:
   • BMONKEY_BLOCKCHAIN_ENABLED=true
   • BMONKEY_BLOCKCHAIN_CHAIN_ID=80002
   • BMONKEY_BLOCKCHAIN_RPC_URL=https://polygon-amoy.g.alchemy.com/v2/{KEY}
   • BMONKEY_BLOCKCHAIN_KMS_KEY_ALIAS=alias/bjungle-bmonkey-anchor
   • BMONKEY_ARCHIVE_ENABLED=false (deferred Arweave)
4. Smoke test contra Amoy con scripts/smoke-blockchain-anchoring.sh.
5. Si smoke pasa: re-evaluar a producción mainnet con findings deferred cerrados.