Saltar a contenido

Encaje de Alfred para Landbridge

Summary

Alfred encaja bien como proveedor inicial de Landbridge para probar crypto-to-fiat settlement porque combina rampas, rails locales, KYC/KYB, quotes, webhooks y posible operación vía Fireblocks según fuentes internas. El encaje es fuerte para un MVP manual y para demostrar que un comprador cripto puede terminar en pago fiat; todavía es incierto para cierres inmobiliarios de alto importe en EE. UU. hasta validar licencias, límites, soporte de escrow/title, third-party payments y responsabilidad de KYC.

Thesis

Landbridge debería tratar a Alfred como proveedor de ejecución para un piloto rápido, no como sustituto completo del diseño regulatorio/compliance propio. Su API reduce build inicial y cubre piezas operativas críticas, pero el verdadero go/no-go depende de confirmar que Alfred puede liquidar a la contraparte inmobiliaria correcta, con evidencia suficiente para underwriters/title companies y sin trasladar a Landbridge obligaciones regulatorias no deseadas.

Supporting Evidence

  • Las transcripciones internas ya priorizaban Alfred frente a Pythas para rapidez porque estaría integrado con Fireblocks.
  • La documentación pública cubre el flujo necesario: customer, KYC/KYB, fiat accounts, quotes, onramp/offramp, liquidation addresses y webhooks.
  • Alfred soporta first-party y third-party payments, incluyendo “pay a vendor in fiat, even if original funds are in stablecoins”. Esto es conceptualmente cercano a pagar a una title company/escrow, aunque debe confirmarse para real estate.
  • Offramp documentado: USDC/USDT a fiat local con customer KYC aprobado, quote y fiatAccountId.
  • Webhooks permiten registrar evidencia de eventos operativos; FIAT_TRANSFER_COMPLETED y FAILED son clave para reconciliación.
  • KYC/KYB integrado puede acelerar el MVP, pero también puede entrar en tensión con la idea interna de que Landbridge haga/verifique compliance personalizado para underwriters.

Tensions

  • Fireblocks: aparece en fuentes internas, pero no en la documentación pública Alfred scrapeada.
  • KYC: la fuente interna sugiere que Alfred no exigiría KYC por cada cliente si Landbridge verifica; la FAQ pública dice que full KYC es requerido antes de depósitos/retiros.
  • Cobertura: Alfred es muy fuerte en LATAM, pero Landbridge necesita validar fit con cierres inmobiliarios, escrow/title y USD wires en el mercado objetivo.
  • Ticket size: docs muestran flows de pago pero no límites ni SLAs para operaciones inmobiliarias grandes.
  • Estado final: para onramp el éxito final es on-chain; para Landbridge el éxito crítico puede ser fiat settled a title/escrow. El flujo debe diseñarse probablemente como offramp.

Open Questions

  • ¿Puede Alfred pagar directamente a title company/escrow como beneficiary third-party y emitir comprobante aceptable?
  • ¿Qué KYC/KYB exacto exige Alfred a buyer, Landbridge, seller/title y beneficiarios?
  • ¿Qué límites, fees, spreads y tiempos aplica para USD, USDC/USDT y tickets inmobiliarios?
  • ¿Cómo se integraría Alfred con Fireblocks en el flujo real: API directa, Fireblocks console, whitelisted address, APM o non-custodial originAddress?
  • ¿Qué ocurre si el cierre falla después de que Alfred reciba o convierta fondos?
  • src-alfred-provider-docs-2026-05-11
  • src-transcripcion-2026-05-07-revision-aspectos-pythas
  • src-transcripcion-2026-05-08-recoleccion-requisitos-1
  • [[entity-alfred]]
  • [[concept-alfred-api-integration]]
  • [[concept-proveedor-de-liquidez]]
  • [[concept-webhook-y-estado-de-pagos-en-alfred]]
  • [[synthesis-tesis-inicial-de-landbridge]]