Skip to content

Gestión de Crowdfunding

Requisitos Previos de Acceso

  • Permiso (módulo): viewCrowdfunding para listar/ver; manageCrowdfunding para crear, editar, generar tokens, cronograma de pagos y permisos.
  • Licencia/Función: CROWDFUNDING habilitada en la licencia del tenant (Vault).
  • Contenedor del menú: GENERAL → grupo Productos

Qué es / Cuándo usar

Crowdfunding es la oferta maestra de la plataforma: una campaña colectiva de recaudación de fondos donde los inversores aportan recursos y, al cierre, reciben tokens (NFT o token fungible 1:1) que representan su participación. El operador utiliza esta área para registrar la oferta, definir cómo será tokenizada, generar tokens para los inversores que pagaron, agendar pagos previstos (cronograma de pagos) y hacer un seguimiento de la oferta de punta a punta (vista 360).

La oferta de crowdfunding es el punto de partida de las Cestas y la elección del estándar de contrato (ERC‑721 vs ERC‑3643), decidida por colección al cierre de la recaudación.

Requisitos Previos

  • Permiso: viewCrowdfunding (lectura) o manageCrowdfunding (escritura) registrados para el rol del operador. Recuerde: el permiso es dual — enum CPM en backend + módulo dinámico en DB. Si falta el módulo dinámico, el elemento no aparece en el menú; si falta el enum CPM, la API rechaza la acción.
  • Licencia/Función: CROWDFUNDING habilitada. Si está deshabilitada, el elemento no aparece en el menú.
  • Dependencias: para generar tokens debe haber definido el modelo de tokenización y la red (pestaña Tokenización). Para que el cronograma de pagos se materialice, la oferta debe tener ya el assetId (token/NFT generado).

Paso a paso (listado)

  1. Acceda al menú Productos → Crowdfunding.
  2. Utilice la búsqueda por nombre y los filtros Tiene captura de billetera (hasWalletCapturing) y Requiere desbloqueo de billetera (walletUnlockRequired) para refinar; la ordenación alterna ASC/DESC. El listado está paginado en el servidor (límite/offset).
  3. En cada fila, utilice los iconos de acción: Ver, Editar, Clonar, Permisos del captador, Generar tokens (NFTs), Cronograma de pagos y Vista 360.
  4. Para crear una nueva oferta, utilice Crear crowdfunding.

Crear / Editar oferta

El formulario (/crowdfunding/create, /crowdfunding/edit/:id) está organizado en 4 grupos y 16 secciones. En modo crear, solo el grupo Campaña está disponible; los grupos Empresa, Análisis y Operacional solo se abren después de que la oferta existe (modo editar) o en modo copia. Esto es intencional: crear la campaña primero, luego enriquecerla con datos regulatorios.

Grupos y secciones:

  • Campaña: General, Tokenización, Foto/Video, Beneficios, Escenarios, Documentos.
  • Empresa: Datos de la empresa, Ejecutivos, Controladores, Abogados, Valoración.
  • Análisis: Riesgos, Matriz de destinación de fondos, Comunicación, Derechos.
  • Operacional: Banco.

Campos de la sección General

CampoQué es¿Obligatorio?Efecto en el sistema/backend
NombreNombre público de la ofertaGuarda name; se utiliza como base para el símbolo del token predeterminado. Iniciales duplicadas generan error tokens_all_pkey (símbolo ya existe).
CategoríaCategoría de crowdfunding (judicial, arte, negocios, inmuebles…)NoVincula la oferta a una CrowdfundingCategories (ver Categorías de Crowdfunding).
Fecha de inicio / Fecha de finVentana de recaudaciónSe guardan como startDate/finalDate (dd/MM/yyyy). Validación: fecha de fin ≥ fecha de inicio.
Captura objetivo (targetCapture)Meta de recaudaciónBigNumber — convertido vía ValueConverterService, sin redondeo.
Captura mínima (minimumCapture)Valor mínimo para que la oferta tenga éxitoBigNumber.
Aporte mínimo (minimumContribution)Aporte más pequeño por inversorBigNumber.
Dinero recibido (moneyReceived)Cuánto se ha captado hasta ahoraNoBigNumber; normalmente actualizado por el sistema conforme ocurren las compras de cuota.
Rentabilidad / PeríodoRentabilidad esperada y frecuencia (anual, mensual, personalizada)Noprofitability + profitabilityPeriodType.
RiesgoNivel de riesgo (mínimo, medio, alto)NotypeOfRisk.
Contrato (subida)Documento contractual de la ofertaNoSubida vía files API (máx. 10 MB; tipos restringidos). Guarda la URL en contract.
Captura de billetera (walletCapturing)Email de un usuario cuya billetera recibe la capturaNoValide antes de guardar con el botón de validación: backend verifica si el usuario existe, está APPROVED y tiene billetera configurada. Las razones de inelegibilidad se muestran (usuario no encontrado, bloqueado/rechazado, no aprobado, sin billetera).

Validación de captura de billetera

La validación de walletCapturing requiere usuario-destino APPROVED con billetera activa. No guarde la oferta con un destinatario inelegible — la captura carecería de destino válido.

Campos de la sección Tokenización

Define cómo los aportes se convierten en tokens. Elija el modelo y el comportamiento (vía presets o modo Personalizado, que expone las banderas del Token/FMS).

CampoQué es¿Obligatorio?Efecto en el sistema/backend
Modelo (tokenization_type)NFT (1 token = 1 cuota indivisible) o FUNGIBLE (token fungible de asignación 1:1 con la moneda)Por defecto NFT. Decide si la generación crea activos NFT o un token fungible en FMS.
Regulada (regulated)Marca la oferta como ERC‑3643NoResuelve el contract_standard de la colección al cierre (token de seguridad con identidad on-chain).
PresetModelo de comportamiento listo: Certificado, Negociable o PersonalizadoNo"Certificado" = NFT regulado, no transferible/negociable, con dividendos. "Negociable" = fungible regulado, transferible y tradeable, con dividendos. "Personalizado" expone las banderas abajo.
Transferible (transferable)Permite transferencia P2P entre tenedoresNoBandera en token_config.
Comprable (buyable)Permite compra directaNoBandera en token_config.
Negociable (tradeable)Habilita la negociación en book/parNoBandera en token_config.
Dividendos (dividends)El token recibe distribucionesNoBandera en token_config; requisito previo para que el cronograma de pagos tenga sentido.
Solo entero (onlyInteger)Impide fracciones de tokenNoPor defecto true.
Red / Institución / Categoría NFT / SímboloParámetros de emisión fijados en la ofertaNonetwork_id, institution_name, nft_category_id, token_symbol. El símbolo predeterminado se deriva de las iniciales del nombre + número final; puede ser sobrescrito. Estos valores son consumidos por la generación de tokens — no se piden red/institución de nuevo en el momento de generar.
Escrow XRPL (use_xrpl_escrow)Usa escrow en XRPLNoxrpl_network/xrpl_issuer_address/xrpl_currency. El emisor es de solo lectura con enlace al explorador público.

Campos relevantes de otras secciones

CampoSecciónEfecto en el sistema/backend
BeneficiosBeneficiosLista {nombre, descripción}; obligatorio tener al menos uno para guardar.
Escenarios (optimista/base/pesimista)EscenariosCada escenario requiere deadline, maximumExposure (BigNumber), multiple, profitabilityCDI, profitabilityTIR. Los 3 son obligatorios para guardar.
Capital social / Patrimonio / ResultadoDatos de la empresaCampos monetarios normalizados vía BigNumber antes de persistir.
BancoOperacionalCuenta bancaria de la oferta (ICrowfundingBankingAccount); copiada en la clonación.

Cuenta bancaria y formas de pago

Esta es la sección Banco del formulario y define cómo el inversor paga la oferta. Existe por exigencia regulatoria: la CVM obliga a disponibilizar pago manual por cuenta bancaria en ofertas de crowdfunding.

La sección tiene tres bloques:

1. Cuenta bancaria (en la parte superior) — la cuenta registrada para el pago manual del inversor (TED/PIX). Es obligatoria por la CVM. Registre vía Agregar cuenta (banco, tipo, agencia, cuenta y clave PIX). Los datos de TED y PIX mostrados al inversor provienen de esta cuenta.

2. Métodos de pago (interruptores) — controlan qué aparece para el inversor en la tienda:

InterruptorCampoQué hace
Habilitar TEDtedMuestra los datos de TED (de la cuenta registrada arriba) para pago manual vía TED.
Habilitar PIXpixMuestra los datos de PIX (de la cuenta registrada arriba) para pago manual vía PIX.
Habilitar CriptocryptoPermite pago de la oferta vía cripto.
Captura en USDisDolarCaptura la oferta en dólar. ⚠️ No habilitar — comportamiento no soportado en operación normal.

3. Integraciones (interruptores) — habilitan conciliación semi-automatizada del depósito conforme la institución de la cuenta:

InterruptorCampoQué hace
Habilitar Transferotransfero_integrationSolo válido cuando la cuenta de depósito es de Transfero (Genial). Fuerza al sistema a buscar el extracto de ellos para conciliar depósitos de forma semi-automática. Puede remover si la cuenta no es Transfero.
Habilitar PIX QRcodedillianz_integrationHabilita el Código QR dinámico de PIX, que permite liquidación automática del pago. (Aparecía como "Habilitar Dillianz" en versiones anteriores — Dillianz era el proveedor del Código QR automático; la etiqueta fue renombrada a "Habilitar PIX QRcode" en este rediseño.)
Habilitar Banco do Brasilbank_of_brazil_integrationCuando la cuenta es del Banco do Brasil, el sistema busca el extracto en BB para conciliación semi-automática.

Recomendaciones por tipo de oferta

  • Ofertas privadas: Habilite PIX, Cripto y PIX QRcode.
  • Ofertas públicas: Habilite TED, PIX, Cripto y PIX QRcode.

Pago manual y conciliación

Si el inversor elige depósito manual (TED/PIX sin Código QR dinámico), la conciliación puede ser manual — por eso la plataforma muestra el mensaje de que el pago puede tardar hasta 2 días en confirmarse. Este mensaje es norma de la CVM y debe estar disponible en la plataforma para fines de auditoría. El PIX QRcode (QR dinámico) es lo que permite la liquidación automática, sin esa ventana.

Configuraciones de la oferta (interruptores en la sección General)

Al final de la sección General hay una tarjeta Configuraciones con seis interruptores que gobiernan tanto la vitrina (lo que el inversor ve en la página pública) como el comportamiento operacional de la oferta (automaciones de fechas, mint, valor de cuota y custodia on-ledger). Ninguno de estos interruptores es meramente cosmético — los de automación disparan trabajos reales en backend.

EtiquetaCampo (ngModel)Qué hace (efecto backend)Cuándo usar
Habilitar FAQshow_faqMostración en vitrina. Muestra la pestaña/sección FAQ en la página pública de la oferta. No cambia ninguna regla de recaudación.Cuando la oferta tiene preguntas frecuentes registradas y desea exponerlas al inversor.
Habilitar Descargoshow_disclaimerMostración en vitrina. Muestra el aviso de descargo/riesgo en la página pública. No cambia ninguna regla de recaudación.Siempre que haya aviso de riesgo regulatorio a mostrar; recomendado para ofertas públicas.
Valor fijofixed_valueComportamiento de pago. Cuando se habilita, el inversor no elige el valor: el aporte se valida (BigNumber) para ser exactamente igual al Aporte mínimo (minimumContribution) — cualquier valor diferente es rechazado en categories.checkout.core.handler. Es una oferta de cuota de valor fijo (ticket único).Ofertas donde toda cuota tiene el mismo precio (ej.: 1 cuota = R$ 1.000, sin aporte libre).
Control automático de fechasautomatic_datesAutomación vía scheduler. Cuando se habilita, el job controlCrowdfunding inicia y cierra la oferta automáticamente por fechas: cuando CURRENT_DATE >= startDate y estado inactive, pasa a active (y provisiona el emisor XRPL si aplica); cuando CURRENT_DATE > finalDate y estado active, pasa a finished. Al cierre automático, si la tokenización está lista (tokenization_type + network_id, y aún no emitido), llama a generateNFTs automáticamente (mint idempotente — sin redeploy). Sin este interruptor, la transición de estado y el mint quedan manuales.Cuando desea que apertura/cierre y el mint de cierre ocurran automáticamente en las fechas configuradas, sin operador.
Generar NFT automáticamente al cierre de la ofertaautomatic_nftsSeñalización de intención. El campo es persistido (entidad/DTO/modelo), pero el auto-deploy de cierre hoy es gatillado por automatic_dates + tokenización lista en controlCrowdfunding, no por automatic_nfts. Es decir: para mint automático en cierre, lo que efectivamente habilita la automación es el Control automático de fechas. Trate este interruptor como declaración de la intención "quiero NFT automático" y combínelo con automatic_dates; solo no dispara el mint.Habilite junto con Control automático de fechas cuando la intención sea emitir los NFTs de los inversores así que la oferta cierre. No confíe en él aislado.
Usar XRPL Escrow (MPT)use_xrpl_escrowCustodia on-chain. Activa el escrow on-ledger en XRPL vía MPT (también gated por la bandera de función global XRPL_ESCROW — ambos deben habilitarse). Al activarse, abre la tarjeta XRPL Escrow para definir red (xrpl_network), moneda (xrpl_currency) y mostrar el emisor (xrpl_issuer_address, solo lectura con enlace al explorador). Efectos: cuando la oferta se pone activa, provisiona un emisor XRPL dedicado por oferta; un scheduler (cada 5 min) crea, para cada aporte pagado, un activo custodiado on-ledger hasta cierre; al final, libera al proyecto (éxito) o realiza reembolso automático al inversor; un job diario (03:00 UTC) quema los IOUs liberados de vuelta al emisor (idempotente).Ofertas que requieren custodia verificable on-chain de aportes (liberación al proyecto solo en éxito, reembolso garantizado en fracaso). Requiere la función XRPL_ESCROW habilitada en tenant.

Automación de fechas y mint de cierre

Lo que realmente habilita las transiciones automáticas de estado y el mint en cierre es el Control automático de fechas (automatic_dates) + tokenización lista. El interruptor Generar NFT automáticamente (automatic_nfts) se guarda, pero no es, solo, el gatillo del auto-deploy hoy. Para mint automático en cierre, habilite ambos y garantice modelo/red definidos en la pestaña Tokenización. El mint sigue la regla de mint exclusivo del job de crowdfunding (ver "Reglas de negocio").

Escrow XRPL está gated en dos niveles

use_xrpl_escrow solo tiene efecto si la bandera de función global XRPL_ESCROW también está habilitada en tenant. Con la bandera deshabilitada, los schedulers de escrow son no-op incluso con el interruptor marcado. El emisor es uno por oferta, creado cuando la oferta se pone activa.

Acciones y modales

  • Crear / Guardar: abre bottom-sheet de confirmación antes de persistir (mensaje reutilizado de manageTokens.crud.snackbar). El botón guardar está deshabilitado mientras falten campos obligatorios (nombre, fechas, beneficios y los 3 escenarios completos) — el tooltip lista lo que falta.
  • Clonar: navega a creación con ?copy=true. Limpia id/fechas y copia datos de la empresa y banco a la nueva oferta.
  • Generar tokens (NFTs): abre el modal CrowdfundingNFTsComponent. Ya no pide red/institución — usa lo que está en la pestaña Tokenización. Backend resuelve contract_standard, símbolo y categoría a partir de la oferta. Gate: modelo + red definidos.
  • Cronograma de pagos: abre el modal de cronograma (ver Cronograma de Pagos).
  • Permisos: navega a /crowdfunding-permissions/:id (ver Permisos del Captador).
  • Vista 360: abre la vista consolidada (/crowdfunding/view-360/:id).
  • Eliminar: remueve la oferta y recarga la página.

Vista 360

La vista 360 (/crowdfunding/view-360/:id) consolida todo en 5 pestañas: Órdenes completadas, Órdenes pendientes, NFTs/tokens generados, Tenedores (resumen por tenedor: cantidad + total pagado) y Distribuciones. Muestra cantidad de inversores, total completado y total pendiente. En modelo fungible, assetId apunta a un token del FMS (no a un activo NFT). Cada NFT individual tiene enlace a su pantalla de edición.

Reglas de negocio / precauciones

Atención

  • El grupo Campaña es el único disponible en la creación; enriquezca Empresa/Análisis/Operacional solo después de crear la oferta (modo editar/copia).
  • El símbolo del token debe ser único — colisión dispara error de clave (tokens_all_pkey).
  • La validación de walletCapturing es un requisito previo de calidad: el destinatario debe estar APPROVED con billetera.

Irreversible

  • Generación de tokens minta supply on-chain a partir de órdenes pagadas. No hay rollback simple; verifique modelo, red y símbolo antes de generar.
  • Mint exclusivo del job: activos/tokens originados en crowdfunding solo son acuñados/quemados por el job de crowdfunding. TKN_OWNER no emite ni hace "reventa" sobre esos activos, y la asignación manual de admin también respeta la regla. Esto garantiza por construcción el invariante valor captado == suma(NFTs × precio unitario). La transferencia secundaria P2P entre tenedores continúa permitida (la restricción es sobre crear/extinguir supply, no sobre custodia).
  • Valores financieros: todos los campos monetarios (captura, aporte, escenarios, capital) son BigNumber — sin redondeo; verifique decimales.

Ejemplos

Escenario 1 — Oferta con NFT‑certificado regulado (ERC‑3643)
  1. En General, rellene nombre, fechas, captura objetivo R$ 1.000.000, mínima R$ 300.000, aporte mínimo R$ 1.000, y valide el destinatario de captura de billetera (usuario APPROVED).
  2. En Tokenización, elija el preset Certificado → modelo NFT, regulado, dividendos habilitados, solo entero. Defina red y símbolo.
  3. Complete Beneficios y los 3 Escenarios; guarde.
  4. Después de recaudación, abra Generar tokens — el sistema acuña NFTs-certificado para quienes pagaron, con contract_standard ERC‑3643 resuelto por la bandera regulated.
Escenario 2 — Oferta con token fungible negociable (1:1 con la moneda)
  1. En Tokenización, preset Negociable → modelo FUNGIBLE, regulado, transferible y tradeable, dividendos habilitados.
  2. Cada R$ aportado se convierte en 1 unidad del token (asignación 1:1, transparente a la moneda).
  3. En Generar tokens, el assetId resultante apunta a un token del FMS. La vista 360 lista tenedores por saldo de token, no por NFT unitaria.
Escenario 3 — Importar una oferta existente (clonar)
  1. En el listado, use Clonar en una oferta de referencia.
  2. El formulario se abre en creación con ?copy=true: id, fechas y ventanas se borran; datos de la empresa y cuenta bancaria se copian.
  3. Ajuste nombre (símbolo derivado cambia) y fechas, y guarde como nueva oferta.

Pantallas relacionadas