Crowdfunding Management
Access Prerequisites
- Permission (module):
viewCrowdfundingto list/view;manageCrowdfundingto create, edit, generate tokens, payment schedule and permissions. - License/Feature:
CROWDFUNDINGenabled in tenant license (Vault). - Menu container: GENERAL → Products group
What is it / When to use
Crowdfunding is the master offering on the platform: a collective fundraising campaign where investors contribute resources and, upon closure, receive tokens (NFT or 1:1 fungible token) representing their participation. The operator uses this area to register the offering, define how it will be tokenized, generate tokens for investors who paid, schedule payment disbursements (payment schedule) and track the offering end-to-end (360 view).
Crowdfunding offering is the starting point for Baskets and the choice of contract standard (ERC‑721 vs ERC‑3643), decided per collection at the close of fundraising.
Prerequisites
- Permission:
viewCrowdfunding(read) ormanageCrowdfunding(write) registered for the operator role. Remember: permission is twofold — CPM backend enum + dynamic module in DB. If the dynamic module is missing, the item does not appear in the menu; if the CPM enum is missing, the API refuses the action. - License/Feature:
CROWDFUNDINGenabled. If disabled, the item does not appear in the menu. - Dependencies: to generate tokens you must have defined the tokenization model and network (Tokenization tab). For payment schedule to materialize, the offering must already have
assetId(token/NFT generated).
Step-by-step (listing)
- Access the Products → Crowdfunding menu.
- Use the name search and Has wallet capturing (
hasWalletCapturing) and Requires wallet unlock (walletUnlockRequired) filters to refine; sorting alternates ASC/DESC. The listing is paginated server-side (limit/offset). - On each row, use the action icons: View, Edit, Clone, Fundraiser permissions, Generate tokens (NFTs), Payment schedule and 360 view.
- To create a new offering, use Create crowdfunding.
Create / Edit offering
The form (/crowdfunding/create, /crowdfunding/edit/:id) is organized in 4 groups and 16 sections. In create mode, only the Campaign group is available; the Company, Analysis and Operational groups only open after the offering exists (edit mode) or in copy mode. This is intentional: create the campaign first, then enrich it with regulatory data.
Groups and sections:
- Campaign: General, Tokenization, Photo/Video, Benefits, Scenarios, Documents.
- Company: Company data, Executives, Controllers, Lawyers, Valuation.
- Analysis: Risks, Fund allocation matrix, Communication, Rights.
- Operational: Bank.
Fields in the General section
| Field | What is it | Required? | Effect in system/backend |
|---|---|---|---|
| Name | Public name of the offering | Yes | Saves name; used as basis for default token symbol. Duplicate initials trigger tokens_all_pkey error (symbol already exists). |
| Category | Crowdfunding category (judicial, art, business, real estate…) | No | Links the offering to a CrowdfundingCategories (see Crowdfunding Categories). |
| Start date / End date | Fundraising window | Yes | Saved as startDate/finalDate (dd/MM/yyyy). Validation: end date ≥ start date. |
Target capture (targetCapture) | Fundraising goal | Yes | BigNumber — converted via ValueConverterService, no rounding. |
Minimum capture (minimumCapture) | Minimum value for the offering to succeed | Yes | BigNumber. |
Minimum contribution (minimumContribution) | Smallest contribution per investor | Yes | BigNumber. |
Money received (moneyReceived) | How much has been captured so far | No | BigNumber; typically updated by the system as quota purchases occur. |
| Profitability / Period | Expected profitability and frequency (annual, monthly, custom) | No | profitability + profitabilityPeriodType. |
| Risk | Risk level (minimum, medium, high) | No | typeOfRisk. |
| Contract (upload) | Offering contract document | No | Upload via files API (max 10 MB; restricted types). Saves URL to contract. |
Wallet capturing (walletCapturing) | Email of a user whose wallet receives the capture | No | Validate before saving with the validation button: backend checks if user exists, is APPROVED and has wallet configured. Ineligibility reasons are displayed (user not found, blocked/rejected, not approved, no wallet). |
Wallet capturing validation
Validation of walletCapturing requires target user APPROVED with active wallet. Do not save the offering with an ineligible recipient — the capture would lack a valid destination.
Fields in the Tokenization section
Defines how contributions become tokens. Choose the model and behavior (via presets or Custom mode, which exposes Token/FMS flags).
| Field | What is it | Required? | Effect in system/backend |
|---|---|---|---|
Model (tokenization_type) | NFT (1 token = 1 indivisible quota) or FUNGIBLE (fungible token 1:1 allocation with currency) | Yes | Default NFT. Decides whether generation creates NFT assets or a fungible token in FMS. |
Regulated (regulated) | Marks the offering as ERC‑3643 | No | Resolves contract_standard of the collection at fundraising close (security token with on-chain identity). |
| Preset | Ready behavior model: Certificate, Tradeable or Custom | No | "Certificate" = regulated NFT, non-transferable/non-tradeable, with dividends. "Tradeable" = regulated fungible, transferable and tradeable, with dividends. "Custom" exposes the flags below. |
Transferable (transferable) | Allows P2P transfer between holders | No | Flag in token_config. |
Buyable (buyable) | Allows direct purchase | No | Flag in token_config. |
Tradeable (tradeable) | Enables trading on book/pair | No | Flag in token_config. |
Dividends (dividends) | Token receives distributions | No | Flag in token_config; prerequisite for payment schedule to make sense. |
Integer only (onlyInteger) | Prevents token fractions | No | Default true. |
| Network / Institution / NFT Category / Symbol | Issuance parameters set on the offering | No | network_id, institution_name, nft_category_id, token_symbol. The default symbol is derived from name initials + ending number; can be overridden. These values are consumed by token generation — network/institution not requested again at generation time. |
XRPL Escrow (use_xrpl_escrow) | Uses escrow on XRPL | No | xrpl_network/xrpl_issuer_address/xrpl_currency. The issuer is read-only with link to public explorer. |
Relevant fields from other sections
| Field | Section | Effect in system/backend |
|---|---|---|
| Benefits | Benefits | List {name, description}; required to have at least one to save. |
| Scenarios (optimistic/base/pessimistic) | Scenarios | Each scenario requires deadline, maximumExposure (BigNumber), multiple, profitabilityCDI, profitabilityTIR. All 3 are required to save. |
| Capital / Equity / Result | Company data | Monetary fields normalized via BigNumber before persisting. |
| Bank | Operational | Offering bank account (ICrowfundingBankingAccount); copied on cloning. |
Bank account and payment methods
This is the Bank section of the form and defines how the investor pays the offering. It exists due to regulatory requirement: CVM requires making manual bank account payment available for crowdfunding offerings.
The section has three blocks:
1. Bank account (at top) — the account registered for investor manual payment (TED/PIX). It is required by CVM. Register via Add account (bank, type, branch, account and PIX key). The TED and PIX data displayed to the investor comes from this account.
2. Payment methods (toggles) — control what appears to the investor at checkout:
| Toggle | Field | What it does |
|---|---|---|
| Enable TED | ted | Shows TED data (from registered account above) for manual payment via TED. |
| Enable PIX | pix | Shows PIX data (from registered account above) for manual payment via PIX. |
| Enable Crypto | crypto | Allows payment of the offering via crypto. |
| Capture in USD | isDolar | Captures the offering in dollar. ⚠️ Do not enable — behavior not supported in normal operation. |
3. Integrations (toggles) — enable semi-automated reconciliation of deposits based on account institution:
| Toggle | Field | What it does |
|---|---|---|
| Enable Transfero | transfero_integration | Only valid when deposit account is from Transfero (Genial). Forces the system to fetch their statement to reconcile deposits semi-automatically. Can remove if account is not Transfero. |
| Enable PIX QRcode | dillianz_integration | Enables dynamic PIX QR Code, which allows automatic settlement of payment. (Appeared as "Enable Dillianz" in earlier versions — Dillianz was the automatic QR Code provider; label was renamed to "Enable PIX QRcode" in this redesign.) |
| Enable Banco do Brasil | bank_of_brazil_integration | When the account is from Banco do Brasil, the system fetches BB statement for semi-automatic reconciliation. |
Recommendations by offering type
- Private offerings: Enable PIX, Crypto and PIX QRcode.
- Public offerings: Enable TED, PIX, Crypto and PIX QRcode.
Manual payment and reconciliation
If the investor chooses manual deposit (TED/PIX without dynamic QR Code), reconciliation can be manual — that is why the platform displays the message that payment may take up to 2 days to be confirmed. This message is CVM standard and must be available on the platform for audit purposes. PIX QRcode (dynamic QR) is what enables automatic settlement, without that window.
Offering settings (toggles in General section)
At the end of the General section is a Settings card with six toggles that govern both the storefront (what the investor sees on the public page) and the operational behavior of the offering (date automations, mint, quota value and on-ledger custody). None of these toggles are merely cosmetic — the automation ones trigger real backend jobs.
| Label | Field (ngModel) | What it does (backend effect) | When to use |
|---|---|---|---|
| Enable FAQ | show_faq | Storefront display. Shows the FAQ tab/section on the offering public page. Does not change any fundraising rule. | When the offering has frequently asked questions registered and you want to expose them to the investor. |
| Enable Disclaimer | show_disclaimer | Storefront display. Shows the disclaimer/risk notice on the public page. Does not change any fundraising rule. | Whenever there is regulatory risk warning to display; recommended for public offerings. |
| Fixed value | fixed_value | Checkout behavior. When enabled, the investor does not choose the value: the contribution is validated (BigNumber) to be exactly equal to Minimum contribution (minimumContribution) — any different value is refused at categories.checkout.core.handler. It is a fixed-price quota offering (single ticket). | Offerings where every quota has the same price (e.g., 1 quota = R$ 1,000, no free contribution). |
| Automatic date control | automatic_dates | Automation via scheduler. When enabled, the controlCrowdfunding job starts and closes the offering automatically by dates: when CURRENT_DATE >= startDate and status inactive, becomes active (and provisions XRPL issuer if applicable); when CURRENT_DATE > finalDate and status active, becomes finished. On automatic closing, if tokenization is ready (tokenization_type + network_id, and not yet issued), it calls generateNFTs automatically (idempotent mint — no redeploy). Without this toggle, status transition and mint remain manual. | When you want opening/closing and closing mint to occur automatically on set dates, without operator intervention. |
| Auto-generate NFT on offering closure | automatic_nfts | Intention signaling. The field is persisted (entity/DTO/model), but auto-deploy on closing today is triggered by automatic_dates + ready tokenization in controlCrowdfunding, not by automatic_nfts. That is: for automatic mint on closing, what effectively enables automation is Automatic date control. Treat this toggle as statement of intent "I want automatic NFT" and combine it with automatic_dates; alone it does not trigger mint. | Enable together with Automatic date control when the intent is to issue investor NFTs as soon as the offering closes. Do not rely on it in isolation. |
| Use XRPL Escrow (MPT) | use_xrpl_escrow | On-chain custody. Activates on-ledger escrow on XRPL via MPT (also gated by global feature flag XRPL_ESCROW — both need to be enabled). When activated, opens the XRPL Escrow card to define network (xrpl_network), currency (xrpl_currency) and display issuer (xrpl_issuer_address, read-only with explorer link). Effects: when the offering becomes active, provisions one dedicated XRPL issuer per offering; a scheduler (every 5 min) creates, for each paid contribution, an on-ledger custodied asset until closure; at end, releases to project (success) or performs automatic refund to investor; a daily job (03:00 UTC) burns released IOUs back to issuer (idempotent). | Offerings requiring verifiable on-chain custody of contributions (release to project only on success, guaranteed refund on failure). Requires XRPL_ESCROW feature enabled on tenant. |
Date automation and closing mint
What actually enables automatic status transitions and closing mint is Automatic date control (automatic_dates) + ready tokenization. The Auto-generate NFT toggle (automatic_nfts) is saved, but is not, alone, the trigger for auto-deploy today. For automatic mint on closing, enable both and ensure model/network are defined in the Tokenization tab. Mint follows the rule of mint exclusive to crowdfunding job (see "Business rules").
XRPL Escrow is gated at two levels
use_xrpl_escrow only takes effect if the global feature flag XRPL_ESCROW is also enabled on tenant. With the flag disabled, escrow schedulers are no-op even with the toggle checked. The issuer is one per offering, created when the offering becomes active.
Actions and modals
- Create / Save: opens bottom-sheet confirmation before persisting (message reused from
manageTokens.crud.snackbar). The save button is disabled while required fields are missing (name, dates, benefits and all 3 complete scenarios) — the tooltip lists what is missing. - Clone: navigates to creation with
?copy=true. Clears id/dates and copies company and bank data to the new offering. - Generate tokens (NFTs): opens
CrowdfundingNFTsComponentmodal. No longer asks for network/institution — uses what is in the Tokenization tab. Backend resolvescontract_standard, symbol and category from the offering. Gate: model + network defined. - Payment schedule: opens the payment schedule modal (see Payment Schedule (Crowdfunding)).
- Permissions: navigates to
/crowdfunding-permissions/:id(see Fundraiser Permissions). - 360 view: opens the consolidated view (
/crowdfunding/view-360/:id). - Delete: removes the offering and reloads the page.
360 view
The 360 view (/crowdfunding/view-360/:id) consolidates everything in 5 tabs: Completed orders, Pending orders, NFTs/tokens generated, Holders (summary per holder: quantity + total paid) and Distributions. Shows investor count, total completed and total pending. In fungible model, assetId points to a FMS token (not an NFT asset). Each individual NFT has link to its edit screen.
Business rules / cautions
Attention
- The Campaign group is the only one available on creation; enrich Company/Analysis/Operational only after creating the offering (edit/copy mode).
- Token symbol must be unique — collision triggers key error (
tokens_all_pkey). walletCapturingvalidation is a quality prerequisite: recipient must be APPROVED with wallet.
Irreversible
- Token generation mints on-chain supply from paid orders. No simple rollback; verify model, network and symbol before generating.
- Mint exclusive to job: assets/tokens originated in crowdfunding are minted/burned only by crowdfunding job. TKN_OWNER does not issue or "resell" over these assets, and admin manual allocation also respects the rule. This guarantees by construction the invariant captured value == sum(NFTs × unit price). Secondary P2P transfer between holders remains allowed (the restriction is on creating/destroying supply, not on custody).
- Financial values: all monetary fields (capture, contribution, scenarios, capital) are BigNumber — no rounding; check decimal places.
Examples
Scenario 1 — Regulated NFT-certificate offering (ERC‑3643)
- In General, fill name, dates, target capture R$ 1,000,000, minimum R$ 300,000, minimum contribution R$ 1,000, and validate the wallet capture recipient (APPROVED user).
- In Tokenization, choose Certificate preset → NFT model, regulated, dividends enabled, integer only. Define network and symbol.
- Complete Benefits and all 3 Scenarios; save.
- After fundraising, open Generate tokens — system mints certificate NFTs for those who paid, with
contract_standardERC‑3643 resolved by theregulatedflag.
Scenario 2 — Tradeable fungible token offering (1:1 with currency)
- In Tokenization, Tradeable preset → FUNGIBLE model, regulated, transferable and tradeable, dividends enabled.
- Each R$ contributed becomes 1 unit of token (1:1 allocation, currency-transparent).
- In Generate tokens, the resulting
assetIdpoints to a FMS token. The 360 view lists holders by token balance, not per individual NFT.
Scenario 3 — Import an existing offering (clone)
- In the listing, use Clone on a reference offering.
- The form opens in creation with
?copy=true: id, dates and windows are cleared; company and bank account data are copied. - Adjust name (derived symbol changes) and dates, and save as new offering.